Wow, this took entirely too long to get google+ working… Hope everyone finds this quick port useful, if not encouraging. @Todd_Fleming and myself had a lot of fun, and none of this would of been possible without @Sonny_Jeon 's original work and his support on this little project.
Wowza. Would this support the spindle on off M3/ M5 commands in addition to the PWM output line, and would the firmware need to be recompiled in order to set the specific pin #'s for those items?
Absolutely amazing job guys! So encouraging to be part of a group of individuals who continue to work together to help pioneer and push the open source movement to even greater heights! #gamechanger
@cprezzi I’ll look into sending it on connect. I’m uneasy changing the ident string because the only protocol difference is the buffer size, which can be changed.
@raykholo right now it supports the spindle PWM signal but I haven’t ported spindle enable and direction signals yet. M3, M4, and M5’s function vary depending on if it’s in laser mode. For laser, it’s best to use M4 at the beginning of the job and M5 at the end. S then controls the PWM value. You have to recompile to change pin numbers.
@Todd_Fleming @cprezzi I’ll start investigating ways for GUIs to quickly know the processor and buffer sizes, but it’ll have to wait until the weekend when I get some time. This new stuff will be placed in a new v1.2 development version to keep the master v1.1 pristine.
@Sonny_Jeon The welcome string right after connection is already a very good thing. This way the host can select the right protocol before sending commands that lead to errors when sending to the wrong firmware.
It would be optimal if we coud establish this procedure as a standard for all firmwares.
Congrats!
Maybe I missed the boat on this, but what is the reason for running GRBL on smoothie? What does it do that the current Smoothie firmware doesn’t do?
It handles higher block rates (pixel rates) over USB.
much higher 
Websockets likely have a higher overhead than USB; it may rob too much time from the main loop. When the step rate is at 200 kHz, the step ISR slows everything down, including the USB interrupt. This causes the USB interrupt to pause the main loop up to 4ms at a time. With the right defines, it can handle 1000 blocks/s at 200 kHz with USB; I fear this would drop with websockets. A dual-mcu model would probably be better. Maybe a PI handling the websocket?
So the LAN port on Smoothieboards is worthless. Or is there a LAN protocol that would be usable for “serial over LAN”?
The hardware only handles the Ethernet level. Software has to implement the entire TCP/IP stack, which is much more complicated than the serial over USB protocol, so would rob CPU time from the planner and segment generator. Maybe there’s a serial-over-ethernet protocol, but I haven’t heard of one and don’t know if Node can access Ethernet directly.
There are TCP and UDP sockets in node js.
UDP sits on top of IP; it still has a lot of software overhead, plus it needs a TCP-like protocol built on top of it to handle data ordering and reliability.
All of that overhead is one possible reason why Smoothieware slows down with rastering. It does an amazing job with most typical work loads, but there is only so much CPU to go around. I think the next gen of Smoothieboard will provide both Smoothiware and GRBL-LPC plenty of room to grow with their dual CPU approach.