jimre

I would like to greet everyone in the forum! This is my first post. Our UM3 printer is struggling with the issue mentioned in the topic. (It was in service, the Ultimainboard was already replaced, but it didn't solved the problem.) The printing stops randomly after 12-13 hours printing time. The error message is misleading as there is no problem with the printhead. The problem is in the background that the +24V power line is switched off. I've put the printer in developer mode, so I could log in and check the logs while the printer is working and even when it is locked and the LCD screen shows the error message. I see this in the log: Jan 31 04:48:04 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:04,353 INFO transportLayer BUILD:Jan 27 2019 22:52:07 Jan 31 04:48:04 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:04,365 INFO transportLayer Detected board with id #3 Jan 31 04:48:04 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:04,373 INFO transportLayer ADS1015 #0x48 ref.voltage=958 Jan 31 04:48:04 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:04,376 INFO transportLayer Marlin started Jan 31 04:48:24 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:24,399 WARNING transportLayer ProtoError:Sequence number is unexpected (receive d, expected): 73,0 Jan 31 04:48:24 ultimakersystem-ccbdd3007324 python3[931]: 2021-01-31 04:48:24,400 WARNING transportLayer Protocol error from Marlin received, send buffer: [MessageTuple(sequence_number=73, message='M105', callback_function=<function ApplicationLayer.__getIdleCommand.<locals>.<lambda> at 0x9ecae618>, in_planner _buffer=False), MessageTuple(sequence_number=74, message='M105', callback_function=<function ApplicationLayer.__getIdleCommand.<locals>.<lambda> at 0x82b7d46 8>, in_planner_buffer=False), MessageTuple(sequence_number=75, message='M105', callback_function=<function ApplicationLayer.__getIdleCommand.<locals>.<lambda > at 0x82b7ddb0>, in_planner_buffer=False), MessageTuple(sequence_number=76, message='M105', callback_function=<function ApplicationLayer.__getIdleCommand.<l ocals>.<lambda> at 0x82b7d618>, in_planner_buffer=False), MessageTuple(sequence_number=77, message='M105', callback_function=<function ApplicationLayer.__get IdleCommand.<locals>.<lambda> at 0x82b7d3d8>, in_planner_buffer=False)] For me it looks like that the Atmel microcontroller on the Ultimainboard rebooted. The firmware version and the "Marlin started" message indicates that. The next message may be related to this as the Ultimainboard waits for sequence '0' (as it just started) but it gets '73'. The protocol error is probably also related to this that as it might continue in the middle of a GCODE transmission. According to my knowledge when the Atmel2560 (re)starts every pin is set to input. Which is probably also true to the pin controlling the relay switching the +24V supply for the heaters and the stepper motors. So the power for the stepper motors and the heating is switched off by the "reboot". It won't enable them again, only recognize that the temperature of the head drops below the critical limit and I see many "cold extrusion prevented" messages in the log and after a while "waitForHeatableObjectsStep Waiting for hotend-1: 31.0/210.0 °C (wait_tolerance: 0.0, progress: 0.00)" messages are logged until the the Linux rebooted or the griffin service restarted. At that point the LCD displays the error and the printer's user interface stopped. Meanwhile if I ssh into the printer I can send GCODE commands like switch on/off the fan(M106), switch on/off the +24V relay(M80/M81). After switching the +24V back I can home the head (G28 X/Y/Z). There was no response to the temperature commands (M104/109 or M140/190) until I haven't restarted the griffin.printer.service on the Linux. After that the bed temperature can be set and it heated up the bed. If I reboot the Linux everything goes back to normal. For me the background of the original error message is clear, but the reason is completely not. The printer uses the latest 2.1.4 version of the Ultimainboard and the latest version of the firmware (both on Linux and on the Atmel part). I don't think that there is a power interruption as the Olimex board always worked continuously, so the +5V voltage which is needed for both is present. I did not observed any interruption in the SSH connection. The printer stops suddenly during the normal printing. Last time when this error appeared I dismantled the electronics. Resoldered the Atmel on the board and the connector to the printhead, cleaned the contacts on the board and on the head, then put everything back together. It worked without interruption nearly in 7x24 for more than two weeks. Before that "repair" it stopped in a day four times in a row. Around Christmas it was good for two weeks without interruption, but that time I've printed short jobs. Do you have any idea why the Atmel board reboots? Some external reset or a watchdog reset? Any help or suggestion greatly appreciated. Best regards, Imre