Hi.

I have an issue with an oven that is suspended in the air with an axis in it's middle. This rectangular oven tilts both side to +/- 39 degrees from the horizontal.

Currently there two solenoid valves that are commanded by two relay outputs (0W-16). The issue is that when the oven has reached it's angle or is commanded to find it's horizontal, the motion is stopped instantly causing the entire structure to wobble like in an earth quake. Recently the top plates and structure that holds the pistons in place just snapped. To prevent this they (colleagues) added more structure (welded plates on). I believe that there will be damaged done else where in the structure as it's been strengthen. Not only that, it's once the horizontal angle (0 degree) is reached the motion stops instantly yet the oven still moves and causes mistakes of about one degree and obviously causes the PLC to set off an alarm because the horizontal sensor and the potentiometer don't match.

So time ago an engineer arrived with the idea to use proportional instead. So the manifold has been replaced. What need to be done now is the change the valve and modify some programming in the PLC. We still have one analog output unused.

I believe I can do this myself.

In a publication on Allen Bradley's library I found some document and in RSLogix too. I try to understand how it works. Will it be the amplifier of the solenoid valves that will do the work or will it be the PLC that will gradually modify the output signal?

I leave it here.

I would appreciate examples of ramps.

Thank you.

Classic bang-bang controller issue. Slam equipment into wall..equipment either "recoils" or fails. Not a pretty picture. And that's also why the control you have now is called "bang-bang".

Whichever you choose to do. The key is jerk. It's not the best but the simplest is just a ramp. You can do this in an output card but since this is harder to adjust, I prefer to do it in the PLC (keep the hydraulics "dumb"). First, I'll answer your question directly. Then I'll explain why it will help but it is not a total cure-all.

Say for instance, you have a "set point" and an output variable. The goal is to adjust the output to match the set point. But the output is only allowed to change so fast. So run a timer. Whenever the timer expires, calculate "output - set point". If this value is greater than your limiting value, set it equal to the limit. If it's less than the negative limit, again clamp it to the limit. Then add this to your output variable and wait for the timer to expire again. Scan time is also an issue and can affect operations depending on how often you fire it. So either compensate the timer, or run it periodically.

If you choose the periodic approach and it's a PLC-5, Micrologix, or SLC, then you need to set up the "STI". For ControlLogix/CompactLogix, use a periodic task. Either way, read the manuals for more info on this.

Now, real world code will look something like this if you use the timer approach (written in text form...type them into Logix if this is hard for you to read):

TON (timer on delay). Use the highest resolution timer available. Set it to 1 second. Let's assume a PLC-5 for clarity here. So we have:
TON T4:0 0.01 100 0
Next, if the timer reaches 100 ms (we're going to fire once every 100 ms in this case), flag it:
GRT T4:0.ACC 10 OTE B3:0/0
Next, "reset" the timer by subtracting 100 ms. The fractional amount will accumulate from scan to scan and keep this function operating with a 100 ms cycle even as the scan time varies:
XIC B3:0/0 SUB T4:0.ACC 10 T4:0.ACC
Next, do the subtraction if N7:0 is the set point and N7:1 is the output. N7:2 will be the difference:
SUB N7:0 N7:1 N7:2
Now, check the positive case (I'm clamping to 10 units here...adjust this to get the speed you want):
GRT N7:2 10 MOV 10 N7:2
And the negative:
LES N7:2 -10 MOV -10 N7:2
Next, add this to the output register:
ADD N7:2 N7:1 N7:1

This system deals with speed only and keeps it under control. It will ramp up/down if the output is controlling the flow (speed) of a hydraulic system through a flow control valve, and so controlling most of the problem (instant changes in acceleration). In this case, you will be limiting the rate of change of the acceleration to a fixed amount. If you need finer control (if the system is "cogging"), then decrease the timer limits. If you want to speed up/slow down faster, then change the limits on the acceleration/deceleration.

Do NOT use a pressure control valve (prop valve) for this. You need a flow control valve. Remember...speed is a function of flow, and power (torque) is a function of pressure. Most folks get this part screwed up.

There is still a "3rd order" thing called "jerk" which will be noticeable. It won't be nearly as bad as it was but purists will point this out. If you want to go after this, best thing to do is to put in a real motion controller. I suggest you buy one from Delta Computer Systems since they specialize in hydraulics. I also suggest NOT using one from a hydraulics or pneumatics company because these tend to be hard to use and kind of finicky (and often buggy as all get out).

In addition, you mentioned potentiometer. These are not known for accuracy or reliability in areas where they get used frequently. I suggest you consider an encoder instead. They will last much longer and are much more accurate and reliable. In fact if you use a motion controller (or if you switch to the built-in one in a ControlLogix or CompactLogix PLC), the code is already written for you. You just have to configure it. It will easily allow you to set maximum acceleration/deceleration limits (which is the problem you are fighting). If not, one additional thing you can do with your motion control code is that you can slow down/stop before you hit the mechanical stop so this problem goes away entirely...just issue a stop command in the PLC at some software set points.

This is interesting.

I will investigate this Delta computer....

I will also crate a ladder with only the timer and outputs and watch it go.

What I wonder is if there is an emergency stop. I will also need to verify how I will manage when I'm close the the desired angle. So I have to figure out how long it will take to slow down and how many degrees it makes to determine when the motion has to stop.

Example: if the desired angle is 39 degrees do I need to slowdown at 37 degrees? So that will be be trial and error.

I will certainly come back later and give some information on my trails and errors that way if any one else make some attempt they will have some kind of collusion.

thank you for your support.

http://www.deltamotion.com/products/motion/rmc70/index.php
This may be gross overkill but it would make life simpler. The question is how much time do you want to devote to becoming a motion control expert?
All the ramping and speed control are done inside the controller. A command would look like this
MoveAbs 37 10 100 100 Nearest
This means move absolute to the the final destination of 37 degrees with a 10 degree per second rate and a 100 degree/second^2 acceleration and deceleration rate going the nearest direction. The motion controller takes care of generating the ramps for you,

Peter Nachtwey
President
Delta Computer Systems, Inc.

This is great.

The president of Delta Computers is giving me tips.

I started to read the given link. Theres allot of material to analyse and understand.

Now if I understand, the RMC75P can communicate with and Allen Bradley SLC500/05 and it will receive the command from the PLC. Does this unit needs an encoder? Or do I need to replace my potentiometer with an encoder? If so, I do I connect the encoder? Via the actual analogue input set for 4 to 20mA?

We are talking of an investment that can rage between what minimum and what maximum?

Thank you M. Nachtwey

If there is an emergency stop, then you've opened two cans of worms. First, you need to know what level of safety is called for by an "emergency stop". This is defined by a risk assessment. Risk assessments are not complicated to do but do take time. They are standardized in several different safety codes. If you don't have one already, I highly suggest you use the RIA (Robot Industries Association) risk assessment procedure. It was developed by the robotics industry but is very good for dealing with mechanical equipment, general enough to apply to anything, and has clearly defined endpoints and requirements, which is something many other codes lack. I'm not much of a fan of the software, but I like the code. Link here:

http://www.robotics.org/robotic-content.cfm?id=23

If you call Rockwell's safety department and you've never done a risk assessment before, they can come out and help lead your team through it. They also do lots of public workshops and such discussing the ins and outs of doing one.

Once you have the risk assessment completed, you will know what the requirements are. A standard ControlLogix PLC by the way is good as a "safety grade" processor (aka SIL 2) and can handle redundant inputs and outputs. Rockwell's web site has a document covering this. If you need control reliable (no single points of failure), then you can implement this through a GuardLogix PLC (SIL 3). It is a bit more expensive but at least your safety and standard machine code can live together. However for most projects, it is far simpler and less expensive to simply buy the appropriate level of equipment and safety relays to do the job, and set them up in such a way that they override PLC control and shut down the process independently of the PLC.



What I described in the previous post is a very, very primitive motion control system. What I described is a system which does a trajectory calculation in that it calculates velocity profiles only and attempts to operate on this alone. If you think of a PID loop controller, it does only proportional control (with limits). It does not do the integral or derivative terms. If the gain (currently limited to 1.0) is too low, then it will stop before it reaches the set point. If it is too high, then it will overshoot and if you don't have some external limits in place, then it will oscillate. In fact it really doesn't do anything at all except attempt to shape the acceleration to give you a ramped velocity profile.

If you want something more sophisticated, then you will need a much more sophisticated controller. You will need to create a trajectory calculator such as the above. But in addition, you will need to create a feed forward controller (if you take the raw outputs, that's what you get) as well as a feedback controller (a PID loop can do this but PIV is even better). And I highly suggest you add S-curves to your trajectory calculator to smooth out the path that things follow.

You can do this in a PLC. It's not impossible but this isn't something you can do in a couple hours either. You really need to know a lot about motion control to write one. If you don't have the knowledge and experience (your questions suggest you don't), then you will save an incredible amount of your time (and your time is worth money) and effort by using a motion controller that someone else already built.

As to pots vs. encoders...this is important. If you want a motion controller to work well and to work smoothly, then resolution on the position feedback is very important. It should be at least 4 to 8 times higher resolution than your desired "resolution". For example, if you want it to stop on 1 degree increments, then you need to measure at least to the 0.125 to 0.25 degree increment. It also needs to operate very fast since the motion controller needs to be changing the acceleration of the system on the fly and the feedback loop needs time to be able to make corrections as needed. Robotics systems usually operate at time intervals of 1 millisecond or less, which is a speed that is just barely attainable by a ControlLogix PLC. Pots tend to have problems with repeatability, skipping/arcing, accuracy, linearity, and I'll repeat it again, RELIABILITY. Encoders have none of these problems. Pots wear out much faster than any decent encoder. This is because other than the bearings, encoders don't have any moving parts making contact with other moving parts. They work either optically or magnetically with no physical contact. This translates into 10's to 100's of millions of cycles, far beyond the lifespan of a potentiometer wiper. In addition, you can usually slip them right onto the motor shaft. They can actually bolt directly onto C-face motor faces. This helps make them even more rugged because you don't have a separate small stub shaft and coupling (the weak spot on most potentiometer / resolver systems).

This is an example of a quality encoder:
http://www.encoder.com/model25th.html

There are similar models from other manufacturers. If you buy one from AB, it will really be a Dynapar (that's who makes them for AB), and you can get it from Dynapar cheaper.

Only spec to watch out for with an encoder is vibration and shock specs. Some models are not known for their reliability specifically because they have problems with shock and vibration. The 25T encoder above doesn't have this problem. Neither does the equivalent Dynapar model from AB. There are others that are similar. I've also heard lots of people who like resolvers because of reliability concerns. Those are/were very popular in the iron & steel industry. I don't recommend them for new projects. At this point, they don't hold up any better than good encoders (actually, less reliable has been my experience) and the controller/transmitter is very expensive, making the actual resolver much more expensive than an encoder.

You would need a RMC75E AA1. The E means Ethernet. You transfer data back and forth using MSG blocks. The AA1 means 1 PID with analog in and analog out.
The analog input can be a voltage or 4-20ma. The analog output has a range of -10 to +10 volts but there are converters to convert current.

I you look we can interfaces to many different feedback devices. I usually prefer SSI.