Roland <[EMAIL PROTECTED]> wrote: > I don't understand why(conceptually) this is so hard to do. > Notwithstanding that servo loops are involved in generating > the steps, at the end of the day, a step sequence(presume > steppers) is being sent out at the parport. If this sequence > was sent to logging file, surely it could be run back or forth. > At this stage, it's simply a step matrix, maybe a spooling > buffer of 1000 x3axis steps. In the application of wire EDM, > you probably only want to extract the wire, so stepping back > at a slowish rate would be acceptable? The GUI might reflect > 'steps' rather than g-code for this function, but this may be > acceptable. > > In use, one might 'pause' the machine, and step back, for > whatever reason, then fowards again to '0', then resume the > program code. Reasonable?
What you are describing has absolutely nothing to do with what the original posted asked about. The original poster wanted to be able to step backwards line-by-line through the G-code program. Implied in there was the ability to step back through the entire program. What you are describing is far simpler, but also far more limited. Yes, it would not be outrageously hard to buffer a few seconds of motion, pause EMC (using feedhold for instance), and back up thru that buffer. But you could not back up to a specific point in the g-code, such as the beginning of a certain line or arc, because the motion you are buffering is at a much lower level than the g-code. You have no idea where you are in the g-code at that level. The distance you could back up would also be strictly limited by the size of the buffer. A simple implementation could handle several seconds, maybe even a few tens of seconds, but much more than that would get very complex. The buffer and replay functions need to be hard realtime code, and that code cannot access huge amounts of memory or any disk space. Memory usage for such a system would be in the neighborhood of a megabyte per minute. Not much for modern PC RAM, and almost nothing on disk, but for kernel space realtime code, that is a lot. There might be applications (such s EDM) where your approach is quite practical. But it is not a suitable answer for the question that started this thread. Regards, John Kasunich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
