The end of ladder logic?

[tom_stalcup]

Evidently the vacuum tubes are making a comeback.... There is some talk floating around that the next big jump in computer speed is going to happen with nanotech made vacuum tubes... I couldn't find the article that I read last week, but here's a similar one.

 

[CaseyK]

I miss vacuum tubes.

More than once, I took the finals out of my motrac to get some customers radio working.

Always had tubes, transistors and IC's were generally not caried, other than a couple of more common ones.

Then, back before modicon, was vacuum tube controllers...

Any antiques out there remember these???

regards.....casey

 

[monkeyhead]

I doubt ladder is going anywhere.

I find it interesting that so many of you said ladder is simpler than some of the other options out there. It took me a while to figure out ladder despite understanding relay logic and boolean. It took reading Phil's book and covering how scans occur before it made any sense to me. Seriosly, without a firm understanding of how scans happen, ladder logic is useless.

I also grew up on high level text languages, so when moving into the PLC world, running into a function block or a language like Opto22 uses was always easier for me to figure out than rung that requires analyzing it in terms of the way it is scanned over several scans.

Either way, I gladly accept new languages. More tools to get the job done. And language X may be **** for one applications, where language Y shines, but there's probably another application where language X is the ticket and language Y's solution is clunky and messy.

 

[ukguy777]

What a thread!!

It seems to be the case that the strongest argument for ladder is "it works well and is easy", which kind of seems like a nostalgic arguament. I, like most of the others on here who's dealings with PLCs/HMIs are as a side issue to their main job, love ladder because i know it. It is a great feeling when you're working on a fault and you know how to hook a laptop up to manipulate the logic and diagnose a fault in seconds ("it wont run because sensorX isn't on...where the hell is sensorX..."). I think my reluctance to accept any other language is that i'm afraid of not being able to do what i can do as easily, so i dissmiss it without trying it.

Many people in my position are self taught (to some degree) and do not want to have to struggle to learn a new language in their ever decreasing free time. It seems like unneccessary use of technology to me to do something in ST, STL or FBD that can be done in ladder (which i will have a fighting chance of understanding).

Unfortunately, my arguament for ladder above is a personal one, and ultimately based on my fear, and desire for an easy life. I've got 40years working left in me though, and if i want to develop and stay on top of things, i will have to adapt to the machines, and not try and hold them back to what i know.

If Ladder really is the be all and end all, it will remain dominant, seeing off the other languages. The proof will come when profitability goes down because of increased downtime - waiting for the OEM to fly in to perform minor modifications. An engineering manager WILL notice if his team now fail to fix faults they previously didn't struggle with.

It's up to me to stay current and learn, and if i love working on the PLCs/HMIs then thats what i'll have to do. Complaining that "it's all in ST..." will not fix the problem, and will not contribute to my development.

I agree that the motivation behind it all may be financial, but i think there is another motivation, which the electricians/techs etc fear more, which is different languages are being used to create an "us and them" divide, between end user people, and OEM people.

Sorry it was a bit rambling.

Guy

 

[TimothyMoulder]

I like ladder, and I want it to stay.

I like Tom's idea of being able to write code in other forms and have it triggered from within a ladder.

I think Ron is right - all these languages without any conventions were a mistake. But while there's a buck to be made, nobody is ever going to have a genuine standard without goverment intervention - and here in the US, the conservatives have bigger concerns, like reducing funding for Sesame Street. Apparently "Bert and Ernie" promote the "gay agenda" or something...

The best outcome, I think, would be for someone to write a ladder editor that could be compiled for different processors. Use the exact same code and compile to run on AB, Seimens, GE, or what-have-you. Now THAT would be a breakthrough, forcing these guys to consider some genuine standardisation.

TM

 

[glenncovington]

The real winner would be if a manufacturer could or would develop software that would allow programming in the higher level languages, but display them in ladder logic form. Step7 does this a little bit, but if the STL is too complicated you're out of luck. In this way the 'programmer only guys' can write code quickly, and the 'guys that make it all work' can troubleshoot the code with a good graphical representation of what is going on.


My $.02

 

[MarkTTU]

My 2c...

Quote:
However windows is a dosshell


Not for a long time.

Actually it really is... Windows NT, 2000, XP, 2003, are all Disk Operating Systems; in fact they are all graphical shells on top of a command line structure. Much like EVERY other operating system they are command line first, graphical second. Take a look at the MAC and you'll see the same thing, difference being that MAC did not publish how to get at the command line until OSX, but even on a MAC you can get at the command line. Think of it like a PLC, it doesn't really matter what language you program in, the PLC only understands machine code.

As for ladder logic I don't see it going anywhere. Writing text code that allows a machine to run if limit switches 1,2, and 3 are made, but 4,5, and 6 aren't, and only while STOP is not pressed is a very simple single rung. In text?!?!?!

I agree that the ultimate will be a combination, ladder calling ST portions or ST calling the ladder. My personal preference would be ladder calling the ST.

As an aside I came from a BASIC, C++ background, loved assembly when they taught it at school, and wouldn't program my machines in anything but ladder.

 

[CaseyK]

I like ladder, and I want it to stay.

Well said!

I like VCR tapes, and don't want to have to buy anything else new. But, I lose on that one.

We do have a DVD player, and a DVD in at least two computers.

But I want VCR's, AND audio casettes to stick around.

It was okay that 8 track left.

regards.....casey

 

[yam785]

So a tradesman can't learn to read anything buy ladder? To the contrary, I can take most tradesmen and show them how to work with STL within an hour. Usually, they say something like "Huh? That's it? This is pretty easy." They always pick right up on it.





Better is subjective. But faster? Absolutely. Unless we are talking about a very simple machine with nothing but boolean logic, the scan time will be cut in half or more. That has been my experience.







Again, that would apply only to a simple program. The last project I worked on took about 1200 hours of programming time. I know I saved about 800 hours by coding STL. It really is that much faster to program with.







It always cuts down on scan time, but it depends on the project whether it matters or not. In the project I just mentioned, my finished scan time was 8ms, and 14ms was the absolute allowable maximum. If I had used ladder throughout, the scan would have exceeded this. And who does it benefit? Well, the customer who gets to use the machine sooner, the maintenance guys who don't have to troubleshoot it as much, and the machine builder who just saved hundreds of hours of programming time.



I look at it this way: If the maintenance guys have to delve into my code all the time, then I screwed up. It just shouldn't be necessary (and apparently it isn't, because less than half of my customers even ask for the source code). We live in the day and age of HMI and marquee systems, so there is no reason that every conceivable fault can't be displayed somewhere. I display everything, right down to the IO status, all of the drive parameters, encoder feedback, plus a multitude of learning and homing functions. That should be the goal of a programmer: Write the code so no one has to work on it later.



By the way, I’m not some kind of computer geek. I specialize in fluid power systems and have more of a mechanical background than anything. I’m completely self-taught, and have never even taken a computer course. I just like to use the best tools available to do the job.

I look at it this way: If the maintenance guys have to delve into my code all the time, then I screwed up. It just shouldn't be necessary (and apparently it isn't, because less than half of my customers even ask for the source code). We live in the day and age of HMI and marquee systems, so there is no reason that every conceivable fault can't be displayed somewhere. I display everything, right down to the IO status, all of the drive parameters, encoder feedback, plus a multitude of learning and homing functions. That should be the goal of a programmer: Write the code so no one has to work on it later.

I can only laugh at this idea, as it is an impossible thought. We have 24 PLC's and 28 1394 drives, with numerous type's of HMI's, quality monitoring devices, and much more on each line. It's a very complicated process. You cannot forget about friction and wear. Parameters that work when the line is installed, will need to be changed. We do not shut down a line, everytime there is a problem. We do a lot of forcing, or using always false bits, to keep lines running. In speed control, alot can be done, with the drive parameters (gain,etc), to make something that is going bad, keep working long enough to make to a holiday, or other planned outage. We are still finding changes that needed to be made, 6 years after the lines were installed. My job is probably 98% use. As to the original subject, I beleive ladder will be around for a long time, as you have to have something simple, for us industrial electricians. Our company does not want operators changing parameters. It would be a disaster.

I have to say that either way, that technology is great. Where we used to have one main shaft with everything driven off of it, we now have 40 plus servo motors. It is incredible that all this equipment can match speeds perfectly.

Bob

 

[MarkTTU]

I've got to agree with S7Guy... I admit that we're an OEM so things are a bit different, but I never have and never will give anyone the source code to any of our products. If there is a program bug I should have caught it long before it made it out of our shop... I realize this is not true for probably 90% of all PLC installations, but I thought I'd point out that with good enough programming and HMI development there really shouldn't be a reason to work on the code... If you need to change something that can't be changed from the HMI, then the HMI was poorly programmed... Just my opinion though.

PS> I love the phone calls from electricians demanding a copy of the source or the CPU password because there is a program bug. Usually its a wiring problem (lack of an interlock most of the time).. It usually quiets them down a bit when I mention that out of the 50+ machines that are identical and working his is the only one with a software bug...

 

[msinclair]

Parameters that work when the line is installed, will need to be changed.

Sorry Bob, but I also have to agree with S7Guy and marksji on this one - parameter changes should be accessible through a properly programmed HMI. You shouldn't need code to do that.

I can (maybe) see your point with forces - though if you need the same forces regularly, I would again think that there is a deficiency in the original machine design.

Where I agree with you and disagree with S7Guy and marksji is that most machines that I work on "change" in their lifecycle. New products must be run on the same equipment, and often require significant code rewrites to address product requirements that weren't on the radar when the original specs were developed. Now, in fairness, most of what I work on are custom one-up machines and not a "standard" item from an OEM. (We do have several component machines that are "standard" - on these few pieces, I have never needed to go online.)

When programming, I strive to make my modifications consistent with S7Guy's ideals: I hope noone ever needs to access my code since if they need to, I have failed in my task . . .



As far as the original topic goes - I can't see ladder going away any time soon. Personally, I hope it never goes away. I find ladder to be the ideal way to write interlock and alarming logic.

The actual process may be well suited to ladder or not suited at all. Where not suited at all, I'd like to see (like others have suggested), a hybrid where you can program in both. It would be nice if it was a standard hybrid across platforms . . .

Marc



An aside similar to marksji - I also did all of my earlier programming in languages like C, Basic, Pascal, Fortan, Visual Basic, . . . so I am very comfortable programming in things other than ladder. I like ladder because it is well suited to many aspects of process control.

 

[glenncovington]

What about using the online code to aid in troubleshooting. No one talks about using the laptop and graphical code to troubleshoot just like using a voltmeter. I personnally use the code to troubleshoot what is happening or not happening more than any other tools (except the story of a good operator).

Not to make changes or to troubleshoot the code, but to troubleshoot the equipment. The code was proved out when the machine was commissioned, but why lock it away for no one to ever look at again. Use it to troubleshoot quicker, why the machine is not working today. Ladder is the easiest way for me to use the code/laptop as a machine troubleshooting tool.

 

[msinclair]

What about using the online code to aid in troubleshooting. No one talks about using the laptop and graphical code to troubleshoot just like using a voltmeter. I personnally use the code to troubleshoot what is happening or not happening more than any other tools (except the story of a good operator).

Not to make changes or to troubleshoot the code, but to troubleshoot the equipment.

Absolutely - I also do this regularly.

That said, a detailed HMI should give the user the same ability without having the code (in fact, it should be easier). I will admit though - I haven't seen too many HMI's up to that standard!


Marc

 

[DanielCamacho]

Technology has to grow...

I think just looking at the history of electronic devices, one sees a common trend of advancement. Electronic devices are getting faster, smaller, and with more capacity. I believe we will see the same with PLCs, they will become smaller faster and with more capacity. However, they simlpy can not go away...

 

[MarkTTU]

What about using the online code to aid in troubleshooting. No one talks about using the laptop and graphical code to troubleshoot just like using a voltmeter. I personnally use the code to troubleshoot what is happening or not happening more than any other tools (except the story of a good operator).

Not to make changes or to troubleshoot the code, but to troubleshoot the equipment. The code was proved out when the machine was commissioned, but why lock it away for no one to ever look at again. Use it to troubleshoot quicker, why the machine is not working today. Ladder is the easiest way for me to use the code/laptop as a machine troubleshooting tool.

I do this to, when working on debugging a new project... In reality if the machine is not working correctly then there should be an error or alarm message displayed on the HMI explaining what is wrong. If I can't get a macine to do X then when I try to tell the PLC do X I want a response from the PLC (via HMI) that says No I won't do X until you fix Y.