Alarm Digital Instruction Acting Weird with Inhibited Input Module

I've inhibited all of my input modules on my program while I'm testing at the office. All the digital input signals are mapped to their respective tags, and all of them are working as expected, except for the ones that are tied to Studio 5000's Alarm Digital instruction.

I've mapped these problematic inputs to their respective Alarm Digital instruction, with a rung for each input with goes to the ".In" for that tag of the ALARM_DIGITAL type. When I run run the controller with the input cars inhibited, non of the inputs are high, but i see the .In for all the digital alarm going high and then low ever second or so.

Again, the reason I think it must be something with the Alarm_Digital insturction is because all of the other inputs are not acting this way if they are tied to a different type of instruction.

The module that I've inhibited is a 1734-IB8/C if that makes any difference.

Thanks Guys.

That's fascinating !

Is your goal to figure out why they're behaving this way, or to simply disable your ALMD instructions while the POINT I/O are Inhibited ?

If it were me I would do both.

For the first diagnostic, add a CTU to the rung in parallel with the ALMD and see if it increments.

Then use a GSV instruction to get the Module's EntryStatus and use the Running status (highest 4 bits = 0x04) to condition the ALMD, so it doesn't run unless the module is online and operating.

So the counter doesn't increment when for the input mapping of the instruction (I have the counter in parallel with the OTE for the .In of the instruciton), evidently it's not the input that is causing the issue.

But, we can only have one OTE per tag, or the controller would fault out on "destructive bits"

How is this possible:

https://imgur.com/SkwqKBV

Thanks for posting that !

Where is the ALMD instruction itself ?

Your screenshot shows a discrete input controlling an OTE addressed to the ALMD instruction backing tag's .IN subelement.

So the ALMD itself must be elsewhere on a rung of its own, with conditions on the Input side of the ALMD instruction. That's conflicting with the state that you're over-writing using the OTE.

You should be using the discrete input, or other input conditions, directly on a rung with the ALMD itself as the output instruction.

The ALMD is in another routine, but there is no boolean logic to enable or disable it, it's always being ran.

The way I understand the instruction is that the .In element is inpput that it monitors for the alarm. So, having the instruction mapped to the discrete input would only make the instruction active when the input goes high, but since the .In bit still isn't high, it wouldn't actually be in an alarm state. Perhaps it would require a parallel run, if the digital input goes high, the two parallel outputs for the rung are the instruction and the .In?

Thanks Ken!

I think you're mis-understanding the ladder logic ALMD instruction.

When you put the ALMD on an unconditional rung, the attached "rung" is controlling the .IN subelement, even though it's not labeled as such like it is on the Function Block Diagram version of the instruction.

An ALMD is triggered when the conditions on the rung prior to it transition from False to True. If it's on an unconditional rung, it will be triggered once when you go to RUN mode, then never again.

When you added a rung with an OTE addressed to the .IN bit, you're interfering with the always-true state of the unconditional rung, which is generating ALMD transitions based on coincidence of when the alarming subsystem runs versus when the user programs run.

Some old-fashioned PLC programmers used some A-B instructions by putting them in unconditional rungs, then causing a False -> True transition by controlling the Input with an OTU instruction. That's a mechanism I don't like, and it was confusing even when used with the simpler SLC-5/0x operating system. I definitely don't recommend it for use with ALMD or ALMA.


Go ahead and put your discrete input bits in the same rung as the ALMD itself.