PanelDue no longer connecting on Duet3/io0 with 3.01-RC11
-
I did. I was using B57600 to match the default.
I did some more testing, and found an issue, but not sure if it's something that can be "fixed" to work as before. Up until now (with the duet2 I had, and now with the duet3 I currently am running), I would "sniff" the output that fed into an arduino to process the JSON packet to drive some neopixels (my printer is a BLV Cube). It's never been an issue until now. When I pull the connection to the arduino, then switch from say control to console on the paneldue, it will update and then show proper data. When I reconnect the arduino, the paneldue still says idle (aka connected), and the controls still work, but the screen stops showing correct data. I test this by changing the extruder temperature.
Another thing to note, even when it's saying "connecting" and not showing proper info such as temperature, the move commands STILL work, so there's communication TO the paneldue, just the incoming data is affected.
I'm not sure what changed where it no longer can "share" the datastream.
-
Huh, thats interesting; maybe a description or picture to show wiring and length of cables while waiting for the man of the hour?
-
It's fairly simple; the arduino sits about 2 inches from the duet3, and the Rx pin on the arduino connects to the io0.out pin. Length of the single connecting wire is approximately 4in (10.5cm). There's no communication from the arduino to the Duet3.
At some point I was looking at how I can ditch the arduino, now that the duet3 uses a SBC/raspberry pi, but haven't gotten around to that. I'm not up enough on programming to accomplish that. That approach certainly would eliminate this problem.
-
If i have this right...
- The PanelDue works OK in both directions if it's the only thing connected to io0.out.
- The Arduino works correctly if it's the only think connected to io0.out.
- The PanelDue stops getting status updates if the Arduino is connected but can still transmit.
I'd say that io0.out may be having a hard time driving both devices at the same time.
-
Oh, one other thing, io1.out can also be configured as a uart so you may want to use that for the Arduino.
-
@gtj0 I'll clarify.
physical layout used, on a duet2 and current duet3+Pi4, working as intended up until 3.01-RC11
DUET3 connected to paneldue per standard guidelines.
Arduino Rx connected to DUET3 by sharing the io0.out pin.Above works/worked for 3.0/3.01 up to RC10.
With RC11:
Above configuration results in the arduino working as expected, but the paneldue now reporting "connecting" and screen data not being updated. controls on the screen such as move x/y/z work properly. Indicates that Tx from paneldue to DUET3 is functioning, and the issues do not appear to crash the paneldue hardware.
With wire between arduino and io0.out removed, either on powerup or while operating:
Paneldue will now function, after switching screens, such as choosing 'CONSOLE" and moving back. Status will now say "IDLE". Arduino as expected, is not connected, therefore not receiving data and neopixels not reflecting printer status.If wire is connected again, while the printer is still running, Arduino resumes working, and the paneldue now will say "IDLE" but data is no longer being updated. Commands back to the DUET3 continues to work as expected.
If the printer is powered up without the connecting wire attached between the arduino and the DUET3, the paneldue functions as expected.
-
@gtj0 said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
Oh, one other thing, io1.out can also be configured as a uart so you may want to use that for the Arduino.
Would the DUET3 push the json package to io1 without any other input? that's a bit of the problem, short of writing code for the arduino, connecting the Tx to io1.in, and tricking the DUET3 to push the same data that is on io0.out when the paneldue is connected. I experimented with JUST the arduino connected without the paneldue also connected to io0 before, and data does not exist on that port unless the paneldue is causing communication. As you can see my skills on this is limited.
-
-
@Nuramori Oops, I missed your response about not getting updates. I'm not sure but I can try a few things and let you know.
-
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.
-
@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.
-
-
The ultimate goal maybe/would be to negate the arduino entirely and use the Pi4 to drive the neopixels. I am digesting the way that could be done by using the API to pull the same info that is used in the JSON package to the Paneldue.
-
@Nuramori There's a command /opt/dsf/bin/ModelObserver that spits out json as its updated by the Duet. All you have to do is keep reading that.
-
@gtj0 said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
@bearer Maybe if you jumper io0.in to io1.in both ports will get the paneldue commands.
probably, but i think thats what Nuramori was suggesting?
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
sniffing and parsing the JSON package for the time to complete, the bed temp, and the extruder(s) temps.
yeah, you could just send M408 with different S paramters in DWC to see which one returns all you need and have the arduino send that string at regular intervals and keep the parsing code as is.
https://duet3d.dozuki.com/Wiki/Gcode#Section_M408_Report_JSON_style_responseThe Pi route may be easier, if not maybe less reliable until the DSF stuff matures.
-
btw
@gtj0 said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:Oh, one other thing, io1.out can also be configured as a uart so you may want to use that for the Arduino.
@gtj0 said in RRF 3.01-RC11 DSF mode: io_1 not outputting "ok" consistently:
Marlin mode and raw mode on io_1...
M555 P2 M575 P1 B115200 S2was wondering if the typo was io_1 or P1, should be P2? (never mind, saw P2 a bit further up here)
-
@bearer Unfortunately it looks like the uart on io1 is disabled in firmware. So P0 is the USB port, P1 is io0 and P2 returns
Error: M575: parameter 'P' too highMaybe @dc42 can enable it in a future release.
-
I'm always up to trying anything; out of pure curiosity, I am interested in what changed that would prevent both devices from sharing the data on io0.out, when it worked prior to RC11, without any hardware changes.
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
I'm always up to trying anything; out of pure curiosity, I am interested in what changed that would prevent both devices from sharing the data on io0.out, when it worked prior to RC11, without any hardware changes.
I'm guessing there was a drive strength change or something. I can't get to the source code right now but I can check tomorrow if @dc42 hasn't answered by then.
-
