[G59]

Yes understood, but eding does that too. Problem is when you have missed steps, this I don't think edingcnc can compensate for and neither would Galil be able to, without the use of absolute encoders.
This is where industrial controllers have the upperhand.
With abs encoders, even with machine off, it knows where everything's at.

[tommylight]

Someone here already mentioned LinuxCNC. Have a good look at it. It can do all that you are looking for easily, and with no special hardware, it can output anything from step/dir signals to quadrature to 3 phase for stepper and BLDC to 4 and 5 phase stepper signals, PWM in torque or velocity mode etc etc. It can take directly to paraport signals from most encoders used today and has PID controll fully confugurable. The paraport route is good for low speeds so for high speed stuff you need a messa card (realy cheap compared to other solutions) and some H-bridges.
You will spend a week or two learning, but you will not regret it.
It can absolutely do the encoder attached to the moving part of the machine and not to the motor, that you need but you will have to have a backlash free machine.
Tom

[Al_The_Man]

this I don't think edingcnc can compensate for and neither would Galil be able to, without the use of absolute encoders.
.

I am talking an E-stop condition where you remove all motive power from drives & spindle the controller is kept alive.
As the encoders go back to the Galil card, any and all physical moves will be recorded.
Al.

[UA_Iron]

This problem has been solved in industry using two encoders - a linear encoder for position feedback and to close the position loop, and with a rotary encoder on the motor as a commutation device [this actually ends up closing the velocity loop]. Your gains and system response settings are where you manage how the machine handles stalls, increased workloads, and other unexpected situations.

Encoders are part of a servomechanism - they provide the motion or position feedback for which the system corrects itself to.

You can achieve the above with Mach3 with the correct stepper or servo motor controller. I mention their stuff a lot [I promise I have no financial interest in the company], but Copley Controls makes a stepper motor controller that will essentially servo a stepper motor using a rotary encoder and linear encoder (stepnet plus). I imagine their servo controllers are even more sophisticated. You can also use these controllers with encoders as standard stepper drivers and monitor the position of your encoder. When the stepper is servo'd, it will not lose steps. All steps and position are accounted for in the controller. By servo'ing a stepper you can also achieve higher than the stated torque ratings of that motor by adjusting your current control loop, and as another benefit, you will consume less power overall because current is only applied when the feedback device starts changing steps.

There are many high end servo controllers that will close position and velocity loops in the same manner mentioned above.

Someone else in the thread mentioned that you do not want to try and close a commutation loop via an external linear encoder because it will result in unstable conditions. This is why you want the motor commutation on the motor itself and then the addition of a linear encoder is appropriate if your motor controller can handle it.

You want motor feedback with CNC machines; this gives you very good velocity controller - which is very important for your cutting tool and your end product if you are milling. An external linear encoder gives you the added benefit of using less precise mechanical systems (that can get very expensive) but operate them in a more precise manner. Most integrated stages in the 'um' range repeatability range all do ballscrew mapping at the manufacturer, even if it is a C5 grade or better ballscrew. This is accomplished by fitting an extremely precise linear scale to the stage, moving it through the range of motion and registering offsets or variances between measured position and intended position and logging to either the motor or controller (they only do this with servo motors).

You want to close the loop at the motor controller if possible. Offload the commutation and feedback loops from any OS or hardware that was not specifically meant to deal with motion control.

Yes understood, but eding does that too. Problem is when you have missed steps, this I don't think edingcnc can compensate for and neither would Galil be able to, without the use of absolute encoders.
This is where industrial controllers have the upperhand.
With abs encoders, even with machine off, it knows where everything's at.

Not true. Incremental encoders feedback a [typical] quadrature output. A motion controller equipped to deal with encoders will monitor this input and know when it has lost steps. Power loss is when position information is lost, unless you have a battery backup. Balluff is likely to introduce a flavor of their absolute linear encoders that will output quadrature for non-industrial controllers, if you wish to get position feedback after powerloss you would send it a high signal and receive a pulse train equating to the position - it's a neat technology. This approach has been used on magnetorestrictive encoders, but magnetorestrictive technology is not fast enough to close a servo loop.


There are other ways to skin this cat as well. Schneider/IMS has their Lexium Mdrive stepper motor that will absolutely not lose counts, even when completely stopped due to collision. The motor/driver technology reduces speed of the motor until it reaches the desirable torque to drive through whatever obstruction. Certain flavors of this motor can accept a step/direction pulse from mach3.

[G59]

I agree.

[localbroadcast]

Wow what a wealth of information that I really don't know what to do with.. Thanks everyone for your input. My gut feeling is that I want to use an absolute linear encoder.. This way I don't have to worry about any backlash because the machine will always know exactly where it is because of the abs linear encoder.. I could theoretically also use whatever drive system I wanted to.. be it hydraulics, a single phase AC motor, 3 phase AC, brushless DC, brushed DC, servo, stepper.. whatever... Getting to the point where I know how to implement these things is where I am at right now. I need to figure out what exactly I need to accomplish this..

So I know I would need a linear encoder. Check.
I need some type of driver board to control my device that moves... so do they make a hydraulic controller board or would I have to build this myself? If I used a servo or stepper motor, im sure I could find a driver board to use for this.. but if I used a single phase AC motor or 3 phase AC motor, what driver board would work here?
Then... What would I connect the driver board to? Is there another board that I connect the driver board to before connecting it to the computer??

I know this seems like a very basic question, but that's the point of me starting this thread.. I am starting at the basics and you guys are going way over my head!! please if you would indulge me... I would appreciate if you reeled it back in a bit and explained the very basicness of the solution that I need...

Thanks again for all your input guys. very much appreciated.

[G59]

Wow, you have alot of work ahead of you.
First, most controllers send out a signal whether it be analogue or pulses, and the encoder in return sends out it's signal back to the controller to confirm it has moved as commanded.

This is all fine and has been done for years now. Yes even with backlash, it works as it can be dealt with via software. Mostly because backlash is a constant.

The problem starts, when your controller sends out, lets say 10000 pulses out to the motor drive and it expects a move of 50mm(2 inches), as commanded, but the linear encoder only reported back 8800 pulses = 39mm of travel.

How do you tell your controller it's OK and to keep pulsing out until the encoder has output 10000 pulses and when it has reach 50mm to stop abruptly without overshoot or under? You have to think about the ramp up and ramp down routines as kinematics will have huge influence on the ability to stop or speed up? When should the controller start to decelerate to avoid overshoot? At what speed?

Many things to consider here. This is not an easy one by far.

I'm sure their are ready made solutions for this, but this is not a job for Linux or Mach.

Maybe someone here has already done this. For myself, it seems to be alot of trouble.

But it's your project, I can only wish you good luck.

[localbroadcast]

Yes, I understand that I have a lot in front of me. As a wise man once told me.. how do you eat an elephant? One bite at a time..

As to the overshoot issue.. I would hope that the driver or controller available for the job would be able to incorporate PID to compensate for inertia of the system so as it nears its destination it decelerates. Of course the PID I hope would be variable in aspects such as ramp up and ramp down speeds to compensate for the given systems ability to accelerate / decelerate.. Different sizes and types of motors or linear actuators would need different PID parameters.. but that is something I will be able to deal with when I get there. The point of the project I am at right now is basically trying to understand the simple layout of such a system..

Here's what I understand to be the proper layout thus far... correct me where I am wrong, because I suspect I am incorrect at least in one aspect of the following:
I have the linear actuators.. be it a motor or hydraulics or whatever.
I have a linear encoder to detect the absolute position of the axis being moved.
I have a driver / controller. The driver / controller sends a signal to the linear actuator to move to a specific position. The encoder provides feedback to the driver / controller to keep it up to date with the current position of the axis. The driver / controller computates the actuators velocity / acceleration and distance from the position it is supposed to move to. Using this information, the driver / controller will tell the actuator to speed up, slow down, stop, or whatever it needs to do to get to the end destination.

Here is where I may be missing something.. It seems to me that there is a need for both a motion controller board as well as a driver board.
The motion controller board would basically recieve the encoder feedback and do all the calculations for PID. The motion controller will then relay to the driver board what needs to happen.. basically giving the driver board a target velocity. The driver board then tells the linear actuator (motor or hydraulics) exactly how to achieve this velocity... be it a series of pulses, or in the case of hydraulics, a solenoid valve gets opened or closed, etc.

Does this sound like the way the system would be laid out? motion control board followed by driver board followed by the actual linear actuator... and feedback to the motion control board via the linear encoder?

[G59]

Does this sound like the way the system would be laid out? motion control board followed by driver board followed by the actual linear actuator... and feedback to the motion control board via the linear encoder?

Yes.

The driver / controller sends a signal to the linear actuator to move to a specific position. The encoder provides feedback to the driver / controller to keep it up to date with the current position of the axis. The driver / controller computates the actuators velocity / acceleration and distance from the position it is supposed to move to. Using this information, the driver / controller will tell the actuator to speed up, slow down, stop, or whatever it needs to do to get to the end destination.

This is a very simplistic way of looking at it.

The driver / controller sends a signal to the linear actuator to move to a specific position.

The controller talks to the drive, The drive(power/step distributor) energizes the motor or actuator for as long as the controller is talking to it. And yes the absolute linear encoder reports back to the controller letting it know what the actuator has done. In layman's terms.

But, many other things come into play.(Kinematics, Inertia, Friction, Resistance etc..... Of course one bite at a time but in this case, you'll have to gorge yourself sometimes, as many things need to happen at the same time.

Imagine circular interpolation how complex it will be, by not following the motor or linear actuator's encoder, but by only following the absolute linear encoder. I can see problems with jitter and short step. The controller would forever seek and search for perfect position and compensate how?
If it was remotely advantageous, don't you think it would be commonly done by the "big" companies. My guess, TOO expensive to implement.

[Al_The_Man]

.

Here is where I may be missing something.. It seems to me that there is a need for both a motion controller board as well as a driver board.
The motion controller board would basically recieve the encoder feedback and do all the calculations for PID. The motion controller will then relay to the driver board what needs to happen.. basically giving the driver board a target velocity. The driver board then tells the linear actuator (motor or hydraulics) exactly how to achieve this velocity... be it a series of pulses, or in the case of hydraulics, a solenoid valve gets opened or closed, etc.

Does this sound like the way the system would be laid out? motion control board followed by driver board followed by the actual linear actuator... and feedback to the motion control board via the linear encoder?

Basically this is it.
The difference between something like Mach and upper end system such as a Commercial control and even Galil, is that Mach is just a front end and HMI and issues the commands to the motor driver which closes the servo PID loop, so mach has no idea if there is a position error, that is the drives job.
With Galil, the drive can be non-intelligent, no Dsp, Galil controls the trajectory and receives all encoder feedback.
Hydraulic CNC is usually done with a Hyd servo valve which uses a 10v analogue signal and encoder feedback the same as a servo motor.
Al.

[UA_Iron]

The problem starts, when your controller sends out, lets say 10000 pulses out to the motor drive and it expects a move of 50mm(2 inches), as commanded, but the linear encoder only reported back 8800 pulses = 39mm of travel.

How do you tell your controller it's OK and to keep pulsing out until the encoder has output 10000 pulses and when it has reach 50mm to stop abruptly without overshoot or under? You have to think about the ramp up and ramp down routines as kinematics will have huge influence on the ability to stop or speed up? When should the controller start to decelerate to avoid overshoot? At what speed?.

Agreed 100%. This is really the crux of any motion system or dynamic system, the error handling and fault tolerance. These concepts can easily make up nearly 80% of the effort of a complex system.

To the OP - you want to stay away from pneumatics to drive axes, unless this is PhD thesis work or something. This gets very complicated with metering in and out, proportioning and control system components. Not to mention that gasses are compressible and add a very complex dynamic to the whole system. Your system response time would probably lag too much to respond to changing forces; imagine multiple pneumatic actuators driving two axes trying to cut a perfect circle out of wood and you hit a knot, air pressure simply cannot respond in time to meet the increased demands of the cutting tool to accommodate for this. Or even materials with varying grain elements that are harder to cut in one direction than another, pneumatics would be difficult to adjust to these factors. All of these are probably why you'll find hydraulic driven components over pneumatic. This goes along with what G59 has said: certain mechanical systems have superior responses to other systems.

The motion controller board would basically recieve the encoder feedback and do all the calculations for PID. The motion controller will then relay to the driver board what needs to happen.. basically giving the driver board a target velocity. The driver board then tells the linear actuator (motor or hydraulics) exactly how to achieve this velocity... be it a series of pulses, or in the case of hydraulics, a solenoid valve gets opened or closed, etc.

And on top of this, coordinating motion between axes - this is why step/dir pulses or sine wave are ouput from controllers, the response of these protocols is adequate for this task. Ethercat, canbus, RS422/serial are all not suitable for coordinated motion (unless there's something out there that does this at a low level, but there's nothing as far as I know).

I have used the Schneider Mdrive plus2 integrated stepper motors with an external absolute linear encoder and no motor encoder. The typical approach to this is end point correction. Meaning that the stepper motor will move blindly to a set position, check encoder and then correct position and recheck encoder until position is reached (or time out). I am repeatable to within 20um on a belt drive with this routine, but I easily overshoot/undershoot the target position by a good 200um (~0.008 in) or more before reaching this position. This is probably not suitable for a precise cutting or milling operation.

My gut feeling is that I want to use an absolute linear encoder.

What's your budget here? Now you need a controller that can read the protocols that absolute encoders output. An absolute encoder that will respond in time to close a servo loop is going to run you at least 600-700 an axis for 10-20um repeatability per some unit distance (I think it's per meter). Then the cost of the controller on top of that.

An incremental encoder can also accomplish what you seek to accomplish for accommodating, but that is more of controller or software function than an encoder function.

What are the requirements of your machine? Size, cutting speed, material(s) to be cut? - or is this an exercise for a general plan of electrical hardware components to solve the control system component?

[localbroadcast]

Thanks again for the replies, all.

I would not be using pneumatics if I went the piston driven route.. it would most likely be hydraulic oil, or possibly water. Definitely not a gas. If I slipped out the word pneumatics when talking about hydraulic driven machines, my apologies.

I probably wont end up using hydraulics. I just used it as an example of the options I want my design to leave open.
Just throwing this out there to get my point across.. If I wanted to build a cnc type 3 axis machine, and I wanted it to be 50 feet long, and the tool head so large that it weighs 5 metric tons, I don't want to be forced to buy a servo or stepper that is big enough to handle something that size.. A stepper big enough to handle that would be extremely expensive, and most likely impossible to find if one exists.. and not to mention the non-existance of a 50 foot long lead screw.. other types of motion devices would be better suited for something like that.. and I want to have this type of flexibility in my design, even tho this example is a clear exaggeration.

I like that Al has made it clear that to have the machine operate by using absolute linear encoders as the feedback source, I need to use a controller such as galil. This seems like the best option to me..

Encoder sends position to controller. Controller calculates distance from current position and target position. Controller calculates needed velocities and direction to get to target position. controller sends velocity / direction command to driver. Driver sends the correct combination of pulses, sine waves, DC voltage, or open / close solenoid valve signals to the motor / actuator. Motor / actuator starts to move. Encoder reports this new position to controller. Controller uses this information to calculate the machines velocity, new distance from target position, etc. The cycle repeats.

If the controller is designed the way it should be, it will use PID to ramp up the actuator speed until it is moving at full speed, or ramp down the speed as it approaches the target position. If it hits a situation where the expected position is not what is reported back by the encoder, then the controller should have an algorithm to address that situation.

Sound about right? I really like the idea of not having to worry at all about backlash in a system designed like this and working properly.