CompactLogix using Analog Press Encoder

I'll set the scene a little before I explain the issue that I am having. I have an application where I have a Linear Servo Slide acting as a Press Kick-off cylinder on a ceramic press. In order to trigger this Slide accurately, I have installed an Absolute Rotary Encoder (a Turck product) to the press, which outputs an Analog signal for its specific position. I then have this as an input into my CompactLogix L33ERM through a 1769-IF4 Analog Input card. Within my code, I'm trying to capture the moment where the press has presented the part out of the die and it can be ejected from the press cavity without damage the part. Mis-timing on this ejection and the part will clip the die pad tooling and incur damage upon ejection.

Now, one last point of clarification, I am a Mechanical Engineer by trade, so I don't claim to be an expert programmer. But I have learned a lot and have gained experience in programming applications like this, so I can learn quick and should be able to program this task. I have had my local Allen Bradley guy look at the code I'm using for this application, and he thinks it looks good, but I'm still having issues. What I have done, is within the code, I have a window that I look for, of the encoder's position, to trigger the ejection shoe to fire its sequence and kick the part off. However, I have had to make this window so large in order for the code to see it every press cycle, that occasionally, the ejection shoe will be fired at the back end of the window, which is actually too late, and my part is being damaged. Attached is a snapshot of the code.

The OkSamplePress.DN is actually a timer that I have that looks at the current press rate and puts a delay in to not allow the kick-off to fire too early, because I was actually getting a glitch before where the kick-off would fire prematurely for some reason.

I don't know if anyone can offer assistance on this or not, but I would greatly appreciate any help at all. Its become quite frustrating, as the rest of my machine functions quite well, and this seems to be the nagging issue I can't get rid of. Thanks in advance...Josh

What is the spm of the press?
What is the update rate of the analog card?

Press is only running at about 25spm right now, up to a speed of 32spm, so not very fast. I currently have the Analog card set a 5ms RPI. As recommended from my local support, they said that's as fast as I should go, and I would think as fast as I would need.

Could you attach your program so we could check what is in the SHOE task?

Sure thing, here it is:

https://www.dropbox.com/s/p26os0ns4k3f0j7/SCARA_Testing_L33erm_HOME_and_SHOE_REDO.DU-CO.jrupp.BAK000.DU-CO.jrupp.BAK006.DU-CO.jrupp.BAK010.ACD?dl=0

That's the Logix5000 program, with all the tasks of my machine. The code that I posted originally is in the PRESS->R00_Main & the SHOE has a single program in that for the Linear actuator. Bunch of other Tasks/programs for the rest of the machine, but you may also be able to provide me some feedback on the prioritizing and RPI settings for the other tasks. That stuff is kind of new to me, but again, I set it up based on recommendations from my local A/B guy. Please let me know how else I can help, if there is anything unclear.

Thanks!!!

I think you are going to be too slow at 5 ms. At 32 spm you have a 1.875 seconds per stroke. 1.875/360 = 0.0052 seconds per deg. At 25spm you are 0.0066 second per deg.

I can't really tell what your window is for the < >. You might have luck opening up the window some.

Ok, that makes sense, but what am I missing then? Is this device just wrong for my application?

Cam tables would be the best.

https://youtu.be/r5GGLuaChdc

Oh yeah, I think I have seen that setup before, pretty sweet! Unfortunately not an option for me, but sweet!

It's been frustrating, because for the most part, I can see the thing work, exactly like it should. It's just those couple random blips that give me trouble.

Yesterday, I received advice to try changing the filter setting on the analog card to a higher frequency. So far this morning, it seems like changing that filter setting hasn't made too much of an impact. Maybe a little improvement, but not much.

From the code I posted above, is that the right way to capture the moment of time that I want? It just seems like there should be a better way to get a more repeatable trigger point than to identify a "window" of time like I have. That window is something like 3 degrees on the presses rotation, but if I make the window smaller, the program seems to miss it some times. I just keep thinking there is a better way to consistently find the same point on the rotation.

I think you are fighting several timing demons that you may not be able to overcome with your approach:
1. The reaction time of the sensor (time for the sensor to change the analog signal)
2. The scan time of the analog input (time it takes to read and record the analog value)
3. The Controller hardware scan time (time it take the controller to read the analog card)
4. The program scan time (How fast the program scans through all the logic to evaluate the logic that pertains to this)
5. The controller reaction time. (time to make outputs react)

My guess is that your total overall time is well beyond 5ms.

A better approach may be to mount a true encoder and wire it back to a high speed counter card or to a high speed input card working with a high speed output card. With the counter card or the combo input and output, you can effectively map the cards to do the logic. This would bypass the controller delays and possibly get you into the window that you require.

jrupp82 said:

Ok, that makes sense, but what am I missing then? Is this device just wrong for my application?

Click to expand...

Yes, probably. Google "sigpod sciemetric", that would be a better choice. Very popular for press force monitoring.

jrupp82 said:

I have installed an Absolute Rotary Encoder (a Turck product) to the press, which outputs an Analog signal for its specific position.

Click to expand...

Can we have the part number?
the one that I found had a 1ms rise time (quick enough for the analog input RPI)

Did you ever considered something like this?
http://www.amci.com/specialty-io/plcmodules-compactlogix-resolver-interface.asp
and this?
http://www.amci.com/specialty-io/plcmodules-compactlogix-programmable-limit-switch.asp

MichaelG, the Turck Encoder I'm using is this one:

RI360P0-QR24M0-ELIU5X2-H1151

It is a contactless, magnetic absolute for this guys. It seemed like a good option from the point of contactless & all for my application, now I'm second guessing.