Fanuc Line Tracking Encoder

[Guilleuma Deeken]

Ifyou are comfortable with UFRAMEs andUTOOLs, youshould catch on to line tracking quickly. A tracking frame is reallyjust a standard UFRAME that moves as an encoder signal changes. Themost common use is tracking a conveyor belt. You mount an encoder to oneof the axes or use a friction wheel to get feedback when the belt moves.You then sync up your tracking program with some external condition(maybe a part passes a photoeye), and the robot then moves along withthe conveyor relative to that trigger.

You jog the target to where the robot can reach it. (The target justhappens to be a 100mm cube right in the middle of the conveyor, and youalso taught the tracking frame in the middle of the conveyor.) If youteach a point at the center of the top cube face, what will thecomponents be?

I am using an Ethernet encoder system for single view line tracking. My issue is that my encoder values are matched on both controllers but for some reason if the power is cycled on my system I view the SETUP menu the "encoder enable" defaults to "off". I checked system variables: $ENC_ETHNET= True $ENC_STAT[1] #14 $ENC_EXISTS= True. I have performed a COLD boot after turning "Encoder Enable" to "ON" in the SETUP menu. I had set this up at the shop for runoff before coming into the field and everything functions as it is suppose to aside from the setup menu. Does anyone have insight as to what I did wrong here? I can run the conveyor all day and the counts are synchronized. I have no errors whatsoever. I am getting stumped. The system is in a different country and has occasional power outages. I don't want my customer to lose their line tracking if such events were to happen. Thanks in advance.

I have an application where I need to track the motion of a set of carriages which are driven by a conveyor chain. It would be simple enough to connect the encoder to a wheel that engages with a flat surface on the carriages. The problem is that there are gaps of 6-8" between the carriages. Does anyone know of a product that provides a solution for this, to provide a continous encoder signal despite losses in engagment between the encoder and the object being tracked? We can look at engineering our own solution to this but I was hoping there's already something out there we can just purchase and deploy.

We've actually done a similar setup here recently, where a chain conveyor had control of several carts that the robot had to engage with. What we did, which from my research I think is typical, is mount our line tracking encoder to the conveyor itself, so the encoder moved when the conveyor moved. We then set up a photo eye that detected the leading edge of the cart once it was engaged with the chain, and the rising edge of that signal was used by the robot to record the encoder pulse count used to track that specific cart.

I found the Fanuc line tracking manual to be quite useful, but you have to read through it a couple of times to get the overall picture if you've never done line tracking before. There are also some decent YouTube videos out there on the subject.

I agree with CKing. While I don't think that having the encoder engage "part time" would be necessarily fatal to your process (to the robot, it would just look like the conveyor is starting/stopping), I think it would introduce several potential failure modes that you would have to be very careful about protecting against.

First, having the part-present trigger sensor trigger while the encoder was disengaged would create a false offset between where the part really is, and where the robot thinks it is. Also, I'm not sure how the Line Tracking software would react to seeing a trigger pulse from a conveyor whose encoder is not moving.

Second, you would need to ensure that the encoder stays engaged the entire time the robot is carrying out any Line Tracking motions. This could get especially tricky when running at reduced speeds for debugging.

Finally, any type of "intermittent engagement" is vulnerable to issues of mechanical wear -- after a hundred hours of wear, the wheel may get shiny/slippery, or worn down, changing its motion ratio. Any wheel riding the surface of a carriage, part, or belt, is vulnerable to mechanical slippage, compared to a direct drive shaft or sprocket connection -- dust or debris on the surface of the carriage could disrupt the accuracy of the encoder.

The line tracking solution we currently use is exactly as you mentioned; the encoder is engaged with the drive chain of the conveyor itself and there are part detect sensors that pick up each cart/mold.

This works well enough for our robots that dispense chemicals into the molds without having to make physical contact. However, we are developing a new application where we are trying to get our robots to insert components onto the moving tools, which does require physical contact at a high level of precision. The current method of driving the encoders with the conveyor is far removed removed from the molds themselves, and is not able to capture some of the more minute unsteady motion dynamics. That's why I was hoping to find a method of driving an encoder with the carts or molds themselves, while being able to deal with the gaps in the signal.

Ah, I see. I can definitely sympathize with the precision concerns. In our application we were able to tighten up mechanical tolerances enough to make our process work, but it took a lot of trial and error.

We were not able to place an encoder directly on the moving carriage as we had to queue pulse counts for multiple carts, so we had to have a common reference for all of them. Is this the case for you as well? Or will you only be required to track one cart/carriage at a time? I.e. carriage #1 is completely done with the tracking portion of the cycle before carriage #2 is entering the tracking area/system.

If, let's say, you are only tracking one carriage, and the amount of time that the encoder would be contacting the carriage is more than the robot's cycle time (with a respectable safety factor), then theoretically you could measure directly off the carriage with no real issue. A nuance with this scenario, going back to some of SkyeFire's concerns, is that you would have to ensure that the encoder make contact and begins counting before the part present sensor detects the carriage, and then maintains physical contact with that cart for the entire duration of any tracking. This would have to take into account variances in process speed, robot cycle time, etc.

As far as a line tracking trigger coming in from a "stopped" conveyor, I don't believe that would cause much issue. There is a field in the encoder setup menu for "Stop Threshold," which tells the robot how low the pulse rate must be before the conveyor is considered to be stopped. This may need adjusted in this case.

I was thinking of how to make use of a discountinous signal and it seems like the transition from one carriage or mold to the next would be very tricky to time right. We have a high mix line with a lot of variability in robot program execution times from mold to mold. Many opportunities for getting it wrong resulting in a crash.

Ah. Yes, that's always the key issue with using a line tracking encoder -- ensuring the encoder accurately represents how the object on the conveyor is moving. Any slippage between the encoder and the object makes the line-tracking process that much less accurate.

As I said, I don't think that intermittent contact between your encoder and the molds is necessarily fatal, but it will make things more difficult and prone to failure, so you'll need to put additional up-front work into preventing those failures.

For instance, I'm willing to bet that you're going to see some variance, mold-to-mold, in the distance between the tracking sensor being triggered and the encoder wheel making full contact. You'll probably also see some definite "jitter" in the encoder while it's making and breaking contact, and you do not want the robot to see encoder jitter while it's performing tracking motions. So you'll need to allow generous margins to ensure the encoder is in full contact and running smoothly before the sensor triggers, and also ensure that the robot is finished with its line-tracking motions and turned line-tracking mode off well before the encoder starts to lose contact with the mold's trailing edge.

Also, any irregularities in the mold surface that the encoder rides along will introduce jitter and inject positional "noise", throwing off the robot's accuracy.

You may need to try multiple different wheel materials to find something that makes reliable non-slip contact with the mold surface. And keeping those wheels inspected and regularly replaced may become a necessary preventative maintenance item. You may need to to consider making your encoder mount adjustable or even spring-loaded, depending on just how much mold-to-mold variance you see.

Going further afield, the robot can accept "encoder" inputs from non-encoder devices. So if it were possible to mount some other sensor that could track the mold motion more reliably than an encoder wheel, and have a PLC translate that sensor's output into an "encoder" signal to the robot, that might be a possibility to consider.

For us it's not so much slippage but more like there's just too much mechanical slop from the chain all the way down to the molds. There's a distinct surging motion that the conveyor exhibits that corresponds to the pitch of the gears on the drive. The way this motion is picked up at the chain is very different from how it manifests eventually down at the mold. Maybe it could be that the oscillation in the signal just needs to be phase shifted to match what the robot sees at the mold travels across it.

A job I was on had a solution to the gap problem. They implemented a pair of long air cylinders with linear scales attached to them. They had prawls that would hook onto the pallet during its travel through the station. The prawl would release when the pallet exited the station, and the air cyclinder would retract. While one was retracting, the other was tracking.

3a8082e126