Board self-resets during the the print

A Former User

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

@thedragonlord could be linked to the amount of variables you are using.
@dc42 will have to comment

ok, I'll wait @dc42 but I'm afraid it's something gcode related because printing the same gcode I have the same issue at the same height...the stragest thing is that the gcode is a simple box with only a 2 perimeters thick wall...

jay_s_uk

@thedragonlord you may want to upload the gcode just in case

A Former User

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

@thedragonlord you may want to upload the gcode just in case

I've modified it to take off all the "extra" extrusions, the thin wall check etc to see if that were the issued and now it's printing...in few minutes it will reach the "crtical" heigth, if it will resets again I'll post the gcode...

A Former User

This post is deleted!

gloomyandy

@thedragonlord Do you have a daemon.g file? If so you should probably upload it for DC42 to take a look at.

A Former User

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

@thedragonlord Do you have a daemon.g file? If so you should probably upload it for DC42 to take a look at.

here it is:

daemon.g

; Check for safe temperature reaching
if {global.isPrinting == true && state.status == "idle" && heat.heaters[1].current < global.toolsSafeTemperature && heat.heaters[2].current < global.toolsSafeTemperature}
   M118 P0 S"Safe temperature reached, turn off the printer" L2
   set global.isPrinting = false

A Former User

@thedragonlord I've rebuild the gcode taking off the unnecessary retractions, the thin wall check and taking off the snapshot at layer change and the print has completed normally....so the "guilty" could be the taking of the snapshot or the Ideamaker "fine-tuning" of the GCODE....

dc42

@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?

T3P3Tony

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

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

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.....