Filament load macro writing to file in /sys

wilriker

Basically I have the same problem that is described in the linked issue. I am running 2.0RTOS build.

I set

M28 /sys/current_material.g
M98 P/macros/Settings/PETG
M29

as load.g of one of my defined filaments (unload.g is empty) and expect that when I load this filament that it will write the middle line to the file defined by the M28 command.

This works sometimes (it seems rather random) but most of the time it either freezes because it wants to write all following GCODE to this file and I can sometimes break out of this by manually sending either M29 or M999 but it is not reliable which one of these two in what order will finally stop writing to the file.
Sometimes it actually evaluates the M98 command instead of writing it into the file.

I have a feeling that these commands are not run in the correct order.

dc42

I have added this to my list of issues to investigate.

Is there any chance that two M28/M29 command pairs are being executed concurrently from different input sources? I can see that the M28/M29 code was written originally to support only one file upload at a time, and it hasn't been updated to support multiple concurrent uploads.

wilriker

@dc42 said in Filament load macro writing to file in /sys:

Is there any chance that two M28/M29 command pairs are being executed concurrently from different input sources?

I don't think so. When I run M999 so the board is freshly booted and then load/change filament the problem will also happen. At least I definitely have no active upload at that time. I don't know what DWC might be doing in the background.

dc42

I have just been looking into this. I created a macro containing this:

M28 /sys/current_material.g
M98 P/sys/homedelta.g
M29
; a comment
M906

When I run the macro, it does the same thing every time. Instead of writing the line "M98 P/sys/homedelta.g" to current_material.g, it writes the contents of homedelta.g to that file, and it also executes homedelta.g. If I change homedelta.g to a name that is not present, I get a message saying that the file was not found.

If I send the same lines one at a time via the command line, then it works as expected.

I conclude that M28 does not work correctly when run from within a macro, because it executes the following lines as well as saving them to file. I intend to fix this in the next 2.01beta.

wilriker

@dc42 Thanks for checking. Looking forward for a fix.

wilriker

Just for reference: Confirm fixed in RRF 2.01 final.