CNCjs for Duet3D
-
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.
