Problem with M28 and M29

[darookee]

I use the filament management feature's load script to write the call to a macro that contains the settings for the material I loaded to the file /sys/current_material.g, which gets called from config.g and before every print (just to be sure it realy is set…). This worked without problems in 1.19 but after upgrading to 1.20b1 it stopped and is not working in 1.20RC1. The load.g for PETG looks like this:

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

When running this macro, either manually or from the filament change I get this output:

M98 P0:/macros/test-m28
Writing to file: /sys/current_material.g
GCode end-of-file being interpreted.

and the file stays empty. It looks like the M29 is not executed, because after running that script no command gets executed anymore and I have to powercycle the Duet

Edit: adding this in regard of my suspicion, when sensind 'M29 /sys/current_material.g' through the GCode-Console I get a green line in the log console saying 'M29 /sys/current_material.g' but the printer is still unusable

[dc42]

Please clarify:

• Are those 3 commands in the SD card file that you are printing, or somewhere else?
• Are you trying to write the line "M98 P/macros/Settings/PETG" into file /sys/current_material.g ?

[darookee]

Sorry for that mess of a sentence

• The three commands (M28…) are in /filaments/PETG/load.g
• Yes, that's the line that I want in /sys/current_material.g

I just tried the commands from the GCode-Console getting the same result. After sending M28 /... the printer does not respond (as expected, because everything should be written to the file) but sending M29 /... has no effect, probably just gets added to the buffer.
I also searched the source for 'GCode end-of-file being interpreted.' and found it in src/GCodes/GCodes2.c:735 with a comment saying 'should be intercepted before getting here'

[dc42]

Thanks, I'll test M29 in 1.20RC1. You don't need to repeat the filename in the M29 command.

EDIT: I found a likely bug in M29 handling, will fix it in RC2.

[darookee]

Thanks!

I had the M29 without the filename and thought that was the reason for it not working so I changed it, as the RepRap-Wiki also shows the example with the filename.