M300 S and P swapped as played back in ~~RFF3 and/or DWC2~~ DSF

A Former User

https://duet3d.dozuki.com/Wiki/Gcode#Section_M300_Play_beep_sound

M300: Play beep sound

Parameters

Snnn frequency in Hz

Pnnn duration in millisecond

M300 S1000 P1000 ;Tone
M300 S1000 P2000 ;Higher pitch
M300 S2000 P1000 ;Longer
M300 S2000 P2000 ;Longer and Higher pitch.

This seems backwards?
RRF 3.0RC1
DWC 2.0.4-1

Also seems like the first beep after DSF is restarted is trunkated to a very short blip, hard to tell for sure if the frequency is changed but I think so, similar happens randomly to the first beep of a sequence after some idle time. And beeps between a sequence of moves will randomly be played partially, not at all but generally not in sync with motion.

e.g:
DO NOT COPY PASTE will mess with your endstop config.

; homex.g
G91
M300 S1000 P2000 
G1 H1 X-3000 F4000      ;fast home x to endstop Xa
M574 X2 S1 P"io0.in"    ; pnp no Xb max
G1 H1 X-50 F4000      ;fast home x to endstop Xb
M300 S1000 P1500 
G1 H1 X-50 F4000      ;fast home x to endstop Xb
M300 S1000 P1000
M574 X2 S1 P"io1.in"    ; pnp no Xa max
G90

edit: tried hooking up PanelDue to see if different, but seems to either not work in combination with the Pi or not on the v0.5 board. ~~will try to locate a sd card and test stand-alone operation and see later.~~ had prepped a sd card with rasbian and /sys/config.g on the Pi's /boot partition but only to find v0.5 has no sd card socket, so neither was tested >.<

A Former User

@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 with socat*, but seems whatever M575 Pn S1 I try the only thing i achieve is that with P0 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 of M575 (presuably P1 S1 would be correct if supported?)

*) variations on socat /dev/ttyUSB0,raw,echo=0,crnl /dev/ttyACM0,raw,echo=0,crnl

A Former User

Never mind, got lucky in the code dive. Its DSF.
https://github.com/chrishamm/DuetSoftwareFramework/issues/92

beikeland created this issue in chrishamm/DuetSoftwareFramework

closed frequency and duration swapped #92

dc42

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.

A Former User

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:)

dc42

@bearer said in M300 S and P swapped as played back in ~~RFF3 and/or DWC2~~ DSF:

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?

A Former User

@dc42 said in M300 S and P swapped as played back in ~~RFF3 and/or DWC2~~ DSF:

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 to Dout 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 the N0 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!

A Former User

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.

dc42

As DSF intercepts M300, the behaviour may be different depending on whether you are running with attached RPi or in standalone mode.

A Former User

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.

A Former User

@bearer said in M300 S and P swapped as played back in ~~RFF3 and/or DWC2~~ DSF:

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