Kinetix 5500 registration event issue.

[Elcan]

Hello all,
About every 3 or 4 months a Kinetix 5500 drive stops recognizing the registration event signal on input 2, even though you can see the bit changes when on-line.
If the program is downloaded the problem clears up for another 3-4 months. This has happened 4 or 5 times already.
Any thoughts?

Thank you!

 

[chantecler]

Hi,

Just guessing, maybe sometimes your axis does not have time to rearm before the registration input changes. See answer 1048754 in the AB knowledgebase.

 

[Elcan]

Hi,

Just guessing, maybe sometimes your axis does not have time to rearm before the registration input changes. See answer 1048754 in the AB knowledgebase.

Hola.
Yes, I had read that tech note in the Knowledgebase, but I don't have an event task like they mention, though.
Gracias, de todos modos.

 

[Elcan]

Attached is the image of the rung were the MAR instruction is located.
I'd appreciate if anybody else can share some ideas about this issue.

 

[kekrahulik]

A couple things I might look for...

record the status of the carMAR tag when things are working and compare it to the status when things aren't working.

You show the MAR instruction. Do you have a MDR instruction to disarm the registration?

When it quits working, does it quit randomly while in use (it was working one minute and not the next) or does is stop working after some event (came back from break and it didn't work)?

 

[Geoff White]

It sounds like a motion instruction faulting. Does it clear up when the power is cycled?
Power cycling or downloading initialises the flags in the motion tags.

I started programming motion when it first came out and there were many ways the motion instructions would get stuck and I would out code in to manually reset the flags of the motion tags (MOVE 0 tag.FLAGS)after they were used or before referencing to ensure they were in a sensible state.

The firmware is much more stable these days but I still do it to be really sure.

 

[DSMR]

It sounds like a motion instruction faulting. Does it clear up when the power is cycled?
Power cycling or downloading initialises the flags in the motion tags.

I started programming motion when it first came out and there were many ways the motion instructions would get stuck and I would out code in to manually reset the flags of the motion tags (MOVE 0 tag.FLAGS)after they were used or before referencing to ensure they were in a sensible state.

The firmware is much more stable these days but I still do it to be really sure.

I agree with this as well. I was finding that I would have to unlatch err bits just to get those blocks to function reliably even though the tech notes said not to.

 

[Elcan]

record the status of the carMAR tag when things are working and compare it to the status when things aren't working.

I'll try it.

You show the MAR instruction. Do you have a MDR instruction to disarm the registration?

No, I don't have a MDR. Do you recommend I add it?

[/QUOTE]
When it quits working, does it quit randomly while in use (it was working one minute and not the next) or does is stop working after some event (came back from break and it didn't work)?[/QUOTE]
I don't have that info. All I know is this happens every 3-4 months.

 

[Elcan]

It sounds like a motion instruction faulting. Does it clear up when the power is cycled?
Power cycling or downloading initialises the flags in the motion tags.

The person in charge of troubleshooting this has been downloading the program in order to fix it. I don't know if they've tried power cycling, but I guess they have.
Which flag(s) should I reset?

 

[kekrahulik]

I would add an MDR. It may help to reset things if they get screwed up.

From the two rungs that you show, it looks like you only need registration armed when ReCutSeq = 10. You might get away with doing an MDR in the previous step? I don't know if doing an MDR when the axis is already disarmed would hurt anything - worth trying.

Do realize that the MAR and MDR are like other motion instructions. Once the rung goes true once, the instruction fires one time, then the registration is armed forever until a reg event is detected or until you execute an MDR. Leaving the MAR rung true or turning it false has no effect on the registration.

Instead of cycling power or downloading, try creating a rung with Unlatch outputs for:
CarMar.EN, Carmar.DN, CarMar.IP, Carmar.Er, Carmar.PC. You can trigger those unlatches with a reset pushbutton or a one shot if the S1_Carriage.ServoActionStatus goes false. So if the servo turns off, you always just reset those tags.

 

[Geoff White]

The person in charge of troubleshooting this has been downloading the program in order to fix it. I don't know if they've tried power cycling, but I guess they have.
Which flag(s) should I reset?

Just nuke the entire .FLAGS structure with a mov 0 motion.FLAGS

 

[nightline]

Just nuke the entire .FLAGS structure with a mov 0 motion.FLAGS

or with a CLR instruction...

 

[Elcan]

Thank you for all the answers!!!!

I really appreciate the feedback!
This is a summary of all the suggestions:

• Add a MDR instruction in the previous step.
• Add a reset bit or push button, or a one shot if the S1_Carriage.ServoActionStatus goes false to unlatch the MAR outputs:
  CarMar.EN, Carmar.DN, CarMar.IP, Carmar.Er, Carmar.PC
• Reset the CarMar flags by moving 0 or using CLR to CarMar.Flags.

If anybody has more ideas or has tried any of these options before, please comment.
I don't know which solution apply. I could apply them all, but I would like to know which ones of them works.
It could take time to come back with my findings, since the issue seems to be happening every 3-4 months...