Sign in to follow this  
Followers 0
487mcgill

Turning inches traveled per pulse (a real number) to inches per minute

5 posts in this topic

I am currently trying to get my program to take distance traveled per pulse, which is based off of the diameter, and convert it into IPM. I am using RS Logic 5000 software. If anyone could help me get over this hump I would really appreciate it!

Share this post


Link to post
Share on other sites
Which PLC? Also, what module are you using to accept the encoder input? Some of them have a "rate" feature that gives you the frequency of the input. You could use that to convert directly to IPM without dealing with timers.

Share this post


Link to post
Share on other sites
This is just a random thought, but if you're using an RSlogix 5000 CPU why not create a virtual axis and feed the encoder counts to the virtual axis. Then you can pull average velocity and position and such from the axis. I haven't written this type of code, but know it can be done.

Share this post


Link to post
Share on other sites
Bob, Could you elaborate or expand on your idea of programatically linking an encoder to a virtual axis. I am thinking of using a 1734-IK with an L18-ERM. I would be getting encoder counts or pulses from another machine that has no provisions for mounting a CIP encoder. K5500 does not have aux encoder. Up to what performance do you think this method could accommodate something like registration correction?

Share this post


Link to post
Share on other sites
I've done something like that about 5 years ago, and unless something has changed, I wouldn't recommend it. I was trying to do an infeed system to a packaging line using hardware that somebody else specced (ahem). The encoder was mounted on the flighted infeed conveyor that was part of the packaging machine, and I had to follow it with a metering conveyor to drop product into the flights. After several conversations with Rockwell, I managed to make it function, but there was a delay that caused a pretty noticeable following error once I got over 100 packs per minute (about 60fpm). Which was only about half the required speed. We ended up getting an M02AE card, which I believe has been discontinued. If you can't use a CIP encoder, then my recommendation would be to either upgrade the 5500 to a 6500 and use the aux port, or get the smallest CIP drive you can and set it up as a feedback only axis (no motor attached). But for the curious, here's what I did. If you aren't going too fast, it might work for your application. I set up the high speed counter card to take the input from the encoder. Since it was on a flighted conveyor, I set it up as a ring-counter scaled it to thousandths of inches (mils). Next I set up a virtual axis with the same scaling. Then I created a periodic task with a fast update time (1 or 2 ms) and used a RDP (redefine position) instruction to write the encoder position into the virtual axis position. The method worked, and I was able to gear the metering servo to the virtual axis, and adjust position on the fly. But the update period wasn't fast enough for a high-speed packaging line. While the line was running, it metered fairly well, but every time there was a stop and start the metering servo was slow to respond and product was damaged. Once we switched to the M02AE, the system took off and ran perfectly.

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