Engineers Vs. "Joe Maintenance"

Friedrich said:

After programming a CompactLogix I can see why you yankees are reluctant towards ST. Not only do you have to pay extra to be able to program ST, but the damn piece of **** doesn't even show the state/value of the variable "in the code", but instead lists them all in a table below the code so you have to scroll through and look all the variables up.
So yes, your claim that it's easier to trace a program in LD is very true as long as you're dealing with Rockwell.

Click to expand...

Maybe it's just that simple? A crappy implementation can make *ANYONE* hate a particular language.

So ... other controllers have ST that actually SHOWS values ... and you can figure out what's going on? That sounds workable!

parky said:

Resisting the urge to post..........it's hard!

Click to expand...

Go ahead! I'm learning stuff from this thread ... plus I get some entertainment as well!

cardosocea said:

I find it's easy to complain about the "pompous" programmer, but have you wrote software for something you didn't have near you to test before releasing? I was in that seat once and it's downright impossible to do that unless the gear you are controlling is near you. All you can do is give it a shot at having all the bits ready and then tweak out in the field.

Click to expand...

Responding to a comment that was not written to me ... but ... that's one of the reasons that you "can't buy experience". The more systems you do, the more situations you see, your programs get a bit more complicated so that they can deal with the real world messiness.

Having the real system available is obviously best. Having a simulator is a distant second due to the simplifications that are required but it helps to get things running 'normally' ... as long as you can list your assumptions. And that's usually a long list

Have you considered they're in the office because their boss doesn't want an expensive asset out in the field?

Click to expand...

The expensive asset in the office is kinda useless without feedback from being in the field. We hire engineering companies that make the same stupid mistakes in every project that they do. There is no feedback loop. They design it, the field guys mod it to get it to work, the office guys don't ever do as-built drawings or talk to the field crews. A different crew on each job, different groups of engineers at the office ... and over-priced, dismal designs that sort-of work when all is said and done.

The engineering companies don't want feedback. My bosses won't stop hiring them. Over the years, a few of the individual engineers .. and some of the smaller companies .. that I have dealt with have welcomed feedback, their designs have gotten much better, and then those engineers leave the toxic, crappy companies ... and we start over with new engineers

You do the best that you can, with what you have, in the time you have.

In my (relatively limited) experience, I feel like there's often a middle ground between "black box" and making things easy to troubleshoot if the techs have access to the program. It also very much depends on the culture of the company. Some of the people are very invested in knowing what's going on inside the program, while others will give me a callout to drive 45 minutes to get out there and open Logix to see that a selector switch is in manual (for example) that they could have easily seen themselves if they had opened the program and saw that the XIC bit was false. I think it's all well and good to use AOIs where everything is "hidden" (if you don't know how to open it and browse the internal logic) if it's going to be a black box type of situation, but getting a feel for whether or not the techs/workers are expected to maintain and troubleshoot it themselves or if they're keen on knowing how the system works really informs how I'm going to program the system. I've definitely worked at both extremes, where the plant workers want to be involved, and where they're completely hands off and apathetic as long as it works.

mylespetro said:

In my (relatively limited) experience, I feel like there's often a middle ground between "black box" and making things easy to troubleshoot if the techs have access to the program. It also very much depends on the culture of the company. Some of the people are very invested in knowing what's going on inside the program, while others will give me a callout to drive 45 minutes to get out there and open Logix to see that a selector switch is in manual (for example) that they could have easily seen themselves if they had opened the program and saw that the XIC bit was false.

Click to expand...

Thats failure on everyones' part though. The tech guy for not looking at the switch, the programmer for not putting a current mode on the HMI.

If someone needs to go online to tell a mode is manual, then thats just poor programming / HMI Design.

janner_10 said:

Thats failure on everyones' part though. The tech guy for not looking at the switch, the programmer for not putting a current mode on the HMI.

If someone needs to go online to tell a mode is manual, then thats just poor programming / HMI Design.

Click to expand...

That was a made up example, I couldn’t think of anything off the top of my head.

busarider29 said:

Uh oh......you didn't just go there did you?? You're gonna rile a lot of AB slappies on this forum. But, I do agree with you nonetheless.

Click to expand...

thingstodo said:

Maybe it's just that simple? A crappy implementation can make *ANYONE* hate a particular language.

So ... other controllers have ST that actually SHOWS values ... and you can figure out what's going on? That sounds workable!

Click to expand...

Rockwell is garbage. Long live Codesys and IEC 61131-3. Sadly people make me use that Rockwell garbage.

busarider29 said:

Uh oh......you didn't just go there did you?? You're gonna rile a lot of AB slappies on this forum. But, I do agree with you nonetheless.

Click to expand...

Oh yes I did, but I think ther's no arguing the shortcomings

janner_10 said:

That was fixed in v31, it's quite similar to Codesys now in the way it displays tag values. But you still got to pay for some odd reason.

Click to expand...

Good to hear that they atleast fixed it. Did they also fix the limitation of 7 OR's in one statement?

thingstodo said:

Maybe it's just that simple? A crappy implementation can make *ANYONE* hate a particular language.

So ... other controllers have ST that actually SHOWS values ... and you can figure out what's going on? That sounds workable!

Click to expand...

Yes! It does exist! I believe it's a bit like Jesus in America, everyone has heard of him, but no one has seen him


Jokes aside, there are good things with Studio5000 as well. The fact that it changes all the variable names in the code if you rename a variable in the global list is really nice.
Makes it a lot easier to keep a good naming-scheme going when your project grows.
But I would never pick a Rockwell PLC again if I had an option, and the main reason for that is their business model; Buttf@ck the customer, no matter what!

I don't believe the programming language should matter, as long as you have an HMI with all the i/o listed, and all the steps sequencing down. If you have this, it shouldn't matter how complicated the program is. If someone besides the engineer is hooking up to the PLC, then I have an issue with that. Anyone, whether it's maintenance tech, engineer, manager, etc. should be able to troubleshoot using the HMI and a volt meter, without ever hooking up to the PLC.

alive15 said:

I don't believe the programming language should matter.....

Click to expand...

No offence but I see a couple issues with this... a lot of machines dont have HMI's most of the ones that do will have a I/O truth table with indicators but I have never seen "and all the steps sequencing down" that would take way to much time and in that case it would be faster to write the code in a language that they could understand and troubleshoot themselves.

A perfect written program will never need to be seen (if there is a HMI) but its almost impossible to write a perfect program regardless of the program language.

Friedrich said:

After programming a CompactLogix I can see why you yankees are reluctant towards ST. Not only do you have to pay extra to be able to program ST, but the damn piece of **** doesn't even show the state/value of the variable "in the code", but instead lists them all in a table below the code so you have to scroll through and look all the variables up.
So yes, your claim that it's easier to trace a program in LD is very true as long as you're dealing with Rockwell.

Click to expand...

I rarely (if ever) get a say in manufacturer nor the programming language, to use. Customer almost always demands AB and almost always demands LD. It is the only language their electricians can follow.

geniusintraining said:

No offence but I see a couple issues with this... a lot of machines dont have HMI's most of the ones that do will have a I/O truth table with indicators but I have never seen "and all the steps sequencing down" that would take way to much time and in that case it would be faster to write the code in a language that they could understand and troubleshoot themselves.

A perfect written program will never need to be seen (if there is a HMI) but its almost impossible to write a perfect program regardless of the program language.

Click to expand...

I guess my plant is the opposite, all of our machines have HMIs. Any fault or issue will pop up on the screen, giving the setups / techs a clue as to what to look at. Otherwise, the i/o indicators are always there. It's always best to have a bit signifying the end of each step, so you can throw up an indicator light once that step is complete. So if the cycle doesn't finish, you know what step the machine is stuck on, thus you know which switch to look for.

Also, it's really good to have your cycle start conditions on a page as well, so in case the machine doesn't start, you can see which condition is not made either and go from there.

The only reason someone should ever connect to a plc, is if you have more than one issue, and you physically can't see both issues at the same time on the screen. Then you can open the plc software and trend the bits, or watch them flicker on the data table. Or if the PLC itself is having a major fault, so you have to hook up anyways.

As long as your HMI is good, I don't think the language will matter. But of course, ladder logic is easier to read. I honestly couldn't even imagine a machine without a HMI, but that shows my lack of experience in this field. I heard at one point, before HMI's and plcs, everything was done through ice cube relays, which sound very difficult to troubleshoot. So I'm thankful to have hmi and plc in my time.

And Yes, it takes time to program the hmi and plc logic, but what would you rather pay for, an engineer to make a decent hmi and plc program, or future downtime / lost revenue?

Everyone in this thread so far is referencing troubleshooting as the issue and citing an HMI screen with good fault logic. This is a non-issue as far as I’m concerned, and misses the point.

When I write logic that the maintenance people can understand, it isn’t because I expect them to hook up to the machine for troubleshooting all of the time. It is because of the inevitable additions and subtractions that will happen to a machine, process, or line over its lifetime. Sensors will be added and/or removed, the machine will have to be interlocked with the one in front of it, or it will have to interface with a SCADA system / etc. There are always additions (at least, in my experience).

If the people at the plant or another integrator can’t make changes to your code, you may think it is great because you get called back out to the site and make more money. My issues are these:

#1) I don’t want to be called back out to the site

#2) If your code is like this and they have to call you out constantly, they probably won’t hire you to do the next machine.

alive15 said:

And Yes, it takes time to program the hmi and plc logic, but what would you rather pay for, an engineer to make a decent hmi and plc program, or future downtime / lost revenue?

Click to expand...

touche

sczot said:

Output1 := LimitSW1 AND LimitSW2;

Click to expand...

Mon Dieu, c'es Python!