Programmers who go off script

[Iner]

I'm with Colonel26 on this one.
When we are talking about custom designs for a specific customer, I am all for that the source code should be handed over. In such cases, I even give training course for the end-customer how to understand our programming framework. Then the local tech has a realistic chance of troubleshooting without causing further problems.
On the other hand, when we are talking about standardized OEM machines, the local tech should not have to look into the code to troubleshoot.
I think that you CAN actually setup alarms for every conceivable hardware error. Higher level errors, i.e. that the sequence waits for certain conditions should also be reported. For standard machines, the programmers may have spent years on gathering every possible error situation.
Are you saying that on a very complex machine, a 3rd party programmer should be able to jump right in and troubleshoot the code ? That makes no sense to me.

For hardware faults I agree and for the actuators it's the very minimum you expect. Sensors should also have all faults, eventhough it can become extremely annoying for the operators to have too many faults and alarms. In heavily standardized plants like Peugeot in France, you can have up to 10-12 faults and alarms for a single sensor if you follow the guidelines. The untrained operators have no chance to understand what is actually going on with so many messages.


But even the maintenance technicians who have been trained to this standard, which has become mandatory for all OEMs, which is controlled and scrutinized by the people who wrote this same standard, often use their PC to open the program and troubleshoot it even if they have their thousands of Prog Alarm.



What I say is that the largest the machine or production line is, the more chance the maintenance people will have to sometime look at the code to troubleshoot it faster.

That is a blatant design error. Never heard that the S7-1200 has such a setting, but I am at a loss why anyone would want to chose such a setting. Can the S7-1200 change mode via its webserver ? In that case it could be the solution.

The S7-1500 has the same setting also. You can choose how they will boot. In RUN mode or in the same mode they were before being turned off and if they encounter and error and go to STOP mode they will restart in stop mode.

The only difference between the S7-1200 and the S7-1500 is that the S7-1500 can be changed to RUN by its embededed screen. I am even wondering if this is not the standard setting that the designer has forgotten to change for the S7-1200 because it make little sense to change this setting this way.

Schneider's M240 by default start in stop mode if you don't change the setting, but at least they have a switch to put them in RUN mode.

 

[VAN]

stuff

Whenever I troubleshoot as an engineer, looking at the code is usually last resort or if I'm lazy and don't want to drive on-site.

Really, why wont a system start or why it stopped should always be on the HMI/SCADA.

It's just simply lazy or "job safety" to not have it on the HMI/SCADA.

 

[OysterMan]

Ha, you would hate working with me OP! Good thing I work alone.

 

[kalabdel]

I am even wondering if this is not the standard setting that the designer has forgotten to change for the S7-1200 because it make little sense to change this setting this way.

Schneider's M240 by default start in stop mode if you don't change the setting, but at least they have a switch to put them in RUN mode.

S7-1200 default starup mode is "Warm restart - operating mode before POWER OF" and to say it's a common problem is quite and understatement; many programmers are unaware of this setting and end up on siemens support forums asking for help.

 

[Iner]

S7-1200 default starup mode is "Warm restart - operating mode before POWER OF" and to say it's a common problem is quite and understatement; many programmers are unaware of this setting and end up on siemens support forums asking for help.

I wasn't aware of this neither and the person who had made the program probably wasn't aware as well. I figured it out when I checked the diag buffer, they desperatly tried to swap IO modules and restart the cabinet, so much time that the original fault was long lost. The messages in the buffer were clear, start in stop mode, waiting manual action to run mode. But you have to have access to it to understand and change the configuration.



When you think about it, these S7-1200 are little ticking time bomb, probably a lot of programmer never encountered a problem during the commissioning but if the machine ever goes to STOP mode then the game starts.


Company who have field technicians with PC and software can restart their production in 5 minutes and those who don't can wait hours/day, up to nearly a week if they don't find anyone to come during week/ends or holydays.

 

[Iner]

Whenever I troubleshoot as an engineer, looking at the code is usually last resort or if I'm lazy and don't want to drive on-site.

Really, why wont a system start or why it stopped should always be on the HMI/SCADA.

It's just simply lazy or "job safety" to not have it on the HMI/SCADA.

It should, I agree, but it's hard to have everything and every cases, especially when the operators start to do manual movements or strange things to take shortcuts. At the minimum they should be able to empty the installation and restart clean, but that's not always possible or wanted in process.



From my experience, the companies who call you for the most very low level of help, beginner levels, are the one who don't have their own automation technicians and can't get a quick look at the code.

 

[JesperMP]

Thanks a lot for the headsup regarding the startup setting.
Was unaware of its existence (!).
I use S7-1500 only, so it is not such an issue since you can change mode on the CPU.
For S7-1200, there are different ways to change the mode, see this FAQ:
https://support.industry.siemens.com/cs/ww/en/view/88781826

Even then, for S7-1200 I would definitely set the startup behaviour to "Warm restart -RUN".

 

[LadderLogic]

Really, why wont a system start or why it stopped should always be on the HMI/SCADA.

That is provided you have had enough chargeable time to design and program all these nice and convenient things. Which might be easier if you are building a repeat machine but is very hard for a custom/bespoke design.

 

[VAN]

That is provided you have had enough chargeable time to design and program all these nice and convenient things. Which might be easier if you are building a repeat machine but is very hard for a custom/bespoke design.

So you seriously think a system that wont start but everything is fine on the HMI is a good system?

If the code is written poorly and you can't see why the system can't start that's another subject but looking at the code should say why a system can't start.

Then just put it on the screen so next time you don't have to go in the code.

 

[I_Automation]

So you seriously think a system that wont start but everything is fine on the HMI is a good system?

If the code is written poorly and you can't see why the system can't start that's another subject but looking at the code should say why a system can't start.

Then just put it on the screen so next time you don't have to go in the code.

I have a line I had to replace a PanelmatePC HMI for a SLC5/04 that I ended up using AdvancedHMI. They wanted a fast replacement since their IT guy killed the computer and couldn't get the DH+ card working - nor could I.

Every time I get to their shop I look at this line and watch it run. Almost every time I find something else to add. Fortunately the alarms are a .TXT file that I can edit with Notepad to add another alarm message, then program in that alarm in the SLC.

 

[LadderLogic]

So you seriously think a system that wont start but everything is fine on the HMI is a good system?

Actually, I think my meaning was quite the opposite: designing an HMI with all the possible troubleshooting features is nice but usually no one gives you enough time for that. So you limit yourself to a minimum set of diagnostic features assuming that in case of a more serious trouble someone will be able to go online with the PLC and figure out the cause.

 

[ra.SlowBoy]

Your "friend" is either young and inexperienced, has never had to maintain someone else's code after three others have touched it with THEIR standards and naming conventions, or (most likely) a dick.
.
I'm an old **** and have been in a few similar situations. I'm in one now as a matter of fact. The managers brought someone in from a different office to "Help" me finish a project on time (end of April). His style is "just make it work even if it doesn't work all the time" and couldn't care less about anyone else or if it means the HMI guy (also me) has to fix all the links he breaks. He has destroyed stuff I've spent months on. Management? They think I'm over-reacting.
.
To get buy-in from the management, there is one thing they ALL understand. Money. It is up to YOU to present the case of why this is costing the company $$ in future expenses when it comes time to maintain or understand his code. Be sure to mention that every other coder has bought into the standards. That means you have a group of programmers that can all understand each other, except for ONE guy. Managers don't understand what that can mean. You have to find a way to put a dollar value on it. I have explained it to a manager as:
Imagine you are in a room full of people from Italy and while they know a few English phrases, they are all speaking fluent Italian. You know a few Italian phrases, but everyone else is fluent and speaking quickly. How long do you think it will be before they understand everything, every nuance, in what you say so they can really get what you are talking about when discussing some technical paper you have read?
.
As for the guy himself. If you have already explained that the group has standards,, asked him to use them, and he refuses. Don't waste your time arguing with him. It's futile. It's a hard pill to swallow.

 

[daba]

CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.

HMI - yeah if not using alignment tools, shoot the *******.

Part way through reading this entire (long) thread, and I encountered your comments quoted above.

"CS - anything that helps identify a tags purpose is fine" : but it does not in any way identify a purpose, it just attempts to tell you which tag database it is in. So what is wrong with the tooltips ?

"NEQ move saves scan time" : No it doesn't - ever ! Adding the NEQ will add more to the scan time than just letting the MOV do its job, and it uses more memory. Everything on the rung has to be parsed and executed, but flavoured by the current "Rung Logic Continuity". I have verified this with test code I could share if you want. The added scan time with the NEQ is not a lot, but you can never reduce it by adding extra and unnecessary instructions.

"500 array is better than needing an extra element later which can't be expanded online" : So an application needs an array of 10 elements, and this guy makes it 500, making it 50 times larger than it needs to be, that's ridiculous!

After that, an array specifically needs 496 elements, does he make that 500 also.

What about a 2000 element array, does the guy make this 50 times larger, e.g 100,000 elements.

If you are going to include "spare" for expansion, then 10% is the norm. But I take the view that an array should be made to fit the code and the application, and in doing so you will spot array boundary violations as they happen, rather than the code not doing what it should do.

"HMI - yeah if not using alignment tools, shoot the *******" : I'm with you on that one !

 

[AustralIan]

Hmm... a 256 element array and using a USINT as an index would solve some of those array index out of bounds issues sleepy programmers make.

 

[daba]

Hmm... a 256 element array and using a USINT as an index would solve some of those array index out of bounds issues sleepy programmers make.

USINT = Version 32 and above, we think. What about all the applications out there in versions 10 to 31 ?