First laser engraving using my newly modified Shapeoko along with an entirely new software stack.
I’m running a Raspberry Pi inside the Shapeoko enclosure, this has a NodeJS driven web interface for me to send files and control the machine remotely. The Raspberry Pi streams GCode to the TinyG which controls the machine. All this makes it safe for me to use a little 1W laser diode inside the enclosure!
Today I got the last of the gcode streaming bugs ironed out and made my first engraving of this little guy. Very happy to finally be getting somewhere.
I will be releasing all the software as soon as I’m confident I’m not going to tear it all down and start over, hopefully within a month or so I expect.
I’ve got a similar setup in the works on the control end of things, also intending to use RPi + Node.js. Are you using node-serial to stream the G-code or something else?
Gotta say, I’m super jelly of the laser gear—lookin’ good! 
Yeah using node-serialport, I’ve got the RPi tx/rx pins connected directly to the FTDI pins on the TinyG saving myself a USB port. This seems to work pretty well but I’m going to have to work out something for connection detection. I’ve also got a bunch of relays connected to the RPi gpio so that I can turn on/off a shopvac, and control lights, a SuperPID for spindle speed control and turn the TinyG on/off. It also monitors raspberry pi CPU temp, and a bunch of temperature sensors scattered around the enclosure using the w1 interface on the RPi.
With all this running on the NodeJS side of things I decided to run the actual gcode sending on a forked process so that there’s no chance the NodeJS event loop could get clogged and stall the machine. Its feeling pretty good now, but I’ve still got a fair bit to go, better graphs for monitoring, and a whole load better error state detection etc. How far along are you? Perhaps we should join forces.
Good call on using the hardware serial port. I see some folks in the johnny-five community use that approach to talk to their microcontrollers, hadn’t considered it as an option for talking to my controller for the ShapeOko.
In short, I’m not far at all. I’d definitely be interested in joining forces rather than starting up something new entirely. I’ve put together some proof of concept demos over the past year or so that I keep telling myself I need to get combined into something cohesive.
For instance, leveraging Hammer.js to create a touch based gesture jog control for positioning from my tablet. Quite satisfying to have a machine like the 'Oko at your fingertip! Another was just a proof of concept “drag & drop & cut a gcode file”. My plan was to start by combining the two into a dead simple job runner backed by hapi so I could take advantage of its plugin friendly architecture as my needs expanded.
The hardware serial port was really so that I could free up enough USB ports to not have to use a hub, as I’ve got the Wifi module and the webcam plugged into the two on the Pi.
I hadn’t thought of using Hapi, that might be interesting. Thus far I’ve got it all setup using Socket.IO mostly, this lets the client have nice fast communication of position and updates. I also found it very beneficial to have Nginx sat in front of NodeJS, for some reason NodeJs serves static files from on the RPi very slowly indeed but they work great from Nginx.
I’m building most of the UI out with Bootstrap 3 since its fast and easy and I don’t want to be spending too much time on the responsive stuff. So thus far it works fine on my phone in landscape and portrait which is a lot of fun. I’d really like to put together a nice little interface where you can just drag the tool head around with your fingertip on the screen, map the cutting area to the screen on the device so you can just drag it around - would be great to play with not sure how useful it would be though.
I will try and get what I have a little more cleaned up and together and get it up on Github soon then, maybe in the next couple of weeks so we aren’t wasting time working on things that have already been solved.
Nice, Wi-Fi + webcam + Arduino was the goal for the person doing it with johnny-five as well, but with the goal of an untethered robotics platform.
hapi’s caching may eliminate the need for nginx and the additional configuration complexity that comes along for the ride. First load is definitely still slow of course, especially with some templating systems involved. And it plays well with WebSockets, even substack’s shoe library which is browserify friendly.
Ping me when you get it posted, I’d be happy to help out however I can!
go ben! Thanks for the post!
Oh btw using the hardware serialport on TinyG @Ben_Delarre had to bypass the built in flow control. Are you using the queue reports from TInyG to sync state and not overflow the buffer?
Hey @Riley_Porter_ril3y . Yeah that threw me for a while there. Currently I’m using line numbers to avoid overflow but I have the code in place for queue reports. I ran into the queue report arc bug so switched to line numbers. Going to upgrade tonight and try out queue reports again.
Ahh the “bug” you speak of is not really a bug but rather arcs can take 3 spots in the planner queue to complete. I typically allow for some breathing room in the qr like 20x moves in the planner buffer vs the whole 28.
It was issue 66 (https://github.com/synthetos/TinyG/issues/66) I think. When I was running my tests the entire machine would just stall and lock up, unrecoverable until hard reset. Seems to be good now though I think!
Any suggestions on the best way to detect connection? Because I’m directly connected to the hardware the serialport just opens, whether the tinyg is powered or not. So I’m sending out regular status report requests once a second, when I receive one I assume I’m connected. I then continue to send these while the machine is idle to detect disconnects. Is there another command that might be quicker? I know SR’s get a low priority…
I have a similar project and would love to see your settings, specifically jerk. Here is a blog post after I first got it working: http://www.rageagainstthemushin.com/2013/09/09/portable-test-burn/
