Board self-resets during the the print

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord from your M122 report:
=== Platform ===
Last reset 09:00:41 ago, cause: software
Last software reset at 2021-11-21 21:04, reason: OutOfMemory, GCodes spinning, available RAM 648, slot 0
...
Heap OK, handles allocated/used 99/16, heap memory allocated/used/recyclable 2048/342/24, gc cycles 15
The heap usage appears OK but it has already done 15 garbage collection cycles, which is rather a lot. So I think you must be creating variables quite a lot. It may be that there is an error in the garbage collection code. What variables to you create or reassign during a print? Is there a macro that gets called regularly during the print, that creates local variables or changes the value of global ones?

I thought it was somethng related to the garbage collector. During a single color print (like this) I don't read/reassign global variables, during a dual color I read (but not reassign) all the GLOBAL variables setted in the config.g. As I told before, taking off all the Ideamaker "fine tuning" for the gcode and taking off the shoot of the picture for the timelapse in the layer change it all works.
In my opinion the issue should not be related to the Ideamaker "fine tuning" but should be related to the picture shooting. In my layer change gcode I execute a macro wich executes the commands:

; ******************* LAYER CHANGE, TAKE SNAPSHOT **************
M400 ; wait for all movement to complete
M118 P4 S"LAYER CHANGE" ; take a picture

I use a plugin installed on a Raspberry PI, I don't remember its name....

Generally speaking if I have only a script wich needs a variable is it better to declare it as local or global in the config.g? I've declared all the variables as global because I didn't know if a garbage collector runs during the print so I didn't know if the memory space were set free or not after the script closure...

A Former User

@t3p3tony said in Board self-resets during the the print:

@dc42 is it significant that the first error reported on the paneldue was:

Warning: failed to parse response heat:heaters^: in state 12

Originally I was asking this too...I don't think this warning is normal...what could be the cause for this warning to show in the PanelDue console?

dc42

@thedragonlord key "heat:heaters^" looks wrong to me, I think it should be "heat.heaters^". Do you always get this after power up? Do you get it if you press the PanelDue Reset button?

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord key "heat:heaters^" looks wrong to me, I think it should be "heat.heaters^". Do you always get this after power up? Do you get it if you press the PanelDue Reset button?

always

mfs12

@thedragonlord said in Board self-resets during the the print:

@thedragonlord key "heat:heaters^" looks wrong to me, I think it should be "heat.heaters^". Do you always get this after power up? Do you get it if you press the PanelDue Reset button?

there's nothing to worry about. it's just a warning. As there are no successive warning, one transmission failed and then things recovered nicely.

T3P3Tony

@mfs12 is that error coming from the PanelDue requesting a key using the wrong format?

Either way it looks like that is a red herring for the board resets?

mfs12

@T3P3Tony, the key reported is from an internal parsing map, which maps json names to internal data structures. So this data is not send. The warning is reported when an incomplete answer is received or an answer gets corrupted on the way from RRF to PD.

So if transmission would be an real issue it would likely occur more often.

dc42

@thedragonlord you said that the M118 command was processed by a plugin on a RPi. Are you using the regular Duet 2 firmware, or are you using the SBC version with the RPi connected to the Duet via SPI?

Can you run a print (without filament if you like) with the Ideamaker fine turning turned off, to confirm that it is the layer change macro that provokes the out-of-memory error?

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord you said that the M118 command was processed by a plugin on a RPi. Are you using the regular Duet 2 firmware, or are you using the SBC version with the RPi connected to the Duet via SPI?

Can you run a print (without filament if you like) with the Ideamaker fine turning turned off, to confirm that it is the layer change macro that provokes the out-of-memory error?

I confirm...I've disabled the macro the same day I've inserted this post and I've never experienced the issue from then

dc42

@thedragonlord thanks.

Is the whole of the macro file exactly the 3 lines you posted above?
What lines exactly did you have as the layer change script?
If you leave the layer change script in place but comment out the M118 line in the macro, do you still get the out-of-memory error?

The out-of-memory error occurred while RRF was evaluating a string expression, so I don't see how that M118 command that contains only a string constant could have provoked the error.

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord thanks.

Is the whole of the macro file exactly the 3 lines you posted above?

What lines exactly did you have as the layer change script?

If you leave the layer change script in place but comment out the M118 line in the macro, do you still get the out-of-memory error?

The out-of-memory error occurred while RRF was evaluating a string expression, so I don't see how that M118 command that contains only a string constant could have provoked the error.

The 3 lines above are all the content for the macro file and I have disabled all of them. Honestly I haven't tried what you mentioned in the point 3 because the error happened after several hours of print and I don't want to throw away filament and hours for experiments....I've seen that completely disabling the statements the error disappears...I apologize that I can't be more helpful.....

dc42

@thedragonlord was the layer change script configured in Idemaker a single M98 command with a string constant as the P parameter, or something else? Your macro lines give no clue as to why a string operation involving the heap was being performed when the error occurred. So it may be coincidence that the error stopped when you removed the layer change script.

If the printer is free for long enough, you could re-run the print with the layer change script in place but no filament.

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord was the layer change script configured in Idemaker a single M98 command with a string constant as the P parameter, or something else? Your macro lines give no clue as to why a string operation involving the heap was being performed when the error occurred. So it may be coincidence that the error stopped when you removed the layer change script.

If the printer is free for long enough, you could re-run the print with the layer change script in place but no filament.

This is the layer change settings in Ideamaker and theese are the "old" scripts:

take_snapshot_at_layer_change.g
layer_change_actions.g

dc42

@thedragonlord thanks, it's passing the A parameter that allocates the string on the heap. I will run some tests to check that the memory allocated for that parameter is properly released when the macro completes.

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord thanks, it's passing the A parameter that allocates the string on the heap. I will run some tests to check that the memory allocated for that parameter is properly released when the macro completes.

let me know if you'll fix it so I'll give it a try!

dc42

@thedragonlord I've tried running a scripts does 1000 M98 calls with a string parameter, and it has never shown a reduction in available memory except right at the beginning. Same if I run two of them in parallel.

dc42

@thedragonlord is this issue still occurring using RRF 3.4.0rc2?

A Former User

@dc42 said in Board self-resets during the the print:

@thedragonlord is this issue still occurring using RRF 3.4.0rc2?

no

dc42

@thedragonlord thanks, I'll mark it solved.