Max performance

I have been reading the mail on this subject for a while. I am curious about using the Mesa card with a USB interface rather than the parallel port or PCI bus. Has this been done? Are the results as good as the PCI version? It just seems that the PCI is going to go away as the ISA and USB is more likely to survive for a while making motherboard upgrades over a 10 year life a bit easier.

The application would be a 4 axis mill with either stepper or PWM outputs (servo). Max configuration would be for servos and ATC machine using modbus to talk with PLC to handle the ATC complexities.

Typical application would be 5 TPI ball screws running 2:1 reductions at the most but generally 1:1, .0001 minimum moves. Target max IPM would be a max of 750 IPM.

Appreciate any thoughts or experience others reading out there have on the subject.

Thanks

I was wondering if the Mesa card had enough of a buffer to cover the USB issues, sounds like it doesnt.

I guess the other way to go is the parrllel port, I suspect that despite it's age, it will be around for a while or can be added pretty easily in some form.

Is the bandwidth of the parrallel port much different than the PCI bandwidth?

The 7I43 has enough buffer to cover 100 mS or so of motion, enough for USB motion devices (we know, we have non-EMC customers that use the 7I43 in that mode) . _But_, buffer size is not the problem with EMC, buffering can work around lack of real time if all of the motion controller is at the far end of the buffer, but EMC _is_ the motion controller so does not work well with buffered non-realtime hardware. Many things that EMC does require real time response from the hardware, threading and rigid tapping being two examples. These cannot be done in a buffered non-realtime motion control system unless you move most or all of the real time control part to the external hardware. This is certainly possible but is not the way EMC is designed and compromises the flexibility of EMC by creating a more complicated, less reliable, less accessible system with multiple loci of control.

Parallel port connected hardware will have much lower bandwidth than PCI/PCIE connected hardware but more than sufficient for normal motion control tasks. Most EMC servo setups use a 1KHz or so servo loop rate, this is not any problem for the ~1M byte/second parallel port bandwidth. I believe a 4 axis 7I43 servo setup uses about 100 uSec for data transfers. This would limit you to a ~3 KHz update rate (assuming you didn't want to steal more than ~30% of your CPU doing the I/O)

I appreciate the analysis and response. I understand the tradeoff between dedicated hardware and doing it in software is a challenge.

I suppose if you wanted to keep it similar to the way it is and have is Linux/software based and you could split the motion/spindle ratio system from the gui/slow I/O system and have two PC's each with tasks that are less likely to conflict with each other or endanger the operator.

A possible nice daughterboard addition for the Mesa cards would be a spindle and single axis ratio processor that would off load the adjusting of the threading axis speed to servo the single axis threading to the programmed TPI and do a master/follower on the spindle encoder when in rigid tapping or threading mode. I suppose it's always easier to conjecture than to be the one that has to make it so.

Thanks again.

andypugh wrote:

jrobson_1 wrote:

Staying on this topic, what about the acceleration curve? Can EMC be set to accelerate the motor like a modern control which uses an S curve or "bell" curve? Part of getting high performance is not the top speed but the acceleration, with mach one can only have a linear acceleration, which of course then limits one as well.

EMC2 allows you to set acceleration limits for each joint individually. This gives you "S curve" profiles in velocity.

EMC2 does not, currently, do jerk limitation. (d3x/dt3) though there has been some talk of implementing it (so, no S-curves in accelleration)

I am pretty sure that jerk limitation doesn't have any axis performance impact, but it will make the machine tend to leap around less.

There has even been talk of going as far as allowing a jounce limit in EMC2.
en.wikipedia.org/wiki/Jounce

If you really need jerk limitation, it would be easy to modify the limit3 hal function to implement it and to interpose that between the motion controller and the hardware driver.

Sorry Andy, I don't agree with you. With jerk limitation is the limiting of d3x/dt3 , or da/dt, is the rate of acceleration limitation. The velocity profile changes to S-shape. Without jerk limit the curve is trapeziodal. With acceleration/deceleration limiting you only limit rate of change of speed a=dv/dt.

Why jerk limitation is important, and why it should be implemented:

- If we look the analogy of velocity and acceleration translated into motor world, we can make an easy analogy: spped is voltage, acceleration is current, jerk is derivation of current (di/dt). As di/dt can't be unlimited because of resistance and inductivity of coils, is it impossible that current rises so fast to follow trapezoidal trajectory, only S-shaped is possible
- High di/dt rates on capacitor banks shorten life of them, therefore most servo drives have a limitator, in servo parameters list is often called bipolar jerk limit.
- If the trajectory is lagging the pid regulator will try to compensate, but because it is physicaly impossible to reach trajectroy the pid regualtor has to be lossy tuned (smaller gain) to prevent oscilations as it could be if trajectory would have acceptabče physical margins, therefore slower dynamics and higher position errors.

Yes, I noticed that my messages dispeared,...

It's the same I was talking about, that physics laws allow instantaenous acceleration change of objects, while electric motor can't accelerate them at such acceleration.

PID is one essential part of servo system, it corrects speed deviation due to load, drag,.. added s-shape deviation is only small error, but if we are seeking full performance -> zero systematic error, then we shall include the nature of s-shape velocity profile that motor can output.

The analogy between rotational speed and voltage / torque and current still persists, if you don't believe, there are plenty of basic introductions to electrical knowledge that wil prove that.

Regards, Marko