My dream machine controller would have...

[petenc]

Branching this off with a new thread from a conversation with kstrauss. I have been working on creating a variant of Pathpilot (or linuxcnc) inside the Windows environment, still using a Linuxcnc controller, but using Windows (client) as my main interface. I am curious to what others input for their "dream machine controller". The sky is the limit, whether possible/practical or not, let's hear it.

Here is the start of mine:
-Fusion 360 on the control. I am constantly switching back and forth, want it on one.
-Sync tool list with fusion. Or have the option to import them.
-Keep previous feed & speed data for each tool number. Mainly for conversational wizards and hand programming
-Have simple calculators (or apps page) to find out speed/feeds whatever else (gwizard?)
-Great conversational wizards, and allow for direct control of the machine inside the feature I am creating.
-Multiple conversational wizards loaded at one time in separate windows
-Simultaneous editing of two programs while machine is running. Which I know you can already do inside PP with gedit.
-Aftermarket hardware support, such as pendants.
-Physical buttons and sliders for the interface, rather than clicking the mouse or touchscreen. A real control box.
-Electronic jog wheels for XY, and an encoded pull lever for Z to run the machine just like a manual.

Similar Threads:

• Need Help!- Dream CNC (DDCNC) Model No. DDLM1V usb motion controller and stepper drive??
• Your Dream Cnc Machine ?
• Dream Machine....??
• Dream machine
• Dream Machine

[109jb]

LinuxCNC needs a realtime operating system. This is true even with MESA cards or the like. The Mesa cards allow the realtime OS to have a bit more latitude, but it is still needed. How will you handle this?

[petenc]

LinuxCNC needs a realtime operating system. This is true even with MESA cards or the like. The Mesa cards allow the realtime OS to have a bit more latitude, but it is still needed. How will you handle this?

There would be two separate computers, probably like you already have now. So one to run linuxcnc, with a Mesa just like the $700? PP controller , which would handle stepper timing. It also allows for a tcp/ip connection, not telnet, and acts as a server for linuxcnc commands. The client is a windows machine, that would run the gui, and that would command the server. Any direct controls, like start, stop, feedhold, etc would be operated by physical controls, and will run to the linuxcnc machine not relying on an ethernet connection.

So whereas you probably have have two computers, one running Fusion 360 or Windows, and you post code to a thumbdrive/samba/network whatever, this just communicates directly with server program loaded onto the linuxcnc controller and loads the sent file. With that, any individual MDI or linuxcnc command (jog, cnc status, feed override, etc) can be sent independently and directly from windows.

Please keep in mind, linuxcnc comes with a similar telnet module already built called emcrsh I think. Its too slow, which is the reason I have started with ethernet directly.

[Jim Dawson]

Branching this off with a new thread from a conversation with kstrauss. I have been working on creating a variant of Pathpilot (or linuxcnc) inside the Windows environment, still using a Linuxcnc controller, but using Windows (client) as my main interface. I am curious to what others input for their "dream machine controller". The sky is the limit, whether possible/practical or not, let's hear it.

Here is the start of mine:

-Fusion 360 on the control. I am constantly switching back and forth, want it on one.

Fusion 360 built into the CNC software? Or just all on one machine so you can switch between windows. So maybe you can edit the next part while the the current part is running?

-Sync tool list with fusion. Or have the option to import them.

It is possible to export the Fusion tool library, so should be easy to import into the CNC software. Not sure how this would be used.

-Keep previous feed & speed data for each tool number. Mainly for conversational wizards and hand programming

Data base?

-Have simple calculators (or apps page) to find out speed/feeds whatever else (gwizard?)

A screen display that gives real time feeds, speeds, and chip load, as well as doubling as a calculator when setting up?

-Great conversational wizards, and allow for direct control of the machine inside the feature I am creating.

Not sure what you mean here

-Multiple conversational wizards loaded at one time in separate windows

?????

-Simultaneous editing of two programs while machine is running. Which I know you can already do inside PP with gedit.

Do you mean being able to edit the running program on the fly. Or, just being able to edit a program while the machine is running.

-Aftermarket hardware support, such as pendants.

Should be easy, depending on the controller and how many unused I/O is available.

-Physical buttons and sliders for the interface, rather than clicking the mouse or touchscreen. A real control box.

Easy, again depending on the available I/O. Could be digitally encoded and fed to the controller via USB

-Electronic jog wheels for XY, and an encoded pull lever for Z to run the machine just like a manual.

Now this is a great idea. I assume you are not just talking about a MPG on a cable, but rather actual hand wheels in the normal locations on the machine. I especially like the lever encoder for the Z. Really pretty easy to do. To put the icing on the cake, tactile feedback from the handwheels and lever, so it ''feels'' like you are turning the leadscrew. Probably doable, similar to electronic steering systems in some of the new cars.

[petenc]

Now this is a great idea. I assume you are not just talking about a MPG on a cable, but rather actual hand wheels in the normal locations on the machine. I especially like the lever encoder for the Z. Really pretty easy to do. To put the icing on the cake, tactile feedback from the handwheels and lever, so it ''feels'' like you are turning the leadscrew. Probably doable, similar to electronic steering systems in some of the new cars.

Yes! The tact feedback would be incredible. My thinking was capturing spindle load, and using that to determine handwheel resistance. The more spindle load, the harder it is to turn the handwheel. I was actually thinking about putting a DC motor on the shaft, and using it as a dynamic brake. Started this a couple years ago, but haven't done any more with it. Only if I knew then what I know now.


I will respond to the other comments tonight, gotta run off to work.

[hanermo]

yes !!!
This IS a great idea, I have also had for several years.

I have MPGs with hw support at high rates of feedback, 1 ms response, on my lathe.
Works fantastic.

But implementing Force-feedback is actually very very hard -- hard -- to do.
Or perhaps not....

I can get the error-count from servos, via inputs, maybe.
It shows on the servo leds.
And is directly related to load => lag, on the servo.
There is no easy direct output, afaik, of real-time error-count, from the servos.
There are no typical outputs showing error-count.

Easiest way, maybe, could be reading the wrong end of the bs, via high speed encoder input, using an external encoder.
Perhaps compare this to actual dro showing commanded-position in the machine controller sw.

Also, I believe some combos of linux cnc and servos can see/capture the error/lag in real time.

Also, perhaps, read load-on-servo via a shunt on the power cable, and then feedback to brake/drag on the handwheels.

It might be done via sw, as a looping macro, or as an external hw bit, perhaps.
The external hw bit would not cost a lot of money.
It is probably a commercially viable product with 10k+ customers willing to buy it, around 100$ / axis.

Now this is a great idea.

I assume you are not just talking about a MPG on a cable, but rather actual hand wheels in the normal locations on the machine. I especially like the lever encoder for the Z. Really pretty easy to do. To put the icing on the cake, tactile feedback from the handwheels and lever, so it ''feels'' like you are turning the leadscrew. Probably doable, similar to electronic steering systems in some of the new cars.

[petenc]

I am not sure if I am doing this multi-quote thing right... never done it.

Fusion 360 built into the CNC software? Or just all on one machine so you can switch between windows. So maybe you can edit the next part while the the current part is running?

-Yes all in one. Mainly for changes to CAM after I've started the part, but yes it would be nice to program while babysitting the machine if needed.

It is possible to export the Fusion tool library, so should be easy to import into the CNC software. Not sure how this would be used.

-Not sure exactly how I want this to work. I just know that I want Fusion to know what toolnums and descriptions I have already programmed in my library. And then I want Fusion to update the toolnums and descriptions (to the machine tool list) if there is something new when I post.

Data base?

-Yes database. I want something that suggests speeds and feeds based what I have done in the past with it.

A screen display that gives real time feeds, speeds, and chip load, as well as doubling as a calculator when setting up?

-Yes, apps for anything and everything. Calculators, send me a text when the machine finishes, sound an alarm, turn the control off when its done with the current program, internet, play Bohemian Rhapsody at random times.... anything.

Not sure what you mean here
-So I stole this from Okuma OSP. On certain conversational controls, you configure the interface for the feature and just click run. No gcode, no posting, just runs that feature internally. The control takes over and runs that feature, and sometimes that is all I want. I don't care about g-code as long as the machine is doing what I want.

?????
-Lets piggy-back this from the last comment, and add some features that Anilam and Prototrak have. If I can run this pseudo-program straight from a conversational interface, then now I want to be able to create several conversational interface's at the same time, put them together, and create an entire part. All without posting any code, g-code, or anything... just make the part.

Do you mean being able to edit the running program on the fly. Or, just being able to edit a program while the machine is running.
-Another Okuma OSP steal here, I am sure others can do this as well. As your program is running, and you don't like a speed or feed, you press a button and it opens an editor right at the program line the CNC machine is on. You can also edit two programs at the same time with a split window, while the machine is running the current program.

Should be easy, depending on the controller and how many unused I/O is available.
-I agree. I have been using USB so far, and don't plan on using direct I/O for much.

Easy, again depending on the available I/O. Could be digitally encoded and fed to the controller via USB
-Yes, I like the idea of keeping the encoder pulse counting ff of the controller, especially for human interface control stuff.

[petenc]

Lol, well that worked like I thought it would, so what does this multi-quote button do?

[Jim Dawson]

Lol, well that worked like I thought it would, so what does this multi-quote button do?

Allows you to quote multiple messages, but it is kind of clunky to use.

To break up a message into multiple quotes like I did above, you have to copy and paste the (QUOTE)..........(/QUOTE), but use the bracket [ ] instead of the parenthesis

[petenc]

Thanks Jim, lets try this again lol. Please work please work please work...

Fusion 360 built into the CNC software? Or just all on one machine so you can switch between windows. So maybe you can edit the next part while the the current part is running?

-Yes all in one. Mainly for changes to CAM after I've started the part, but yes it would be nice to program while babysitting the machine if needed.

It is possible to export the Fusion tool library, so should be easy to import into the CNC software. Not sure how this would be used.

-Not sure exactly how I want this to work. I just know that I want Fusion to know what toolnums and descriptions I have already programmed in my library. And then I want Fusion to update the toolnums and descriptions (to the machine tool list) if there is something new when I post.

A Data base?

-Yes database. I want something that suggests speeds and feeds based what I have done in the past with it.

A screen display that gives real time feeds, speeds, and chip load, as well as doubling as a calculator when setting up?

-Yes, apps for anything and everything. Calculators, send me a text when the machine finishes, sound an alarm, turn the control off when its done with the current program, internet, play Bohemian Rhapsody at random times.... anything.

Not sure what you mean here

-So I stole this from Okuma OSP. On certain conversational controls, you configure the interface for the feature and just click run. No gcode, no posting, just runs that feature internally. The control takes over and runs that feature, and sometimes that is all I want. I don't care about g-code as long as the machine is doing what I want.

?????

-Lets piggy-back this from the last comment, and add some features that Anilam and Prototrak have. If I can run this pseudo-program straight from a conversational interface, then now I want to be able to create several conversational interface's at the same time, put them together, and create an entire part. All without posting any code, g-code, or anything... just make the part.

Do you mean being able to edit the running program on the fly. Or, just being able to edit a program while the machine is running.

-Another Okuma OSP steal here, I am sure others can do this as well. As your program is running, and you don't like a speed or feed, you press a button and it opens an editor right at the program line the CNC machine is on. You can also edit two programs at the same time with a split window, while the machine is running the current program.

Should be easy, depending on the controller and how many unused I/O is available.

-I agree. I have been using USB so far, and don't plan on using direct I/O for much.

Easy, again depending on the available I/O. Could be digitally encoded and fed to the controller via USB

-Yes, I like the idea of keeping the encoder pulse counting ff of the controller, especially for human interface control stuff.

[Jim Dawson]

For quoting the forum software wants brackets [ ], not < > like in HTML tags

Fusion 360 built into the CNC software? Or just all on one machine so you can switch between windows. So maybe you can edit the next part while the the current part is running?[/I]

-Yes all in one. Mainly for changes to CAM after I've started the part, but yes it would be nice to program while babysitting the machine if needed.

I have AutoCad, Fusion 360, and cam programs on my machines. I can draw and edit while running. It depends on how much the machine running is dependent on computer resources. If the controller is pretty much handling everything, the switching between active programs is possible and let the CNC program run in the background.

It is possible to export the Fusion tool library, so should be easy to import into the CNC software. Not sure how this would be used.

-Not sure exactly how I want this to work. I just know that I want Fusion to know what toolnums and descriptions I have already programmed in my library. And then I want Fusion to update the toolnums and descriptions (to the machine tool list) if there is something new when I post.

Fusion 360 also will import tools, but I'm not sure how it needs to be formated.

A screen display that gives real time feeds, speeds, and chip load, as well as doubling as a calculator when setting up?
-Yes, apps for anything and everything. Calculators, send me a text when the machine finishes, sound an alarm, turn the control off when its done with the current program, internet, play Bohemian Rhapsody at random times.... anything.

A lot of that is easily doable.

Do you mean being able to edit the running program on the fly. Or, just being able to edit a program while the machine is running?
-Another Okuma OSP steal here, I am sure others can do this as well. As your program is running, and you don't like a speed or feed, you press a button and it opens an editor right at the program line the CNC machine is on. You can also edit two programs at the same time with a split window, while the machine is running the current program.

I think I would rather adjust the feed and/or speed with an override knob, even if it's an on screen knob. Once the run has completed, then I would think that would be the better time to edit the program.

[kstrauss]

Since I was blamed for starting this as a separate thread I have to comment...

A description of my current environment will clarify where I'm coming from. I'm retired and work at home. My Tormach is in a workshop about 100 feet from my house. My house has the computers that run CAD/CAM, email, word processing, web server, etc. There is an underground gigE link between the house and workshop. The workshop has a Windows machine using RDP (Remote Desktop Protocol) to access the home computers and with an Ethernet link to the PP computer for file transfers.

I don't find it a problem to move gcode between machines. In fact, it is an advantage because I always have a backup copy when I do something stupid. Pentec's suggestion of using a Windows machine to directly control LinuxCNC seems to be a lot of work for limited benefit for my way of working. The PP screen is close at hand and I only have to turn my chair to access it. Perhaps I'm just not thinking enough out-of-the-box!

Things that I would like include:

Easy import/export of tool descriptions and tool numbers

An easy way to implement fancy pendant functions. I see this including the usual MPG, axis zero and feed overrides plus things like reading the load on the spindle (I seem to recall reading that the Emerson VFD supports modbus), changing the current tool, building your own coolant nozzle control (need access to current tool number and offset), etc.

Improved conversational wizards that remember appropriate feeds/speeds. It would be great to have a well defined API to assist third party development of specialized wizards.

There are several feed/speed calculators available so duplicating them is not necessary. A database of tested cutting parameters would be great to go with the improved wizards.

It would be great if there were a few improvements to the PP UI. For example, remember the last path to gcode (preserved between sessions), better use of screen real estate for folder navigation, etc.

Note that these wants are mostly independent and could be developed separately. If I've been too vague, just ask and I'll try to explain.

[kstrauss]

I was having a few additional thoughts regarding a universal pendant interface.

A major goal should be to use hardware interfaces -- USB or Ethernet -- that are available on most PP machines.

It would be nice to support both wireless and wired pendants. The link to a wireless pendant could be via Ethernet, Bluetooth or maybe infrared. Wired could be USB or perhaps serial.

There are perhaps a few dozen parameters that you might want to display and/or change with a pendant -- current values for each axis, target values for each axis, feed rate, spindle RPM, feed override amount, spindle RPM override amount, path to current program, current program line number, current program line text, current tool number, current tool description, current tool offset, run status (cycle start, pause, stop), spindle load, etc. Since these variables require at most a few hundred bytes it might be expedient to just continuously broadcast (perhaps a packet every 100msec or so in a tagged format) the current values via UDP. The pendant could then decode and display whatever values are of interest. To change a variable the pendant could supply a variable identifier and desired new value via TCP. The PP machine could then respond with a confirmation that the change was made in

There are inexpensive Arduino boards and Android tablets that talk WiFi or Bluetooth so it would be simple to develop a variety of "pendants" to satisfy everyone's form factor and capability desires. These pendants could show a subset of current settings on a TFT or OLED display and include dedicated knobs or touch screens to change parameters. Slightly expanding the definition of "pendant" to include more capable computers It would be possible to do as pentec proposed and fully control PP from a Windows machine with a UI to taste.

Just a few musings for your consideration/criticism.

[kstrauss]

Based on some recent postings on the EMC-users mailing list it appears that current versions of Linux may provide acceptable performance without using RTAI.

With my suggestion for an enhanced definition of "pendant" there would be no need to include Windows in the mix. The pendant machine could be a desktop running Linux, Android tablet, cell phone, a dedicated micro based on Arduino/Teensy/Edison, or anything else that the developer chooses. There would be a clean and stable division of functions and the only configuration requirement would be an Ethernet or Bluetooth connection between the control machine and the pendant. Considering the price and size of today's computers there is little to be gained by combining everything into a single machine.

BTW, you need to add values for things such as G5x (#5221-#5390), and probably many more, to the data available to the pendant. I suppose that making all numbered variables from #5001 to $5601 (?) available would ensure that nothing is missing.

[petenc]

Based on some recent postings on the EMC-users mailing list it appears that current versions of Linux may provide acceptable performance without using RTAI.

With my suggestion for an enhanced definition of "pendant" there would be no need to include Windows in the mix. The pendant machine could be a desktop running Linux, Android tablet, cell phone, a dedicated micro based on Arduino/Teensy/Edison, or anything else that the developer chooses. There would be a clean and stable division of functions and the only configuration requirement would be an Ethernet or Bluetooth connection between the control machine and the pendant. Considering the price and size of today's computers there is little to be gained by combining everything into a single machine.

BTW, you need to add values for things such as G5x (#5221-#5390), and probably many more, to the data available to the pendant. I suppose that making all numbered variables from #5001 to $5601 (?) available would ensure that nothing is missing.

I agree, in my opinion keep them separate. My understanding, all that is needed is a "Remote API" that can bridge the gap from whatever OS, whether that be Ethernet / Bluetooth / USB-Serial. That what Okuma does and its great. https://thincster.com/what-is-the-okuma-api/

I think you would find more difficulty trying to edit PP to do this than to start with a fresh Linuxcnc install. My thinking is just emulating the python interface that linuxcnc has and trying to make an TCP/IP server version for the controller.
And maybe later bluetooth or serial usb for arduinos. Python Interface

My software vision with Windows is just an addition to that. I like your term "pendant machine", that makes a lot of sense.

[petenc]

this is the link to the "Remote API" https://pmcoltrane.wordpress.com/201...-api-part-iii/

the tldr is
"This system potentially expands the THINC ecosystem beyond .NET. Because it is based loosely on REST principles, and because every modern platform supports web requests, we are not limited to C# or VB.NET for THINC development. Using the server component in this system, we could create a mobile THINC app for Android or iPhone. We could even code a THINC-enabled Javascript web application."

[kstrauss]

Interesting! However, there seem to be a number of issues of which some are mentioned by the author. My objections boil down to: the design is excessively complicated (the result of current programming practices?) and too slow for many potential uses. I am unsure of the accuracy of the author’s estimates but he mentions 50msec (total time?) to set a variable. Causes are things such as:

HTTP is TCP based which results in considerable latency and overhead compared to UDP

HTTP is based on text messages rather than binary data

Parsing the returned XML document takes time and additional code

Perhaps I missed it but there doesn’t seem an obviously way for the controlling app to be notified when a variable changes. Would the app have to continually request the value?

This type of API might be great to remotely display the current tool number or other data that changes infrequently. I suspect that it would be hopeless if the associated app wanted to provide a continuously updating display of X/Y/Z/A or to provide a responsive MPG capability.

An earlier post mentioned applying a feed override and having the Gcode automagically updated to reflect the change. This might be acceptable or even useful in a hobby environment but not in a production shop with proper change management.

I agree that starting from a clean installation would be preferable to attempting to change PP.

[C*H*U*D]

Two things I disagree with, but only mildly.

I would not want my CAD/CAM on my controller. I'd rather not take the chance of anything happening while my machine is running, and we all know things go wrong with software from time to time. I'd rather have those hiccups happen on a computer that's not running my Tormach. I'd prefer a laptop that I can take outside to my patio to work on changes while my machine runs by itself.

I'm also not big on handwheels to control my CNC like a manual. I'd rather see Tormach come out with a 2-axis CNC/manual that operates like a ProtoTRAK. Conversational in PathPilot is "ok" but I find it lacking compared to the conversational found on a ProtoTRAK. Something like a Rong Fu RF-45 with ball screws and a simple pendant/DRO...no need for a controller.

[petenc]

Two things I disagree with, but only mildly.

I would not want my CAD/CAM on my controller. I'd rather not take the chance of anything happening while my machine is running, and we all know things go wrong with software from time to time. I'd rather have those hiccups happen on a computer that's not running my Tormach. I'd prefer a laptop that I can take outside to my patio to work on changes while my machine runs by itself.

I'm also not big on handwheels to control my CNC like a manual. I'd rather see Tormach come out with a 2-axis CNC/manual that operates like a ProtoTRAK. Conversational in PathPilot is "ok" but I find it lacking compared to the conversational found on a ProtoTRAK. Something like a Rong Fu RF-45 with ball screws and a simple pendant/DRO...no need for a controller.

Yea, running the machine from a remote PC is a concern of mine as well. I am currently digging into it, and I am thinking there is enough isolation between linuxcnc and the client that even if Windows (or the software) were to lockup, linuxcnc would still continue doing what it was told to do until its done.... such as running a program. Maybe if you were right in the middle of a jog command, and you lost connection for some reason, it would continue in the jog trajectory until it was told to stop jogging.

The Prototraks are awesome, I know what you mean, we have a brand new DPM2 at work, and I have been taking a lot of notes from that very machine. It may seem silly/crazy, but I think it would be awesome to get the conversational and controls as good or even better for my 1100. I know the 2-axis w/ manual quill will never happen, but it would be fun to try and develop something as close as possible.

Here is the very start to my development for a Windows interface for linuxcnc. The UI is only for programming the code for all the different functions and libraries, I will make it look pretty once I get further along in the project.

Thanks,
Pete

[kstrauss]

There are several issues that worry me about remotely operating the actual machine controller.

You mentioned that the machine will usually continue running the current job but with a possibility that certain remote failure modes might leave a jog or other actions in progress. This soft of failure could be disastrous and needs careful analysis. However, a more dangerous situation may result from losing control due to a failure of the remote (or the link to the remote) and having a machining code failure. It could take many seconds before the operator realizes what happened, walks to the machine and hits the eStop.

Security is also a huge issue. I don't just mean a malicious hacker that connects to your WiFi while parked outside. Many shops have multiple Tormachs. Consider the results of connecting to the wrong machine and commanding it to start machining!