Someone of you may be positively surprised how simple it is to stream GCode

(anon57870006) #1

Someone of you may be positively surprised how simple it is to stream GCode to the printer. Here I have made a single screenshot code that does it.
I would appreciate your suggestions on running it concurrent for several printers. For your comments to live longer please comment on the blog instead of this G+ post that is going to die soon.

(Craig Hissett) #2

Would it be possible to wrap this code up into a class? Then you could write a script to create a class instance for each printer, then run the class functions asynchronously. I used threading (import threading) to fire concurrent processes off on one of my projects.
foreground function launched a webserver, while background function ran a jukebox-like music player:

def background():

def foreground():

b = threading.Thread(name='background', target=background)
f = threading.Thread(name='foreground', target=foreground)
(anon57870006) #3

Do you think using the multiprocessing module would be better?

(Craig Hissett) #4

@shauki absolutely!

(anon57870006) #5

I need an alternative to sleep(sec) because the way this code is written loads the CPU core 100% which reduces printing speed. Adding sleep(1) also reduces print speed. Need a better way for checking _command_received.is_set() please.

(Craig Hissett) #6

@shauki I shall have a look tonight buddy, see if I can find an alternative :slight_smile:

(ThantiK) #7

@shauki , I’m thinking you could use serial.in_waiting to determine if there are items in the buffer to read in the first place.

(Nathaniel Stenzel) #8

I can tell you that Cura and OctoPrint are both written in Python. You could use them for inspiration. OctoPrint is Python 2.7x. I do not know which major Python version Cura is.

(Nathaniel Stenzel) #9

You should probably read this too. It mentions importing Event from Threading so that you can define myEvent and say myEvent.wait() which is handy.

I have saturated 8 cores on a 2 or so year old server using Python. It got the job done. I even managed to do it without wasting CPU cycles. I was using some of those multithreading modules. I forget if it was with multiprocessing.pool or what.

(Nathaniel Stenzel) #10

Oh yeah. The Python website has a good multiprocessing section to read through.

One thing to watch out for in multiprocessing and multithreading is accessing the same variables from multiple threads/processes without locks.

(anon57870006) #11

Thanks gentlemen. Please notice:
while not _ok_event.is_set():
time.sleep(1) # pass overloads CPU core
The loop in the updateDaemon does not overload.
What actually I need is a sleep of milliseconds, not seconds.

OpenMultibot Project Started I officially announce that with the birth of my first grand
(anon57870006) #12

My bad: “The argument may be a floating point number to indicate a more precise sleep time” so sleep(0.01) should work. To be tasted later :slight_smile:

(Craig Hissett) #13

@shauki That should do it :slight_smile:

(anon57870006) #14

(Craig Hissett) #15

@shauki great to see mate!

(anon57870006) #16

Thanks Craig! The prior print job finished in 3:30 compared to SD 2:35. It was with 0.001 sleep and print to screen. Now 0.01 sleep without print output and things look and sound much better:

(Nathaniel Stenzel) #17

I was wondering how changing from 0.001 sleep time to 0.01 sleep time made it perform better and then I realized that you removed a print statement. Yeah. opening up the console and printing a little bit of text is for some reason a performance hog. I don’t know…maybe they need to change console interaction to a separate thread or something in Python. It is mind boggling that it would be that slow at printing text.

(anon57870006) #18

The far most one printed in 2:25. Switching gears to multiprocessing

(Steve M) #19

Does this take into account checksums and requests to re-send certain lines?

(anon57870006) #20

Not in this iteration @Steve_M . Before I get troubles in real production I shall not consider bringing it in.