Outputs will not fire

As a diagnostic, immediately after the line with the [OTE OUTPUT], add summat that will declare whether the output is assigned a 1 by the OTE, i.e.:




When running, either AFLOAT will increment at order 1kHz, indicating the programm is assigning 1 to output, or not at all, indicating the program is assigning 0 to OUTPUT.


If AFLOAT is incrementing, but OUTPUT is 0 in every other indication, then there is something else that is setting it to 0.



SourceA/Dest does not have to be named AFLOAT; any float will do.


Use floats to avoid any overflow and subsequent fault.

dr... That's interesting.
There are many ways to trap the output going high on the same rung as the output. Even catch duration... do weird things...

Like has been said, there are no other occurrences of that output in the program. Nothing seems to be stepping on it. I'm not sure this is the case as I haven't seen the actual program, but I'll take their word for now.

This is in Logix, which is the really big brother of your free ML1100 software. Things do work differently.

You can probably get the mini version for under a thousand dollars that deals with CompactLogix, then move up from there.

I think you will be a really good PLC programmer, so keep up the good work.

It's only meant as a diagnostic. The OP says

• there is nothing else that is assigning a 1 or 0 to that bit;
• the rung, which is feeding the OTE that does assign the bit, is true;
• 1 is not being assigned to the bit.

All three of those statements should never be simultaneously true in normal operation. Of course, the last one should actually say that the bit is not seen as a 1 via RSLogix online monitoring, which is a slightly, but significantly, different statement.


My proposed diagnostic is only attempting to eliminate one of those statements as the problem; if the float does not increment, then "HUH?*;" if the float does increment, then there must be someplace else where the bit is being assigned to 0.


* if the float does not increment, then the statement, that the rung is true, is suspect and it is possible that some of the other inputs on that rung are seen as one value by RSLogix but actually have a different value when this rung executes.


It would also be worth incrementing another float with no other conditions on its rung just to ensure that the rung is actually executing.


I don't think the OP is deliberately trying to mislead, but unless the rules of digital logic are somehow different inside that system, something is rotten in the state of Denmark, and sniffing around is the only way to find what it is.

LOL... I'll take your word for it.

drbitboy said:

...sniffing around is the only way to find what it is.

Click to expand...

That should be "sniffing around is one way to find what it is."

drbitboy said:

That should be "sniffing around is one way to find what it is."

Click to expand...

That brought to mind the movie TRON.

How many years until we can digitize ourselves and zap into the PLC to find out what is really going on?

Aabeck said:

That brought to mind the movie TRON.

How many years until we can digitize ourselves and zap into the PLC to find out what is really going on?

Click to expand...

https://www.youtube.com/watch?v=9_Jw7maERgk

LOL... Now I need some popcorn...

Is your routine in an actual scheduled (and enabled) task?
What kind of task? Cyclic or periodic?

corbett11 said:

I tried to toggle the output bit. It doesn't do anything. We executed the logic so the whole rung was "true" only leaving the output to fire. It still does nothing.

I made a separate test rung in the same subroutine with just a bit that I could toggle and an output bit. That output will turn on.

Click to expand...

Is the output located within an MCR zone? If you placed that test rung at the top or bottom of the sub-routine, outside of the MCR zone, that rung would act as you would expect. If you placed that test rung directly above or below the rung with the suspect output and it worked, then I would assume no MCR is being used in that area.

If you could post your program here for us to take a look at, we could probably be more helpful. (Zip it first)

MikeyN said:

If you could post your program here for us to take a look at, we could probably be more helpful. (Zip it first)

Click to expand...

Or print it as a PDF and post it here.