Interruptible gcode commands about duetsoftwareframework HOT 13 CLOSED

It really depends on where you execute the macro file and/or M280. Depending on the code channel, certain codes including M280 are queued for just-in-time execution. If the macro is executed via the HTTP channel (web interface), the code queue is not used which causes M280 to be executed when it is interpreted and not when the move has been finished.

This behaviour is primarily caused by RepRapFirmware and probably not related to DSF itself.

from duetsoftwareframework.

Is this the code queue suppose to be respected if these commands were executed within a user or sys macro? If so, then it’s not behaving as intended.

from duetsoftwareframework.

It does not matter if it is a user or sys macro, it entirely depends on where you execute the macro/code. The code queue is only used on the file print, serial (USB) and Telnet channels AFAIR.

from duetsoftwareframework.

Ok so this is an intended effect on RRF3? As this was not how RRF2 worked.

from duetsoftwareframework.

In this regard there should be no difference between RRFv2 and RRFv3 - the corresponding code was barely modified after RRFv2.

Where do you attempt to execute M280, via the web interface or via a file print?

from duetsoftwareframework.

This was executed from the web interface. More specifically, this was part of the tool change script (ie tpre, tpost, tfree). So for example, in tfree, there is a G1 command that moves the carriage to a specific location, then calls for a M280 to unlock the tool head. Well what happens is: while the carriage is still on the move, before it arrives at the dock, the tool head is unlocked and dropped.

This did not happen in RRF2. In RRF2, M280 occurs sequentially after the G1 move is completed.

from duetsoftwareframework.

The behaviour needs to be changed so that if the command received over the SBC interface was fetched from a file (whether a macro file or a regular print file), the M280 is queued for just-in-time execution. I think it makes sense to do this for all channels when the command is within a macro file. I will implement this change later this week.

from duetsoftwareframework.

Sorry, a little new at the terminology here, can you clarify what you mean by "just-in-time execution"? I assume this means the M280 will be queued and will wait for previous commands to complete?

from duetsoftwareframework.

Yes that is correct.

@dc42 in my RRFv3 branch I added a new function to the GCodeBuffers called IsDoingFile which is true if either a print or macro file is being performed (works both for Duet2+DSF). We could use that for the buffering detection.

from duetsoftwareframework.

I have used IsDoingFile to fix this in RRF 2019-07-02b2. The fix works for the case that the macro file is commanded by the Duet, for example by sending a M98 command from USB. It does not work if the M98 command is sent from the GCode Console of DWC because the fileId member of GCodeMachineState doesn't get set. Does fixing that require a change to DSF?

from duetsoftwareframework.

New RRF binary available at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0

from duetsoftwareframework.

I flashed the new binary, when launching DCS, I get to "connecting to reprapfirmware...." and I get "Error: Duet is not available". Is DCS looking for a particular version? I am pretty sure I have it flashed correctly, did the same thing as I did the first time around.

edit: just reflashed the original firmware, everything is back to normal.

from duetsoftwareframework.

I've changed the latest RRF version to queue codes whenever a file is being executed. If it does not work, feel free to reopen this issue.

from duetsoftwareframework.