dave wrote: > On Mon, 2010-05-17 at 20:42 -0500, Jon Elson wrote: > >> John Kasunich wrote: >> >>> The quirks are not with offsets. The problem is "run-from-line". >>> >>> It is evil. Don't do it. >>> >>> Sorry, just had to say that.... IMO RFL is only suitable for >>> very simple programs, I don't trust it to handle subroutines, >>> offsets, etc correctly. >>> >>> We've had the discussion of why a rock-solid RFL is a hard >>> problem about 100 times... >>> >>> >> Ugh, this is bad news. I really hate this bit of having to edit the >> program and reload every time something goes wrong and you have to pick >> up in the middle of a program. >> >> I have had good luck with it on totally linear programs. >> >> Jon >> >> > Maybe this is a gentle hint to stay with linear programs. KISS > has its advantages. > I do a lot of work with a few lines of C to write G code. > Yes it generates lots of lines but to my simple mind an easier way to > go. ;-) > Actually, I think RFL works fine, you just have to understand what happens when you stop a program midway through.
My understanding of run from line is that it does execute the entire program up to the selected line, simply not issuing NML commands for motion or I/O (machine state). (coincidentally, my first commit to EMC was to change the interpreter so it would execute these lines faster) The trouble happens when the program is stopped, not when it's restarted. When you stop a program, you stop both the motion controller and the interpreter, but they don't get stopped in the same place. The interpreter will likely be miles ahead of the motion controller. In a program that depends on existing machine state when it's run (e.g. you touch off G92 before running), and which changes that state (e.g. by issuing G92 commands), the initial state will be different when you restart. Compound that with the fact that what you see - the machines physical position - does not match the interpreter state due to read-ahead, and things can be very confusing. Another point that I think Steve B quoted from the manual - the machine moves to the endpoint of the previous line, and then executes the selected line. In Jon's case, the previous line happened to be a subroutine call. I think that shouldn't matter, and it's a bug if it does. The observation that the program seems to start a few dozen lines away from the selected start point is troubling, and may also indicate a bug. It's possible that this is an observation error though - changes in offsets could make the earlier lines execute in the machine position that the later lines would have. (this is all irrelevant if the display showed the later lines being executed. - Steve ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
