CNCjs for Duet3D
-
Status update:
-
I have made all the changes to have a "Duet3D" tab appear, in the CNCjs GUI, and it is fully functional, because it is a copy of the "Marlin" tab, with everything renamed. To be clear, all the 'internals' are copied and renamed as well.
-
I've completed a few 'minor' changes that tailor the internals to Duet. Example: Marlin uses G28.2 to home. Duet really should have a G28. I've made that change. This is as much a verification of the build and change management processes as anything else. Everything seems to be working.
Next steps:
Immediate: Change the M114 used to request position from Marlin to an M408, and change the return parser to correctly process the JSON response, and ensure this is properly displayed in the "Work" and m408 "Machine" DROs (Digital Read Outs) in CNCjs.
Long term: Crawl through every request/response and see what else should be changed to be more 'native' to Duet.
-
-
Thanks for the update and working on this Danal. I am keen to get more support for CNC into RRF.
I just checked out CNCjs's Github and it looks good. I assume the normal application would be to run it from a raspberryPi etc, networked to the Duet or fram the desktop app version?
Coincidentally but related I was talking to Matt from 713Maker at MRRF about CNC applications and one thing we discussed was using a PanelDue (with different firmware, rotated 90 degrees) as a CNC pendant to allow for manual jogging etc. I am not sure how much a touch screen interface vs Physical buttons would be preferred by machinists but CNCJs looks to accept a variety of inputs.
-
I'm very interested in the idea of putting a Duet + paneldue on my CNC (just a shapeoko 3 xxl).
I think it would be a great platform, and most of us using a shapeoko are using software buttons to jog as is.
-
I just checked out CNCjs's Github and it looks good. I assume the normal application would be to run it from a raspberryPi etc, networked to the Duet or fram the desktop app version?
CNCjs runs in a browser; the files can get to the browser via almost any server. There are many variants of "where is the browser" and "where do the files come from". In addition, the github repository also contains pre-built binary stand-alone 'desktop' apps for Windows, Mac, and Linux, that combine the browser/server/CNCjs into a single binary for that platform.
However… at this time... CNCjs supports only serial (Including USB Serial) connections. I plan to make it more "native" to Duet3D/RepRap within this boundary for the first couple of pulls. I may, repeat may, become ambitious enough to add TCP/IP support.
Coincidentally but related I was talking to Matt from 713Maker at MRRF about CNC applications and one thing we discussed was using a PanelDue (with different firmware, rotated 90 degrees) as a CNC pendant to allow for manual jogging etc. I am not sure how much a touch screen interface vs Physical buttons would be preferred by machinists but CNCJs looks to accept a variety of inputs.
CNCjs is internally architected to make adding almost any kind of "Pendant" very easy. PanelDue hardware, running different firmware, could easily become such a pendant. At this time, I have no ambition to do this… primarily because I already have pendant(s) like this one:
And, just a personal opinion: When I'm using a pendant, I am almost always looking at the machine and not the pendant... I want tactile buttons. I believe I'd hate a touch screen.
-
Thanks - yeah the touchscreen not being tactile would probably not work.
When you say that CNCjs does not use TCP IP but runs in a browser that through me for a bit. I do not know if the ESP would be happy serving up the node.js parts however but that would probably be ideal - being able to load it from the Duet in a similar way to DWC
-
Yeah, browser/serial struck me as odd as well. Remember, though, CNCjs was created for Grbl, TinyG, and things like that which are all pure USB serial. I'm hoping it will be easy to add TCP/IP transactions… CNCjs does appear to be well structured, so I am optimistic.
I know of no reason why Duet couldn't be the server. I will give it a try. If it works, I may generate a "pull" for DWC that enables a separate directory (or subdirectory) so as not to clutter up /www.
-
As far as http is concerned, the file system root is /www. So any web server extensions should be in a subdirectory of /www.
I'll take a look at how G28.2 differs from G28.
-
As far as http is concerned, the file system root is /www. So any web server extensions should be in a subdirectory of /www.
Great. A subdirectory would be most appropriate. I'll head in that direction when I experiment.
I'll take a look at how G28.2 differs from G28.
No need, really. The Marlin tab in CNCjs issues the G28.2 and, while that is not documented to work on the Duet, it does. Perhaps you added it a long time ago to make Marlin compatibility better, or perhaps it just ignores the ".2".
Anyway, the Duet3D tab in CNCjs will (already does) issue a plain 'ol G28. So nothing needs to change.
-
CORRECTION: The server side of CNCjs is NOT static files. There is JavaScript running in the server, actually a full node.js implementation.
Therefore, CNCjs cannot be served from a Duet. I was mistaken.
It CAN be served from anything that can run node.js, including a Raspberry Pi. And/or the "appears to be a standalone desktop app" package can be used.
-
I used the Electron based version of CNCjs with GRBL and it was quite OK. Anyway, hugely better solution than having another dedicated board or software stack installed, at least on Windows.
-
I used the Electron based version of CNCjs with GRBL and it was quite OK. Anyway, hugely better solution than having another dedicated board or software stack installed, at least on Windows.
Agreed. That is actually my most common way to use it as well.
Being completely self contained is a huge advantage, especially on a real "production shop floor". I'm not 100% in that situation, in that it is my personal shop. Still, I very much like running something that has fewer dependencies, and absolutely no internet connection.
-
I'm not in that situation either… if you can imagine, 90% of my time is developing applications for SDRs (Software Defined Radio). But now and then we have to build custom PCs with internally installed radio receivers or build some bespoke RF processing equipment. All those require a lot of one time items. Thus sometimes I don't touch the CNC for months, other times, like this very period, I do mostly mechanical stuff. If we need large quantities, we pass STEP files to a CNC shop.
Though I started preferring LAN over USB these days. While keeping an eye on the machine (actually, mostly listening to it!
), someone has to do something else not to get bored. So I have my desktop controlling the CNC right now. With USB connected GRBL I had to be careful not to get the CPU to 100% usage (no problem when compiling 50+ C++ source files in parallel!). With LAN connected Duet, as everything gets executed in the controller, I don't really care if the status is not updated in the browser for 10-15 seconds at a time.WiFi is not an option for us. Sometimes we turn off all wireless devices in order to not interfere with our software/hardware tests.
-
Yeah if it uses quite heavy weight server side middleware then its not gonna fly on the ESP 8266. It would still be good to get it working with TCP/IP though as you could then connect via ethernet as Catalin says.
-
I hear you about "Listening". My big CNC is in an aircraft hangar, and I usually start a long cut and then go do a maintenance item on one of the planes. Etc. Easy to tell if everything is going right…
I will probably do the TCP/IP thing for CNCjs, and it may very well turn out to be dirt simple once I get into it. I've just got it slotted AFTER the "Get the Duet3D tab working as natively as possible" updates.
-
Yeah if it uses quite heavy weight server side middleware then its not gonna fly on the ESP 8266. It would still be good to get it working with TCP/IP though as you could then connect via ethernet as Catalin says.
Exactly. Full Node.js. So not on the Duet, not even under RTOS. No big deal though, either the self-contained or the R-Pi version… whatever each individual wants.
-
Is there any reason why the Javascript code can't be run client side instead?
-
Is there any reason why the Javascript code can't be run client side instead?
In theory, it could all be client side. For example, Chilipeppr works this way*. In practice, that would be a huge change to CNCjs.
As a "never before had a pull accepted", I feel it would be prudent to "go with the flow" for the moment, and add native Duet support to the way CNCjs is structured. After that, add a TCP/IP connection option.
And… there is always the Windows, Mac, and Linux stand-alone versions. No server is needed at all. With those in play, I'll say that "all browser side" is somewhere between third priority and no real need to do it at all.
.
.- Chilipeppr runs entirely in the browser, EXCEPT for a small program that provides the serial USB connection (browsers won't let Javascript control serial ports). Obviously, with a TCP/IP connection, this would be come moot.
