You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old February 14th, 2020, 03:17 AM   #1
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Settle a bet

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.
Attached Files
File Type: zip deadtime_complexity_bet.zip (116.0 KB, 20 views)
  Reply With Quote
Old February 14th, 2020, 07:56 AM   #2
cwal61
Member
United States

cwal61 is offline
 
Join Date: Jan 2011
Location: NC
Posts: 1,151
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.
  Reply With Quote
Old February 14th, 2020, 08:02 AM   #3
gclshortt
Member
Canada

gclshortt is offline
 
gclshortt's Avatar
 
Join Date: Dec 2014
Location: Ontario
Posts: 3,015
+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,
__________________
Garry
https://www.accautomation.ca
Connect with us on Facebook: facebook.com/accautomation/
  Reply With Quote
Old February 14th, 2020, 09:33 AM   #4
Aabeck
Member
United States

Aabeck is offline
 
Aabeck's Avatar
 
Join Date: Feb 2013
Location: Detroit
Posts: 1,653
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.
__________________
Never underestimate the quality of idiots that will be running your machines
http://aabeck.com
  Reply With Quote
Old February 14th, 2020, 10:50 AM   #5
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Quote:
Originally Posted by Aabeck View Post
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:

Quote:
... 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.
Quote:
Originally Posted by Aabeck View Post
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 by drbitboy; February 14th, 2020 at 11:20 AM. Reason: fix pronoun
  Reply With Quote
Old February 14th, 2020, 11:19 AM   #6
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Quote:
Originally Posted by cwal61 View Post
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.

Quote:
Originally Posted by cwal61 View Post
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?).

Quote:
Originally Posted by cwal61 View Post
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 by drbitboy; February 14th, 2020 at 11:21 AM.
  Reply With Quote
Old February 14th, 2020, 11:35 AM   #7
Rson
Member
United States

Rson is offline
 
Join Date: Jun 2017
Location: Michigan
Posts: 260
PDFs preferred
  Reply With Quote
Old February 14th, 2020, 12:58 PM   #8
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Quote:
Originally Posted by Rson View Post
PDFs preferred
As you wish, and thanks!
Attached Files
File Type: zip deadtime_complexity_bet.zip (1.23 MB, 19 views)
  Reply With Quote
Old February 14th, 2020, 02:16 PM   #9
Peter Nachtwey
Member
United States

Peter Nachtwey is offline
 
Peter Nachtwey's Avatar
 
Join Date: Apr 2002
Location: Vancouver, WA, US
Posts: 7,034
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.
__________________
"Living is easy with eyes closed, misunderstanding all you see...." Strawberry Fields Forever, John Lennon
  Reply With Quote
Old February 14th, 2020, 06:56 PM   #10
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Quote:
Originally Posted by Peter Nachtwey View Post
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.

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 by drbitboy; February 14th, 2020 at 07:12 PM. Reason: add humour
  Reply With Quote
Old February 14th, 2020, 08:45 PM   #11
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 604
Quote:
Originally Posted by Peter Nachtwey View Post

PLC timers are crude.
Peter you have lost it!!
  Reply With Quote
Old February 14th, 2020, 09:40 PM   #12
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
Quote:
Originally Posted by Phrog30 View Post
Peter you have lost it!!
I think he is absolutely correct, just his definition of crude is different from anyone else's.
  Reply With Quote
Old February 14th, 2020, 10:20 PM   #13
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 604
He forgets he’s on a plc forum. There is nothing wrong with plc timers.
  Reply With Quote
Old February 14th, 2020, 11:24 PM   #14
willxfmr
Lifetime Supporting Member
United States

willxfmr is offline
 
willxfmr's Avatar
 
Join Date: Nov 2013
Location: Wisconsin
Posts: 405
Quote:
Originally Posted by Peter Nachtwey View Post

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.
__________________
“Now will come the nay-sayers with all the reasons why you shouldn't do this. Some of them are teachers, and some of us are doers. Besides, you have got to let the smoke out of this equipment every now and then, or it starts to clog up the chimney.”
~Lancie1
  Reply With Quote
Old February 15th, 2020, 04:50 AM   #15
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
Join Date: Dec 2019
Location: Williamsburg, Virginia
Posts: 199
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.

Quote:
Originally Posted by Peter Nachtwey View Post
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 by drbitboy; February 15th, 2020 at 04:59 AM. Reason: minor addition and rhetorical flair ;)
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
problem in a communication that lost bet. S5 135U (ALARM S3964RDDE SERVER) & In Touch mohamed fouad LIVE PLC Questions And Answers 0 September 25th, 2013 10:51 AM
Communication bet S7-400 and PC using NI opc server prasad.shukre LIVE PLC Questions And Answers 2 March 26th, 2009 11:02 AM
Difference bet. RSLinx Single Node & OEM? ckchew666 LIVE PLC Questions And Answers 9 June 26th, 2008 06:10 PM
What's the difference bet AB PCMK'S? miker LIVE PLC Questions And Answers 7 January 15th, 2007 05:46 AM
Need to win a bet chop347 LIVE PLC Questions And Answers 18 September 1st, 2006 10:51 AM


All times are GMT -5. The time now is 06:50 AM.


.