Abort instruction executed before reaching it's code line

Hello everybody,

I have a subroutine that executes a bar feeding operation at the end of my programs. I use a global parameter that stores the bar lenght in the machine, the subroutine updates this variable after each execution. At the beggining of the subroutine, I have an "if" conditional that checks that the bar lenght is enough to make the next part, otherwise aborts the program.

Sometimes, not allways, when the bar is short enough to activate the conditional, the abort instruction is activated before reaching it's line of code, before executing the parting operation in the program (and just the parting is 700 lines of code).

My understanding is that since the interpreter reads the Gcode ahead of it's execution, it might be executing the abort at that reading. But this would cause the program to fail each time, not just sometimes. ¿Is there a way to force sync the interpreter reading with the Gcode execution to avoid this issue?

Regards.

I wonder if adding a queue buster line in the sub or main would force LCNC to stop and process the parameter calc.

Just out of curiosity, you run the bar load/change sequence at the end of your main programs?  My (non-LCNC) bar pull logic is at the beginning of each program; if you've tried both ways do you find an advantage having it at the end?

I would think the 'if' statement should cause a queue buster.
i don't know how to check this though.

Yea, I guess I didn't read the OP's sequence closely... the IF statement is at the beginning.

This is one of those times where having a real-time display of parameter values would be helpful.
 

Thanks for the idea of the queue buster line. It was what I was looking for but didn't knew the name. So I have been searching about the queue busters and found this old but interesting page:

LinuxCNC Documentation Wiki: QueuebustersRevisited

Seems that reading the system parameters does not case a queue buster (the "it" statement neither cause it). If something changes one of those parameters in between the interpreter read the parameter and the machine does it's movements that can be problematic as they will be wrong. It think it will be usefull to the users to get it clear in basic documentation.

So I have added a fake touch probe movement, then I read the #5070 (touch probe result) parameter in an "if" and perform all the bar feeding operation inside the conditional. Might not be very elegant, but does the job. Probably the best way would be to create a sync Mcode.

Andypugh, I'm aware of the #<_task> parameter since it did bite me on the past and you helped me solve the problem. According to the documentation you show it does only affect while loading the code for the preview. Just to check I have tried to use it to solve this issue but did not work.

Spumco, I run the bar feeding at the end so I have the machine ready for the next time I go. Could be at the beggining but I don't see any advantage or disadvantage. My main program has a repeat subroutine that runs the whole thing several times, so not sure if feeding at the beggining would solve the issue. The queue buster works great so I'm happy with it.

Thank you all for your help!

Good to hear you've got it sorted out, and thank you for the explanation.

And if it works that well, you might consider posting a 'vanillia' flavored version of the subroutine & example main program as an example for others to use in the Lathe Library.  "Barfeeder Example" or similar would be a nice searchable title...