Printer reset detected when connecting with Octoprint about repetier-firmware

[repetier]

First this is no watchdog issue. We have a separate message that exactly mentiones watchdog as reason. It looks more like your board resets with dtr toggle and that seems to happen here. Only thing is that this 1.4 seconds after connect where dtr gets set, which seems a bit slow. But there is also no info with restart reason.

What happens if you disconnect and reconnect without new powering as this might be related?

Regarding decouple that behaviour is not uncommon. When you come from below you start with 100% power, but if you switch within control range for PID you don't and it can take a bit longer to show reaction on direction switch. Have the same on my printer. So either know and cool down more or extend test period as you did.

[GIJ0E]

Thanks for the info about the watchdog and decoupling!

If I leave it powered on, then disconnect and reconnect in octoprint, it gets an error and it will not reconnect. I can retry a few times and it will end up reconnecting. This is a new behavior that I noticed a bit later after I created this issue. Unfortunately I can't tell you what that error message is right now as the printer is at work and unplugged. It will be Tuesday before I can look.
If you have any ideas, I can try them when I'm back at the office.

Thanks for the help!

[repetier]

Not without knowing the error:-)
One question is of course if board resets or not on dtr change. The one not resettings are normally 32 bit boards with native usb support.

[GIJ0E]

Looking at the schematic, dtr is wired to reset.
It's an 8 bit mcu. ATMEGA2560-16AU

https://www.geeetech.com/wiki/images/7/72/GT2560_REVB.pdf

[repetier]

The ATMEGA2560 has no internal usb capabilities so it needs a usb-serial converter and these do add reset on dtr in most cases, e.g. original Arduino Mega 2560 board and all boards based on this design.

[GIJ0E]

Here's the error message when trying to connect.
I basically hit disconnect and reconnect until this came up.
The first 4 connections were successful.
Then the next 2 gave me errors.
Then the last connected successfully.
Here's the error messages from the 2 error attempts and the last successful attempt.

Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Error"
Changing monitoring state from "Error" to "Offline after error"
Unexpected error while connecting to serial port /dev/ttyUSB0, baudrate 250000 from hook default: SerialException: '[Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable' @ comm.py:_open_serial:3699
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Error"
Changing monitoring state from "Error" to "Offline after error"
Unexpected error while connecting to serial port /dev/ttyUSB0, baudrate 250000 from hook default: SerialException: '[Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable' @ comm.py:_open_serial:3699
Connection closed, closing down monitor
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 250000
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6e2c3090, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0125
Recv: start
Send: N0 M110 N0125
Recv: Info:External Reset
Recv: Detected EEPROM version:20
Recv: Free RAM:3520
Recv: SelectExtruder:0
Recv: FlowMultiply:100
Recv: ok
Send: N0 M110 N0125
Changing monitoring state from "Connecting" to "Operational"
Recv: ok
Send: N0 M110 N0125
Recv: ok
Send: N1 M11539
Recv: ok 1
Recv: FIRMWARE_NAME:Repetier_1.0.4 COMPILED:Sep 3 2021 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 REPETIER_PROTOCOL:3
Recv: Cap:PROGRESS:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:HOST_RESCUE:1
Send: N2 M2118
Recv: Cap:EEPROM:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:Z_PROBE:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:1
Recv: Cap:PAUSESTOP:1
Recv: Cap:PREHEAT:1
Recv: Cap:EMERGENCY_PARSER:1
Recv: Printed filament:527.88m Printing time:7 days 6 hours 19 min
Recv: PrinterMode:FFF
Recv: ok 2
Send: N3 M2119
Recv: ok 3
Send: N4 M2021
Recv: ok 4
Recv: Begin file list
Recv: End file list
Send: N5 M155 S2*102
Recv: ok 5
Recv: wait
Recv: T:21.94 /0 B:21.67 /0 B@:0 @:0

[repetier]

Could not exclusively lock port /dev/ttyUSB0

that is the problem. So sounds like the port is already visible and an other software is currently trying to use that port.
Does your linux have modemmanager installed. Not sure about exact spelling of the package, but that package tries to connect the first 20 seconds to any new serial device to check if it is a modem. So that might disturb connection and block the port.

At that stage Octoprint has not even tried to connect - it wants to use the device but fails allocating a unique lock on the driver.

As a test wait 30 seconds after enabling/resetting printer and see if it works directly.

[GIJ0E]

I don't know if there's any other packages that are connecting to the port at this point. This is an octopi image and I would assume any software that could cause connection problems would be removed already.
I do know that I've added a plugin to update the firmware through octoprint, which could connect to the port. However, I don't know if this tries to connect w/o user interaction or not. I'll have to look into that.

My concern with the printer not connecting (the locked port issue) was that it was related to the initial problem where it would reset during a connection because it received the start response twice. It appears that the failure to connect problem is octoprint related and not firmware related. As it's a minimal occurrence and doesn't appear to be related to my firmware build, I'm not too worried about it right now.

As you mentioned that this is not watchdog related and it could be caused by the dtr reset. How would I go about testing this and why would adding the watchdog timer reset line cause the problem to go away?

[repetier]

why would adding the watchdog timer reset line cause the problem to go away?

What do you mean with that?

Normally as long as this problem only happens during connect I would not be too worried. Connection is a critical time and sometimes gets disturbed by power issues, rest signals, initialization problems (like when you have a due and eeprom can not get read it would trigger watchdog if enabled or hang forever). But once you are connect for lets say 10 seconds you should get no further hicups or something is really wrong.

[GIJ0E]

why would adding the watchdog timer reset line cause the problem to go away?

What do you mean with that?

With my initial post, I mentioned that when the printer first connected to octoprint, the printer would run what appears to be the whole Printer::setup() routine twice. During that routine, it sends the "start" message to octoprint. Octoprint saw this message twice and gave me the error "Printer reset detected".

This was a new error that only started after I only changed the EXT0_DECOUPLE_TEST_PERIOD time to 30000 and re-compiled the firmware. No other changes were made and this was the same firmware source code that I had been using without the "Printer reset detected" error before then.

Adding HAL::pingWatchdog(); before it starts the watchdog timer fixed the "Printer reset detected" problem. It no longer ran the Printer::setup() routine twice, only once now. Everything appears to be starting normal, except the occasional port locked error.

You had asked...

What happens if you disconnect and reconnect without new powering as this might be related?

This is when I explained the occasional octoprint error that the port is locked, which doesn't appear to be firmware related and it must be a coincidence that I saw that message during all of this troubleshooting.

If this isn't a watchdog timer problem and it's a dtr/reset problem, how would resetting the watchdog fix the problem of it running the Printer::setup() routine twice when connecting?

I hope this explanation helped.

[repetier]

Ok, I see these are 2 different problems and I was only thinking about one problem.

Strange that this makes a difference if you add ping especially since it does not reset watchdog but only an internal flag that otherwise temperature method calls or sd card init. So this might increase time to watchdog, but why should it need higher value then previously? And why is there no message about watchdog trigger. Strange thing, but leaving it in does no harm so if it helps leave it. It is then most likely a watchdog problem.

[GIJ0E]

My apologies for the confusion. I was just trying to give all of the details.

I just wanted to make sure that it didn't cause some other issue with it in there.

Thanks for the help!!

[repetier]

No setting it true at setup makes no difference to logic, just resets watchdog counter earlier the first time.