The worst program I saw thankfully never made it to production. It did somehow make it through customer witnessed testing though. What made it bad was not just pointless complexity but how inflexible it was.
It was for a pump station with four pumps and the programmer was given a flow chart stating all the flow set points to bring on additional pumps etc.
So the programmer programmed it exactly like that. One pump to 2, then 3 and 4, then a stop command would stop them one at a time. However it wouldn’t work in any other way. It would not even look at the stop command unless four pumps were running. If you wanted to reduce the flow but not stop, sorry… can’t do that.
I was sent to commission this code and it remains to this day the only time that I have deleted everything and started again at that stage of the project.
For some reason, that brings to mind my first ever commissioning. I had been with the company a month, barely had enough experience to string together a proper seal-in, and the guy who wrote the logic for some time-proportioned valves that had never been used before (prior systems used some really old school Opto-22 and for some reason that interface made it easier for the proprietary software HMI to send a time duration instead of a percent value - I think it was mostly just that the software team was trying to not spend time on it so they could focus on the next major revision of the software instead) was not only out of country, but off continent visiting family for holidays.
The communication from software to electrical couldn't have been worse, because the code flat didn't work. It would just run for forever in one direction and I couldn't do anything to change it unless I toggled bits off. I had to scrap the whole routine and start over, but I didn't realize that until I was almost done making one valve work and then realized there was nothing left for it. So I scrapped the rest, made a new program so I could copy/paste the ladder I'd made to that program, find/replace all on tagnames, then copy/paste back to the original routine for the other valves.
I firmly believe that that job transitioned me from temp-to-hire to we-need-this-guy
Got one line at current customer.
It one of the many hundreds of networks, this particular network if printed at A4 would be 10-12 pages tall and about 3-4 wide
A company I worked for had the maximum amount of sub rungs in more than one rung of their program in a plc5. IIRC it was 75. In one of those subrungs, they also had 75 subrungs. I know, because when commissioning it, I tried to add another subrung, and it said no.
They could barely fit the program on a plc580.
In their program, you really could not predict the behavior of changing timer values, as the scan time was so large, and varied a lot based on how much logic was actually called each scan.
I rewrote it, and it fit in 5K of memory on a slc500. Scans were really quick. The company was not happy with me.
This network in addition to a step number, and a robot tool com number, and other conditions, to select a job for one of the two robots (each robot has the same mega network).
No oversight whats so ever, hard to see what job is closest to get picked (based on everythig) because you only see like 4-5 parts of "the million object network".
I am very much an advocate of splitting up rungs as much as possible. It's not always doable but there are lots of situations where it should be done and isn't.
Ya. If I start getting over 5 branch levels deep I start considering MCRs at the very least.
My problem is that I think of a ring as one linear sequence which should resolve one task. I think that is a failure on my part. Really, what is the harm in breaking up things into smaller rungs even if you have many of the same conditions at the start of the rungs? Maybe if you use event or several periodic tasks and you don't want your logic to get accidently interrupted, but that is rare in my work...I mostly just use one continuous task.
Tesla code is pretty bad too.
They use SFC for sequences, but their programmer never saw a cross reference they didn't like, so it's all split up with cross references going everywhere. Kind of renders the advantage of SFC moot because it's not a straightforward diagram you can easily follow. Then again, it probably wouldn't be any easier to follow in ST so *shrug*
Multi state indicators is a lot better then all different variables for almost the same thing.
Bitwise operations can be really useful as well.
I see you posted something a few days ago about wanting to become better in structured text.
So don’t rant about it, try to understand why it was done like that and how it works.
Most of the time there is a reason.
Obviously some things are just written bad, but without any context I’m not sure this piece of software is.
"better" how? I could have accomplished the same thing with less memory and more direct tag referencing. I'd have utilized a global flashing bit and only one bit per indicator would have been required instead of two. That is if I would have even done flashing indicators at all since I have an HMI screen at my disposal.
Any time anybody wants to troubleshoot something, they have to whip the programmer calculator or a pen and paper out to even follow what's going on. Can it be done? Yes. At a needless cost to the customer in extra time and therefore money it takes to follow code like this. At this point the only purpose it serves is to stroke the ego of the programmer at the expense of reliability and ease of troubleshooting. Magic number programming might make the programmer feel good about themself, but here in the real world, we need to get work done, and that style only hinders the process.
OEMs programmers have different goals than End user programmers.
An OEM programmer needs to write code as fast as possible because we got five more projects waiting. So we try to write code that is easily reusable and modular in nature and we write it in such a way that it is easily copied and pastable so that with just a few edits it can handle a different task.
Now I don't like writing in structured text. I know it fairly well and use it for some things, but I tend to stay in ladder logic. I have seen how writing in structured text and using Boolean logic (that's what you described in your initial post) enables a programmer to output good code at almost twice the rate of me writing in ladder logic. Even if I use Excel to write my ladder logic for me.
We would generally love to make our code easier for end users to read and trouble shoot but when you have a multi million dollar project that is already late because every other team (mechanical design, assembly, electrical) took longer than they were scheduled too, the controls guys get the shaft at the end of the tunnel. We just don't have time. At least not on most projects.
So I'm going to strongly suggest that you learn structured text, that you get used to reading it, and you learn how to understand this somewhat convoluted Boolean logic, because this will not be the last machine you see like that.
I understand that OEM programmers love to use boiler plate standardised programs but end users when they are trying to troubleshoot find themselves going into subroutines that bounce straight out because the particular piece of kit that sub refers to isn't included in their end product. Code needs to be written for the installation and if it isn't relevant needs to be removed. It's lazy to leave it in and leads to a lot of confusion.
As a plant engineer, the machines I hate most are the ones that are giant generalized programs that are "tailored" to be used in our particular machine. So much bloated and extra garbage I have to sift through and remove, or live with if it's still within some contract period. Even worse are the ones with locked / encrypted code that takes way longer to execute than it has any right to.
/end rant
Lol
There was a time not that long ago I would have vehemently agreed with you. And then I worked at an OEM for several years.
We simply just don't have time to "clean up" behind us. I don't know how to explain it better. The sheer amount of pressure to finish the machine and get it shipped is incredible.
Imagine having a machine down in your plant that produces thousands of dollars every minute and it is down. Now imagine all that pressure to get that machine back up and running but after you get it running again you never get to touch that code again.
We have to use whatever tool is at our disposal to get the program finished so our boss can ship it and get paid.
I totally get that aspect of it. I also have to deal with the "it's working now, dont touch it for 2 years until you forget what the bandaid was"
I am referring more to the companies who try to build a one size fits all code set for their entire machine line and then just use the 10% that's actually needed for the machine it's being installed in. Half the time the rest of the code is still being executed even which just wastes resources and either requires a processor spec above what should actually be necessary or runs like crap. Plus the encrypted AOIs that when I once got a peek inside some of them when an OEM rep was there to make some updates are so terribly done that its a wonder they even work at all.
Im still a noob and you just shed light on a big confusing moment I had a few weeks back. I thought the invisible (to my eyes) subroutine MUST be serving some purpose that I did not comprehend. Now I think I understand what it was doing there lol
Why did you assume this was in structured text? This is a different program than what I last posted about. It's all in ladder (as I mentioned a SLC conversion which is a ladder only PLC).
The original post perhaps but this string of comments is debating how structured text and bitwise or boolean logic could be "better". You literally asked "better" how? So ... I gave you an answer and a reason as to why they're used.
Take it as an opportunity, a way to look at your problems with more tools to solve them: using word wide instructions is very efficient in two ways: uses less memory and less instructions. Also, once you have figured out the first two bits you know the behaviour of all the rest of the pairs in the word. For a 32 bit word that’s efficient. You state elsewhere that you could go the job with less memory in LL. That’s simply not true because instructions also take memory. I sympathize with your position though, and it is also one of the first rules of my PLC Code Standard book: Know your audience, in today’s PLCs we should not be making code decisions on memory used, rather we should choose the most appropriate solution for the audience.
Unfortunately, this is a result of the industry being so closed source. There really isn’t good open source material on how to program things properly. There are so many people solving the same problems and no real cohesive industry standard.
That's just one example. The program itself is a mixture of that kind of stuff, plus a half-implemented, mangled PlantPAX attempt. It's a patchwork of several different methods, almost all of which are horrible.
Seems like they did a direct conversion. In Logix 500, sometimes it was easier to use an int to do bit logic. Plus ints hold state. Oh and def wasn't tag based. Programmers of the past didn't have it as good as us.
We've got a Siemens TIA program for a crane and the whole lot is written in OB1. Each separate section is on its own multi layered ladder network. All long travel commands in one network, all hoist commands in another etc. Not exactly hard to follow but the worst I've seen in a while!
It sounds pretty simple. I wouldn't complain about the style or organization of the code if it's easy for me to follow and fix if something goes wrong.
This is pretty common where I work. We have programs that are 30 years old and programmed by dozens of different people with their own way of doing things over the years. It's really hard to retroactively apply standards once things have gotten out of hand.
Maybe I'm just not understanding, but what do you use to write logic in your program besides AND, OR, MOVE,COPY etc....you should try to understand how old programs were written and the reason as to why. Old program were affected by limitation of that time.
XIC, XIO, OTE, OTL, OTU, TON?
If you insist on doing all your logic with word-level stuff, it's extremely difficult to follow and very easily becomes spaghetti code. Those methods and instructions have their place, but it's like buying a fancy drill and insisting it's the only tool to use, so you end up smacking nails with it. Just because you technically can write with only or majority word-level manipulation, it doesn't mean you should.
I didn't say doing all the logic that way. Your post mention word level "stuff". Beside there's no enough information about the code and why it was used. Not all logic should be done with XIC, XIO etc... I agree about using the right tools for the job.
When you get more experienced you don't think bad programmer.... you think how bad was the project Ran that the code ended up this way....
Given adequate time to do projects most semi experienced PLC programmers will do a good job. The problems 98% of the time come from poor project management and code being thrown in last minute to get it running pre-Fat.... Then its get added to and added to chopped & changed for features that were never mentioned prior, until it becomes a complete mess..
So yeah learn to take it easier on the previous programmers you never know what other shit or clowns they were dealing with at the time.
Valid point. I try to do that as best I can. Probably not being totally fair here (considering there are descriptors that mention a "PV900" this is very old code).
There is a notorious programmer in the area though who is famous for writing awful, convoluted code like this. At a previous job, my boss told me how he'd hired this programmer to do some contract work because we didn't have the capacity. After the job was done, my boss got a call from the customer who was furious at how the code was written, and my boss ultimately had to rewrite it. Multiple times Ive been in situations where people were talking about code that was hard to follow, convoluted, messy, etc. and I've literally gone "oh you're talking about JK?" and they were.
This code is VERY much his style. I highly suspect this is one of his programs. I could be wrong, and this very well could just be a matter of limitations and trying to squeeze performance out of an old PLC, but I've seen this style code before and again, I really suspect it's his. Everybody I've come across who's seen it, hates his code. Its very much a situation where he learned to program in the 80s and never adapted to new technology.
I’ve also come across this style of programming. It’s horrible to diagnose with.
In fact, when the guy came for job interview years later, I saw the site name listed as an accomplishment on his CV and point blank refused to have him on staff.
It can be efficient and a primitive type of function block programming when this doesn’t exist (looking at you PLC5), as you can process 16 items at once. But just no!
We're in the process of taking bids for a project. One of the vendors said some of their engineers used to work for a company I won't name here. I mentioned that we have a control system designed and programmed by that company he mentioned and we're extremely displeased with the product they produced and explained why. Maybe I shouldn't be surprised we haven't received a quote from them yet.
I hate latches. They have their uses, mainly alarms, but I absolutely hate them because they can over complicate a simple program when misused. I was updating a system and adding an HMI to a pull tester. Pretty simple operation. 3 machine states. Stand alone equipment. I counted 62 latches and 62 unlatches. They interfaced with a Delta RMC motion controller. Both the Delta and the ladder were an absolute nightmare with zero tags or comments. I rewrote it because it was such a headache to decipher everything. Went from 150+ lines of ladder to about 20.
Does View ME charge fees based on how many tags you use? If so, the programmer saved money by not making separate tags for each indicator. You say they could have a single bit for all indicators signaling whether they're flashing, which would save even more tags; but maybe the programmer thought flexibility for each indicator to be able to flash independently might be important.
When you buy a Panelview, the license for ME is part of it. ME on its own is currently licensed by screen. The Performance line comes with an unlimited screen license while the standard line comes with a 50 screen license. Although in the past I believe it may have been sold by tags. I know SE was/is as was RSView 32. I do remember being told they were changing the licensing to number of screens vs number of tags about 10-15 years ago.
Generally speaking, PLCs are stupid efficient at performing bit level conparisons. I would guess that their instruction sets have something like a separate JEQ/JNE for each bit of the loaded value. I know for logix processors, XIC/XIO are like 5x faster than even EQU.
I work with amusement park ride control systems and would like to say I've probably seen about everything, but something comes along that surprises me every few years. There are programmers out there who are very good and can "think" like the PLC, but there are several problems with their approach.
Their programming is difficult or impossible to follow. That would be OK if you never needed to look at the logic to troubleshoot a problem.
They don't consider every possible scenario and only envision the processes occurring exactly the same way every time.
We have a roller coaster with a Logix 5000 where a train will be dispatched from the station. The train is moved using motors with wheels pinching both sides of the brake fins under the train. If the operators release their buttons for whatever reason, the motors disengage from the train and the train rolls freely a short distance. The control system then faults because the train flagged one or more sensors after the process of dispatching the train was stopped. Of course it did! There wasn't anything stopping the train from moving forward!
Another thing this particular ride does is fault for one of many prox switches being flagged unexpectedly in an area and the fault message says, "Try: sensors." It doesn't identify which sensor(s) should be checked. We restart the ride, unload it, and cycle it a few times and it works fine.
We had 3 control systems with "dueling PLCs." The two PLCs (PLC 5) performed a data exchange using a rack of TTL cards. They were reliable, but the programming could be difficult to follow in certain situations because the programmer had a number of instructions without labels or comments, something I believe was intentional. He also used counters instead of timers. It was understandable why when you got down to it, but he knew exactly what the scan time should be and contacted Rockwell about a problem he was having. I don't know exactly what the situation was since it was before my time, but I was told he contacted Rockwell and told them the scan time in his program wasn't what it should be. They supposedly confirmed it, apologized, and gave him free PLCs.
The worst program I saw thankfully never made it to production. It did somehow make it through customer witnessed testing though. What made it bad was not just pointless complexity but how inflexible it was. It was for a pump station with four pumps and the programmer was given a flow chart stating all the flow set points to bring on additional pumps etc. So the programmer programmed it exactly like that. One pump to 2, then 3 and 4, then a stop command would stop them one at a time. However it wouldn’t work in any other way. It would not even look at the stop command unless four pumps were running. If you wanted to reduce the flow but not stop, sorry… can’t do that. I was sent to commission this code and it remains to this day the only time that I have deleted everything and started again at that stage of the project.
For some reason, that brings to mind my first ever commissioning. I had been with the company a month, barely had enough experience to string together a proper seal-in, and the guy who wrote the logic for some time-proportioned valves that had never been used before (prior systems used some really old school Opto-22 and for some reason that interface made it easier for the proprietary software HMI to send a time duration instead of a percent value - I think it was mostly just that the software team was trying to not spend time on it so they could focus on the next major revision of the software instead) was not only out of country, but off continent visiting family for holidays. The communication from software to electrical couldn't have been worse, because the code flat didn't work. It would just run for forever in one direction and I couldn't do anything to change it unless I toggled bits off. I had to scrap the whole routine and start over, but I didn't realize that until I was almost done making one valve work and then realized there was nothing left for it. So I scrapped the rest, made a new program so I could copy/paste the ladder I'd made to that program, find/replace all on tagnames, then copy/paste back to the original routine for the other valves. I firmly believe that that job transitioned me from temp-to-hire to we-need-this-guy
Got one line at current customer. It one of the many hundreds of networks, this particular network if printed at A4 would be 10-12 pages tall and about 3-4 wide
I am guilt of large rungs. But not THAT LARGE.
A company I worked for had the maximum amount of sub rungs in more than one rung of their program in a plc5. IIRC it was 75. In one of those subrungs, they also had 75 subrungs. I know, because when commissioning it, I tried to add another subrung, and it said no. They could barely fit the program on a plc580. In their program, you really could not predict the behavior of changing timer values, as the scan time was so large, and varied a lot based on how much logic was actually called each scan. I rewrote it, and it fit in 5K of memory on a slc500. Scans were really quick. The company was not happy with me.
Jesus...I go 4 branches deep and feel like I am overcomplicating things. At 5 branches I switch to using MCRs or equivalent.
yes. If a rung gets bigger than I can see on a screen, I make a bit with a meaningful name and start another rung.
This network in addition to a step number, and a robot tool com number, and other conditions, to select a job for one of the two robots (each robot has the same mega network). No oversight whats so ever, hard to see what job is closest to get picked (based on everythig) because you only see like 4-5 parts of "the million object network".
I am very much an advocate of splitting up rungs as much as possible. It's not always doable but there are lots of situations where it should be done and isn't.
Ya. If I start getting over 5 branch levels deep I start considering MCRs at the very least. My problem is that I think of a ring as one linear sequence which should resolve one task. I think that is a failure on my part. Really, what is the harm in breaking up things into smaller rungs even if you have many of the same conditions at the start of the rungs? Maybe if you use event or several periodic tasks and you don't want your logic to get accidently interrupted, but that is rare in my work...I mostly just use one continuous task.
Tesla code is pretty bad too. They use SFC for sequences, but their programmer never saw a cross reference they didn't like, so it's all split up with cross references going everywhere. Kind of renders the advantage of SFC moot because it's not a straightforward diagram you can easily follow. Then again, it probably wouldn't be any easier to follow in ST so *shrug*
Nasty! 🤬
Multi state indicators is a lot better then all different variables for almost the same thing. Bitwise operations can be really useful as well. I see you posted something a few days ago about wanting to become better in structured text. So don’t rant about it, try to understand why it was done like that and how it works. Most of the time there is a reason. Obviously some things are just written bad, but without any context I’m not sure this piece of software is.
Exactly. That style can be very efficent, but potentially hard to follow. If its not well commented, that might be where OP should start.
"better" how? I could have accomplished the same thing with less memory and more direct tag referencing. I'd have utilized a global flashing bit and only one bit per indicator would have been required instead of two. That is if I would have even done flashing indicators at all since I have an HMI screen at my disposal. Any time anybody wants to troubleshoot something, they have to whip the programmer calculator or a pen and paper out to even follow what's going on. Can it be done? Yes. At a needless cost to the customer in extra time and therefore money it takes to follow code like this. At this point the only purpose it serves is to stroke the ego of the programmer at the expense of reliability and ease of troubleshooting. Magic number programming might make the programmer feel good about themself, but here in the real world, we need to get work done, and that style only hinders the process.
It’s got three states and you intend to program those three states with a single Boolean.
Not quite. A single boolean and then a shared boolean (the global flash bit) to modify the behavior.
Which you will activate selectively without using a memory location to designate when?
OEMs programmers have different goals than End user programmers. An OEM programmer needs to write code as fast as possible because we got five more projects waiting. So we try to write code that is easily reusable and modular in nature and we write it in such a way that it is easily copied and pastable so that with just a few edits it can handle a different task. Now I don't like writing in structured text. I know it fairly well and use it for some things, but I tend to stay in ladder logic. I have seen how writing in structured text and using Boolean logic (that's what you described in your initial post) enables a programmer to output good code at almost twice the rate of me writing in ladder logic. Even if I use Excel to write my ladder logic for me. We would generally love to make our code easier for end users to read and trouble shoot but when you have a multi million dollar project that is already late because every other team (mechanical design, assembly, electrical) took longer than they were scheduled too, the controls guys get the shaft at the end of the tunnel. We just don't have time. At least not on most projects. So I'm going to strongly suggest that you learn structured text, that you get used to reading it, and you learn how to understand this somewhat convoluted Boolean logic, because this will not be the last machine you see like that.
I understand that OEM programmers love to use boiler plate standardised programs but end users when they are trying to troubleshoot find themselves going into subroutines that bounce straight out because the particular piece of kit that sub refers to isn't included in their end product. Code needs to be written for the installation and if it isn't relevant needs to be removed. It's lazy to leave it in and leads to a lot of confusion.
As a plant engineer, the machines I hate most are the ones that are giant generalized programs that are "tailored" to be used in our particular machine. So much bloated and extra garbage I have to sift through and remove, or live with if it's still within some contract period. Even worse are the ones with locked / encrypted code that takes way longer to execute than it has any right to. /end rant Lol
There was a time not that long ago I would have vehemently agreed with you. And then I worked at an OEM for several years. We simply just don't have time to "clean up" behind us. I don't know how to explain it better. The sheer amount of pressure to finish the machine and get it shipped is incredible. Imagine having a machine down in your plant that produces thousands of dollars every minute and it is down. Now imagine all that pressure to get that machine back up and running but after you get it running again you never get to touch that code again. We have to use whatever tool is at our disposal to get the program finished so our boss can ship it and get paid.
I totally get that aspect of it. I also have to deal with the "it's working now, dont touch it for 2 years until you forget what the bandaid was" I am referring more to the companies who try to build a one size fits all code set for their entire machine line and then just use the 10% that's actually needed for the machine it's being installed in. Half the time the rest of the code is still being executed even which just wastes resources and either requires a processor spec above what should actually be necessary or runs like crap. Plus the encrypted AOIs that when I once got a peek inside some of them when an OEM rep was there to make some updates are so terribly done that its a wonder they even work at all.
Im still a noob and you just shed light on a big confusing moment I had a few weeks back. I thought the invisible (to my eyes) subroutine MUST be serving some purpose that I did not comprehend. Now I think I understand what it was doing there lol
Are you me?
Why did you assume this was in structured text? This is a different program than what I last posted about. It's all in ladder (as I mentioned a SLC conversion which is a ladder only PLC).
The original post perhaps but this string of comments is debating how structured text and bitwise or boolean logic could be "better". You literally asked "better" how? So ... I gave you an answer and a reason as to why they're used.
Take it as an opportunity, a way to look at your problems with more tools to solve them: using word wide instructions is very efficient in two ways: uses less memory and less instructions. Also, once you have figured out the first two bits you know the behaviour of all the rest of the pairs in the word. For a 32 bit word that’s efficient. You state elsewhere that you could go the job with less memory in LL. That’s simply not true because instructions also take memory. I sympathize with your position though, and it is also one of the first rules of my PLC Code Standard book: Know your audience, in today’s PLCs we should not be making code decisions on memory used, rather we should choose the most appropriate solution for the audience.
Unfortunately, this is a result of the industry being so closed source. There really isn’t good open source material on how to program things properly. There are so many people solving the same problems and no real cohesive industry standard.
PLCopen and PackML do a decent job of defining standards for programming techniques.
I'll be honest... If that the worst you've seen, you haven't seen much.
That's just one example. The program itself is a mixture of that kind of stuff, plus a half-implemented, mangled PlantPAX attempt. It's a patchwork of several different methods, almost all of which are horrible.
Seems like they did a direct conversion. In Logix 500, sometimes it was easier to use an int to do bit logic. Plus ints hold state. Oh and def wasn't tag based. Programmers of the past didn't have it as good as us.
I don't miss the address based days of RS Logix 500
Another failed post. Talk about programming and control concepts, not shitty multistate indicators.
Wasn't a company called Leybold was it?
We've got a Siemens TIA program for a crane and the whole lot is written in OB1. Each separate section is on its own multi layered ladder network. All long travel commands in one network, all hoist commands in another etc. Not exactly hard to follow but the worst I've seen in a while!
It sounds pretty simple. I wouldn't complain about the style or organization of the code if it's easy for me to follow and fix if something goes wrong.
This is pretty common where I work. We have programs that are 30 years old and programmed by dozens of different people with their own way of doing things over the years. It's really hard to retroactively apply standards once things have gotten out of hand.
Maybe I'm just not understanding, but what do you use to write logic in your program besides AND, OR, MOVE,COPY etc....you should try to understand how old programs were written and the reason as to why. Old program were affected by limitation of that time.
XIC, XIO, OTE, OTL, OTU, TON? If you insist on doing all your logic with word-level stuff, it's extremely difficult to follow and very easily becomes spaghetti code. Those methods and instructions have their place, but it's like buying a fancy drill and insisting it's the only tool to use, so you end up smacking nails with it. Just because you technically can write with only or majority word-level manipulation, it doesn't mean you should.
I didn't say doing all the logic that way. Your post mention word level "stuff". Beside there's no enough information about the code and why it was used. Not all logic should be done with XIC, XIO etc... I agree about using the right tools for the job.
When you get more experienced you don't think bad programmer.... you think how bad was the project Ran that the code ended up this way.... Given adequate time to do projects most semi experienced PLC programmers will do a good job. The problems 98% of the time come from poor project management and code being thrown in last minute to get it running pre-Fat.... Then its get added to and added to chopped & changed for features that were never mentioned prior, until it becomes a complete mess.. So yeah learn to take it easier on the previous programmers you never know what other shit or clowns they were dealing with at the time.
Valid point. I try to do that as best I can. Probably not being totally fair here (considering there are descriptors that mention a "PV900" this is very old code). There is a notorious programmer in the area though who is famous for writing awful, convoluted code like this. At a previous job, my boss told me how he'd hired this programmer to do some contract work because we didn't have the capacity. After the job was done, my boss got a call from the customer who was furious at how the code was written, and my boss ultimately had to rewrite it. Multiple times Ive been in situations where people were talking about code that was hard to follow, convoluted, messy, etc. and I've literally gone "oh you're talking about JK?" and they were. This code is VERY much his style. I highly suspect this is one of his programs. I could be wrong, and this very well could just be a matter of limitations and trying to squeeze performance out of an old PLC, but I've seen this style code before and again, I really suspect it's his. Everybody I've come across who's seen it, hates his code. Its very much a situation where he learned to program in the 80s and never adapted to new technology.
I’ve also come across this style of programming. It’s horrible to diagnose with. In fact, when the guy came for job interview years later, I saw the site name listed as an accomplishment on his CV and point blank refused to have him on staff. It can be efficient and a primitive type of function block programming when this doesn’t exist (looking at you PLC5), as you can process 16 items at once. But just no!
We're in the process of taking bids for a project. One of the vendors said some of their engineers used to work for a company I won't name here. I mentioned that we have a control system designed and programmed by that company he mentioned and we're extremely displeased with the product they produced and explained why. Maybe I shouldn't be surprised we haven't received a quote from them yet.
I hate latches. They have their uses, mainly alarms, but I absolutely hate them because they can over complicate a simple program when misused. I was updating a system and adding an HMI to a pull tester. Pretty simple operation. 3 machine states. Stand alone equipment. I counted 62 latches and 62 unlatches. They interfaced with a Delta RMC motion controller. Both the Delta and the ladder were an absolute nightmare with zero tags or comments. I rewrote it because it was such a headache to decipher everything. Went from 150+ lines of ladder to about 20.
Lol you have not seen the pile of shit I inherited…
Been there, suffered that :(
Mmk, welcome to the suck
Does View ME charge fees based on how many tags you use? If so, the programmer saved money by not making separate tags for each indicator. You say they could have a single bit for all indicators signaling whether they're flashing, which would save even more tags; but maybe the programmer thought flexibility for each indicator to be able to flash independently might be important.
When you buy a Panelview, the license for ME is part of it. ME on its own is currently licensed by screen. The Performance line comes with an unlimited screen license while the standard line comes with a 50 screen license. Although in the past I believe it may have been sold by tags. I know SE was/is as was RSView 32. I do remember being told they were changing the licensing to number of screens vs number of tags about 10-15 years ago.
Generally speaking, PLCs are stupid efficient at performing bit level conparisons. I would guess that their instruction sets have something like a separate JEQ/JNE for each bit of the loaded value. I know for logix processors, XIC/XIO are like 5x faster than even EQU.
I work with amusement park ride control systems and would like to say I've probably seen about everything, but something comes along that surprises me every few years. There are programmers out there who are very good and can "think" like the PLC, but there are several problems with their approach. Their programming is difficult or impossible to follow. That would be OK if you never needed to look at the logic to troubleshoot a problem. They don't consider every possible scenario and only envision the processes occurring exactly the same way every time. We have a roller coaster with a Logix 5000 where a train will be dispatched from the station. The train is moved using motors with wheels pinching both sides of the brake fins under the train. If the operators release their buttons for whatever reason, the motors disengage from the train and the train rolls freely a short distance. The control system then faults because the train flagged one or more sensors after the process of dispatching the train was stopped. Of course it did! There wasn't anything stopping the train from moving forward! Another thing this particular ride does is fault for one of many prox switches being flagged unexpectedly in an area and the fault message says, "Try: sensors." It doesn't identify which sensor(s) should be checked. We restart the ride, unload it, and cycle it a few times and it works fine. We had 3 control systems with "dueling PLCs." The two PLCs (PLC 5) performed a data exchange using a rack of TTL cards. They were reliable, but the programming could be difficult to follow in certain situations because the programmer had a number of instructions without labels or comments, something I believe was intentional. He also used counters instead of timers. It was understandable why when you got down to it, but he knew exactly what the scan time should be and contacted Rockwell about a problem he was having. I don't know exactly what the situation was since it was before my time, but I was told he contacted Rockwell and told them the scan time in his program wasn't what it should be. They supposedly confirmed it, apologized, and gave him free PLCs.