Greetings folks. My name is Tom. I'm fairly new here and still very green.

I'm recently built a 24"x48" hobbyist machine from a cncrouterparts kit. It's up and running and I'm learning more every day. My "shop" is a small storage unit below my apartment I'm just beginning to trust my machine to run unattended while it whittles away on 3D signs and address plaques. I'm wondering if the Mach software has any way to send data over the network while its running. It would be nice if it had a built-in web sever that published a current DRO screen with some kind of progress indicator? The software (.dll libraries via Apache) to implement such a thing is easy to include in the code, or it could be a stand-alone thread initiated when Mach3 starts. I think there are web libraries that will serve a simple cgi page on a custom port. If not, is there any other way besides the sound of wood being cut to indicate its progress?

You could also do a remote desktop type of thing. It would be the next best thing to being there.

You could also do a remote desktop type of thing. It would be the next best thing to being there.

Yea but I'm running a Smoothstepper Ethernet. I doubt the Ethernet communication would be an issue but I suspect the remote desktop would tend to hog CPU time and might let the ESS run out of data. It generates a tremendous amount of interrupt activity that could easily interfere with Mach. I get smoothstepper errors when I fiddle with the Mach toolpath display while running code as it is. I also have not found the remote desktop to be very reliable or functional. A web page would only take 1ms or less of CPU to generate the HTML page and slam it into an outbound Ethernet buffer ready for packeting. A remote desktop runs a screen update server as a service that continually compares the "off screen" screen with the current screen sending updates to the remote. In short tons and tons of software interrupts.

I could me wrong though, has anyone tried it?

I do know that the Mach guys will remote in to do trouble shooting. not sure if they have actually run the machine or not.
I thought that one of the nice things about external motion controllers was that they took most of the load off of the CPU. You may not have your ESS setup properly if you have problems when you fiddle with the tool path display.

Mike

I do know that the Mach guys will remote in to do trouble shooting. not sure if they have actually run the machine or not.
I thought that one of the nice things about external motion controllers was that they took most of the load off of the CPU. You may not have your ESS setup properly if you have problems when you fiddle with the tool path display.

Mike

That's one of the reasons I bought an ESS, it does take some of the load off the CPU. But there isn't really anything to "set up" with the ESS. You assign it an address and plug it in. The driver does the rest. There really are no communication parameters to fiddle with and I don't see any options in the plugin that would effect its operation in terms of loosing communication. It's far more likely that the library calls that Mach3 uses to update the 3D display either load the CPU enough to miss communication (very unlikely) or they directly interfere with the ESS protocol by preventing an uninterrupted stream of instructions. Ethernet adapters are hardware interrupt driven devices and nearly all new adapters have on memory board buffers so it's unlikely its a communication issue. The code to operate the ESS is terse so if I get an error saying it ran out of instructions to execute its either a communication issue or something is preventing Mach from generating or sending code. I tend to think it's CPU load since the communications are interrupt driven. In any case, it would still be nice, and very easy, to add a web page server to the Mach suite.

It just occurred to me there is probably a way to write a VB script that would serve a web page. It might require installing an MS library package but I'll bet its possible.

It's far more likely that the library calls that Mach3 uses to update the 3D display either load the CPU enough to miss communication (very unlikely)

Actually, this is very likely. with the larger toolpath display in my 2010 Screenset, some users have seen CPU usage go to 90% as soon as they load a g-code file, just from the toolpath display. Turningit off drops the CPU Load back down near zero.

I have to laugh that a CNC controller loads up a modern PC.  The old Bandit controller I used to run had the same processor as the Apple II!

Gary H. Lucas

I have to laugh that a CNC controller loads up a modern PC.  The old Bandit controller I used to run had the same processor as the Apple II!

Gary H. Lucas

I don't think it really does load it up. We're talking about scheduling issues not real CPU usage. Even an old 80286 at 16mhz could keep up with a gcode interpreter sending a data stream to the parallel port. But its likely that some of the software libraries that are part of the Mach3 exe module are inefficient at displaying video. Depends on how they code it and which library routines get compiled or referenced at run time. That or its been coded in such a way that it does not gracefully share the processor causing a pile up or stack overflow somewhere. It may have nothing at all to do with Mach3. It may just be a quirk of the language they use to generate the exe file.