Servo Motion--Through the Looking Glass...

[dcooper33]

I've been banging my head against a wall for about a week now with a problem that seems to be a logical impossibility.

The situation is this:
Film winding machine, L61 processor, ver 16.03, Kinetix 6000 servo module talking to Sercos card.
High-speed prox seeing leading edge of rotor bar, wired into 2nd reg input of the infeed drive. Flag is driven by the rotor motor.
An input from a SSR is wired into the 1st reg input for the infeed drive.

The anomaly:
Occasionally, the MAR instruction for the 2nd registration fails to set the .PC bool. When this happens there is a "registration out of tolerance" error, which kicks out the rotor and a wrap-up happens. Now, when trending, I see the trigger bit for the MAR, the .IP, and the "Infeed.Reg2InputStatus" on every bag. But, occasionally, even with all these conditions being present, the .PC still isn't set!

By my way of thinking, if the TrendX object sees the input, then so should the processor. Is this a faulty assumption? Is this possibly just a scan-time issue?

Oh, and there is an MDR instruction at play, but the trend shows that it is not being set, so I still have no explanation for how the .PC is not set.

Any thoughts, wild theories, etc??
Thanks in advance.

Cheers,
Dustin

 

[A353322]

Quick question: is the rung going from true to false between seeing registrations?

 

[Eric Nelson]

Any thoughts, wild theories, etc??

Sure! Why not?...

I can't be much help here, but could the ControlLogix's asynchronous I/O update have an effect? Sounds like the input is turning on, but maybe every once in a while it's turning back off BEFORE that rung is scanned?...



-Eric

 

[dcooper33]

Quick question: is the rung going from true to false between seeing registrations?

Yes. The trigger condition is a window of the Rotor.CommandPosition, which usually goes false midway through the duration of the .IP, give or take a few hundred usecs. The .PC bool, during normal operation, goes true after the trigger condition goes low. The trigger is between 50-80 degs, and the registration occurs at approx 120 degs.

 

[MichaelG]

I do not use .PC

I use Servo.RegEvent1Status and I use this to then Retrigger a MAR

I also look at Servo.RegEvent1ArmedStatus to see if the MAR is in operation or whether I have to use the MDR (Motion Disarm Registration) so I can use a MRP (Motion redefine position)

The .PC can complete some scans later

I have seen (trended) .RegEvent1Status turning on 1+ scans before servo.Reg2InputStatus (I cannot remember but I may have a seen a trend where inputstatus never turned on but eventStatus did)

 

[Mark Buskell]

What is the the default scan time set on the servo module? The default is 2ms but you could change it to .5ms.

 

[dcooper33]

What is the the default scan time set on the
servo module? The default is 2ms but you could change it to .5ms.

I hadn't even thought to check that.
I imagine it is still set as default, I will look tomorrow.

I do not use .PC

I use Servo.RegEvent1Status and I use this to then Retrigger a MAR

I also look at Servo.RegEvent1ArmedStatus to see if the MAR is in operation or whether I have to use the MDR (Motion Disarm Registration) so I can use a MRP (Motion redefine position)

The .PC can complete some scans later

I have seen (trended) .RegEvent1Status turning on 1+ scans before servo.Reg2InputStatus (I cannot remember but I may have a seen a trend where inputstatus never turned on but eventStatus did)

That is interesting. I've been unable to find a good explanation of all the embedded motion instruction tags. Is .RegEventStatus basically the same as an MAR .PC, ie the .IP is high, and the reginput has been seen by the module?
If .eventstatus does indeed indicate a successful registration, then perhaps using it in place of the .PC would solve my problem.

I've also considered shortening the scan rate on the periodic task. It is currently set on 10ms. But, it has been this way for over 6 years, and 20+ other machines are the same way. On the other hand, over the last year, lots of subroutines and tags have been added to the program to perform various tasks such as cull control and data handling and networking. I'm wondering if these are increasing overhead to the point that it is slowing down the crucial execution of timing tasks.

Thanks for the input, fellas.

 

[Mark Buskell]

I am in the process of starting up a very high speed servo project later this week. I have been getting lots of help from the A-B servo engineers plus I will have one on site once the wiring is complete and ready to be tested. One of the things they had me do is buy a seperate processor for the servos. I actually have a total of 3 processors in one rack for this system.

 

[dcooper33]

I am in the process of starting up a very high speed servo project later this week. I have been getting lots of help from the A-B servo engineers plus I will have one on site once the wiring is complete and ready to be tested. One of the things they had me do is buy a seperate processor for the servos. I actually have a total of 3 processors in one rack for this system.

Sounds like a good approach. I have been pushing for upgrading processors for years now, but management just plugs their ears when they hear things like "scan time" and "version compatibility". I'd like to go to the L7x series processors, as we already have logix 5K v21, but mgmt figures if the cpu's are still working, why should they spend some of their bonus money on new ones??? I think that mentality is finally starting to bite us in the a**.

 

[MichaelG]

I am in the process of starting up a very high speed servo project later this week. I have been getting lots of help from the A-B servo engineers plus I will have one on site once the wiring is complete and ready to be tested. One of the things they had me do is buy a seperate processor for the servos. I actually have a total of 3 processors in one rack for this system.

+1 for that recommendation - I have done the same
Fast servo - 2 axis - 25mm movement that must complete in 7 ms (Standing start Full stop) 0.5ms Sercos
normal servo - Master reference from fast servo - 4 axis 5/6 ms sercos
Everything else (HMI, VSD's etc) third processor

Did this on V16 3/4 years ago

 

[Peter Nachtwey]

+1 for that recommendation - I have done the same
Fast servo - 2 axis - 25mm movement that must complete in 7 ms (Standing start Full stop) 0.5ms Sercos
normal servo - Master reference from fast servo - 4 axis 5/6 ms sercos
Everything else (HMI, VSD's etc) third processor

Did this on V16 3/4 years ago

That is only 14 points to approximate the move. What kind of interpolating is being done?

 

[ndzied1]

+1 for that recommendation - I have done the same
Fast servo - 2 axis - 25mm movement that must complete in 7 ms (Standing start Full stop) 0.5ms Sercos
normal servo - Master reference from fast servo - 4 axis 5/6 ms sercos
Everything else (HMI, VSD's etc) third processor

Did this on V16 3/4 years ago

That's like a 200g move. Are you sure of your numbers?