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

tenaja

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

@tenaja said in Ways to ensure gcode within trigger is uninturupted?:

You will note that at the "top", I disable the triggers, then run another program, then re-enable the triggers.

From the M581 docs:

Polling for further trigger conditions is suspended until the trigger macro file has been completed.

Did you verify that your trigger could be re-triggered while is was executing?

Frederick

I am not sure if you got your answer to this, but the word "suspended" in the sentence above could be rewritten "queued for later execution". That is why I disabled them--if you press the button several times during a macro execution, it stores up the number of button presses, and runs them upon completion. This was catastrophic in my application.

DocTrucker

@tenaja interesting. I hadn't read it like that. The errors I saw were definately commands from the main build file getting interleaved with the gcode contained in the trigger file and any associated pause or resume scripts.

As of yet no one from duet3D has even confirmed if this is a bug yet...

o_lampe

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

if you press the button several times during a macro execution, it stores up the number of button presses, and runs them upon completion.

I asked @dc42 lately, if the triggers needed to be 'debounced' but he said, that the first trigger would lock the input until the macro is finished. Hard to believe, they count up while the macro is running? (another bug?)

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.