Filament load macro writing to file in /sys
Basically I have the same problem that is described in the linked issue. I am running 2.0RTOS build.
M28 /sys/current_material.g M98 P/macros/Settings/PETG M29
load.gof one of my defined filaments (
unload.gis empty) and expect that when I load this filament that it will write the middle line to the file defined by the
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
M999but it is not reliable which one of these two in what order will finally stop writing to the file.
Sometimes it actually evaluates the
M98command instead of writing it into the file.
I have a feeling that these commands are not run in the correct order.
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.
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
M999so 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.
I have just been looking into this. I created a macro containing this:
; a comment
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.
@dc42 Thanks for checking. Looking forward for a fix.
Just for reference: Confirm fixed in RRF 2.01 final.