Sign in to follow this  
Followers 0
Bill Linne

FIFO/Indirect Addressing Issue

6 posts in this topic

Good Morning: Using a 1756-L61 running version 17.2, I FAULTED the processor with the attached logic. Fault was not immediate, but didn't take more than a couple minutes. In my haste to get the processor back on-line (plant was running) I did not thoroughly examine the Fault Code, just saw that it was rung 108. So, first question: Does the processor/L5K keep track of historic faults in a file somewhere that I can access? The object of the new logic is to determine tank level decrease in the past hour. It is my first use of FIFO. I see that the FFL and FFU instructions may be used in pairs, but is that a requirement? I don't think the FFU does me any good in this application. Is that correct? Next, am I correctly dealing with the DN bit of the FFL by MOV'ing a zero to .POS of the Control Word? (I did that because the help file states that a major fault occurs if: (starting element + .POS) > FIFO array size). Is there a better way to "reset" the FFU? Last point of confusion is the gray background color behind the actual values in the SUB instruction. Makes me think something is not cool with my indirect addressing. And since that is the rung that faulted the processor, I'm doubly suspicious. I've never faulted with a SUB instruction before. Any hints? Note: I added the AFI to rung 108 in order to bring the processor back on-line. The AFI was not there when the fault occurred. Thanks in advance for any education you can provide. Bill

Share this post


Link to post
Share on other sites
First things first... the fault is caused by you trying to pull a value from an array position that doesn't exist. I'm assuming you sized your FIFO array to match the length you set up in the control on the FFL instruction. In the SUB instruction, you're asking it to look for a value in "****.POS +1". So when the control reaches the last position in the array, you're asking the SUB to look at an array position that isn't valid, hence the fault. There are several ways to keep this from happening by interlocking the SUB instruction to not operate when it could cause a fault, but let's look at your application and see if there is a better way to do it first. Do you need to keep the last 5 values, or do you just care about the current value, and the value from an hour ago? Does it need to be a running tally (from now back one hour), or can it be based on snapshots on the hour (from the top of the current hour back one hour. if it's 2:54, you'd see the value for the hour from 1-2). In answer to your questions, you're better off using the RES instruction to reset the control word you are using for the FFL. That will make sure everything is reset cleanly. And the grey highlighting just indicates that you are using indexed addressing. Also means you can't modify the value that you see, like you can in direct addressing.

Share this post


Link to post
Share on other sites
Thanks! Some further testing (and another fault!) confirms your reply. Logic is modified accordingly. I used an output branch to handle the one point in the count where +1 (or -1) won't work. And I do need the "running" total, rather than the snapshots.

Share this post


Link to post
Share on other sites
That's what I figured based on your five minute timer. So you are basically taking a snapshot every 5min, and then looking at your current level compared with the one roughly 60 minutes ago? In other words, doing essentially the same thing as the "snapshots" I was talking about, but updating every 5min. So you are using the FIFO stack as a shift array, wanting to shift in the new data as it arrives. To do that effectively, you'll want to use the FFU instruction to unload and scrap the "First-In" data point (e.g., the oldest data point) whenever you get ready to load a more recent data point with the FFL. With your current logic, the FIFO stack fills up, which causes the DN bit to turn on. Then you're resetting the FIFO stack back to zero so you can load more data, but clearing all your useful data. Take a look at the attached snippet and see if that helps. I haven't tested it, so it might require some tweaking. Basically, allow the FIFO to accumulate data until it's full, then every time the 5min timer is done, unload one piece of data, and load the new one. The SUB will subtract between the oldest data point and the newest one, giving you the last hour of usage. You can play around with that to get better resolution (update once a minute?), reset the FIFO on power-up to avoid erroneous calculations, etc.

Share this post


Link to post
Share on other sites
Jeremy: Thanks for your detailed input. I now understand the operation of the FFU/FFL pair. I've attached the version of my logic that has been running all night and works fine. Using the MOV instruction to "reset" the FFL .POS pointer to zero (when the FFL goes .DN) avoids loss of data in the array. I also had to modify the operation of my SUB instruction, once I better understood that the .POS value is where the next value will be written, not where the last value was written. Thanks again for your help! Bill

Share this post


Link to post
Share on other sites
No problem, glad I could help!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0