Sending GCode commands to duet3D Mini 5+ using python

shenouda13

@Falcounet I have tried that and still no luck..

Falcounet

@marco13 To answer your initial question, the code blocks because write_timeout parameter isn't specified to serial.Serial.
The default value is set to None which means write() is blocking by default. Set a value for non-blocking mode. See https://pyserial.readthedocs.io/en/latest/pyserial_api.html#serial.Serial.write

shenouda13

@Falcounet yes. if I set a value for write_timeout in serial.Serial() then it exits the code with an error after the amount of time that I set, but still cannot tell the duet to rotate the motor

alankilian

@marco13 Is it possible that the 'Y' motor is already at the Y=60 position and so it doesn't move?

Try sending Y0 and then try sending Y60 and see if it moves.

You can change this behavior and get Y60 to move 60 in the positive direction each time by changing to relative-motion-mode first. (I don't know the code off the top of my head, but you can find it in the GCODE reference)

Falcounet

Actually, the problem is not related to python or the code.
Something wrong seems to appear between the board and the pi but not sure what.

I just did some tests and if I connect my Duet Wifi 5+ to my computer and open a serial connection using putty, I can read a M122 output.
I close the serial connection, disconnect the USB cable from my computer and connect it to a RaspberryPi 4.
I open a serial communication using picocom -c --imap lfcrlf /dev/ttyACM0 but issuing M122 doesn't get any output.

I connect back the USB cable to my computer and try again with putty : M122 doesn't get any output anymore.
However, when I power off the board, I get Warning: VIN under-voltage event (9.4V) so the serial connection still works.

RYANPDX

@Falcounet I wonder if this is related to the issue I am current troubleshooting.

https://forum.duet3d.com/topic/30554/issue-with-usb-serial-on-duet-3-mini-5

Could you try connecting it to the Pi4, opening the serial port, and then pressing the 'reset' button on the Mini 5+? That would indicate you are experiencing the same thing I am, which seems to be unique to the Mini 5+ USB->Serial connection on Linux.

Falcounet

The problem is the RTS control signal has to be raised after the serial connection is open.
The firmware use that control signal to check the IsConnected state. Thanks @gloomyandy !

For picocom : picocom -c --raise-rts --imap lfcrlf /dev/ttyACM0 do the trick

For python; ser.setRTS(True) will do the trick :

import serial

with serial.Serial('/dev/ttyACM0') as ser:
    ser.setRTS(True)
    ser.write(b'\n')
    ser.write(b'M122\n')
    eof = False
    while not eof:
        line = ser.readline()
        if line == b'ok\n':
            eof = True
        print(line)

RYANPDX

@Falcounet at least in my case, this did not work. Not sure if this is a different issue than OP on this thread, so if so I apologize for cross-posting.

157fb322-ffca-4393-87ef-3667bb6404f8-CleanShot 2022-11-29 at 18.45.59.png

shenouda13

@alankilian thank you for your reply. I have tried that but still didn't work

shenouda13

@Falcounet in my case I have got this output:

b'=== Diagnostics ===\n'
b'RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus WiFi (standalone mode)\n'
b'Board ID: QMD5L-P296U-D65J0-40KMY-2203Z-HKNTX\n'
b'Used output buffers: 1 of 40 (4 max)\n'
b'=== RTOS ===\n'
b'Static ram: 98732\n'
b'Dynamic ram: 106852 of which 68 recycled\n'
b'Never used RAM 39564, free system stack 152 words\n'
b'Tasks: NETWORK(ready,358) HEAT(blocked,315) CanReceiv(blocked,947) CanSender(blocked,372) CanClock(blocked,363) TMC(blocked,106) MAIN(running,517) IDLE(ready,20) AIN(blocked,269)\n'
b'Owned mutexes: WiFi(NETWORK) USB(MAIN)\n'
b'=== Platform ===\n'
b'Last reset 00:00:27 ago, cause: power up\n'
b'Last software reset at 2022-11-29 10:16, reason: User, GCodes spinning, available RAM 39564, slot 0\n'
b'Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a\n'
b'Error status: 0x00\n'
b'Aux0 errors 0,0,0\n'
b'Aux1 errors 0,0,0\n'
b'Supply voltage: min 0.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes\n'
b'Driver 0: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 3849, writes 9, timeouts 0, DMA errors 0\n'
b'Driver 1: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 3849, writes 9, timeouts 0, DMA errors 0\n'
b'Driver 2: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 3849, writes 9, timeouts 0, DMA errors 0\n'
b'Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 3848, writes 9, timeouts 0, DMA errors 0\n'
b'Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 3849, writes 9, timeouts 0, DMA errors 0\n'
b'Driver 5: position 0, assumed not present\n'
b'Driver 6: position 0, assumed not present\n'
b'Date/time: 1970-01-01 00:00:00\n'
b'Cache data hit count 59010343\n'
b'Slowest loop: 4.53ms; fastest: 0.13ms\n'
b'=== Storage ===\n'
b'Free file entries: 10\n'
b'SD card 0 detected, interface speed: 22.5MBytes/sec\n'
b'SD card longest read time 3.2ms, write time 0.0ms, max retries 0\n'
b'=== Move ===\n'
b'DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000\n'
b'=== MainDDARing ===\n'
b'Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1\n'
b'=== AuxDDARing ===\n'
b'Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1\n'
b'=== Heat ===\n'
b'Bed heaters = 0 -1, chamberHeaters = -1 -1\n'
b'=== GCodes ===\n'
b'Segments left: 0\n'
b'Movement lock held by null\n'
b'HTTP is idle in state(s) 0\n'
b'Telnet is idle in state(s) 0\n'
b'File is idle in state(s) 0\n'
b'USB is ready with "M122" in state(s) 0\n'
b'Aux is idle in state(s) 0\n'
b'Trigger is idle in state(s) 0\n'
b'Queue is idle in state(s) 0\n'
b'LCD is idle in state(s) 0\n'
b'SBC is idle in state(s) 0\n'
b'Daemon is idle in state(s) 0\n'
b'Aux2 is idle in state(s) 0\n'
b'Autopause is idle in state(s) 0\n'
b'Code queue is empty.\n'
b'=== Network ===\n'
b'Slowest loop: 9.56ms; fastest: 0.00ms\n'
b'Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions\n'
b'HTTP sessions: 0 of 8\n'
b'- WiFi -\n'
b'Network state is active\n'
b'WiFi module is connected to access point \n'
b'Failed messages: pending 0, notready 0, noresp 0\n'
b'WiFi firmware version 1.25\n'
b'WiFi MAC address f0:08:d1:02:e9:d4\n'
b'WiFi Vcc 3.35, reset reason Power up\n'
b'WiFi flash size 2097152, free heap 27528\n'
b'WiFi IP address 255.255.255.255\n'
b'WiFi signal strength 31dBm, mode 802.11n, reconnections 0, sleep mode modem\n'
b'Clock register 00002002\n'
b'Socket states: 0 0 0 0 0 0 0 0\n'
b'=== CAN ===\n'
b'Messages queued 244, send timeouts 242, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 15\n'
b'ok\n'

Falcounet

@marco13 Yes so that means it works to me.

shenouda13

@Falcounet it gives me a wrong wi fi address ----> b'WiFi IP address 255.255.255.255\n' thou..

Also, right now if I run :

import serial
ser = serial.Serial("/dev/ttyACM0", 115200)
time.sleep(1)
print('read')
ser.write(b"G0 Y30 F50000\n")
print('write')
time.sleep(2)
ser.close()

the code it doesn't get stuck anymore but still cannot get the motor to rotate

also what does this line mean?

b'Messages queued 244, send timeouts 242, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 15\n'

dc42

@Falcounet said in Sending GCode commands to duet3D Mini 5+ using python:

The problem is the RTS control signal has to be raised after the serial connection is open.

RRF on the Duet 3 Mini does not require the virtual RTS to be asserted for USB comms to work.

Falcounet

@marco13 If you do G0 Y30 F50000 in DWC console, does the motor moves ?

The output displayed is the output of M122 command.
Not sure why 255.255.255.255 is displayed as IP address but it is unrelated to python or serial connection problem.

dc42

@marco13 said in Sending GCode commands to duet3D Mini 5+ using python:

also what does this line mean?
b'Messages queued 244, send timeouts 242, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 15\n'

Those are statistics about CAN messages sent and received. You are running on old version of RRF, so they are less meaningful than in later versions.

Falcounet

@dc42 From what I experienced, raising the RTS signal once the serial connection is open made the things to work.

Opening a serial connection using picocom -c --imap lfcrlf /dev/ttyACM0 and issuing M122 doesn't get any output and I can't even close picocom (because it can't reset the tty, I believe).

Opening a serial connection using picocom -c --raiserts --imap lfcrlf /dev/ttyACM0 and issuing M122 works.

shenouda13

@Falcounet I was able to get the motor to rotate with your code:

import serial
with serial.Serial('/dev/ttyACM0') as ser:
ser.setRTS(True)
ser.write(b'\n')
ser.write(bG0 Y30 F50000\n')
eof = False
while not eof:
line = ser.readline()
if line == b'ok\n':
eof = True
print(line)

thank you very much!!!!!!!!

dc42

@Falcounet my guess is that it's a function of the Linux driver you are using that it requires RTS to be raised. Using YAT under Windows, I can set RTS and DTR to any states, and communication works.

RTS has no real meaning when the connection is USB from end to end, without a serial element, because flow control is handled by the USB protocol.

shenouda13

@Falcounet Is it possible to communicate back from the Duet to the Raspberry Pi such as if a condition is met stop the python code?
I would really appreciate your help again

Falcounet

@marco13 What you mean ? Was an exception raised and thus stopped your script running ?