When I click the “open” button in cncjs, I can hear the Shapeoko make the sound (as if all the steppers are now locked). But when I click “homeing” it does nothing. In the console, I can see the $H being passed, but no luck.

Hmmm - I also see this:

Grbl Widget
This widet shows the Grbl state and provides Grbl specific features.
Set $10=2 for Grbl v1.1d (or $10=15 for Grbl v0.9) to see planner buffer and receive buffer in queue reports.

I put that in the Grbl console and hit enter, but that didn’t seem to get “stored” anywhere. FWIW - connecting carbide motion V4 works perfectly, so I know it’s not the board…

I hope that it is working for you now. The default baud rate for GRBL is 115200. Older version use a slower rate and I believe that you can recompile GRBL to use something else. But, again, the standard is 115200. Also, the controller should be connecting to a ttyACM port like you’re seeing. ACM stands for abstract control model and it is a standard subtype for USB communication devices. Basically, it allows USB to act like a serial port and should be compatible with the older RS-232 communication standard. None of that particularly matters other than that is how it should show up in CNCjs.

I hooked up a Dell10v (yeah yeah, me and my commodity hardware…) and it runs just fine. No stuttering, no stumbling.

The original raspberry pi I was using was a Model B, version 1 (https://en.wikipedia.org/wiki/Raspberry_Pi). I even overclocked it up to 900mhz and still saw the stuttering. The issue was the planner buffer was getting saturated (I could see it get full in the grbl widget). As I understand it, that means that the Shapeoko Grbl board is waiting for instructions. I understand it’s just waiting a few milliseconds, but it’s stuttering none the less.

The Raspberry Pi 3’s have a 64 bit quad core 1.2 Ghz processor. That’s 2x the power of this old Dell 10v (roughly).

Again, the goal is to create a dust proof CNC setup so I’m off to find one of those bad boys.

Yes, definitely recommended, although I haven’t really upgraded CNCJS on it in a while. If it ain’t broke don’t fix it kinda thing. My rpi3 hasn’t caused any problems at all and runs very well (haven’t even rebooted the thing in months).

My Fusion 360 export and upload to CNCJS is done on my laptop, and I just run the job from the safari browser on an old iPad 3 on a flexible arm mounted under my workbench.

No experience with cncjs. Carbide Motion 4 works a little unusually compared to most G-Code senders. It’s my understanding that when one sets zero, it’s programmed into the machine as a work coordinate system (G54 I believe) and the software tracks where that offset is relative to the machine bed.

Could one of you guys (@eciramella, @yfi ) post the part of rc.local you added to autostart it please?
It looks like some env vars are not present during that time.

Much appreciated!

Thanks Michael

Edit: solved

Open crontab
crontab -u USER -e

Paste the following into Cron Tab [ NOTE: which cnc and which node # used to find location of application and env (remove node from env… )]@reboot env PATH=$PATH:/home/USER/.nvm/versions/node/v4.5.0/bin /home/USER/.nvm/versions/node/v4.5.0/bin/cnc >> $HOME/cncjs.log 2>&1