Sign in to follow this  
Followers 0
Pulsar2003

RAMP and hydrolics

19 posts in this topic

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. 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. Edited by Pulsar2003

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
It's been a while since this topic was initiated. One of the reasons is that it wasn't one of my priorities. As we have had problems again with the structure failing the priority is back as an important one. Nothing has been done. Nothing has been changed on the oven. I have a recommended valve by the company that maintains our hydraulic system and have performed modifications over the years; it's ATOS DHZO-AE-073-D3. As recommended I will first try using the timer to control the acceleration/deceleration. The concept used for the motion is that two cylinders make the oven tilt. It's the rod side that are used. There for the opposite cylinder will be used meter out to control the movement while the other received oil from the pump. One issue is that the oven is heavier on one side because the bogey has a gear box and other devices just on one side. We are talking an approximate of 700lbs. Before I move on I want to know something: We use a SLC 552 with a P4 and a A13 rack. It is full. On it's right side there is some space where I can easily put another rack with a C7 cable. If I already have an existing program already loaded and I need to make this addition with a NO4V, do I simply add it in RXLogix500 and add the required lines and then upload the new program (taken that the hardware has already been added)? Could that part be that easy? On the other hand there is the ControlLogix or CompactLogix possibility. Can I have two different types on processors handling this? The Ethernet connection of the 552 is already used by the PC that monitors the process with a VB application. Could I simply use the discrete output that controls the valves and hook them to the inputs of the "Slave" plc and then have a simple ladder that would command the +/-10 VDC that would be applied to the new valves? I should also investigate on how much it would coast using a Delta Motion system. I stop here and see what the experts think of it. Thanks.

Share this post


Link to post
Share on other sites
Our controller would be cheaper than using another PLC especially if you consider your time. At this time I think you should try ramping down the analog signal to get a smooth stop using what you have. From your description it seems that is all you want or need. An RMC could make your oven move with precision but you haven't indicated you need precision.

Share this post


Link to post
Share on other sites
Actually I've lost sleep last night trying to figure things out. Had it been a new project is would have done it differently. I studied a part of the ladder that has to do with the rocking of the oven. so there is a subroutine for it and the anther on "output" there is again line with comparison commands. Seems like more than twice the angle. I don't think that it should be too hard to fine tune. It's just trying to get a few tons of steel move or stop instantly. Were are limited in the tilts angles +/-39 degrees. I may need to have a few lines that will recalculate the desired angles as the oven will have to start decelerate shortly before. In other word if we want 39 degrees I better get it to slow down at 38 or else the limit switches will halt it. What is great about this oven is that each recipes can have up to 20 steps with about 25 parameters that can be changed. One of the is the angle to tilt and it can be different from on side to the other. Makes is tougher, but that is just a value that gets moved to a specific N file. As for the accuracy of the angle it can easily be +/-1 degree and I'm sure it would matter. I will put my ladder to the test and see how it performs. After maybe I should post it here? Thanks.

Share this post


Link to post
Share on other sites
This is not clear. If a 13 bit absolute encoder is used the resultion would be about 0.04 degrees per count.

Share this post


Link to post
Share on other sites
This still should be easy. Since you are using analog feedback it will not be as accurate.

Share this post


Link to post
Share on other sites
That is why I want to use an encoder. Potentiometers aren't accurate and they worn out. Definitely I should start the topic. Thanks again.

Share this post


Link to post
Share on other sites
If you are using hydraulic cylinders use SSI MDT rods. Get MDT rods with 1 micron resulotion if possible. It doesn't cost any more or little more. When using hydraulic motors use SSI rotary encoders. The more bits per revolution the better. Nothing you are doing is that fast. I can understand why some of the motion needs to be slow whiile baking/curing but other motions like the arms below in front and in back seem to be too slow. If you can reduce the cycle time by 5% the value of the machine goes up %5 more because it can produce more.

Share this post


Link to post
Share on other sites
The arms actually have various speeds preset. The PLC sends an analog signal (4-20mA) to the drives. What you see on the video is a manual control of the machine and from what I noticed the arm is turning rather slowly. Sure if you have a mold attached the extremities will seem to go much faster. I'd like to point out that the arm is considered as the minor while the oven is the major axis. Currently we cannot change the speed at which the oven tilts on both sides, having a proportional set of valves would offer great opportunities for us as we would have eliminated many problems for the plastic to build up in some angles. You point out yourself something very interesting: If you can reduce the cycle time by 5% the value of the machine goes up 5% more because it can produce more. I my situation, you do you think we could cut the cycle time by a certain amount of time? Or was it just a remark?

Share this post


Link to post
Share on other sites
If the motion is the limiting factor then definitely yes. The motion I see in your video is slow. If your machine sells for 1,000,000 and we can make it 5% faster it is now worth 1,050,000. If it cost $20,000 to increase the value by $50,000 then that is a good deal. Also, many places will not have the room for two slower machines so one faster machine is the way to go. See this <iframe width="425" height="349" src="http://www.youtube.com/embed/GY8cXywBekk" frameborder="0" allowfullscreen></iframe> This platform was used in the making of the movie 2012. It is controlled with our controller. Our controller is also used in flight simulators.

Share this post


Link to post
Share on other sites
If the motion is the limiting factor then definitely yes. The motion I see in your video is slow. If your machine sells for 1,000,000 and we can make it 5% faster it is now worth 1,050,000. If it cost $20,000 to increase the value by $50,000 then that is a good deal. Also, many places will not have the room for two slower machines so one faster machine is the way to go. See this: 6 DOF motion platform with weights This platform was used in the making of the movie 2012. It is controlled with our controller. Our controller is also used in flight simulators. Edited by Peter Nachtwey

Share this post


Link to post
Share on other sites
Here we are AGAIN!! Okay, I've tried the suggestion on the post #2 but it doesn't work properly. I also, though it was not encouraged, looked up at the RAMP command in the SLC literature. And I'm skeptical that is would work properly. I took a good moment to analyse the way the actual program for the oven works and I came up with the ladder I uploaded here. In a recipe there is a time we can set up for the oven to stay at the particular stop angle for it to remain in the position. Also at the end of the cook time we never can tell where the oven will be therefore the POSITIVE direction is demanded to a certain angle and then it move back in the opposite direction and stop when a sensor is ON. This is where the "HORIZONTAL" is demanded for the oven to open up. Also if there should be an intrusion or an E-stop or even a short power flash. So it was not too easy to deal with. I did follow some suggestions by using a timer. I ended up using timers. The Bits B3:0.0 and B3:0.1 would replace the current outputs of the tilting subroutine. The outputs are actually two 120 volts solenoid valves. This means that if the add a deceleration time the opposite output will be energized while the oven has not yet halted this explains the EQU=0(O:4.0) on the first two lines. So if you toggle B3:0.0 and wait and toggle B3:0.1 and keep them toggled the output is a -32767 (-10VDC) that is fine. When you toggle again B3:0.0 there will be a deceleration and then the output will then increase to +32767. Then toggle B3:0.1 back to 0 and the output decreases back to 0 and 0 VDC. The valves we will be using will have an input of +/-10 VDC. Having this type of valves will give us an interesting possibly: to vary the speed of the tilting process. This is why there is % possibility. It will be to set values(i.e.:10,20,30....90, 100%). I've set the timer a 10 seconds to let me enough time to see what goes on in the ladder as I interact to simulated real situation we encounter. Once all is in place I'll determine the acceptable value. The current program doesn't have an STI ladder, should it be a good idea to have a separate ladder independent from the rest? There are two major bugs. The first is if you toggle just B3:0.0 and then toggle it again once the timer T4:0 is done the -32767 output jumps to a positive reading. The DC voltmeter jumps from -10 to 10 and slowly reaches 0 volts. I completely started from scratch and made an alteration to the original ladder by multiplying the last value by -1 before it gets moved to the output O:4.0. It didn't solve my problem. The second one is when I toggle, for example B3:0.0 for 5 seconds and toggle it back again. At 5 seconds I'm half way through and read about -16000 with an approximate -5 VDC. What happens is the the timer T4:2 gets energized and it has no hint that the other has not reached the full time. Probably I would need a condition that would MOVE the T4:0.ACC value to replace the T4:2.PRE. Then it would start where the other ended and avoid this "JOLT". Well I hope you gentlemen are not too tired of this topic. Thank you! Tilt-rev1.RSS

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0