Hi Chris, obviously I used the wrong file for most tests :(
On Samstag, 28. März 2020, 17:40:40 CEST Chris Morley wrote: > If you run a long program with a different feedrate at the end, (I use a > modified 3dchips.ngc) then watch the f code say on AXIS, you'll see it > changes to the last feed rate way too soon. It's because it's status of the > interpreter state, which is not synced with motion. Yepp. Did not realize it, may be caused by M1 or tool changes. Now I added few FCodes to 3Dchips.ngc and used axis singlestep ... Things are even worse, than already realized. First singlestep stops at line 21, which might be ok, if you accept, that lc takes only motion commands into accout. Next step ist line 22 ... ok ... but third single step advances to line 29, which is not ok. Lines 23-28 all contain motion commands, so LC skips these lines, for whatever reason. Continuing with single steps shows, that behaviour of LC is unpredictable :( Starting with singlestep changes feedback from motion. It does not report all motion commands in advance, only their line numbers. That could be helpful for big 3D Surface jobs. F-Code is wrong, as you already noted. Even at first singlestep the Feed is set to the last F-Code from file. So there is no delay and result is absolutely wrong. Glad you're already working on that problem :) I noted a bug in single step processing in my app - so have to fix that first. Cheers Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers