PanelDue no longer connecting on Duet3/io0 with 3.01-RC11
-
I thought I might throw this in here, not to conflate the issue with another, but it’s somewhat related (if only because it was affected by the same port).
The other week when there was an update that included an update to the paneldue firmware (iirc it was RC-8?), I could not get the paneldue to communicate with Bossa at all. It finally worked, and I could flash the new version 1.24 after I physically disconnected the paneldue from the io0 connector. While plugged into io0, whether the duet3 was powered up or not during the attempt, the paneldue could not be flashed.
I’m not sure it’s even related or a coincidence, but I thought I’d mention it.
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
@bearer said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
The Arduino would have to send M408 S0 or S1 depending on how much of the data it needs to update to work independent of the PanelDue.
The arduino code is basically sniffing and parsing the JSON package for the time to complete, the bed temp, and the extruder(s) temps. That info is then graphically represented via driven neopixel rings.
How complicated is the code that translates the temperatures into neopixel colours? Perhaps you could connect the neopixels directly to the Duet 3 and use the daemon.g file to update the colours.
-
There are three distinct neopixel rings, one for each data point (bed temp, extruder temp, and time of print).
I’m still stumped why, from the code changes in RC-11 I saw, why there would be an issue with the paneldue.
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
The other week when there was an update that included an update to the paneldue firmware (iirc it was RC-8?), I could not get the paneldue to communicate with Bossa at all. It finally worked, and I could flash the new version 1.24 after I physically disconnected the paneldue from the io0 connector. While plugged into io0, whether the duet3 was powered up or not during the attempt, the paneldue could not be flashed.
That can happen because the SAM4 chip in PanelDue v3 accepts programming from either the USB port or the serial port. So if it sees traffic on the serial port, that can stop it responding to the USB port. We planned to support PanelDue firmware updates from the Duet via the serial port, but we haven't found time to write this functionality yet.
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
I’m still stumped why, from the code changes in RC-11 I saw, why there would be an issue with the paneldue.
So am I. The only significant difference should be that the pins don't get initialised as a serial port until the M575 command is executed.
-
I decided to just avoid the issue by reprogramming the arduino (Adafruit Metro Mini) to create and use a soft serial port, and poll a different digital pin instead. I'm suspecting that there's something odd about the Rx pin on that board, since it also shares the built-in USB comms with that UART pin. The documentation says I can use it as a normal UART Rx, but hmmmmm......
I recoded it, and now everything is working. Thanks for the input, I hope I didn't waste anyone's time (too much).
-
I've put new internal builds of RRF at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. In these builds the M575 command is mandatory when using PanelDue, even on the Duet WiFi/Ethernet/Maestro; however it is no longer necessary to repeat the command when changing the baud rate.
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
I decided to just avoid the issue by reprogramming the arduino (Adafruit Metro Mini) to create and use a soft serial port, and poll a different digital pin instead. I'm suspecting that there's something odd about the Rx pin on that board, since it also shares the built-in USB comms with that UART pin. The documentation says I can use it as a normal UART Rx, but hmmmmm......
I recoded it, and now everything is working. Thanks for the input, I hope I didn't waste anyone's time (too much).
Yay! No time wasted but yeah, I got my directions mixed up with the setPullup. It was late (for me anyway).
