Motion sanity check...

[Controls Guy]

Slick -- I predict that will get used a LOT!   

Thanks!

[BobO]

Due to some other discussions we've had, I now have a better understanding of camming, and it looks like we are going to add it. Only concern I have is that we will probably need to limit the number of cam points to 64 or less. We're using cubic interpolation, which produces a very nice sin wave in just 8 points, so hopefully 64 is enough for most stuff.

Comments?

[Controls Guy]

Wow -- even when I brought it up I didn't assume it would be practical for this platform -- that's amazing.

Not sure  whether you mean a limit of 64 cam points per slave axis or 64 total, but either way I think you're fine.  In the second case, it end up [slightly] limiting the number of slave axes, especially if they're complex, but you're still in the stratosphere relative to the size and cost of the PLC.

This (multi-axis camming) gets used on complicated sewing-machine type machines where there are a bunch of axes all working in synch but all doing different things.  Where in the old days, there'd have been one main shaft and a bunch of cams simultaneously proving motive power and timing to all the axes.  Here's the best example I could find in two minutes of looking on Youtube:  https://www.youtube.com/watch?v=IipB44kxXy8

[BobO]

Not sure  whether you mean a limit of 64 cam points per slave axis or 64 total, but either way I think you're fine.  In the second case, it end up [slightly] limiting the number of slave axes, especially if they're complex, but you're still in the stratosphere relative to the size and cost of the PLC.

It would be 64 X/Y pairs per AXCAM instruction. Since we're using cubic interpolation, the X values are equidistant. They would probably be entered as start/end values (although start may always be zero) and a count of internal points. You would then provide the Y values for each implied X. We would provide some kind of import/export facility so you could use a spreadsheet to manage the data. Also kicking around the idea of reading a profile definition from a file in the microSD.

I wasn't going to even think about this, until one of the motion guys at ADC sent me an example. After looking at it, it's just gearing, where Y = CERP(X) instead of Y = X*GearRatio. The only complication was what to do when initially enabled and Y != CERP(X). I think the easy answer is to say that X needs to be stationary and we'll do a trapezoidal move to CERP(X), after which you can start moving X. Since it is just gearing, there is no accel/decel except as provided by the X move. Stupid simple really.

You will be able to disable the pulse output of any axis, which essentially makes it a virtual master. You will also be able to use an encoder input as the master. If the encoder were driven by a pulse output from some other source you could do three coordinated slave axes on a $200 brick.

[BobO]

One realization that is creeping into our thinking is that having a low cost brick capable of actual 'motion control' opens up huge opportunities for these to be components in larger systems. How many times do you need an axis or two distributed across a large system, and need a small amount of local control logic to handle initialization, or termination, or communications with other stuff, or whatever? Seems like that would be very useful and from a design perspective allows you to button those guys up into well-formed objects. Not an automation engineer so I may be wrong on this, but my years of software development tells me that well-formed objects are the foundation of robust complex system development. My gut tells me that this could be very useful in areas that we haven't been in before.

[Controls Guy]

One realization that is creeping into our thinking is that having a low cost brick capable of actual 'motion control' opens up huge opportunities for these to be components in larger systems. How many times do you need an axis or two distributed across a large system, and need a small amount of local control logic to handle initialization, or termination, or communications with other stuff, or whatever? Seems like that would be very useful and from a design perspective allows you to button those guys up into well-formed objects. Not an automation engineer so I may be wrong on this, but my years of software development tells me that well-formed objects are the foundation of robust complex system development. My gut tells me that this could be very useful in areas that we haven't been in before.

Nope, you're right.  That's exactly the direction I go with a lot of stuff.  Little safety PLC instead of a burner controller, but still interfaced to the same non-safety PLC I used with the burner control, etc.  Or when there are accessory equipment modules that you sell either standalone or with your main equipment, then when you are bundling, still just use the stock standalone accessory unit rather than integrating the software into the main PLC, etc.

[ATU]

Following error is critical in camming. Most times you'll have tooling interference if the axis don't track together. 

[BobO]

I guess it depends on your definition of following error. If you want to see the relationship between what the cam says we should be doing vs what the axis position actually is, that's easy, but since camming uses straight gearing, the only way the two ever fail to stay tight is if the cammed output tries to exceed the max freq of the axis.

Following error would make better sense in the follower mode where there is some expectation of the master and slave not tracking perfectly due to master freq changes or accel/decel/ freq limitations in the slave.

I can easily add the following error I described previously when using encoder feedback, but most don't use encoder feedback.

These are just pulse outputs, not drives with some loop closing mechanism. I'm not entirely sure I understand what you are wanting.

[ATU]

Yes,It would only make sense when you had encoders in the system. I just don't recall there was definitely going to be a following error check.

[BobO]

I think I would describe it more as a method of stall detection, but yes, I would still like to add that.

[ATU]

When you work with independent axis with single move motion, if the motor stalls and doesn't get there in a reasonable amount of time, its usually not a big deal. But if you have 2 or more axis that have to move in unison, like a pick & place, if one axis stalls and the other keeps moving, its motion is a path that it shouldn't be and  more than likely something is going to break. If you can fault closely on the following error for each axis, all axis should be able to stop before this happens. I apologize if this sounds quite obvious. 

[BobO]

I understand, it's coordinated for a reason.

The only counter point is that following error comes from the device with the encoder. That may be a servo drive. Not having it in the profile generator doesn't invalidate the function.

[ATU]

No it doesn't, I think it is a great feature for a low cost PLC, actually pretty amazing. The user just has to understand its limitations and it would be the perfect fit for applications that don't require tightly coupled coordinated motion. I am sure there are plenty of those type of applications out there.

[BobO]

Do servo drives typically have a following error parameter that can be read, or error output that can be triggered?

[ATU]

Most have an error output that can be configured. Drives with communications to read parameters are typically more advanced. Still waiting for AD to sell a servo drive with Ethernet.