Existing Lift Application Cross Linked Feedback

[Chris Elston 79]

I have a lift application with some proportional valves. Each of the cylinders are independent of each other. Each valve has it's own PID controller card. Commanded with an analog command signal scaled to some distance value. Rather than close a loop around the cylinder I want to close a loop around the stroked distance, I.E the top of the platform. There is a mechanical linkage in between the cylinder and the top of the lift. It's like a scissor lift where the cylinder strokes 1 foot, the lift actually goes up 2 feet. So at 5 feet the lift is at 10 feet. I want to keep the top of the platform level within 3/16" of each other. What I really need is a master follower set-up, but it's an existing application and I want to improve the control that exists. Here are my thoughts, I wanted to use a cable encoder and bolt it to the top of each platform. This way I am measuring the stroked distance rather than the cylinder distance. Sometimes there is some slop in the lift itself. So picture two cable encoders bolted to the top of each platform. Each of those cable encoders go to each other's PID controller. This is what I think I want to do...so I am asking you guys...am I nuts? Lift Cylinder LEFT Lift Cylinder RIGHT. I want to take the lift cylinder cable encoder on the LEFT SIDE and put it into the input feedback of the RIGHT cylinder PID controller I want to take the lift cylinder cable encoder on the RIGHT SIDE and put it into the input feedback of the LEFT cylinder PID controller. I will always command both cylinders the same. They will both be scaled the same dead nuts. So in my mind, I think I can keep a level platform with these few changes verses an LVTD on each cylinder. It's not level now. Due to mechanical slop. If you measure the stroke of the cylinder each cylinder is dead nuts, but the top of the platform is not. This slop changes some times and the cylinders remain dead nuts on, because the LVTD is on the cylinder. So my goal is checking the final stroke distance and taking into account mechanical slop. What do you guys think?

[paulengr 44]

Not sure how this is really going to work in reality. As I understand it the best setup is to use one as a master and the rest as slaves. The remote set point will be the distance that the master cylinder has moved..the goal for those control loops is to match the master cylinder height. The goal (set point) for the master cylinder is the intended height. There are only two things to watch out for though. First, you will have to detune the speed of the master cylinder such that it is always operating slower than the others (allow for loop dynamics), and second, if it's possible to have a "% error" alarm/trigger to shut the whole mess down in the event that one of the slaves is unable to keep up.

[TimWilborne 108]

I don't think it's going to work very well...reminds me of a project I did once...actually I might have been crazy enough to do it twice... I'm confused. Why take the left encoder to the right controller and vice versa. I understand trying to make up for mechanical slop, but why not the left cable to the left controller?

[Peter Nachtwey 15]

This is what you need http://www.deltamotion.com/products/motion/rmc70/ The RMC75 can easily synchronize two axes. There is a command SyncMoveAbs and SyncMoveRel that makes this easy. Our older model, RMC100, is used to control scissors lifts on Oprah's stage. Sure you can probably get the system to work but the master/slave axis technique is not the right way to do it. The RMC75 will save you lots of time in the end and be something that can be supported rather than a kludge between two PID controllers.

[Ken Moore 23]

Why left to right and right to left? Master/slave seems better, position of master is setpoint of slave?

[Sleepy Wombat 27]

I would go with Peter;s suggestion personnaly... my 2 cents of experience with the skytower job (although on that one we used a different brand)

[Chris Elston 79]

So basically I am nuts. LOL...thanks guys for yanking my chain. To risky to go out on a limb on this one.

[Peter Nachtwey 15]

One should NEVER gear to a master if you have control of that axis. In this case Chakorules has control over both axes so gearing should not be used, synchronizing should be used instead. Gearing should be done to things like conveyors and feed lines that you have no control over and they run at relatively constants speeds. Even then the big challenge is to filter the encoder input so one gets usable positions, velocities and accelerations to gear too. I have never been a fan of slaving one axis to another for these reasons. 1. The slave lags the master. 2. If the master stops the slave will stop but not the other way around. 3. The master positions are coarse. They are limited by the resolution of the feed back device. Calculating the masters velocity is very coarse. For instance, if the feed back resolution 0.001 inches and the loop is closed every millisecond then the best resolution is 1 in/sec. The best acceleration resolution is 1000 in/sec^2 and this assumes there is no sample jitter. However the target generator generates smooth 5th order motion profiles with the resolution of 32 bit floating point. 4. The coarse master position, velocities and accelerations make it almost impossible to use derivative gains and velocity and acceleration feed forwards and the Kp gains need to be reduced to keep the control signal from jumping all over. Chakorules should use synchronizing. The best way to synchronize two axes is to have each axis follow its own virtual master. We call the virtual master the target and the code that generates the targets motion profile the target generator. In a simple case where the two axes are to be at the same position at all times we just generate the same target profile for both axes at the same time. This is easy do if there is ONE motion controller controlling all the axes, one just issues the same command with the same parameters to all the axes at the same time. Actually on most systems issuing a Move Absolute command to two axes at the same time will do the trick. We have a special Sync Move Absolute command that will move all the axes at the same time and make sure they get to their destinations at the same time regardless of how far they must go. However, this feature isn't needed in Chakorules' case. However the Sync Move Absolute has a feature where if one axis gets a fault it will stop all the axes in a synchronized way if it can. This feature is handy because it automatically prevents binding or skewing. One can do the same thing under program control with a Move Absolute but a small program must be made to test for errors and then shut down the actuators.