Need Help with Logic on CLX FBD

I have a question concerning logic on the AB CLX. I have been posting so often these days, guess a lot of people know what i am upto.

ANYWAYS....

My algorithm is split into two peices, one in ladder and the other using FBD. My program is supposed to converge and its a iterative process, so a timer basically waits till the end of a process and clears up all values and the system is ready to crunch new values(the new values are a result of the number crunching the algorithm produces)

The whole issue concerns some Function blocks and the fact that the outputs dont seem to follow the inputs. Like for example, I have a GRT block( same holds true if i use LES etc), I kill the inputs to the block at the end of the timing cycle, including the Enable IN pin but my output stays a ONE as the states dont get updated.

In other words the Enable OUTPUTS stay latched!! despite my inputs to a block being ZERO.

So i am currently ending up with a race condition.

Does anyone have any suggesstions? I have previously tried to replicate what i did in FBD in Ladder and it works well. The only issue with that is i have almost 40 pages of code written in FBD.

What is the best way to clear outputs in FBD at the end of a cycle? The inputs to the source A and source B and the enable In are all forced to zero through Ladder. how can I make the output go to zero?

Makes me think, why cant AB provide users with an option to keep EN OUT latched or otherwise. I mean we have an option to latch bits or leave them a high in ladder. Why cant they add that feature in FB? Anyways, that doesnot bother me at this point of time.

Ashwin.

...from RSLogix 5000 help -
EnableIn BOOL Enable input. If cleared, the instruction does not execute and outputs are not updated.

prescan.................No action taken.
instruction first scan..No action taken.
instruction first run...No action taken.
EnableIn is cleared.......EnableOut is cleared.
EnableIn is set...........The instruction executes. EnableOut is set.
postscan..................No action taken.

Click to expand...

Think of it as similar to a ladder subroutine - when EnableIn is false, the subroutine is not called and outputs are not updated. Note that EnableOut follows the state of EnableIn.

If you want the block to take note of its inputs, EnableIn must be true.

UPDATED

Gerry

Thanks for replying.

Yes i did go through the manual and it says outputs are not updated. I have a problem with that though!(maybe I am not understanding it very clearly)

There is a stage in my program when I "clear" the inputs to the blocks in FBD. As you maybe aware the FBD doesnot have any CLR, I clear the values in Ladder and pass those parameters into FBD.

So Now i have this condition where the inputs to the FBD are cleared but the output is latched and stays at a high.This is the cause for the conflict. If i understood you correctly, you state that the system would execute the way it would in ladder.

The difference is that in ladder, if the inputs go to zero, the outputs follow them. In the case of the FBD, the "not UPDATED", makes the output latched.

I converted the place where i had seen this problem into ladder program and it worked.

I propose two solutions and you may correct me on this.

1. I plan to unlatch the output of the FBD in Ladder logic and pass the parameter on to FBD.

OR

2. Would it be better, that at the end of the cycle when I want the whole system to reset, i just introduce a new condition (force values or else) that will make my outputs go to false.

I would really appreciate having more INSIGHT into this whole issue in FBD.I called the AB people and they read me the same stuff from the manual. I have the manual too is what i thought to myself.

I think they have very poor examples in the 5000 manual. thats my opinion.

Thanks

Ashwin.

When I said 'think of it as similar to a ladder subroutine', I was trying to draw an analogy to what you're doing with the EnableIn inputs.

I don't think you need more logic - I think you need Less. You're already clearing all the inputs. Just return the EnableIn's on all your function blocks to the default setting - not shown and internally set to 1. Then the blocks will continue to execute and the outputs will reflect the state of the inputs.