Alarm state should not depend on history

[mark0n]

When I send my motor to a position (-3) outside of the hard limits it stops at -2.96 as it is supposed to. No alarms are raised. But when I send it to the same position again a MAJOR alarm is raised:

SFTB:motorRadPiston            2014-11-17 14:05:43.911588 -3  
SFTB:motorRadPiston            2014-11-17 14:05:48.921004 -2.96663  
SFTB:motorRadPiston            2014-11-17 14:05:55.221718 -3  
SFTB:motorRadPiston            2014-11-17 14:06:00.347807 -3 STATE MAJOR
SFTB:motorRadPiston            2014-11-17 14:06:00.407250 -2.9666 STATE MAJOR

This alarm might cause more confusion than it helps. I also would expect limit alarms only to be raise when HLSV is set to MINOR or MAJOR.

[mp49]

Does it stop on a high limit switch at -2.96? I don't understand why a MAJOR STATE alarm is not raised at that point instead, unless it's transient in some way.

I think I've only ever had HLSV set to MAJOR. It's possible HLSV isn't used in the motor record, but I'm not sure.

[mp49]

HLSV does work with the motor record, I just tested it. I'm not sure why SFTB:motorRadPiston didn't go into alarm state in the first place though. But it was in 'STATE' alarm, not 'HIGH' alarm. That means something else was wrong, like a following error, or the 'Problem' bit is set in MSTA.

[mark0n]

It seems like what happens is the following:

1. caput SFTB:motorRadPiston -3: The motor moves to the hard limit and stops (no soft limit configured). No alarm is raised since HLSV is NO_ALARM.
2. caput SFTB:motorRadPiston -3: The driver commands the motor to move into the same direction again, the motor controller responds with "INVALID CONDITIONS FOR COMMAND-AXIS 1" since the limit switch is active. The motor record goes into the STATE MAJOR alarm state.

I guess to fix this we need to the following before sending the D and GO commands to the motor controller: Check if a limit switch is active. If so we need to check if the new commanded position requires travelling further than the current position. If so we skip the move.

Do you see any issues with that?

[mp49]

What's the issue that you're trying to solve, and why is HLSV set to NO_ALARM? Is driving into that switch a normal routine operation, and so you don't want the record going into alarm state? Could you ignore the alarm state?

I'd rather keep the driver able to send moves and fail (and reflect the controller error state), at least by default. If we decide to add in logic to ignore moves in the direction of a active limit switch, then we can add that in as an option controlled by a parameter.

[mark0n]

For my application hitting the limit switches is a routine operation (as far as I can see there is no way around this since this is a dual axis system with a very complex boundaries/limits). Right now I'm getting tons of Asyn errors related to this issue. At the same time the operator sees red boxes and the "Problem detected" bit of MSTA coming on. All these false alarms make it very hard to notice other ("real") errors. Since my system is very complex I do not want to disable alarms completely (e.g. communication alarms).

[mp49]

Is the second move required, the one that generates the STATE alarm?

Either way, I think it should be easy to add a new parameter that controls if the move() function sends a move command in the same direction as a limit switch. The parameter could be called something like P6K_ALimitDriveEnable. The logic would be:

In move() function:

Read P6K_ALimitDriveEnable If P6K_ALimitDriveEnable == 1 Read motorStatusHighLimit Read motorStatusLowLimit Read motorPosition if ((motorStatusHighLimit == 1) && (position >= motorPosition)) then return if ((motorStatusLowLimit == 1) && (position <= motorPosition_)) then return

How does that sound?

If P6K_ALimitDriveEnable == 0 then it behaves as before.

That way we still catch comms errors, and any other other errors resulting from a normal move.