Improve speed and/or accuracy??

[esp400]

Hi,

A little background before the question: The company I work for makes switches. One contact is fixed and the other is moveable on an actuator. We test the force necessary to move the actuator to close the switch to ensure it is serviceable. Currently, I am using an air cylinder to close the switch. The cylinder pushes up against an adjustable strut(for smooth slow movement), the switch we are measuring, and an LVDT all at the same time. The tooling that contacts the actuator to close the switch has a load cell connected to it so that we can monitor the force while the cylinder is pushing on the actuator. The three points we monitor are: When the actuator is first contacted(1 ounce), the point the switch closes, and the when the actuator bottoms out at 32oz of force. The processor we are using is a SLC 5/03 and a Micrologix processor as well. The Micrologix simply turns on some relays to start the test while the bulk of the data goes in the SLC. I have scaled both the LVDT and the load cell and their inputs are feeding the program as IIM with an I/O interrupt. My scan times are around 20ms. I'm using an Omega button type load cell LCKD-25 and a Trans-Tek 353 LVDT.

There is a lot that is really inefficient about this test. The pneumatics are probably not the best way to move the actuator and LVDT. The cylinder presses on an adjustable strut instead of just a fixed surface. There's probably more but I'm trying to be mostly general here. My switchpoint is about the only consistent measurement I have. The measurements should be within a certain tolerance and are not. They jump all over the place. Especially the last measurement where we capture 32oz force measurment.

If anyone has any suggestions for improving accuracy or speed(scan time), I'm all ears. I've tried most everything that is feasible that I can think of.

Thanks!

 

[gclshortt]

Sounds like an interesting application. You mention your pneumatics on the system. I would use gravity instead if you can to trigger the actuator and use the flow control to limit the exhaust for rate of decent.

Just a thought,
Garry
http://www.accautomation.ca

 

[esp400]

Ultimately, I would like to upgrade to a servo motor so that it is controlled all the way through the motion and take all of the variables of pneumatics out of the equation. i.e. regulators, fluctuating psi, blow by in cylinders. But it needs to work better soon. No time for a big redesign yet.

 

[just the cowboy]

20 ms scan time seems like alot

You say your scan time is 20ms? That seems like allot I have seen some large operations that are not that long. If this is true and are doing other things in the program you may need to use a STI or small dedicated PLC.

AC or DC outputs to valve?

Have you thought about servo instead of air? A small servo and gear reducer will get you repeatable positioning for the motion part of your test, this should help with the output reading as well. Garbage in garbage out.

 

[esp400]

DC outputs to valves. Will look at STI. Servo is in the works. No manpower at the moment so it needs to work as is.

 

[esp400]

I tried to implement an STI. We had an I/O interrupt on the rung for the IIM. I got rid of that and put the STE above the IIM rung and I put the STD and the end of the subroutine. The book I have said that status file S:30 is where you enter the time interval in 10ms increments from 1-32767. But when I went into the processor file on the STI tab, the increment showed it in 1ms increments. So I made the interval 1ms. S:31 is the program file to be monitored. It already had a 13 in it and I modified ladder 13. I assume it just picked that up. What if there is more than one file to be monitored? What goes in S:31? Anyway, I started the program and it immediately faulted the scan time watchdog. So I cleared major faults but I'm having issues with the program now. Outputs for that station are now stuck on. OSR's in the program are not completing the other half of the rung to unlatch outputs it appears. The logic has not been changed so I'm sure it is the processor. I'm not sure if I implemented the STI correctly or had the interval too low or if I should have reset something else. Any thoughts?

Thanks

 

[LadderLogic]

I would suggest talking to Yaskawa as a possible option for a small servo solution. They are close enough (Waukegan, IL) so an application engineer could stop by and see the actual system.

A servomotor operating in torque control mode sounds like something that might work here.

 

[Peter Nachtwey]

Something like an Exlar and Yaskawa drive would work but a load cell would be required because there is so much internal friction in the Exlar that 32 oz let alone 1 oz would be small compared to the friction.

For fine control I would use a linear voice coil actuator if the stroke isn't too long. A PLC is too slow to control one of these.

 

[esp400]

While I completely agree and it is one of the first things I suggested to my boss, all of our automation resources are tied up until December. I like the STI instruction idea regardless of how the actuator is being moved.

 

[kamenges]

It sounds like you were already using an I/O interrupt routine to capture something. What was that something? If the I/O interrupt was working correctly you won't get any better response from an STI routine.

Keith

 

[Doug-P]

We had an I/O interrupt on the rung for the IIM.

What does this mean? Interrupts are configured in the processor status area.

 

[esp400]

The I/O interrupt was capturing three IIM outputs. Because this SBR is not in the main file#2, you would think it wouldn't make a difference. I thought the same as you. However, the scan time is cut in half as soon as I try to employ the STI. I still cannot get it to work. It is ignoring the entire STI zone and since I have the STI zone around the entire SBR#13, it never outputs anything from the SBR. The STI should be more efficient because it will get called to run and capture the inputs(measurements) when the cylinders that move the measurement devices( LVDT & load cell)are latched from SBR#6. Instead of being always on, it will look over there only when its run and the interval it's checking the inputs can be specified as well. What I'm seeing right now is that the Lost Bit is set all the time. I don't know what impact this has. Whether it shuts the STI down or not. I only know that if the STI timer overflows that the pending bit gets set and if the STI starts again then the Lost bit is set and it is supposed to warn you. I get no warning and nothing is moving. So I guess it will run slow for now til I get to play around with it again.

 

[Doug-P]

It sounds like you were already using an I/O interrupt routine to capture something. What was that something? If the I/O interrupt was working correctly you won't get any better response from an STI routine.

Keith

What he said. The manual states "The DII reads the first byte of input data of a selected discrete input
card at least once every 100µs". That's at least ten times faster than you'll get with the STI. What triggers the DII?

 

[esp400]

The DII is triggered by using an input file. You then establish another word file that is compared to the input file. Every match to non-match increments an accumulator and when the preset value is reached the DII runs.

 

[kamenges]

So what digital input were you using to trigger the input interrupt? I mean, what physical input in your process? It sounds to me like all you have are analog inputs?

I wouldn't enable and disable the STI the way you are showing. Let the STI run all the time. Just put as little into the STI as you can. Use it to compare and record values. Do all the processing in other locations.