Control Data Structure UL Bit

[duncrock]

Hello All,



I am relatively new at this, so I apologize if my questions are unclear.



Either way, I am using an FAL To copy a value from an array into a Tag. My issue is that the UL bit of the Control Structure keeps turning on. I'm not sure what the UL Bit does, or why it keeps turning on. I cant find any good documentation on Rockwell about this bit either.

 

[drbitboy]

You probably already checked this, but is the CONTROL structure passed to the FAL instruction being used anywhere else in the program?

 

[duncrock]

I use the .POS in a few different spots.
If the sequence is paused and then restarted then I subtract 1 from the POS.

If the sequence gets to a certain step then we set the POS to a new value.

And then if the sequence is stopped the POS is set to 0.

apart from those nothing from the CONTROL structure is used anywhere other than the FAL.

 

[drbitboy]

According to the available documentation ...

The .UL bit of a control structure is normally used only in the BSL and BSR (Bit-Shift Left and Bit-Shift Right) instructions cf. here.

It can be cleared by the AVE (AVErage) instruction cf. here.

If .UL is being assigned a value of 1 elsewhere, that may indicate the equivalent of a buffer overflow, but changes to the other CONTROL structure bits would likely be effected as well.

It's a puzzle; can you post your code (PDF preferred)?

 

[drbitboy]

Also, if this CONTROL structure is not being used in a BSL or BSR instruction, why do you care?

 

[plvlce]

The CONTROL data type is used by multiple instructions, with different instructions using different pieces of it.

The FAL documentation does not indicate it uses the .UL bit; afaik that bit is used only by BSL and BSR for the value of the bit that was just shifted out.

As drbitboy's question implied, the most likely explanation for the UL bit to change is if the CONTROL word is used elsewhere by an instruction that does use that bit. Crossreference the CONTROL structure as a whole to make sure it isn't being used elsewhere.

It's possible you've got something else overflowing and overwriting the data in the CONTROL structure, but I would expect more than just the UL bit to be affected. Does your FAL work as expected otherwise?

 

[duncrock]

Attached is the code. I guess youre right I dont really need to care about the UL bit as im not using a BSL or BSR. I just am wondering why its being activated. As for whether or not the FAL is always behaving properly, the answer is no. There are some points where I will send it the step advance, and the FAL will not increment. Or it will increment too many times

 

[BachPhi]

The CONTROL data type in RSLogix 5000 is used for many different instructions.
Consequently, the bits in the control word have different meanings depending on the instruction that is using it.
The .UL in BSR/BSL is the unload bit that is shifted out.
The .UL bit in FAL is a secondary enable bit(internal bit).

Your StepAdvance logic needs more work.
For example, the Drain bit is basically a oneshot at 'Step.1' and yet it has to wait until 'step.11'

 

[drbitboy]

...As for whether or not the FAL is always behaving properly, the answer is no. There are some points where I will send it the step advance, and the FAL will not increment. Or it will increment too many times

Do you understand that the FAL executes (and increments .POS) on the rising edge of its EnableIn (input rung)?

And that the logic in Rung 24 is could toggle the CIP_SugTankLine_VS_StepAdvance bit, either from 0 to 1 or from 1 to 0, on each and every scan cycle, for example if DTR_Test.6 was assigned a value of 1 in Online Mode of RSLogix/Studio 5000?

 

[drbitboy]

Also, for the CIP_SugTankLine_VS.Seq0X outputs and the CIP_SugTankLine_VS.Hex0X arrays, is it the integer value of CIP_SugTankLine_VS.Hex0X[.POS] that you are interested having the FAL in write to CIP_SugTankLine_VS.Seq0X, or is it the statuses of the individual bits in CIP_SugTankLine_VS.Hex0X[.POS]?

Because if you are interested in the latter, then you might consider the SQO/SQO instructions, although I agree with @BachPhi that the problem is in the logic that assigns values to the CIP_SugTankLine_VS_StepAdvance (and possibly CIP_SugTankLine_VS.Active) bits.

 

[L33er]

What's up with the BookKeeping?

 

[drbitboy]

What's up with the BookKeeping?

Just that most of programming is bookkeeping.

As in, I need to know, and have control of, every bit in my data model, either explicitly and individually for booleans, or implicitly and in agreement for integers, reals, structures (UDTs), etc. Digital computers are binary, there is no fuzziness, so ensuring my code can deal with every possible (reasonable) combination correctly is my primary goal.

A friend taught me a great lesson about programming projects: the first thing he does is design the data structures. Once I do that, the program often all but writes itself.

 

[robertmee]

Curious why you're using INCremental FALS to step through an array, and forcing the FAL to jump to different sequence positions based on conditions. Seems very inefficient. I would create a single UDT of the different parameters you need for each step, then create a single tag array of that type UDT. Keep a step tag that's an index into the array and move the data you need:

condition x, MOV 40 Step_Index
Data 1 = UDT_Tag[Step_Index].Parameter1
Data 2 = UDT_Tag[Step_Index].Parameter2
...
Data X = UDT_Tag[Step_Index].Parameter3

Just got rid of all the control tags, and truncated it down to one UDT Array Tag.