Possible RPI issues or some delay in PLC

[Cody Anderson]

Hello all,

I am using a temposonic R series linear transducer for positioning of a lower ram on a hydraulic powdered metal press. The transducer part number is RPS0180UD601A01 and it is connected to the analog input on a 1769-L24ER-QBFC1B processor. There is an HMI where we can set a fill position. When we get to the fill position the lower ram should stop moving up. I am using a 1769-OW16/A relay output card to send the signal to the solenoid valve that controls the upward movement. When I get to the fill position it does not stop right at 4.9 inches, it keeps overshooting, but not consistently. Sometimes I stop at about 5.6 inches. Sometimes it stops at 5.4 inches. Sometimes at 5.35. It would not be an issue if I could get it to stop consistently, but I cannot get it to. So we ended up wiring a limit switch for a test. I did not hook the switch up to my plc, just brought power to the switch and straight to the valve afterwards and the lower ram would stop in the same position every single time with the switch, so I am thinking it has something to do with the PLC causing some kind of inconsistent delay when trying to stop the lower ram. The RPI setting for my analog input is at 80 ms, would lowering this value help at all? Should I try a different output card? Not sure exactly where the issue is yet.

 

[PLCDontUQuitOnMe]

To test your RPI theory, have you tried slowing the ram down and see if the accuracy improves?


I am thinking more of a noise issue on the analog input or something wrong with the mounting of the transducer. Is there any backlash or play in the mechanical side of things that could be causing this?



When you say the stopping distance varies, is that the measured distance from the transducer or the actual measured distance via some other means?


If the ram is not moving, is the value at the analog input changing at all or static? Possible noise caused by wiring issue?



You have checked that your code that is driving the relay output has no other logic in there that could be causing the variation in stopping times? Tried changing to another output to rule out that particular relay output?

 

[Cody Anderson]

I tried messing with the flow control on the actual valve, it did not make a difference. There are supposed to be slowdown valves that turn on to slow the ram down as it gets closer to the position but they do not work.

I am not sure about the mechanical side of things, but again if I hook up just a limit switch to stop this valve, it stops in the same place time and time again. Which would be the measured distance from the transducer displaying on the HMI.

I am going to head back down to the press soon and will check to see if my signal is changing at all when not moving. I am also going to try and hook up the valve to one of the digital internal outputs on the plc instead of using the Output card.

I looked over the code and even adjusted it to make sure nothing else was causing this issue. I do not believe it is a coding issue.

Lastly, when I say stopping distance, its the distance displayed on the HMI coming from the transducer after being scaled in the program. I have not actually taken a physical measurement, but I am going to do that to make sure that the position is actually different and not just displayed different. I am positive that the physical distance is changing because they notice the different in size on each part that is pressed.

Will let you know any results I find out!

 

[Peter Nachtwey]

I never recommend analog MDT rods. Besides the noise, you don't know when the position was valid. I always recommend SSI MDT rods and Synchronous SSI rods on top of that. I know it sounds redundant but it isn't SSI just means the data is sent synchronous to a clock. The Synchronous part mean the data is sampled synchronously to the controller which doesn't' mean much in your case because a PLC doesn't run synchronously. Fast updates are helpful, how fast is the response time of the analog outputs.


Get a scope and input an analog signal and see how long it takes the analog output to respond. How fast is the solenoid valve? Is it linear.

 

[kamenges]

80msec is a long RPI for what you are trying to do. Assume the ram is moving 3"/sec, which isn't all that fast. Just by dumb luck the analog value may be read and transferred to the plc just as you hit the target or up to 80 msec later and anywhere in between. 80msec at 3"/sec is 0.24". There is also the variability of the conversion delay in the module but that should be minimal compared to the RPI variability.

Some of the 1769 analog modules also support an update mode where you can set the rate at which the channel data is updated. This usually comes along with a timestamp. This is Rockwell's poor man's way of trying to inject some determinism into the analog data so that things like integrals and derivatives mean a little something. The problem is this is geared toward the process market so the rates are often pretty long. Again, this just turns into a variable delay relative to the real life thing you are trying to measure. If someone decided to try and use this to get more consistency in the read it probably made things worse.

Are you using any filtering either on the module or in the plc program? While this shouldn't cause variability if the ram is always moving the same speed it will certainly cause an offset. If you filter use the "lightest" filtering you can get away with.

Keith

 

[drbitboy]

80msec is a long RPI for what you are trying to do.... 80msec at 3"/sec is 0.24". ...

This.

As a test, presumably the PLC is waiting to see a measured value of 4.9" or greater before it starts the closing of the valve; if the PLC can store and display that value i.e. the first value it sees greater than or equal to 4.9" (see below), and other tests indicate the signal is not too noisy, then that will make it apparent whether the 80ms is too large and the cause of the variation.

      ______________           ______________
--+--[    LES       ]--+------[   MOV        ]--
  |  [SrcA  Measured]  |      [Src   Measured]
  |  [SrcB       4.9]  |      [Dest    Stored]
  |   --------------   |       --------------
  |   ____________     |
  +--[    LES     ]----+
     [SrcA  Stored]
     [SrcB     4.9]
      ------------

 

[drbitboy]

Also, an image showing a plotted trend vs. time of the measured value and the valve signal might help diagnose the problem.

If a trend is too cumbersome, storing data into an array would help; a time resolution of one or a few ms would be best, but even every scan for a few hundred scans either side of the 4.9" trigger point would not be useless. E.g.

• Start with an empty FIFO (.POS=0)
• FFL a measurement onto a 1000-element FIFO on each scan until .POS reaches 1000
• FFU one item on each scan that the measured value is less than 4.9" AND the .POS has reached 500

 

[Ken Roach]

The 80 ms RPI certainly jumps out as the most likely issue.

1769-L24ER-QBFC1B is one of the 5370 series controllers with built-into-the-box analog and high speed counter modules (the F and C in the part numbers).

Those controllers have four "universal analog inputs", which can be 15 bit signed or 16 bit unipolar. They can be configured for a bunch of different input types, including current and voltage and thermocouple and resistance.

The Technical Data booklet suggests they can be configured for as fast as 11 ms RPI. Studio 5000 suggests you could set it as fast as 0.5 ms.

The first thing I would do is set the filter to 500 Hz and the RPI to 5 ms and see if the repeatability improves.

You can fuss with interrupts and the Real Time Sample feature later if you wish, but first get that analog value updating faster.