logix5000 sequence timer (beginner)

[Paullys50]

...he has nothing to debug on the procedural part...

But he has to understand the procedural part, which means reading the instruction help file and interpreting it. I've answered many calls where all they had to do was read an alarm message...

 

[willxfmr]

TOF's

Tell me that's a joke .....

I'll toss my two cents in from the Bubba side of things. Not that you fancy pants, nice shoe wearing, night sleeping folks ever give a hoot what poor, old, fat, lazy Bubba thinks.

It's only partially a joke that TOF's should be avoided. It's somewhat embarrassing to admit how many Bubbas don't understand how the TOF functions. If you want to avoid confusing the more simple minded of us, please just use the TT bit of a TON. I know it's a sad state of affairs, but it is the reality of life. I don't like it either, but it is the world I live in.

But above all else, please don't be clever in your programming. Just because you figured out a really cool way of using BSL combined with MVM to update the inputs, doesn't mean that is how it should be done. At the end of the day, when you are warm and cozy in your bed, us poor, fat, lazy, dumb Bubbas are the ones that have to try and keep the machines running. So if you could try to keep things straight forward, and maybe toss in a rung comment or two here and there, we would appreciate it. That doesn't mean that I don't have an obligation as a professional to learn the tools of my trade, or keep my skills and knowledge current with technology, but if you could meet us half way, you will get far fewer 2 AM phone calls, and I get more coffee and chair time. To me, that's a win for all of us.


Thanks,
Bubba.

 

[robertmee]

^ Bravo

And no TOF's aren't a joke....just as Bubba so eloquently stated it's not the most well understood instruction. So if there is an easier more straightforward way to code a function then why not do it?

I was an engineer on the manufacturing side for 10 years and I have been a SI for 20 years...both sides of the aisle. In manufacturing PLCs and the techs that support them are necessary evil. If it was cheaper to have a 1000 monkeys producing the same quality widget they would use them. The technicians are considered overhead. Every bit of time lost due to a technician scratching his head because he doesn't understand some code impacts the bottom line. To suggest that a technician should use the instruction help file to figure it out is laughable. They don't have the time to do that when production is screaming at them because the line is down and everyone's bonus is dwindling. And forget them learning in their idle time....idle time is occupied by safety meetings and six sigma meetings and process improvement meetings and TQM meetings and lunch if their lucky. No their learning time is OJT and repitition. So each time they encounter the odd TOF or other MVM instruction because the programmer saved one rung of code it's a pain in everyone's ***. I'm really surprised there is some degree of condescension towards Fat Frank and Bubba....spend a year or two everyday in a manufacturing facility and the perspective may change.

 

[John Morris]

Good day everyone, I just got into rs logix5000 programming. Can anyone help me explain how a sequence timer work? In my sample logic.

Poor OP. I get a kick how things go sideways in here.

 

[robertmee]

Happens when the OP, a first time poster, doesn't revisit for 4 days or ever posts again.

 

[John Morris]

Good Point. Took on a life of its own.

That's going to be me in a couple of days. Got my shine new 5000 Tuesday. I'm half way thru some 400 tags.

I get to learn analog motion, SCADA, temp control, laser distance measuring, and manage wash 5k lbs stators in the dark.

Shoot, I'll be a whole new person in a week or so. Bald, anxiety attacks, suicidal, unwillingness to but down the beer bottle, divorced (again), curled up in the corner, catatonic, drooling, twitching, muttering incoherently about someone named Allen.

Can't wait.

Actually, I'll throw one out now. This overhead robot is supposed to tell my machine the size and shape of the incoming piece, and I have to open the correct amount of lids and configure for proper ingress.

Now consider two weeks ago they didn't know which SCADA system they were going to use, and I don't know what I'm doing yet, I'm not sure how to ask the proper question to get this information.

To quote Socrates, "Knowledge is knowing......that you know nothing" Yea.

 

[skeet]

that seems like a very short sighted approach. Maybe the difference between oem for small machines and large scale si systems. As a si i make my code as easy to follow and troubleshoot while getting the job done. I don't want 2am phone calls because a sensor has failed and it takes an engineering degree to read the code to figure out what's going on. I don't subscribe to the thought that i can make the code as convoluted as i want as long as the machine does what it's asked today. Because tomorrow will come where something external fails or an added functionality is needed. I guess as an oem that's your bread and butter. You want the customer to call you and spend more $ for a minor change. I dont...once i walk away from a system i want very little to do with minor add on in the future.

As a side note i have made a fair amount in the past 20 years rewriting oem code for manufacturing for just that purpose....to conform to better standards and to make it easier for their techs to troubleshoot. Most oem code is great...as i'm sure yours is...but some of it looks like a thousand monkeys at a typewriter

and lastly, don't discount the power of frank (pretty condescending to call him fat) complaining to management about your code. Again i've gotten work from those complaints and have been contracted back to the oem to write future code for their plants.

+1

 

[harryting]

But above all else, please don't be clever in your programming. Just because you figured out a really cool way of using BSL combined with MVM to update the inputs, doesn't mean that is how it should be done

+++++++++++++++++++1000000000

let me add another one....

Just because the functionality is there, it doesn't mean you have to use it, eg. AOI.. worse yet, AOI (Add-On-Instruction) within an AOI.. then because your darn AOI doesn't do everything you wanted, you deviate part of your code to not use it.

Also, this one is controversial and I only came to this conclusion lately.

- Commenting is overrated. If your code is hard to understand, no amount of commenting will save it.

Quoting SICP:

A computer language is not just a way of getting a computer to perform operation... it is a novel formal medium for expressing idea about metholdology. thus, program must be written for people to read, and only incidentally for machine to execute

 

[proof]

+++++++++++++++++++1000000000
Also, this one is controversial and I only came to this conclusion lately.

- Commenting is overrated. If your code is hard to understand, no amount of commenting will save it.

Good comments are not. Comments aren't useful unless they have a point. Code is relatively straight forward about what it does. The bigger question is why it is does what it does.

 

[daba]

I feel a bit ganged up on....

Let me throw this into the mix...

If Bubba/Frank can't accept that an in-built instruction such as the SQO actually works, and has done since its inception in the late 60's/early 70's then we should also discount many other instructions, such as FAL, FSC, DDT, FBC, even PID, the list goes on and on.

The logic that any of those instructions performs could be brute-force hard-coded, using many rungs of code, but mostly they aren't, they are just used as the need arises.

The singling out of SQO as being "hard to understand" doesn't make any sense to me. FAL and FSC in numerical or incremental mode is a much harder concept.

At the very least the "Help" for complex (sic) file-based instructions is always to hand, as opposed to whatever rung documentation the programmer provided if coded verbosely.

If Bubba/Frank can't appreciate that if anything goes wrong with an application using SQO, then it is not the fault of the instruction itself, but the data it is working with.

I still say that if you had any substantial sequence (e.g. greater than 20 steps), Bubba/Frank would rather see an "engine" such as SQO or an AOI driving it, rather than working his way through 20-plus rungs of code, especially when he doesn't know if the problem is caused by a coding, or data error. Using SQO simplifies his debugging, IMHO.

 

[Doug-P]

The singling out of SQO as being "hard to understand" doesn't make any sense to me. FAL and FSC in numerical or incremental mode is a much harder concept.

I agree. The SQO/I is not a difficult concept, the music box analogy explains it very well. I think the 'problem' with AB's sequencers is the exactitude required to set them up and follow along. That is, keeping the truth table in your mind's eye to grok what the instruction is doing as it progresses. By contrast, I find Automation Direct sequencers much easier because they're visually oriented.

YMMV

 

[willxfmr]

I feel a bit ganged up on....

Let me throw this into the mix...

If Bubba/Frank can't accept that an in-built instruction such as the SQO actually works, and has done since its inception in the late 60's/early 70's then we should also discount many other instructions, such as FAL, FSC, DDT, FBC, even PID, the list goes on and on.

The logic that any of those instructions performs could be brute-force hard-coded, using many rungs of code, but mostly they aren't, they are just used as the need arises.

The singling out of SQO as being "hard to understand" doesn't make any sense to me. FAL and FSC in numerical or incremental mode is a much harder concept.

At the very least the "Help" for complex (sic) file-based instructions is always to hand, as opposed to whatever rung documentation the programmer provided if coded verbosely.

If Bubba/Frank can't appreciate that if anything goes wrong with an application using SQO, then it is not the fault of the instruction itself, but the data it is working with.

I still say that if you had any substantial sequence (e.g. greater than 20 steps), Bubba/Frank would rather see an "engine" such as SQO or an AOI driving it, rather than working his way through 20-plus rungs of code, especially when he doesn't know if the problem is caused by a coding, or data error. Using SQO simplifies his debugging, IMHO.

I actually agree with your point for the most part. The very first time I encountered the SQO instruction I had no clue what it was or what it did. The same was true for MVM, PID, AOI, and a whole host of other instructions. I personally believe that if I don't understand what an instruction does or how it works, the burden is on me to learn what it is, and how it works. I have no problem with any specific instruction being used, because it is my job to figure things out, even if I have never seen or heard of it before. Thanks to the generous people here, and those that post YouTube videos, combined with some formal Rockwell classes, I can for the most part sort out what is going on, and why it isn't working right this moment.
But what really grinds my gears is when something that could be done simply, is made complicated. I see this a lot from OEMs, and I assume that a lot of it comes from having stock code that is intended to work on many machines that are similar, but not necessarily identical. Another example, and one that I deal a lot with at my current job is indirect and index addressing with no explanation at all of where it is being addressed from, or what is doing the indexing.
However, the unfortunate fact is there are a lot of Bubba's that don't have the desire to learn and stay current with technology. Many of them think that if they didn't learn it 20 years ago, they don't need to know it now. For the record, I HATE working with people like that. They give all of us whos one true goal in life is to drain the worlds coffee supply, a bad name.

I will admit that anytime I see Peter Natchway start a post with "That's easy." I know I will well and truly lost before I'm done reading. But I still read every word and catalog it all as something I will need to try and learn more about later.

Bubba.

 

[robertmee]

I feel a bit ganged up on....

No need to feel that...I read your posts often and your solutions are elegant and well thought out. My only point is that it's not prudent to discount entirely the need of the customer and their technical staff...some posters made reference that it's not their problem that Fat Frank or Bubba doesn't know how to troubleshoot their code...that they aren't going to the trouble of rewriting code just because it works. I understand that from an OEM standpoint where your time is money, and re-engineering for no apparent gain on your side is not prudent. But I've been firmly on the other side in 100's of manufacturing facilities across this land, and the competent, near engineering level technician is a dying breed. The older guys/gals are retiring and the younger ones want to go into IT in a clean environment, and not a dirty manufacturing environment. So, most companies are forced to run skeleton crews of technicians and because the job pool is limited, they might have to hold on to technicians that don't want to learn. They know XIC's, XIO's, OTE's and a few higher order instructions. So, it's our job to help our customer and write code that are within the means of their staff to troubleshoot and expand. With today's powerful processors, 1 rung with a non-understandable instruction that replaces 20 rungs of well structured and understandable code is not an advantage.

And trust me, upper management listens to their technicians when they grumble that this code isn't understandable, or hard to troubleshoot or looks like spaghetti. I've made a fair living on rewriting OEM code for my long time customers for this reason. In the end, the base functionality is the same, but it conforms to a standard that their technicians are used to, can understand and troubleshoot.

Finally, in regards to the comparison of an SQO to say a PID or FAL instruction. Certainly a PID takes a fair amount of understanding to set up and tune. But it has limited control...One PV and one CV. Once it's working, rarely does anyone have to interact with it. The same for a FAL that's usually doing a math operation on an array. But an SQO that's controlling an entire sequence of event of operations is a different animal. When the OEM walks away and it's working from A to E, that's great. But three years from now, the plant wants to add step M in the middle, and since the plant has no engineering staff, the technician is asked to do it. The OEM is out of business so they're no help. I've seen it often.

 

[proof]

I feel a bit ganged up on....

I don't see what is said was so bad, especially considering people tend to be blunt on the Internet. Try not to read too much into 'rude' posts. Even when people think you are wrong, the disagreeable posts are usually meant as constructive criticism, or are funny rants from drunk and stoned trolls.

However, this time I will gang up on your side.

People that code for OEMs may be able to take exception, I think code should be written so that it can be easily maintained by engineers, but not the Bubbas. Easy to maintain does not mean only using the most basic instructions, it is more about logical flow and segmenting of functions, and formats that permit changes to code to me made that doesn't require shutting down HMIs. The people maintaining code should be competent enough to understand these instructions. Even if they don't know how the work, they should be able to learn them from the manuals.

On the other hand, Bubbas need to get into the code to troubleshoot, it is because
1) The code is buggy and doesn't work properly.
2) Something in the field isn't working properly.

For situation 1, if that is due to people misusing the fancier instructions, I can assure you that they will screw up just using simple commands. This code is also a nightmare to try to understand.

For situation 2, Bubba should be able to use his basic troubleshooting skill to find/look at inputs and outputs to find field problems, but he shouldn't be need or be expected to understand the nuances of the code.

Unfortunately, with more of the networked drives and devices, the Bubbas are out of their leagues. For example, they don't understand how drives communicate with devicenet masters, and how the PLCs talk with devicenet masters, and how the different parameters get mapped. Trying to program for Bubba can be futile.

If you want to help Bubba, write code using AOIs and routines that have been well designed and tested, work properly, and give appropriate alarms and overrides in the HMI when field issues occur that will show what is not working normally. If Bubba never needs to get into the code, it doesn't matter to him how its coded. It might matter to the maintenance engineer, but he should be smart enough to be able to learn and understand the higher level instructions.