Which mode is best for new setups?

Hi Guys,

I searched all over the internet and LinuxCNC forums for an answer to this but can't really find any good information. I was on the phone Friday with an engineer from the Teknic servo motor company. I was talking to him about what I may need to buy for my Z axis now that I've come to realize the servo motor I have is under-powered. I was asking him if it can be controlled with Velocity mode and he said "Why would you do that?" I explained that's how my other 2 servos were working. He then told me that all of the new machines are simply using step & direction for the servo motors. Then you don't need a driver at all, just a power supply and the newer servo motors have everything built into them to move properly. This was intriguing as I started getting visions in my head of new possibilities.

So I'm hoping someone can shed some light on this for me. Is this how the new machines being built today work? Just step & direction and let the servo do the calculations from their internal PID loop etc... it seems elegant I guess but I want to make sure he wasn't just blowing smoke up my backside.

I asked him how you can ensure that your axis is in position and he said the new motors have an error pin and they just throw an error on that pin if they are not in position. He said we just tie that pin to an input for LinuxCNC. You would do this for each servo setup in the same manner.

Ok I'm in agreement with what you said, but then what is the recommendation you are giving? Velocity loop control and feed +/- 10v then manage your own PID loop in linuxcnc?

OK I've got the velocity mode working but would like to test Step / Dir just to see if it behaves differently. I tried this last night but ran into issues when trying to keep the encoders. I set 3 encoders 2 pwm and 1 stepgen. When I tried to run LinuxCNC it squawked about my encoder pins already being defined for the stepgen or something like that. I can re-configure things to reproduce the error again but I need to get around that little issue.

The bigger problem I'm having is I can't tell which PINS I'm supposed to use on my 7i42TA card to output the step and direction. I think IO0 is my step and IO1 is my dir but short of sticking an oscilloscope on those pinouts is there any other easy way to tell. This pin mapping can get confusing when translating from software pins to the true hardware pins.

Guys I have tried a LOT of different things to get step/dir working. Is there an easy way to test step/dir on an oscilloscope? Or can I tell which pins should be spitting out my step and dir commands? I played with my o-scope today and only saw 1 pin pair doing something but that was it. I wanted to test this on my existing Parker servo motor and drive before pulling the trigger on the more expensive unit from Teknic. If I cannot do step direction it will just cost a bit more from what the salesman told me.

The VELOCITY drive I'm thinking about getting for my Z axis is this:
CPM-MCVC-3441S-RLN ($388)
Not sure if I need the drive which is IPC-5 ($248)

Hi hatch789,

Full disclosure first: I’m an engineer who works at Teknic (not the guy you spoke to). Obviously, I’ll understand if you feel I might be biased because of that, but I decided to chime in anyway, so at least you’ll have another experienced opinion to consider. And if anyone on the forum wants to ask questions about any of my points, I’ll be happy to engage in a discussion.

I think there are two questions to consider:

1) Is it a better system design to close all the servo loops (torque, velocity and position) with the same device or is it better (or at least equivalent) to distribute the servo loops between multiple devices (e.g., like your current setup—torque and velocity in the servo drive, and position in the LinuxCNC software).

2) Should you send the raw encoder information to the controller (in your case, LinuxCNC), or send a high-level feedback signal (e.g., a digital signal that confirms everything is functioning)?

I think the first question is easy. In all position servo control systems, the three servo loops are tightly interrelated (any change in one means a change in the others), so you want the tightest possible synchronization between them. In other words, you want the absolute minimum delay between the time the servo reads the encoder position and the time the torque changes at the motor shaft to affect the velocity to compensate for any position error. This can be proven mathematically and empirically. If the CPU that reads the encoder position has to communicate to another device that is controlling the velocity and torque, there will be a time lag that will hurt performance.

Even if the analog drive itself is very responsive (which they can be), splitting the loops between two devices will significantly compromises the overall system responsiveness (which is what matters). In addition, the analog signaling has its own problems of noise and drift that fully-digital devices don’t have.

When I started at Teknic in the early ‘90s, the state-of-the-art microprocessors were not powerful enough to handle the math required to close all three loops. So your current architecture (where the controller handles the position loop and sends an velocity signal to the motor drive) was not uncommon. But around that time, Texas Instruments introduced a DSP that was powerful enough to handle all the loop calculations. Teknic introduced a product in 1994 that utilized this DSP to close all the loops in one device, and the performance was exceptional. (There are also are a number of other advantages to this architecture that are beyond the scope of this already long post.)

Teknic sells drives that operate in either mode. They can be configured to run in all-digital mode (closing all the loops) or analog mode (closing the velocity and torque loops, or just the torque loop) and accepting an analog command from another device. I can say without reservation that the digital mode is always the better performer by a wide margin. (The only customers we have who use our drives in analog mode are OEMs who need to do so for legacy reasons.)

If, as I recommend above, you don’t use the controller (LinuxCNC, in your case) to close the position loop, then the controller does not need to process the raw encoder signals.

But, going back to question #2, if you have access to the raw encoder signals, should you send them to the controller anyway just for status information? Sending the high-speed encoder data through a cable to another circuit on a separate device adds cost and many more opportunities for system failure (e.g., intermittent cable/connector issues, noise corruption, etc.). So how can the controller get feedback about what the servo is doing?

We recommend using a status bit (in the controller cable) to close a supervisory loop with the controller. In other words, you let the servo drive CPU close all of the high-speed loops, and then keep the controller “in the loop” by letting it monitor whether the command is being faithfully followed (or not). On Teknic products, this status bit is called HLFB (High-Level FeedBack) and can be configured in a variety of ways depending on your specific needs.

This gives you the best of all worlds. You get a fully closed-loop, high performance servo system that will run with minimal error, and you have low-cost, reliable status information that the controller can use as you wish. For example, you can set the HLFB sensitivity relatively low and use it as a signal to simply stop all axes when there is significant error, or you can make it sensitive and use it as an early warning to tell the controller that your feed rate is too high and to slow down before the error becomes significant to you.

One final point, if you do choose to go the route of using velocity mode for some reason instead of step & direction, you should NOT buy a Teknic ClearPath velocity motor (i.e., do not buy the MCVC model you mentioned). Although this motor accepts PWM velocity commands, and could theoretically be used, it was designed for pure velocity applications, and would not give you very good performance in a demanding positioning application like CNC. (The technical details to explain this are too complicated to go into here.) You would have to buy a velocity drive from a different company (we only sell our analog drives to large OEMs).

Regarding setting up LinuxCNC for step/dir operation, I know very little about LinuxCNC specifically, so I can’t really help with that, but maybe Googling how people use your hardware with stepper motors would be helpful. A stepper motor setup should work fine with any SD-series ClearPath servo motor. I know we have customers that successfully use LinuxCNC with ClearPath-SD (step and direction) servo motors. (You will need an IPC-5 power supply, or equivalent, by the way, to power these motors.)

Good luck with your project!

Best regards,
Warren G.

Thanks, I appreciate that. But I wonder how many people will agree with "concise"?