JJH

Encoder Following Logic

9 posts in this topic

Hey group!

I am working on a project that has a machine that forms cartons that will drop the cartons into a cleated conveyor after they are formed. The forming machine needs to be synchronized with the cleated conveyor so that the formed cartons will drop in between the cleats as they pass under the forming machine. So, in essence, the conveyor will be the master and the forming machine will be a slave to the conveyor and match its position accordingly.

Initially, it was proposed that the conveyor utilize a CIP encoder so it could be set up as a motion axis, but the customer declined that option as they didn't care for using CIP encoders (can't really blame them!). So, a slightly cruder proposal of using two 1024 count encoders was proposed, which they accepted. However, your friendly programmer here isn't quite sure how to make that work!

I think the basic concept is encoder following but but I can't seem to find anything online that really describes the actual process or logic for this. The RA Sample Code site doesn't seem to have anything on there but maybe I just haven't entered the right search keywords.

The forming machine has the following notable components:

  • 5069-L310ER
  • 5069-HSC2xOB4
  • PowerFlex 525 drive
  • 1024 count incremental encoder

As noted, the idea is to have a 1024 count encoder mounted on the conveyor with some sort of ratio so that the counts will run the pitch of the cleats 508 mm). Some trickery will have to worked in to get them to sync at the right time but for the time being, I'm just looking for a method to do the encoder following and asking the group if anyone has some ideas, or better yet, a method, of how to accomplish that.

Edited by JJH

Share this post


Link to post
Share on other sites

I might be over simplifying this but...

Seems the box or case erector needs to know when to drop or push the box onto the conveyor between the cleats.  Why not have a prox detect the cleat and maybe an adjustable delay timer to determine when to "release" the box?

Share this post


Link to post
Share on other sites
36 minutes ago, pcmccartney1 said:

I might be over simplifying this but...

Seems the box or case erector needs to know when to drop or push the box onto the conveyor between the cleats.  Why not have a prox detect the cleat and maybe an adjustable delay timer to determine when to "release" the box?

That's an interesting thought, I could see if that would be an easy but effective solution. However the cleated conveyor has intermittent motion so it was thought the best idea would be to synch the two in order to keep things on track. The customer has a machine that is doing this but they are using a 0-10V speed reference from the drive system for the conveyor and they wanted to move away from that for some reason, possibly due to latency or something like that. 

Share this post


Link to post
Share on other sites

I would lean towards the PROX sensor and timer solution myself. Couple it with conveyor speed feedback (from an encoder or the feedback from the drive, or whatever) so you can tell for sure how much conveyor has passed by when the sensor turns off. If the drive is stopped and the sensor is on, you know exactly where the cleat is and may or may not be able to drop a carton. If the sensor is off, you can wait until the drive is at speed and then drop after a time after a cleat passes.

Out of curiosity, what's their/your reluctance to use a CIP encoder? I've used them in the past and have had zero issues with them. That processor isn't motion capable, so you wouldn't be able to use the built in motion instructions but you wouldn't need to for this.

For the incremental encoder, figure out how many counts there are between cleats and use a sensor to see the cleat. When the sensor turns on, zero the HSC count. That eliminates errors due to conveyor stretch and such and makes it independent of conveyor length.

Share this post


Link to post
Share on other sites
41 minutes ago, Joe E. said:

I would lean towards the PROX sensor and timer solution myself. Couple it with conveyor speed feedback (from an encoder or the feedback from the drive, or whatever) so you can tell for sure how much conveyor has passed by when the sensor turns off. If the drive is stopped and the sensor is on, you know exactly where the cleat is and may or may not be able to drop a carton. If the sensor is off, you can wait until the drive is at speed and then drop after a time after a cleat passes.

Out of curiosity, what's their/your reluctance to use a CIP encoder? I've used them in the past and have had zero issues with them. That processor isn't motion capable, so you wouldn't be able to use the built in motion instructions but you wouldn't need to for this.

For the incremental encoder, figure out how many counts there are between cleats and use a sensor to see the cleat. When the sensor turns on, zero the HSC count. That eliminates errors due to conveyor stretch and such and makes it independent of conveyor length.

They haven't been happy with having to work with Ethernet-based encoders and for me, I think the latency with Ethernet communications isn't the greatest solution for trying to sync motion or be accurate. Obviously you obtain data from a servo drive in that fashion, but all the feedback is held in the drive. I honestly haven't used the CIP encoders much so I could have a gross misconception there but I often cringe when an idea comes of of controlling critical data/positioning via Ethernet.

Share this post


Link to post
Share on other sites
2 hours ago, JJH said:

They haven't been happy with having to work with Ethernet-based encoders and for me, I think the latency with Ethernet communications isn't the greatest solution for trying to sync motion or be accurate. Obviously you obtain data from a servo drive in that fashion, but all the feedback is held in the drive. I honestly haven't used the CIP encoders much so I could have a gross misconception there but I often cringe when an idea comes of of controlling critical data/positioning via Ethernet.

Interesting, and I agree to an extent. It depends on the speed of the movement and how busy the network is. One of the places I've used one was on a dancer arm riding on bimetallic strip to detect delamination and ripple. The dancer mechanism wasn't the greatest but the encoder did really well. The network had a ControlLogix PLC, 7 remote IO racks, 5 HMIs, 5 or 6 drives (VFD, DC), a PC (doing servo control), another PC doing data logging, and a SCADA PC. The strip was only running at about 40 ft/min, though, so it wasn't a super high speed thing.

In a true motion control setting, I don't think I'd use them either.

In your customer's application, the issue with 0-10V signal may just be inability to get an analog input module for the PLC. The last time I had a 5069 analog module quoted, the lead time was long and fluid.

Share this post


Link to post
Share on other sites
53 minutes ago, Joe E. said:

Interesting, and I agree to an extent. It depends on the speed of the movement and how busy the network is. One of the places I've used one was on a dancer arm riding on bimetallic strip to detect delamination and ripple. The dancer mechanism wasn't the greatest but the encoder did really well. The network had a ControlLogix PLC, 7 remote IO racks, 5 HMIs, 5 or 6 drives (VFD, DC), a PC (doing servo control), another PC doing data logging, and a SCADA PC. The strip was only running at about 40 ft/min, though, so it wasn't a super high speed thing.

In a true motion control setting, I don't think I'd use them either.

In your customer's application, the issue with 0-10V signal may just be inability to get an analog input module for the PLC. The last time I had a 5069 analog module quoted, the lead time was long and fluid.

Yes, all lead times on microprocessors, regardless if it's a PLC, a VFD, an ECR module for a car or a cell phone are seriously delayed. Some Rockwell devices are quoting 12 month lead times! I've seen a video of their current setup, it looks like it works so I'm not entirely sure why they want to change it. Most of the time, I ask alot of questions but I sort of committed to making this work, so I'm trying to find a resource to make it happen. I have found lots of articles about what "encoder followers" are, which is just wonderful, but I need logic, not a show-and-tell.

Share this post


Link to post
Share on other sites

Sounds like you need a position follower/electronic gearing but the 525 is not capable of that. Network latency would throw off synchronization when not using motion. Without additional hardware, I don’t think the 525 is a fit for this application 

Share this post


Link to post
Share on other sites
11 hours ago, VFD Guy said:

Sounds like you need a position follower/electronic gearing but the 525 is not capable of that. Network latency would throw off synchronization when not using motion. Without additional hardware, I don’t think the 525 is a fit for this application 

Yeah, not the greatest solution, we were just trying to go with something that was already built to workaround lead times on other devices but we may end up there, anyway.

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