Position Control using Laser and SEW movitrac B drive

[PierrePaulPaquet]

Hi,

I've been struggling to find information about this, even though it feels like it shouldn't be that hard.

I'm working on upgrading an hoist application. They were doing really basic position control for the hoist using a position laser. It basically was, when you get close to the target position, slow down, when you get to +/- (some value) from the target position, stop the drive and hope you stop at the position wanted. They didn't need huge precision, so it kind of works, but it is pretty ugly.

Now my question is this : using the same equipement, so a position laser giving the hoist position relative to the laser who is at the start of the hoist track and a SEW movitrac B drive (with the ethernet/ip extension, so i can use an ethernet module to communicate with it), how could i do position control that would be more fluid and precise then what they had.

We have a AB plc, so programming is done in Studio5000, but it is not a motion controller, so i don't think i can use the motion instructions as far as i know.

I was thinking of using a PID where my input would be my position laser and the output would be the speed of the drive, but my struggle with this is for the forward/reverse control. If the hoist actual position is lower then the target position, i go forward and my speed is positive, but if my actual position is higher, then my speed needs to be negative.

I know my post is pretty long, i'm not good at shortening things.

Thank you in advance, and don't hesitate to ask for more precision.

 

[drbitboy]

Two choices: feedback control; feedforward control.

With feedback, which is what is already in place, if you want to improve on it, provide more steps of decreasing the speed. Ultimately you could increase that to nearly infinite steps by making the speed proportional to the distance remaining to some target e.g.

• Assume upper target is 100
  • but anywhere between 99 and 102 is acceptable
• Assume you want to start slowing down at 94,
  • and run at 100% speed below 94.
• Calculate speed as absolute value of (102 - measurement) * 12.5, clamped to 100% of speed.
• Stop whenever measurement is greater than 99

The actual numbers will depend on the hardware in place. Similar logic would be in place at the lower target. I assume it will always be necessary to have a hard-stop in place to stop the motor e.g. at 103 in case the PLC comms failed.

With feedforward, you model how fast the hoist moves at various speed references. There is a current thread called [s-curve math] that provides the formula, but it may need to be tweaked as the equipment ages, or re-tuned if equipment is replaced.

But I am not sure motion control capabilities of Studio 5000 cannot be used here.

 

[seth350]

I applaud anyone wanting to improve on code. Kudos to ya.
However, heed this warning.
Once you touch it, you own it. Forever. At least until someone else touches it.

We had an integrator do the same thing with hoists and laser sensors. The sensors were 4-20mA hooked up to a Compactlogix with Powerflex40 drives on ethernet.
We used the exact same logic as you described. We did not need precision, just as long as we raised/lowered within 1/2" of target.

The issues we had were no fault of the logic, but of the lasers. As long as the laser gave the PLC consistent/repeatable distances, they worked fine.

Introducing steam, dirt/dust, different lighting in certain areas, and foggy lenses were our biggest challenges. Mind you, we were using some cheap laser distance sensors from Banner at the time (8 years ago).
We have a dirty process and maintenance upkeep on the lasers and reflective tape was a constant chore. It wasn't long until the entire project was abandoned and reverted back to human control.

At the tail end, we discussed installing encoders to keep track of the hoist position and we tested a set of Ethernet/IP encoders on one hoist. The reason why they failed were due to environment (corrosion) and lack of a way to intuitively home them. Guys would forget to home the encoders or home them incorrectly OR the limit switches would fail (corrosion).

If you read this far, just consider if there is indeed a tangible issue you will solve by rewriting the code. At the end of the day, if an operator is not happier, throughput is not increased, quality is not improved, cost of maintaining is not less, and uptime is not increased then you are doing it solely for yourself.
We all have been there and done it, and yes it does improve the code and troubleshooting later on (if done sensibly).

I am merely just sharing my experience and a bit of advice so as to help you navigate your challenges.

"As you successfully traverse a rotten rope bridge, do not turn to the next traveler and say it is too dangerous. Instead, let them know which board almost sent yourself under." -Me

 

[PierrePaulPaquet]

I don't actually need to upgrade the code since I'm using a code we already had on a hoist for a new hoist, its just that I have time to try stuff before we have to install the hoist at the client's facility and we are going to have 4 more hoists in the next couple years for the same client, so me and my boss are trying to clean up our old programs to make it as easy to debug as possible and as effective as possible.

So I might try drbitboy first advice and test it out. If i can do something better, then perfect, and if not, i'll just use the old code.