What would cause this output to stay on?

[Sean Teague]

This makes no sense to me... these two outputs stay on no matter the condition of the statement before them.

 

[I_Automation]

Look at the routine that rung is in.


If it is not being called the outputs will stay on until that rung is called to turn them off. If that routine is called with a conditional JSR then it won't be called until that/those condition(s) are all true.


Here's an example from a SLC that has conditional messaging:
[The toggle bit to enable is the condition, the TRUE is to pass the Messaging Current that I have as an indicator

 

[Sean Teague]

the JSR has no conditions so it should be running all the time

 

[I_Automation]

In that routine is there any RET before that rung that would return to the calling routine?


Or a TND that would end scanning the entire program?


Or a MCR section that would bypass it?


Do an online edit and add a rung after this one: OTE Test_Bit_Running


As soon as you test that rung that bit will come ON if it is being scanned

 

[harryting]

In this type of situation, one typically check the following:

- What happens when you toggle them off?
- Are these bit being used latched or energized elsewhere?
- Add some logic next to it just for testing to see if they are executed correctly.

 

[joseph_e2]

May be a long shot, but also look at other things that write to the tags in the GRT instruction. The values shown on your screen are the values at the end of the scan, but they could be something else while the GRT is being evaluated. To isolate that, add a couple of MOV instructions on a new rung right above this one that MOV the tags to new, otherwise unused locations.


The same holds for the tags on the OTE instructions. Do a cross-reference on them and look for additional places where they're used destructively. Something else could be writing them ON.

 

[harryting]

^^^ one simple thing to do to check for rung condition is to add a timer instruction on a branch and see if it accumulate time correctly.

 

[Bit_Bucket_07]

I'll go ahead and ask the stupid question: Is it possible that you are looking at the program in offline mode?

 

[Sean Teague]

I'll go ahead and ask the stupid question: Is it possible that you are looking at the program in offline mode?

Haha no, i'm definitely online. Made that mistake in years past though

 

[Sean Teague]

this if the full rung

 

[Steve Bailey]

Based on the ADD and SUB blocks on the branch above the GRT block, the coils will always be true unless the value in CORE_HEIGHT_DEVIATION is negative or zero.

 

[TheWaterboy]

I'll go ahead and ask the stupid question: Is it possible that you are looking at the program in offline mode?

I have done that more times than I am going to admit.

 

[TheWaterboy]

Thinking WAY outside the box . . . any chance there is a write taking place where the element prior in sequential memory to the bits is inadvertently writing into the next register? I know it's possible to do that when you COP different data types.

 

[Sean Teague]

Based on the ADD and SUB blocks on the branch above the GRT block, the coils will always be true unless the value in CORE_HEIGHT_DEVIATION is negative or zero.

How could that be true? doesnt the plc just look at the information in the same line as the coils to be true?

 

[Sean Teague]

Thinking WAY outside the box . . . any chance there is a write taking place where the element prior in sequential memory to the bits is inadvertently writing into the next register? I know it's possible to do that when you COP different data types.

no, none of this