What's new
What's new

HMC retrofit

I'm not a controls engineer, but my understanding is that most modern CNC controls have two parallel systems. There is a PLC that does the motion control and handles all the real-time events, trajectory planning, I/O, etc. Then there is a second computer system that handles the user interface, editing, program storage, and is what we generally think of as the "control".

I know I used to work with an Okuma P200 control that worked like this. The control ran in Windows and the screen would sometimes freeze up and not show the position or anything. The machine would keep right on machining until the g-code buffer ran out.

EMC2/Linux tries to do everything in one system. They delegate the I/O to a Mesa card or parallel port, but a single processor handles the interface and the real-time motion control. That sounds good but it seems a bit less robust.

Mach3 is a disaster. It's not a real-time system and it also tries to do the motion control all in one unit. Things like rigid tapping have to be done outside of the control like a parallel system but much more limited. If someone came up with a real-time PLC that could handle all the motion control and just use Mach3 as the interface, they might have something.


Does anyone know if Linux CNC can handle a floating tool changer where the tool numbers do not match the pot numbers? I know that is tricky for a lot of other controls. See Ox's money pit for example.
 
I think what you are wondering about is what linuxcnc calls a 'random' tool changer. This is where the current tool is exchanged with the one in the chain.

http://linuxcnc.org/docs/html/gcode/tool-compensation.html#sec:tool-changers

Linuxcnc can do both. I have a 3rd setup. My tools have a mechanical barcode on them. When I call a tool - the chain runs scanning each tool until it finds the correct one. All possible with linuxcnc
 
You have to understand, with linux if it does not yet do what you want you just have to write the code your self. Honestly if you have ever made or modified your own CAM post, you can modify linux.

Theres no real tool number limit in linux either. well i spose there is i think tool numbers are limited to 4 digits.

Yeah things like e stop and such are not implemented to OSHA stds they can not be, LINUX CNC is a piece of software, its upto you to do the refit to conform, it is possible. Because its real time you just have a IO line monitoring the estop circuit, secound it changes programmes paused - stopped, still knows were it is.

As to pages of ladder, worth remembering most of us Linux cnc users are using monitors far larger and with way more definition than you fanuc guys, we see a lot more per page! Also worth adding, bloated shitty PLC ladders spread across vast numbers of pages generally is not something to be impressed with, it just means the programmes scruffy - not tidied up post writing. Its a lot easier to modify - fix a few pages of ladder logic than it is 50 pages!!!
 
As to G71 theres been more than a few attempts at it over the years, bu its turned out to be pretty hard to do, Simple shoulder cutting versions have been got to work, more complex stuff theres been bugs bad enough that have stopped it reaching prime time so far.

Its a hard code to implement, it requires some heavy trig and a lot of variables that govern its action, based both on its line of G code and also what mode - units the controls running + what the tool profile is. Its a seriously big project, most people have simply chosen to get around using CAM. Equally you need to remember, relatively speaking theres really not all that many lathes out there, most people are interested - after milling not turning capabilities.
 
EMC2/Linux tries to do everything in one system. They delegate the I/O to a Mesa card or parallel port, but a single processor handles the interface and the real-time motion control. That sounds good but it seems a bit less robust.

The trajectory calculation is done on the main CPU and the actual moves are offloaded onto the motion control hardware - basically the same way all modern controls work AFAIK.

Now the reason this is all implemented on Linux and not Windows; The RTOS kernel modules in Linux are much more robust than any of the hacked on driverspace realtime botch jobs that exist for Windows. Likely the reason that Heidenhain build their controls on some variety of Linux. Why all the other MTB's decided to build their front ends on Windows I just can't understand. It's such a terrible platform for anything mission critical.
 
As to G71 theres been more than a few attempts at it over the years, bu its turned out to be pretty hard to do, Simple shoulder cutting versions have been got to work, more complex stuff theres been bugs bad enough that have stopped it reaching prime time so far.

Its a hard code to implement, it requires some heavy trig and a lot of variables that govern its action, based both on its line of G code and also what mode - units the controls running + what the tool profile is. Its a seriously big project, most people have simply chosen to get around using CAM. Equally you need to remember, relatively speaking theres really not all that many lathes out there, most people are interested - after milling not turning capabilities.

That is interesting.
M-Cam solves this inside without much effort and it is hardy rocket guidance software.
Yes some trig and look ahead but not all that hard since you have the base source code to change.
Does this speak to the user base and open source machine control in general?
Seems like a week long project including debug. Must be easier than multi-passing splines with cutter comp on and handling under/overcutting or the classic cutting turbine blades with multiple rotary axis and many tool offsets/corner rads.

Lots of ways to dump part of the work off to another processor or thread.
Mach is an open loop (step/direction) control unless you stick a card under it so yes rigid tapping is hard for it to handle.
EMC2 is different in that it was designed from the ground up to handle the servo loops inside.
Yes, I prefer a second chip lifting this end and a third handling the PLC side.
Partially this is a x86 chip thing which was not meant for real time work but there are ways to make it behave since even the delays are now so darn fast.
Not like the old days when simple gate propagation and clock speeds would get in your way of moving fast.
Bob
 
I can't understand why G71 was never tackled. It's been pretty much standard on every lathe control going back to the old Fanuc 5T in the mid 70s. I'm sure it was around before that too.

Also, I remember that Linux CNC has no built in editor. It just opens your file in note pad or whatever text editor you choose. It works but it's a little cheesy.
 
.....Also worth adding, bloated shitty PLC ladders spread across vast numbers of pages generally is not something to be impressed with, it just means the programmes scruffy - not tidied up post writing. Its a lot easier to modify - fix a few pages of ladder logic than it is 50 pages!!!

The following comment is not directed at LinuxCNC or any CNC in particular. Also sorry for the length and rant like tone, but ladder issues are an item for me.

I've spent lots of time wandering through CNC and general PLC ladders for the past 30 years or so. Many apparently "bloated" ladders are large because the machine builder usually has one ladder for all configurations of a given machine. Does this make the ladder poor or "shitty"? No way. It's much better to have one version that can do it all as required by the machine configuration. Add a parts catcher? Easy, turn on the parameter that "activates" that portion of the ladder. It would suck if one also had to obtain and load a new ladder from the machine tool builder.

When I see small ladders on a machine it usually indicates to me that many good logic practices have been left out. For example, all mutually exclusive conditions should be checked and alarmed if detected. Lets say limit switches for turret clamped and unclamped are both on because one is sticky. This should trigger an alarm rather than let the machine run. Use of a small time delay to ignore contact bounce is another often overlooked ladder item. Leaving all that out surely allows one to create a compact ladder, but in general it would not be considered robust.

Testing during development rarely uncovers the odd behavior that poor logic can produce. Since all parts are new and working properly all functions operate as desired. I worked on a mill once several years after someone did a retrofit. Customer complained about it shifting from high range to low as soon as M30 was processed or the Reset pushbutton was pressed.. Didn't matter if the spindle was running or not didn't matter what speed the spindle was running either, just an immediate attempt to shift to low gear with all the attendant grinding of gears. If the spindle was already in low, then no shift occurred. The hardware cause was a failed in the on condition low gear prox sensor. Ultimately the root issue was poor ladder logic. The omission of a rung to check if both high and low sensors were on could have stopped the attempted shift. Checking the condition of the run output versus the jog output to the spindle drive before enabling a shift in either direction could have prevented the shifting from occurring at high speeds. And so on. There are a few other checks that would have been good to include.
 
G71 has proven harder than it seams, thats all i can say, i have not attempted it, or had a use for it on a linux controlled machine yet just if you read through the threads no one has yet pulled it off. To make the official release it has to get through beta testing which means multiple users making use of it and not finding bugs - problems. Can't stress enough though few and i mean few users are using linux cnc for lathes, its just not a common thing. Theres probably more hexapods being controlled with it than simple 2 axis lathes.

Things like ladder and PLC's are all down to the machine builder - programmer, with linux like a lot of retrofits thats YOU. If you want it totally fail safe then you have to make it so. This is the trade off of doing your own retrofit, you need to be able to grasp the logic well enough to make it do stuff and do it safely with fail safes that stop at any non recoverable errors, which is always easier said than done. Oftern with only one machine this development takes longer and bugs will appear over years compared to a OEM that has a couple of hundred machines out there all in very different environments doing different things. If you can not accept going into a retrofit your potentially going to fuck some stuff up, have to learn stuff and may have some bugs to work out down the line, then you really should be buying the pre made debugged machine from a good supplier with good support.

As to no onboard editor, true, but then thats sorta a std linux approach to most problems, In linux, if you want a drawing programme you load one, if you stick a spread sheet into most documents, you do it using the spread sheet programme all be it nested in the document. You can - are free to set it to load any editor you want, its another easily made change. But i can't stress enough its kinda a basic Linux philosophy, you don't buy a pizza from the super market and go home and cook it, you just go to the pizza place, same with the programming interfaces in linux, you use the best tool for the job every time. Its also not like it affects speed, with Linux CNC running in real time the rest of the applications get shunted around its needs, on pretty much even the minimum spec PC's needed to run - install the ubuntu 8.** my mill currently runs i can easily watch you-tube videos post here or do invoices. Theres so much processing spare running the PLC and motion control really is not a issue. Separate processors for each gain you little.

Other thing with editing in linux, most users are running a keyboard - mouse + a large enough high enough definition screen its easy to have a window pop up and be editing the code quickly and efficiently, not scrolling through page after page line after line on a little 6" square monitor fanuc style, then pecking god knows how many keys and using shift - function buttons to get the letters, pretty much all linux users can type with a keyboard and are use to a keyboard, not like in a typical shop were the operator is only a single finger hunt and peck typer! With the txt editor you have some pretty powerful search find and replace capabilities too.
 
Like other people have said Linux CNC is on you and your abilities. I have the Pico PPMC hardware on my Hurco. The e stop is all hardware driven it just tells the PC it went to estop. I'm currently looking for a turning center to retrofit. The only thing I have left on my Hurco is the tool changer and a bad servo drive left to address. It is nice to pull up inventor or the inventor g code window right there at the machine, make a change, and tell it to run it. Any retrofit is a challenge and a serious amount of hours. Two of the machine retrofits i know one prefers the Siemens, and one prefers the Bosch Rexroth. Unless it's a model machine they have already done, it's a bunch of hours to reverse engineer and retrofit.

Sent from my XT1254 using Tapatalk
 
Un my situation I already had a pretty powerful pc based control with ethernet, full logic, all the servo integration done, etc. I just had to fix a couple parts - it was cheaper to go back to the acramatic 2100 than all the time to change to linux cnc. I have 5 of these devils - no real control issues other than finding replacement boards ( I have a parts machine for that now. If you have the time to do it great, but it still stands that I know of NOONE commercially retrofitting primarily with linux, although I admit I have not looked for that.
 
I don't think you will find anyone willing to do commercial retrofits with open source software and no dedicated hardware support. When a company pays for a retrofit, they are paying for an expectation of support from the control supplier for the expected lifetime of the hardware.

If your Linux PC dies, you have to find another PC that can handle the real time kernel. Then you have to hope that the motherboard is compatible with whatever I/O card you are using. With the way computers change, that is hardly a given. If your I/O card dies, you have to hope whoever made it is still around or start over.

I've worked on a lot of retrofit machines. Fanuc is the most popular. It's expensive and PITA, but they support their hardware back to the stone age. Plus Fanuc can give you a true package with control, servos, drive, spindle motor, spindle drive, encoders, etc that is all going to play nice with each other.

Other controls like Fidia, Fagor, Dynapath, Delta Tau, Siemens, etc can do the same things but are less prolific.

Centroid seems to be pretty good and has a large user base. I can't remember what Ox used on the money pit, but I know he had issues with the random tool changer and the multiple axes.
 
....., pretty much all linux users can type with a keyboard and are use to a keyboard, not like in a typical shop were the operator is only a single finger hunt and peck typer! .

Well that kind of rules me out. I'm used to a keyboard but I am one or two finger typer.
I was able to touch type once before there were computers everywhere. I lost this when the favorite programming style was octal and hex.
People get used to the man-machine interface they work with Fanuc included. How much of a cnc program is text and how much is numbers.

Now after 30 years since their general availability we are moving to touch screens
Systems like EMC have been hampered by simply not enough low buck cpu power. That is changing.
What you once tossed to hardware is now just as fast on the soft side. Look at PLCs, for tons of real time drag look at machine vision.
Bob
 
.....Now after 30 years since their general availability we are moving to touch screens

The pace of touch screen adoption has really been up to machine tool builders Control manufacturers have made them available for quite some time. My 20 year old Mori Seiki has a Mitsubishi touch screen and Amada has had Fanuc touchscreens on their turret punches for at least 10 years.
 
my acramatics came out with touch screens in 1996. I have not had a single one with a working touch screen in over 5 years, they are too expensive to repair compared to a $ 129.00 lcd commercial pc monitor ( of low resolution and common type, which is basically what they had but with touch). Honestly I don't miss the touch screen.
 
I'm not a controls engineer, but my understanding is that most modern CNC controls have two parallel systems. There is a PLC that does the motion control and handles all the real-time events, trajectory planning, I/O, etc. Then there is a second computer system that handles the user interface, editing, program storage, and is what we generally think of as the "control".


EMC2/Linux tries to do everything in one system. They delegate the I/O to a Mesa card or parallel port, but a single processor handles the interface and the real-time motion control. That sounds good but it seems a bit less robust.

Mesa's FPGA cards like the 5i20 in my Lagun retrofit offload a lot of that bandwidth and responsibility away from the PC to the EMCMOT motion controller, much of which is configured in the FPGA itself, so the "single processor" in the PC isn't handling encoder counting, PWM signals and other high-bandwidth things that can cause much crying and gnashing of teeth if they go wrong. A neat diagram of how EMC/LinuxCNC actually handles things can be found here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC_Components

Mach3 is a disaster. It's not a real-time system and it also tries to do the motion control all in one unit. Things like rigid tapping have to be done outside of the control like a parallel system but much more limited. If someone came up with a real-time PLC that could handle all the motion control and just use Mach3 as the interface, they might have something.

My biggest beef with Mach, aside from the price tag is that most of these machines are running in completely open loop configurations - I don't have to tell you that a few missed servo steps can scrap a part, whether its due to a loose wire or pushing your servos hard. Nevermind the difficulty of troubleshooting where the hell those missed steps went, was it a loose wire, pushing past the servo's ability, bad encoder, the list goes on. Some motion controllers make an attempt to do the same thing that a LinuxCNC/Mesa combo does but it seems like all the Mach-based motion controllers do so outside of the PC, some using serial (ugh!) interfaces like USB. Kflop, CSMIO, KSI Centipede, all of these motion controllers keep the actual motion control far away from a PC running an OS that can't be trusted to operate in real time.

IMHO, I'd much rather see ethernet interfaces for motion control (was considering a Mesa 7i80 when I did my build but at the time there was limited LinuxCNC support) or better yet, ethernet support for existing motion control systems like the ones you can buy from Siemens, ABB, Allen Bradley and other industrial automation hardware.

Also, I remember that Linux CNC has no built in editor. It just opens your file in note pad or whatever text editor you choose. It works but it's a little cheesy.

You can specify whatever editor you'd like, but most default LinuxCNC installs have Gedit. I'm sure there are others out there, but you can customize Gedit with plugins to make it do more than just act as a "simple text editor"
Apps/Gedit/PluginsLists - GNOME Wiki!
 
Actually it does not require a high dollar super fast huge memory PC to properly run Linux and have proper real time. My parts for mine ran about $400. Downside to the $400 machine is it is very slow with 3d and inventor. Running the code editor in inventor no problem. I have the hot rod PC in the office. The retrofits i mentioned are using the whole package from the manufacturer. The Linux retrofit is not really intended for someone to be out making money on the retrofits. I mentioned the retrofits as no matter which route the retrofit goes it's a project. Linux CNC is my only alternative to a full industrial package such as the Siemens, Bosch, Fanuc.....

Sent from my XT1254 using Tapatalk
 
2 weeks to retrofit a machine that you have never seen run with a open source PC based control with sketchy documentation and no support?

I'd love to see that. I guess it depends on your expectations. I'm sure he could make the 3 axes and spindle run in 2 weeks. Where theses hobby control retrofits drop the ball is with the details.

Tougher aspects that few address:
Monitoring the pressure cycles of the lube system.
Getting the timing optimized on the tool changer.
Rigid tapping.
Homing from the encoder marker pulses.
Pallet changing.
Spindle gear box.
Probing (tool, work)

Then there is the safety stuff. A real CNC machine will have an E-stop string designed to some ASME spec. All the push buttons will be 24VDC.

Next is the alarm messages. A typical CNC might have 20 pages of alarm code messages. Most of these will need to be programmed into your retrofit so you have a clue what is going on when the machine screws up. Things like tool changer recovery will require macros that you will have to write.

If I recall with Linux CNC, that's going to be a lot of Python programming.

If you can do that in 2 weeks you're hired.

You are so clueless you crack me up.
Keep your head low.....down in the sand.
Ha!
Pray to the Fanuc gods and spend your money with them like a good little machinist. Makes NO difference to me, but...how can you be so ignorant that you
bash something you know NOTHING about, yet state your hearsay as fact.
Really makes you look foolish.

In reality the ONLY people here bashing PC based retrofits and Linuxcnc are the clueless ignorant ones that never bothered to learn just what the capabilities are.



Linux was never intended originally for a multiple pallet 4 axis hmc with a ton of tools and " auxillary axes " for things like tool changers, pallet changers, etc. A few years back ( last time I looked into linux) it looked great for a simple 2 axis lathe, not so great for a vmc and a total no go for a hmc ( as I saw it, you may do as you please). add in that no cam system will ever have a preconfigured post for it and I'd be taking great pains to fix the existing.

Again, stating "facts" that are completely WRONG.
Another ignorant "expert" spouting off.
You are SILLY.
 
Rigid tap, you need a spindle encoder with a once per rev - home pulse thats about 5 wires to hook up, a 5or 24V supply, ground, A signal, B signal and the home signal line. The 3 signals you have to may through the interface, each is a line of code or two in different files all done with a txt editor, its about 15 minutes work if you want the cable run neat, obviously longer if you have to mount the encoder, but most cnc's already have one so its just a wiring exercise.

Lube cycle pressure is easy, std car oil pressure switch, pull the plunger on the pump time how long till switch closes again as pressure falls, (most car lube pressure switches are pressure open) say its 20 seconds. Then write the ladder logic, you have a timer start, running to say 15 minutes, that point it signals pump, second timer say 1 minute kicks off, if switch closes ie pump has developed pressure this timers stopped and another pair is started, first at say 18 seconds, 2nd at 40 seconds. First timer runs out and pressure switch is still open all is fine if not alarm, second timer runs out and switch is still open alarm, second timer runs out and switch is open it resets the original 15 minute timer. Honestly its easy basic ladder logic, takes but a few minutes to write, and you get to have a brew whilst the 15 minute timer runs. IMHO if your employing someone to do this and they can not get that plumbed, wired and proven within the hour, its time to hire someone else.

Homing from a typical micro-switch - then homing pulse, you can setup in sub 15 minutes on the software side. Presumably with this being refit of a cnc the switch, trigger and encoder with homing pulse is already there, even if you need to wire them up it should not take long. Whats more once one axis is working, doing the rest is just repeating more of the same. Will go really quick.

Probing is easy, just connect the wires and set the input channels, on Linux theres already some probe routines written, if you want custom, yeah you have to modify them, if not just down load then, Probe will need calibration too, but thats more or less the same for any machine out there!

Pallet and tool changers are much the same problem to do, there unique to most machines so you have to write your own plc ladder either in Linux cnc or hand it off to a stand alone PLC, which you would still have to write the ladder for and prove it. Theres no free rides on this one, you have to do it your self and that all comes down at this point to how good you are at writing plc code.

Spindle gear changes have been done, 30 minutes googling should find you some examples, though again its a machine dependant thing, could be as easy as a simple relay brining in a clutch coil and a inductive sensor showing the gear change state to things far more complicated, hence again it may end up almost being its own PLC programme.

Safety is never carried out through the control alone, it should be hard wiring and certified components, most drives have some kinda IO for this though so its realy just sitting down and working it out wiring it up. Again a retrofit will have enclsure interlocks and such hence it should all mostly be there, just a wiring exercise.

As to why Linux cnc is not more common in the commercial space, i don't really know, probably much the same reason a lot of the gunu licensed tech - code is not, most people can't grasp the notion that something thats free could be as capable as to what others are charging £10,000's for. Its not just CNC programmes that have this problem, even libre office has this issue, people still spend a fortune with microsoft when the alternatives just as capable and even coded by more than a few of the same people!
 








 
Back
Top