Settle a bet

drbitboy

Lifetime Supporting Member
Join Date
Dec 2019
Location
Rochester, NY
Posts
7,895
I have three ladder solutions to a deadtime task: a discrete input rising edge generates a 1s discrete output pulse after a delay of 20s, which delay can be adjusted via HMI (yes, this started on another thread).

I am requesting any and all opinions, please, on ordering the three A-B .RSS files in the attached .ZIP by relative complexity. Our internal discussions revolve around things like "indirect addressing is evil." Coming from a broader programming background I am comfortable with indirect addressing and so prefer the circular buffer, but it is also interesting to watch the bits traverse the binary file in the two BSR-based solutions.

Also, a statement of how complex each solution is e.g. would the average maintenance tech* be able to grok the code so I don't get a call at 2am? If any are so opaque that they cannot be understood, that would be helpful to know too.

I realize the answers will be subjective, but I am interested anyway.

I also realize this is a lot to ask, so only those with copious free time ;) should even look at the code (less than a dozen equivalent rungs each), and I will not be insulted if nobody responds.

If anyone is interested but unable to deal with .RSS format, I could post PDFs.

Thanks!

* now there's a subjective concept.
 
my vote is for > BTC_BSR_DEADTIME

I have a few observations.

Rung 1. I think I would capture current timer preset in a buffer to load instead of a constant. That way whatever preset value is present when system was powered down would be loaded when system is powered up.

Rung 2. Not sure why you using a ONS on B223:5/0 when you unlatch it in the same rung.

Rung 3. An XIO of Timer Done would pulse the timer. Would be easier to understand that the timer is resetting itself and you would not have to explain the reset function in the next rung comment.

A+ on rung comments though, good job.
 
+1 Indirect Addressing
Without even looking at the code. The HMI can easily display what the inputs should be doing vs what they are doing. This can easily apply to the outputs as well.
No need to even look at the logic. All of the troubleshooting is on one screen of the HMI.

Regards,
 
I think that whomever says "indirect addressing is evil" simply does not know how to utilize or troubleshoot it properly.

If done well it is very useful, especially for cycle step motions, alarms codes, etc. that one pointer could quickly show the correct value.

If done poorly it would be a mess to troubleshoot or try to update the program.
 
I think that whomever says "indirect addressing is evil" simply does not know how to utilize or troubleshoot it properly.

Hol' on there Baba Louie!

I know for a fact that the person I was referring does know how to utilize and troubleshoot indirect addressing properly; they have a successful career of more than a few decades working with PLCs.

So first of all, I apologize because the phrase "indirect addressing is evil" was my hyperbole of what was actually said, which was this:

... Not good for plant personnel. I can follow indirect addressing but it takes time so I use indirect addressing in a PLC program only as a last resort. ... I have been in Plant Automation for 35+ years and know what works in the Real World in a manufacturing plant.

If done poorly it would be a mess to troubleshoot or try to update the program.

Bingo: I am fairly certain the reasons they avoid indirect addressing are
  • the large number of hot-mess programs written by others that they have had to troubleshoot
  • the large number of 2am calls by maintenance techs who could not troubleshoot it on their own.

I am a procedural programmer (Python, Node, C++, C, Fortran, Pascal, Basic, assembly, machine code, etc.) from way back, so much of my mother's milk involves indirect addressing a.k.a. arrays; shoot, the fact that indirect addressing exists is probably one of the most important reason computers are so useful.

But all views are subjective and biased by our experience; I may like the indirect addressing, but who am I to argue with a few decades of experience when I have only been in the PLC game a few weeks?

Anyway, I thank everyone for the input!
 
Last edited:
my vote is for > BTC_BSR_DEADTIME

I have a few observations.

Rung 1. I think I would capture current timer preset in a buffer to load instead of a constant. That way whatever preset value is present when system was powered down would be loaded when system is powered up.

Ooh, nice catch! This was intended as a proof of concept, but I appreciate this forest vs. trees insight into how an actual application could be implemented and interface with the Real World.

Rung 2. Not sure why you using a ONS on B223:5/0 when you unlatch it in the same rung.
Yeah, I kept noticing the OTU and the unlatch, thinking the latter was unnecessary; I think the unlatch was implemented first, then ONS was added, and now the unlatch is hanging around like a stale f@rt.

Oh wait, I know: at this point the program is still proof of concept, so the deadtime rising-edge trigger is done manually via RSLogix in Online mode (press 1, press Enter: two-finger simple sequence); the unlatch is a convenience for the user who now does not have to clear the bit manually (press 1, press Enter, press 0, press Enter: two- or three-finger complex sequence); the unlatch would be removed in an actual application (can I even apply an OTU to a discrete input?).

Rung 3. An XIO of Timer Done would pulse the timer. Would be easier to understand that the timer is resetting itself and you would not have to explain the reset function in the next rung comment.
Yes, I have used that XIO of [Timer Done] before, and I agree it is usually much cleaner (like a [Stop] XIO in my favorite ladder pattern: the sublime and beautiful seal-in starter circuit).

However, this program is about timers cycling every 200ms or so, and the other person and I noticed, independently, that that XIO would add a scan to the cycle. Maybe 5% so meh; but it is noticeable. Anyway, that's why I did it that way.

Thanks for the input. I am a newbie in PLCs and the inrush of new knowledge in the past few weeks has been exhilarating, and I only grok about 5% of it.
 
Last edited:
My solution is best. It allows delaying a pulse stream by any amount and changing the delay. There input can change many times within the delay and all changes will be delayed by the correct amount.


PLC timers are crude. They can delay events but not exactly because of variations in the scan time. The PLC timers tend to delay for a little longer than requested.


My solution would not be simple it doesn't need to be if programmed so it works as intended.



This whole idea that things should be dumbed down so that bubba can fix it at 2AM is wrong. Fist, the code shouldn't need to be fixed and bubba should be smarter.
 
PLC timers are crude. ...

Really? I have a scan time of order 1-10ms, plus noise, and I am running a timer order 100ms, and you are telling me I may not scan exactly at the 100ms expiry, each time, every time? Wow, I never would have guessed. I'm shocked, shocked to find that gambling is going on in here. :rolleyes:

Every computer program is, or assumes, a model of summat in the real world.

The only real choice to make is the fidelity of the model; everything else is an implementation detail.
 
Last edited:
This whole idea that things should be dumbed down so that bubba can fix it at 2AM is wrong. First, the code shouldn't need to be fixed and bubba should be smarter.


I'll just toss my two cents in here.

You are exactly correct that I (we) should be smarter. Sadly, the days of bean counters believing that hourly peons are worth investing dollar number one in are going away very fast. I know there are still companies that are willing to spend the money, but they are getting to be the exception rather than the rule. And don't get me started on the lazy, good for nothing Bubbas that simply refuse to even try to understand anything beyond basic relay logic. Those folks annoy me far more than they do you.

It is also important to note that we Bubbas are often called to fix things that were in fact not done correctly the first time, and often criticized for not being able to sort out what the intentions of the original programmer were. All programmers should feel free to use as complex a solution as the problem requires, but please take the time to make sure your solution works. I do fully understand that engineers have their own bean counters to answer to, so there is usually not nearly as much time to debug a program as everyone would like, and being able to predict every possible manner that things can go worn sounds easier than it actually is that's where the concept of programming in a manner that Bubba can understand comes into play. If the program works like it is supposed to, then odds are I'll never open it up. However, if the program doesn't function as intended, or I can't use it as a tool to find the failed field device, then I'll gladly pour myself a cup of coffee and keep hitting the re-dial button from now until you pick up the phone, or 0500 rolls around, and the next Bubba picks up where I left off.


For the OP,
Indirect addressing is not in and of itself evil, but it can easily be used in evil ways. For me, the key is proper documentation. As long as there are decent comments that explain what is being indirectly referenced and maybe even from where, then the burden is on me to be skilled enough to sort it out from there. For instance, if the [x] is from a recipe file, just make a note that
[x] is from Tag/UDT/Parameter File (Y). However, all to often important details like that seem to be left out.



Bubba.
 
Rabbit trails, to you, until, we meet, again

Well, this thread having been re-purposed to pick-on-Peter day, I'll make another deposit.

My solution would not be simple it doesn't need to be if programmed so it works as intended.

Even if it works as intended, that is irrelevant in the "bubba scenario."

When something else in the process breaks down (and it will, no matter how perfect the code) and a real-world Bubba is troubleshooting, Bubba doesn't know your code is bulletproof nor should they care: they are only looking at the code to find the next clue to where the actual problem is. The extra time someone spends grokking your complex code is money lost while the process is down; it doesn't matter if it's the smartest Bubba, the backup engineer, or even you trying to remember why the heck you coded it this way six months ago (been there ...;)).

Also, with the Bubba who won't get there, or can't get there because your better code is too opaque*, the problem with the 2am call is not the inconvenience to the engineer, it's the time (money) lost while they drive in.

Summary: making the code plain enough that maintenance staff can take ownership of as much of the process as possible is a real-world profitability issue, not some quixotic kumbaya delusion.

I started this thread to compare indirect addressing/circular buffer vs. a BSR/FIFO approach; back then I understood the former but not the latter, while my brother understood both but preferred the latter. That was the genesis of the "settle a bet" OP: take a sample** consensus of the subjective complexity of each approach.

Now that I grok BSR***, I think of a circular buffer and a BSR/FIFO as leaves off the same design pattern tree, and maybe all my OP did was start yet another religious argument.

* and as willxmfr notes, they do exist
** plctalk.net-biased, admittedly
*** The BSR instruction help page was gibberish to me for some reason, but watching those 1 bits move through the binary file was revelatory

Full disclosure: my initial reaction to my brother's preference for BSR over indirect addressing was the same as Peter's: Bubba should find another line of work.
 
Last edited:

Similar Topics

So our com tech is telling me that one can't use a fiber/copper media converter on one side and another brand's switch on the other side of fiber...
Replies
14
Views
3,033
Hello all, I got into a discussion with a co-worker about P and PI loop behavior. I am hoping that someone can confirm the proper way to...
Replies
7
Views
2,789
In the year 2000, I had to hold the shift key down before clicking on an object in Wonderware. Do you still have to do this in 2016?
Replies
29
Views
6,484
Dear fellows, I need to know what is the protocol which i can use in LS plc to make the schneider HMI and scada work with it . I have alot of...
Replies
0
Views
1,745
problem in a communication that lost bet. S5 135U (ALARM S3964RDDE SERVER) & In Touch Hi all experts and members ...
Replies
0
Views
2,113
Back
Top Bottom