Motion Stop on DI

benaiahhenry

Lifetime Supporting Member
Join Date
Sep 2011
Location
Corning, NY
Posts
265
Hi All,

Here's a little back ground on what I've got and need to do. I've got a machine that has a vertical axis that raises a part of varying height. I've also got a prox switch digital input that tells me when the top of the part is found. So I'm writing a searching routine to raise the part until I find the top, and then move to an offset so the part can be inspected.

I'm looking for suggestions on the best way to stop the axis quickly once the input prox is seen. Is there some kind of interruptable move command that I'm missing, or do I need to detect the input and issue a stop command? If I need to issue a stop would be the recommended method for detecting the input as fast as possible? Should I have a separate high priority periodic, or event task checking the input that then issues the stop?

I'm using RSLogix5000 vs 20 with a Kinetix 350 ethenet drive (2097-V31PR2-LM) and a AB MPL-A1530U-VJ72AA motor. The prox will be a standared input on an IQ16 input card.

I've also thought about instead of trying to stop the drive as quickly, I could use a MAR to grab the position when the prox is seen and then move to my offset based off of that. But as with the stop command, how would you recommend triggering that position capture as quickly as possible?

This isn't a large application so my scan time in my continuous task shouldn't be to high, but I'd like to be able to see the input as soon as possible.

Thanks for any suggestions!

-Benaiah
 
Is there a reason that you need to stop quickly after the edge of the sensor is found? Are you going to hit the sensor physically?
 
I'm not going to hit the sensor, but there is a second horizontal axis that could get hit and I don't have a huge amount of head room. I could slow everything down, but the parts vary a lot in size and I want to make the searching routine as fast as possible. So I'm trying to find a balance between speed of the axis and the speed at which I can stop it.
 
I think you would want to connect the sensor to the drive's 'registration' input, rather than a PLC input. From the user manual:

"Fast registration inputs are required to inform the motor interface to capture the positional information with less than 5 ÎĽs uncertainty."

🍻

-Eric
 
Eric is right that you want to wire the sensor to the REG input on drive. This will give you the most accurate encoder value. The MAR instruction will be what you use for this encoder capture.

I would recommend driving the axis to an absolute value using an MAM instruction. This value will be the worst case you can move to. You would arm the registration before moving and get the value after the move is complete. This way way you won't have to worry about stopping as the axis will automatically do it for you with the MAM instruction. As long as your servo parameters are tuned correctly (and your position is set right), you will never hit your obstacle.

At the end of the move (.PC from MAM), you can use the .RegistrationPosition variable. You can also interrogate whether the event even happened (.PC is on or off from MAR) and do something different in your logic.
 
Eric is right that you want to wire the sensor to the REG input on drive. This will give you the most accurate encoder value. The MAR instruction will be what you use for this encoder capture.

I would recommend driving the axis to an absolute value using an MAM instruction. This value will be the worst case you can move to. You would arm the registration before moving and get the value after the move is complete. This way way you won't have to worry about stopping as the axis will automatically do it for you with the MAM instruction. As long as your servo parameters are tuned correctly (and your position is set right), you will never hit your obstacle.

At the end of the move (.PC from MAM), you can use the .RegistrationPosition variable. You can also interrogate whether the event even happened (.PC is on or off from MAR) and do something different in your logic.

Thanks for the info on the REG input. That will make things easier.

However, I can't just do a MAM to an absolute position and let it finish. Due to the fact that I don't know how tall the part is that I'm finding the top of, I may have anywhere from about a 20-150 mm travel before the axis would crash the part into the horizontal axis above it. That's why I was looking for either a move instruction that could be interrupted by the input, or the fastest way to check the input to issue a stop.

Even using the REG input to capture an accurate encoder position I still need to interrupt the move. How would you recommend doing that? Just watching the .Reg1InputStatus from a high priority, fast periodic task?

Thanks!

-Benaiah
 
Even using the REG input to capture an accurate encoder position I still need to interrupt the move. How would you recommend doing that?

I think that you should be able to detect when registration has occurred by examining a status bit, then you should be able to execute a MAM (with the new target calculated based on registration) and it will essentially replace the existing MAM for that axis.
 
Thanks for the info on the REG input. That will make things easier.

However, I can't just do a MAM to an absolute position and let it finish. Due to the fact that I don't know how tall the part is that I'm finding the top of, I may have anywhere from about a 20-150 mm travel before the axis would crash the part into the horizontal axis above it. That's why I was looking for either a move instruction that could be interrupted by the input, or the fastest way to check the input to issue a stop.

Even using the REG input to capture an accurate encoder position I still need to interrupt the move. How would you recommend doing that? Just watching the .Reg1InputStatus from a high priority, fast periodic task?

Thanks!

-Benaiah

I follow you on the the collision issue. I did not realize it was the part itself that was the crash point. A design problem, eh?

If your continuous task is that slow, then your only option for a quicker response would be a periodic task. But I suspect that you have a lot more room than you think. What is the distance from the theoretical trigger of the sensor (from the part) till the part hits the axis above it? And what speed did you need to travel to find it?

We can figure out how much wiggle room you really have.
 
This is just the sort of application that an EVENT Task is suited to.

You can configure the input module to update the processor on "Input Data State Change", and configure an Event Task to handle the Axis Stop. Make sure you disable all the other input channels, or you'll be stopping more than starting, lol.

2013-01-25_212143.jpg
 
I think you would want to connect the sensor to the drive's 'registration' input, rather than a PLC input

then you should be able to execute a MAM (with the new target calculated based on registration) and it will essentially replace the existing MAM for that axis.

You can configure the input module to update the processor on "Input Data State Change", and configure an Event Task to handle the Axis Stop.

Thanks for the suggestions! Both of those ideas look like they'll do the trick with a couple modifications. The IQ16 input card does not support "Change Of State" so I can't use the "Input Data State Change" event, but the L30ERM does support event triggering based on the Registration Input.

So here is my compiled solution :)

1) Wire the sensor to the Reg input on the drive.
2) Trigger Event task based on that Reg input
3) Calculate target position and issue new MAM in the event task.

Does that sound feasible?

Thanks to all for the input!

-Benaiah
 
So here is my compiled solution :)

1) Wire the sensor to the Reg input on the drive.
2) Trigger Event task based on that Reg input
3) Calculate target position and issue new MAM in the event task.

-Benaiah

Just wanted to give an update on this project. After many delays on the part of our customer the machine was finally built and deployed. The "complied" solution worked perfectly! Thanks again for all the input.

-Benaiah
 
benaiahhenry, thanks for taking the time to report your success.

It's great to get this sort of feedback, many people would just move on, happy that their problem was sorted, and leave the thread wide open.
 

Similar Topics

Bom dia, Estou com uma máquina parada algum tempo, meu servo funciona em modo manual, porém não funciona em automático. Meu equipamento e...
Replies
0
Views
53
Hi currently my existing PLC using AB motor & driver to spin production, however customer want to another set, if this possible we use different...
Replies
1
Views
181
I have always controlled servos in Rockwell motion using position loop. I have an application where one process will push against a servo...
Replies
3
Views
244
Hello Experts, I'm wondering if this has been done before if possible to create an Emulate file that have motion control axis? I tried to...
Replies
0
Views
130
This is not a PLC question, but maybe one of you have seen a product like I am looking for. I have a portable pneumatic misting system that is...
Replies
7
Views
558
Back
Top Bottom