When I spoke of motion I meant linuxcnc's motion component. I'm sure you know your gcode if that's how you make your living :)
>For example: I use a tool in two different situations and in the second part I >use the same tool with different spindle speed and different motion feed. >So it's obvious, that I code a S-Word standalone between different motion >commands. >No matter what the motion planner or optimizer does with the motion >command, the spindle is not allowed to change speed at any other place than >coded. I preferred my fcode example because I am familiar with it, but looking in emccannon, there is a message: emc_spindle_speed_msg for setting the so yes it is 1:1 with the gcode in linuxcnc. A process timer as you described, there should not be any principal problem -it would be done in motion side. I was thinking to add a counter to M2 or better yet a way to run a script at the end of a program. I saw the counter from HAAS controller description. Oh and I would like to fix block delete to work in program.... Chris ________________________________ From: Reinhard <reinha...@schwarzrot-design.de> Sent: March 26, 2020 4:00 PM To: EMC developers <emc-developers@lists.sourceforge.net> Subject: Re: [Emc-developers] ask for help Hi Chris, nice to read you :) > You have picked some tough items to fix. > The reason the line number doesn't follow the action 1:1, is because the > gcode and motion commands don't correspond 1:1 Well, that's true and not true ;) Of cause, there is a lot of gcode, which is not motion code. But - its related to the last and/or next gcode. I'm working on a pretty old mill (mori seiki from early 90th) with a 0-series fanuc controller software, which is pretty simple and has plenty of bugs. Anyway - I love my work and I'm used to code GCode, as I receive a drawing and have to code right on the machine and manage the milling (dirty hacks - fire and forget like) - I mostly work on very small series or single pieces. Lots of coding, less machining. So I think I've a pretty good understanding of gcode and their relation to motion. What I don't have is the knowledge of linuxcnc. I know simple equivalents from 3D-printing and the like. > When you start the cycle, the gcode get interpreted into motion commands and > put in a list. This is done as fast as possible and has nothing to do with > actual movement, the list will get way ahead of movement. Sure! Motion planner and optimizer has to do their jobs. > In the process of interpreting, the motion commands loses 1:1 reference to > gcode line in some cases That's a point, I don't understand. For example: I use a tool in two different situations and in the second part I use the same tool with different spindle speed and different motion feed. So it's obvious, that I code a S-Word standalone between different motion commands. No matter what the motion planner or optimizer does with the motion command, the spindle is not allowed to change speed at any other place than coded. Same is true for M7/M8 or even more important M0 > In my branch's case I send an fcode message to motion and motion does > nothing but send it back as status. It's a ton of code to do this one > little status. > I believe statetags works on the same principle, just in a more general way. Chris, I'm very happy, that you work on that corner of lc. Would like to get closer to your work. > So it's not that your (or any other) GUI is broken, it's the information > currently is not available. Well, I never thought, that my gui is broken :D I'm confident, that it does what I coded. I know, that the status information does not offer, what I'm looking for. But as any professional controller shows this information, I'd like to help improve lc to become more professional. > I assume by process time you mean estimation of gcode running? No! I don't care about estimations. The valuable time information is the time, of tool usage and time, that processing of gcode has consumed. In my fantasy: just a timer that runs as long as gcode processing is active and pauses at M0 or the like and resumes after user continue action. Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
