Leslie Newell wrote: >I think a bidirectional jog would be a nice feature. I am thinking of >doing a crude version of this on my lathe. In jog wheel mode the FRO >would be tied into the velocity output of an MPG. The faster you turn >the handle, the faster the code is executed. Stop turning and the >machine stops. Great for proof testing new code. > > Yep. That's what I was talking about, even though Stuart wasn't :)
>One option would be to generate a 'pre-digested' intermediate file. This > contains all of the moves after tool compensation, executed code loops >and any other fancy stuff. It would basically just contain simple linear >moves, arc moves and triggers for spindle, coolant, I/Os etc. It would >be easy to design this format so that it can be read in either >direction. This file is then fed to the TP to generate movement. I >actually do something similar in SheetCam. The offsets are generated >then the cut paths are calculated from the offsets, in whatever >direction is needed. > > The only thing left out of this is machine state. This could be done with checkpointing of some sort >I think that would be a lot easier than trying to interpret the G-code >backwards, especially when you take code loops and subroutines into >account. The only disadvantage is that you would get a delay when you >load a G-code file as the whole intermediate file (or at least a >significant portion of it) has to be generated before movement can >start. For small files the time would be insignificant but it may be an >issue for multi megabyte 3D contouring code. > > This is more or less done on the fly in EMC2, since the interpreter issues CANON calls for all motion and machine control functions. It seems that it should be possible to "tee" those calls, send one copy to a log file and the other to motion. If you get a backup command, you go back through the log file. Once you jog forward to the last-started motion, you continue with the queued commands. There are still issues with this though, if we're talking about jogging through "motion" as opposed to "moves". Jogging within a move would require the ability to go forward and backward in "pseudo-time". Arcs could be handled as long as the center is always specified in absolute coordinates (meaning "not relative to the current location", the opposite of ijk arcs). Additionally, blending may give different shapes at different velocities. Jog through a program slowly and you'll have nice sharp corners. Jog quickly and you'll get rounded ones. Which should be queued, the lines and the arc blend or just the two lines? So many details, so little time :) - Steve ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
