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

DocTrucker

Yesterday I tried re-arranging the code so that the triggers executed a tool change rather than a dynamic tool change. This isn't my preferred way of doing this as I can't seem to command independent extrusion axis moves when one 'extruder' is on T0, and the other on T1. Another barrier against this method is the lack of being able to drive an extrusion axis to a limit switch. While I appreciate this wouldn't be used by many it seems odd that it's not there as this either suggests the axes aren't sharing a base module of functions, or that the home function on the E axis has been coded out. For me the solution is conditional gcode and defining what was limit switches as inputs 2 & 3.

So using the conditional gcode to run a home routine looks like:

T0
var attempts = 0
while var.attempts < 1000
    if sensors.gpIn[2].value != 1
        G1 E-0.1 F400
    set var.attempts = var.attempts + 1
G1 E5 F800

But this has drawbacks:

Sounds rough. This suggests that the motion controller is executing a start/stop on each G1 move and running the check when stopped.
Slower to respond. Not sure why this is but you can see the syringes driving had onto the limit switch. How can this be queuing gcode and still checking after each 0.1mm? You can hear the switch click in the videos.

So the main objective of running these tests was to demonstrate that the use of dynamic drive re-assignment was not upsetting an interlock that normally protects the contents of triggers.

Spoiler: tool change behaves in a similarly chaotic manner. This does however have implications for conditional gcode. If this overlapping of build and macros occurs in other areas to then whatever condition you are checking for - in for example an if statement - could have changed before the indented statement code executes. I think this is what is occurring when the conditional gcode homing routine is executed that fails at the end of test 2.

Test 1:

Using tool changes instead of dynamic drive re-assignment. Using M24/M25 and M300 peeps to indicate when the system is processing the triggers.

Largely behaved as before aside from one glitch which may be a false trigger on the switch input.

Video: https://youtu.be/dTjPfLtTX9I
System directory zip: https://www.dropbox.com/s/fd2imu1so6vzcbp/210329_01_Pauses.zip?dl=0

Test 2:

As above but without the pauses. Things go wonky very quickly·

Video: https://youtu.be/FUZJCz39Iro
System directory zip: https://www.dropbox.com/s/ynokr33cyow68fb/210329_02_NoPauses.zip?dl=0

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.