Python PI GCode Sender Questions

ZenXY Software
#1

Hello Folks,
Hope everyone is keeping well. Im making some progress with a raspberry Pi python GRBL sender. Right now,

  1. It picks a random G-Code file from a folder
  2. Streams the file accross the serial to the GRBL
  3. Closes everything - It completes one pattern and then stops.

Im looking for a little assistance if possible

  1. Scheduling: Id like to be able to run the machine on certain days and time. It sounds like Crontab is used for this. Is it better to use a python library like datetime and control the stuff in the actual program OR use crontab to schedule to when to run the program. Can I have a while loop that keeps on running the patterns if using crontab does anyone know?

  2. Plotting the G-Code: I’d like to have a little screen that plots the X,Y co-ordinates so students could appreciate that the sand pattern is controlled by the raspberry pi. Does anyone know of a simple python library that opens up a little window and prints out the plot.

  3. Any chance someone more experienced in programming and python could look over the code and give me some feedback - is there any error checking we could add - any other suggestions?

Big thanks for all the help so far - If your ever in Maryland - ill buy you a pint ,
Tim

import serial
import time
import os, random

# Open grbl serial port
s = serial.Serial('/dev/ttyUSB0',115200)
 
# Opens up a random G-Code File
random_file = random.choice(os.listdir("/home/timcallinan/GCODE/"))
file_path = os.path.join("/home/timcallinan/GCODE/", random_file)
print(file_path)
f = open(file_path,'r');

# Wake up grbl
s.write("\r\n\r\n".encode())
time.sleep(2)   # Wait for grbl to initialize
s.flushInput()  # Flush startup text in serial input
 
# Stream g-code to grbl
for line in f:
    l = line.strip() # Strip all EOL characters for streaming
    print('Sending: ' + l,)
    s.write((l + '\n').encode()) # Send g-code block to grbl
    grbl_out = s.readline() # Wait for grbl response with carriage return
    grbl_out_str=str(grbl_out)
    print(' : ' + grbl_out_str)
 
# Close file and serial port
f.close()
s.close()
#2

I’m working on something similar for my sand table but im at about the same point as you are with totally different setup… grbl and esp32 for a polar machine

It will be fun to see how you tackle it. I suspect that the buffering bit may be a bit of a pain to deal with but not sure yet.

May we toast each other’s victories as I’m also in maryland.

1 Like
#3

Definitely! Are you in Annapolis? I am. Id like to see your setup. Ill see if i can privately message you here.
Tim

#4

Running your program forever, with a while loop, is fine. The suggestion for crontab was a little different. I imagined sandypi running forever, with no changes. Crontab would send a command at 8am to say, “play” and at 8 to say, “stop” pr “pause”.

With a while loop, you could just ad something like this:

if hour < 8 or hour > 20:
    print("sleeping")
    time.sleep(60)
    continue

Inside a while loop.

Your code looks fine. I have a couple of suggestions:

  1. Use with to open the serial port and the file. It makes errors easier to handle and closes then automatically.
  2. Use a log. Whenever you get this running. And you want to see why it stopped, you’ll want to look at the text log. You’re doing a decent job of printing frequently. Just be sure you record the output of the app so you can see the log later, after an error.
  3. If you want this to be more generally useful, make the serial port and the gcode folder parameters.
  4. How are you going to run this? You could run it from cron with @restart. You could configure systemd. You could use docker with restart=unless stopped. You’ll have to look into each of these options. There are many choices.
  5. About error handling. I imagine the ways this is going to fail is that there will be a loose connection on the USB, or a command will get lost and you’ll be waiting for a new line. If you lose the serial port, then things like send will raise an exception. I would recommend just not handling that for now. But make sure you have a good log to see where it is falling before it fails. The log can also help you detect a stalled scenario. But remember that output can be cached. Eventually, if that becomes a significant problem, you can make a watchdog that you feed when things are working, and if you haven’t fed the WD in 10 minutes, then it will flush the serial port and start over, or whatever.
1 Like