Bug: Gcode within trigger is interleaved with later build gcode?

o_lampe

@DocTrucker
I call such locking mechanism 'semaphores'. It could be as simple as a boolean variable like 'extruder(0).available'. If your trigger macro needs exclusive access to extruder(0) it would set the variable to false and the print queue would stop (unless it contains commands not related to the locked resources) until the macro is finished and 'available' is true again.
M116 is a good example for an existing 'blocker'. Maybe it can be used for other things than temperatures?
(eg. M116 E0.endstop)
I'm not familiar with all the object variables, I made up the variable name above. But that way, it could be implemented,

DocTrucker

@o_lampe yeah, semaphores, interlocks, interpretor locks. Different languages have their pet names for them. I've gone so far as manually coding them using the existance of files in the file system to sycronise multiple processes. Multithread and multiprocess issues easily gave me the biggest headaches when I was doing lots of code.

DocTrucker

@o_lampe funny that, I was thinking about de-bouncing. I use makerbot style mechanical limits for simplicity, but strip all the surface mounts off to be able to use the normally closed part if the switch. I had considered taking a closer look to see if there was an electronic implementation of debounce with the cap/resistor and if I could be more selective in thw removal of parts and still have that.

That said I'm not sure if that us an issue or not. I will run one of the tests with disabling the interlock as the first, and resuming it as the last action at some point.

DocTrucker

@dc42 @droftarts @T3P3Tony @Phaedrux Can one of you confirm if the interleaving of trigger/build code is a bug please? Not had any official confirmation in that yet.

dc42

@DocTrucker, it's normal for commands from multiple GCode streams to be interleaved. However, if the movement system is locked because of a command in a macro file (including a trigger), it will remain locked until either the macro completes, or user input is requested via M291. So if you include M400 near the start of your macro, then the machine will compete any moves already queued and then run the rest of the macro without any movement commands from the file being printed.

I will look into adding a parameter to M24 and M25 to allow the pause and resume macro files to be skipped.

DocTrucker

@dc42 Thanks for the conformation. Appears I burnt a weeks work there needlessly. Look forward to the skip pause/resume gcode flags.

Tried M400. It is not suitable as it causes a large overrun on the limit switch placing too much reliance on the gcode pre-parse which I like to keep largely machine independent where possible.

dc42

OK, I've looked at adding a P0 parameter to M24, M25 and M226 to prevent pause.g /resume/g running, and it appears fairly straightforward. I'll try to squeeze it into the 3.3beta3 release.

DocTrucker

@dc42 Great. What's the most effective way to find the current beta release? I can go a week without checking the forum and miss when a thread is most popular. The 3.3beta2 doesn't appear to be pinned to the top of the 'Beta Firmware' category.

dc42

@doctrucker said in Bug: Gcode within trigger is interleaved with later build gcode?:

@dc42 Great. What's the most effective way to find the current beta release? I can go a week without checking the forum and miss when a thread is most popular. The 3.3beta2 doesn't appear to be pinned to the top of the 'Beta Firmware' category.

Look at the Releases page on github, https://github.com/Duet3D/RepRapFirmware/releases.

DocTrucker

@dc42 Thanks.