Sending GCode commands to duet3D Mini 5+ using python
-
@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)
-
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 usingpicocom -c --imap lfcrlf /dev/ttyACM0
but issuingM122
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 getWarning: VIN under-voltage event (9.4V)
so the serial connection still works. -
@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.
-
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 trickFor 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)
-
@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.
-
@alankilian thank you for your reply. I have tried that but still didn't work
-
@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' -
@marco13 Yes so that means it works to me.
-
@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'
-
@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.
-
@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. -
@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.
-
@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 issuingM122
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 issuingM122
works. -
@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!!!!!!!!
-
@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.
-
@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 -
@marco13 What you mean ? Was an exception raised and thus stopped your script running ?
-
@Falcounet I am performing some image classification in a loop on the RPi and based on that the duet will perform some actions. But sometimes the mechanism controlled by the duet gets jammed and the python code keeps running. So for each time the Rpi sends a command I would like the duet to be able to send back a signal/command in order for RPi to perform the next image classification.
-
@sarco13 Hard to help you more without code or details.
What commands are you sending ?
If you want to sync a macro and python code, you can maybe use a global variable that you increment on one side and check the value on another side. Something like that. -
@Falcounet I am calling macros to rotate motors and control sensors.
the code is something like this:def send_command_duet(command):
with serial.Serial('/dev/ttyACM0') as ser:
ser.setRTS(True)
ser.write(b'\n')
ser.write(command)
eof = False
while not eof:
line = ser.readline()
if line == b'ok\n':
eof = True
print(line)while True:
Capture image
classify image
send_command_duet(command) #perform action
receive signal from duet to go to next iteration