jrupp82

CompactLogix using Analog Press Encoder

20 posts in this topic

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 Edited by jrupp82

Share this post


Link to post
Share on other sites
I suspect your problem is with the speed of the analog to digital conversion. What rate does your press run? With default settings on the input card, the A/D conversion takes 50ms. Try changing the input filter selection to a higher frequency. I would generally use an encoder with digital outputs for a press application.

Share this post


Link to post
Share on other sites
My press is running at a max of 32spm. Currently I have the analog card set for a 5ms RPI, that was recommended to be the fastest I should really go. I was worried that this might be the case, was beginning to think that the rotary encoder/sensor I chose was incorrect for the application. I was kind of hoping I could get a little better performance out of it.

Share this post


Link to post
Share on other sites
RPI is the speed of the connection between the input card and the processor. I'm talking about the speed of the analog to digital conversion on the card itself. In the card properties, go to the configuration tab and change the filter setting to 250 or 500Hz.

Share this post


Link to post
Share on other sites
Gotcha, I will check that setting to see what it is set to. I'm assuming faster the better. Is the only downfall to increasing this memory consumption on the processor?

Share this post


Link to post
Share on other sites
Well... Faster means that it will react faster. Downside is that you're more susceptible to noise. The input filter smooths out the signal. I would start with 250 and see if you get any improvement. Also make sure your analog signal is properly shielded and routed to minimize noise.

Share this post


Link to post
Share on other sites
Ok, I'll give that a shot tomorrow and see what happens. Thanks for the advice! I'll keep you posted.

Share this post


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

Share this post


Link to post
Share on other sites
If you are running at 32 SPM, then a 3 degree window is @ 4.44 mSec in time length

Share this post


Link to post
Share on other sites
The fastest you can set the filter is 500hz which is equivalent to a 6ms response. Jrupp, what is the window of time you have to withdraw your tooling? What is the tolerance?

Share this post


Link to post
Share on other sites
JRoss, I would say the window that I have to kick the part off cleanly (by that I mean the point in time where the Kickoff slide must make contact with the part) is about Time (X) plus/minus 100ms max. If the kickoff comes in earlier than that, then the part will not be presented fully out of the lower die. Any later and the bottom punch has fallen (and with it the part) back into the die cavity. In both cases, the part will catch on the die and cause part damage. Here's a link to a short video clip: https://www.dropbox.com/s/8l5wfjkwivyepxw/PartEject.mp4?dl=0

Share this post


Link to post
Share on other sites
That seems like a pretty big window. The symptom is that the eject occasionally happens late or not at all. Sorry to rehash this, just want to make sure I'm clear.

Share this post


Link to post
Share on other sites
Most mechanical style presses have "built-in" Programmable CAMS that are designed to specifically control this type of operation, granted thereare still "time" constraints and propagation delays associated with relay and valve actuation but they are generally pretty "tight" if your press speed is within the original design parameters of the press manufacturer. Does your press NOT have Programmable CAMS?

Share this post


Link to post
Share on other sites
Just a thought , is your ejector pneumatic? If so then Mechanical "drag" or air flow limitations during certain cycles may be the true culprit of your delayed timing ( would also check for "sticky" valve

Share this post


Link to post
Share on other sites
sorry just reread "Linear Servo" ignore previous post

Share this post


Link to post
Share on other sites
JRoss, yeah the symptom is an eject that happens too late. The only time that I would have a "not happen at all" is if I try to tighten up that window shown in the code I originally posted (the RET_GO & RET_GO_BY values). If I make that any tighter than 0.75%, which correlates to 2.7 degrees of press rotation, and actually a 14ms window, the PLC totally misses that window on a scan and won't trigger the eject. As I'm typing all of this, it seems like everything I have set, and the devices I'm using should be fast enough. Is it actually noise, or something else that is causing my problem?

Share this post


Link to post
Share on other sites
typ2112, as for the programmable CAMS, no, our presses don't have this. I'm familiar with what you are talking about, as I spent some time in the Metal Stamping world, but these Ceramics presses are quite crude. Very, very mechanical in nature, with really no adjustment on the timing of things. They operate with a camshaft (without adjustable lobes) and that operates the functions required for pressing. As for the ejection slide, the original setup had a pneumatic on it, triggered by a sensor that would get adjusted at press setup. Since I was adding some additional automation to the press, I wanted to replace that with the Linear Servo, and additionally, add an Encoder to keep track of my press position, prevent crashes, etc. Old setup did not of that, and wrecks are a common thing on our other presses here. I didn't want my automation to be involved in any wrecks if possible.

Share this post


Link to post
Share on other sites
Probably not noise, though I wouldn't count it out. What percentage of the time does it fire late? Are they evenly distributed, or tend to come in clumps. What's the scan time on your PLC program?

Share this post


Link to post
Share on other sites
I would say it all depends, but on average it happens once every 10-15 minutes of run time. Not really a high percentage of time, but a production killer if someone is not standing there (which there will not be). Its also not evenly distributed. Its very random in occurrence; one time it may hiccup 1-2 times within a 20 press strokes, and another time it won't be for 20 minutes. As for the scan time, I have the machine broken into several tasks, all with different priorities and scan times to try and remedy this issue (also from previous advice received). I have a Main continuous task, the task with the above code (and other code) set as a Periodic with an 8ms scan & priority 5, another Periodic with a 25ms & priority 10, and then the SHOE Event that is triggered with priority 1. Again, that stuff is kind of new to me, so I used the advice I received to put this together as explained. I'm not sure if I may have a conflict going on there or not. I can say, however, that I used to have all of the above in one large Continuous Task, as still had the issue. However when all lumped together, the issue was far more frequent. So my changes helped, just didn't fix it all.

Share this post


Link to post
Share on other sites
So I thought I would get back to this thread on how I have been making out. As most of you know, this issue was intermittent and seemed to be "glitchy" in terms of when it would happen. I believe that the simple change that JRoss suggested making, by speeding the Analog card filter to 500Hz, did the trick. I uncovered a "mechanical" issue, if you will, of the parts being pressed sticking to the bottom punch of our tooling because of the high humidity in our pressroom. This sticking showed itself with the same symptoms of the late fire issue that I was having. It wasn't until I looked closer at the parts that I recognized what was happening. All that said, I'm much appreciative of the help I received here. One more question I have, if I may, is regarding my last post about the scan times, and different Task types I have for the programs on my project. I separated everything as above from a recommendation of my local support, but when it came to setting up the scan times and choosing what type of Task to use, I still did a fair amount of guessing. Is there a logical way to go about setting this up? I feel like I did a bunch of that, and it may not have been necessary. I mean the controller memory is still only at about 30% utilized. My gut tells me the processor should have been able to handle these tasks with out all that segregation. Is my gut right, or is this typically necessary? And if so, is there a logical way to go about it? Sorry for the silly questions, just trying to learn as much as I can coming from my MechEng background. Thanks!

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