"asynchronous" - I don't like the sound of that -
Greetings, garryt1,
It looks like some of your addressing text “came loose” on the rungs you posted - but I still think I’ve got the general ideas. May I offer a few thoughts on your top set of rungs? It seems that you’re trying to synchronize a chain of events for “PID sampling” in a PLC-5.
Basic idea: A timer keeps track of elapsed time - whenever the timer gets done, we use the timer’s Done bit to trigger three steps in sequence on the following rungs.
(1) execute a BTR (Block Transfer Read) to bring in new analog data from the field.
(2) execute a PID (Proportional, Integral, Derivative) to calculate a new “control” value.
(3) execute a BTW (Block Transfer Write) to send our new analog data out to the field.
You’re not the first to have been bitten by this - but there is a fundamental problem with your approach. The dirty word for today is “asynchronous” - which is used to describe the operation of the Block Transfer instructions in the PLC-5 processors. (You lucky SLC readers don’t have to worry about this issue for your analog signals.) It turns out that just “triggering” the Block Transfers with the timer’s done bit (as I think you’re showing in your top set of rungs) will NOT necessarily guarantee that your PID will always be operating on fresh “new” data from the field. Putting the rungs in this 1-2-3 order seems to be a good idea on the surface - but there’s a lot more to it than this. Let’s look at the Block Transfer Read for a minute. The same concepts apply to the Block Transfer Write also.
The sad truth is, when the processor scans the BTR with true logic, the actual execution of the BTR is not NECESSARILY going to happen BEFORE the scan continues on to the next rung. Think about this: We’re literally talking about TRANSFERRING a big BLOCK of data. Actually accomplishing that transfer of data might conceivably take up a considerable amount of time - time which would tend to slow down our processor as he tries to continue scanning the ladder logic program. And so - in the PLC-5 family - the processor puts this “request” for a transfer of a block of data into a “queue” or a “buffer” - or in other words, into a line-up of “communication-type” requests. These requests will then be accomplished as soon as practical by a “communications handler” inside the processor - but NOT necessarily before the scan moves on to the next rung.
So the big question is: Will the “new” data from the analog input module arrive at the Process Variable location in time? “In time” meaning, of course, BEFORE the PID “picks up” the value from the Process Variable location and starts to work his mathematical magic on it. And the sad truth is: “We simply don’t know for sure.” Now in a relatively short program with very few “communications” type operations going on, the approach you’ve shown will undoubtedly give satisfactory results. For most student exercises it’s ideal. On the other hand, once we’re out in the field and begin to burden our processor with more and more communication operations, then the “asynchronous” nature of the Block Transfers starts to rear its ugly head. The actual word “asynchronous” comes from the Greek and, by definition, carries the meaning “not sequenced together in accordance with time”. Which sort of nails down the basic idea that your top set of rungs might not work precisely as you’d been led to believe.
And incidentally, before I started writing this post, I did a search on this forum for the word “asynchronous” and didn’t find even one mention of it. If it’s there and I missed it, someone please post a link to its location. Surely this can’t be the first time this particular topic has come up? But back to our story ...
In reality - how bad is this asynchronous execution “problem” anyway? Well, the good news is, in practice you’d probably never even know that your PID wasn’t getting fresh “new” data before each execution anyway - not unless some picky nut like me comes along and points it out. Think about it - how long has it been since the last time the data came in? - usually it’s only a fraction of a second ago. So how big a change would we expect to see in the actual values of the input data? Answer: Not very much. So in actual practice, the fact that the PID’s input data is just a “little bit” stale - doesn’t usually adversely affect the operation of the system at all. “So what?” - if the PID is reading yesterday’s mail and he happens to be a fraction of a second behind the times? Who cares? Only people like me (who actually enjoy these types of details) - and once in awhile a technician with a long interval for his “trigger” timer - and who goes crazy just trying to figure out why his 1-2-3 “get data in - do PID - send data out” chain-of-events sequence acts sort of “fishy” once in a while.
So in actual practice, most programmers just set up their BTR’s and BTW’s to execute “as often as possible” and get on with their lives. Still there ARE ways to sequence these types of things - but it’s a lot more involved than the “timer done bit” approach in your post. In case you or anyone else desires more information about this topic, see Chapter 15 in:
the PLC-5 Instruction Set Reference Manual
This book gives quite a few programming examples which might help you actually “sequence” your Block Transfers - and “buffer” your analog input and output data - if you feel the irresistible urge to do so.
Sorry - but the “timer done” bit approach in your top set of rungs is not really a “fail-safe” sequencing technique - but I’ll agree - it is a relatively popular one and a LOT of programmers use it successfully in the field. Thanks for the opportunity to bring this topic up for discussion.
Incidentally, using the STI approach as in your second example brings up additional issues. You may find information on this topic in:
the PLC-5 User’s Manual
A good place to start reading is on Adobe page 239 of 350.