PanelDue no longer connecting on Duet3/io0 with 3.01-RC11
-
@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.
-
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
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.
Interesting. I wasn't aware that something like that was controllable through software. Thanks for the help @gtj0 .
Yeah on most "microcontroller" platforms, including the ones on the Duets, Pis and other SBCs, many pins are general purpose and have their function (uart, GPIO, SPI, etc) and capabilities (input, output, both, drive strength, pull up/pull down, tristate, etc) controlled from software.
-
couldn't spot any changes to low level functions, just some conditional logic around the higher level initilization.
https://github.com/dc42/RepRapFirmware/commit/6f912e9ca47930d7b91d504c0e9c8be31251284a#diff-52cb419324e9c23a2e2c5a269e0e70fcR3581 -
Could it be this?
setPullup(APIN_Serial0_RXD, true);
I didn’t see anywhere else where the pull-up resistor is used/set in the old code, could the setting the pull-up affect the signal enough that it “dies” enough in signal strength for two electrical connections to be too much for the paneldue circuitry?
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
setPullup(APIN_Serial0_RXD, true);
click the beginning of the line and choose "git blame" to see when it was changed. (if viewed on github, otherwise git cli works as well)
i'm guessing its part of the other repositories then
-
@Nuramori said in PanelDue no longer connecting on Duet3/io0 with 3.01-RC11:
Could it be this?
setPullup(APIN_Serial0_RXD, true);
I didn’t see anywhere else where the pull-up resistor is used/set in the old code, could the setting the pull-up affect the signal enough that it “dies” enough in signal strength for two electrical connections to be too much for the paneldue circuitry?
Absolutely!
I just did a build without the pullup. See this helps...
http://dueui.org/download/Duet3Firmware_MB6HC.bin -
@bearer It was new in the last 2 commits.
-
(for CoreNG, ofc, my bad)
-
@gtj0 I downloaded the file, pushed it to the printer, and performed a "M997 S0"
Result was :
Error: Operation failed (Reason: ArgumentNullException in SimpleCode: Value cannot be null. (Parameter 'input'))
