M300 S and P swapped as played back in ~~RFF3 and/or DWC2~~ DSF
-
@dc42 sorry to bug you, but could you chime in on if/how to isolate the issue to RFF or DWC? Seems I cannot use the PanelDue with the v0.5 board.
I've tried connecting
/dev/ttyUSB0
to/dev/ttyACM0
withsocat
*, but seems whateverM575 Pn S1
I try the only thing i achieve is that withP0 Sn
then/dev/ttyAMC0
stops working locally on Pi, even if I replay PanelDue messages with or without checksum. IO_0 doesnt seem work with any combination ofM575
(presuablyP1 S1
would be correct if supported?)*) variations on
socat /dev/ttyUSB0,raw,echo=0,crnl /dev/ttyACM0,raw,echo=0,crnl
-
Never mind, got lucky in the code dive. Its DSF.
https://github.com/chrishamm/DuetSoftwareFramework/issues/92 -
A PanelDue should work with a Duet 3 0.5 board if you connect it to the IO_7 connector.
Please note, we are withdrawing support for the Duet 3 V0.5 prototype boards. You will need to get a v0.6 or V1.0 board to use future firmware versions.
-
Right you are (ofcourse). I'll see if I can make sense of the timing issues as well with the help of the PanelDue. Out of interest where would I be able to find that information myself?
Re, future support, yeah, as expected. Will see what I can pull off:)
-
@bearer said in M300 S and P swapped as played back in
RFF3 and/or DWC2DSF:Right you are (ofcourse). I'll see if I can make sense of the timing issues as well with the help of the PanelDue. Out of interest where would I be able to find that information myself?
Which timing issues?
-
@dc42 said in M300 S and P swapped as played back in
RFF3 and/or DWC2DSF:Which timing issues?
Tried adding some beeps to the homing sequence. Which revealed duration and frequency were swapped around in DSF and the playback is not timed to the movement, nor consistent. Some sounds get skipped, some get played all together at the end of the homing macro.
So I figured I'd borrow the Maestro's PanelDue and see if different.
IO7.in
toDout
and so on, no luck. But spoke too soon, no dice on the Duet3 - PanelDue. Tested the rest of the IO ports to no avail. Can see theN0 M408 S0 R0*46
from the PanelDue, but no response on the serial lines.I did notice an issue relating to random G1 moves out of order so coud be that I'm seeing. Although the homing sequence did behave as expected methinks.
On the other hand its as good a place as any to draw a line, no point in chasing bugs that may be isolated to the specific board. Anyways, thanks for help as always!
-
Did get PanelDue sort of working with socat, but the beep message isn't sent to serial nor CodeConsole so for this usecase not helpfull.
However:
pi@duet3:/opt/dsf/sd/sys $ socat -d -d /dev/ttyUSB0,raw,echo=0,b57600 /dev/ttyACM0,raw,echo=0,b115200 2019/12/29 21:40:39 socat[5875] N opening character device "/dev/ttyUSB0" for reading and writing 2019/12/29 21:40:39 socat[5875] N opening character device "/dev/ttyACM0" for reading and writing 2019/12/29 21:40:39 socat[5875] N starting data transfer loop with FDs [5,5] and [6,6] 2019/12/29 21:41:51 socat[5875] N socket 2 (fd 6) is at EOF 2019/12/29 21:41:52 socat[5875] W cannot restore terminal settings on fd 6: Input/output error 2019/12/29 21:41:52 socat[5875] N exiting with status 0
Edit: had to include baud rates, stty before socat didn't work after all.
-
As DSF intercepts M300, the behaviour may be different depending on whether you are running with attached RPi or in standalone mode.
-
In that case it sounds more likely than not that the beep would be similar if not equal on the panel and in the browswer and as such maybe not so helpfull in troubleshooting.
-
@bearer said in M300 S and P swapped as played back in
RFF3 and/or DWC2DSF:Out of interest where would I be able to find that information myself?
https://github.com/dc42/RepRapFirmware/blob/v3-dev/src/Duet3_V05/Pins_Duet3_V05.h#L222
for future reference
https://github.com/dc42/RepRapFirmware/blob/v3-dev/src/Duet3_V06/Pins_Duet3_V06.h#L230