Engineers Vs. "Joe Maintenance"

I don't believe this to be off-topic....I will just throw it out here and see how it lands. I had an electrician ask me if there is a document available that one could use ladder logic to decipher ST. I built an air flow test rig and I had to use ST, couldn't find a way around it (at the time). I started to create something for him however, haven't been back to it since. Does anyone know if such a document exists, where there would be a LD and ST that are the same project, that I could pass on to this gentleman? Thanks.

here's a small project that might help get you started ...

if you still have your lab manual from the ControlLogix class, compare pages 13 and 44 side-by-side ... both of those are the same basic "Walkthru" program – with timers, counters, one-shots, seal-in rungs, etc. ...

the Ladder Logic format is shown on page 13 – and the corresponding Structured Text format on page 44 ... (and if you're ever interested in Function Block Diagrams – you can find the same "Walkthru" project on page 45 in that format) ...

ceilingwalker said:

I don't believe this to be off-topic....I will just throw it out here and see how it lands. I had an electrician ask me if there is a document available that one could use ladder logic to decipher ST.

Click to expand...

This doesn't make sense. What do you mean by decipher ST? I think it is possible to write a parser that could parse ST and output LD but that would require a lot of work and then what would be format of the LD program? It would be possible out IL as a text file but I don't think that would help.
Generating a LD file in JSON format seems doable but how would that be converted to a LD image?

Ron Beaufort said:

here's a small project that might help get you started ...

if you still have your lab manual from the ControlLogix class, compare pages 13 and 44 side-by-side ... both of those are the same basic "Walkthru" program – with timers, counters, one-shots, seal-in rungs, etc. ...

the Ladder Logic format is shown on page 13 – and the corresponding Structured Text format on page 44 ... (and if you're ever interested in Function Block Diagrams – you can find the same "Walkthru" project on page 45 in that format) ...

Click to expand...

Well hello old friend! Yes Sir, I do indeed have all my things from both boot camps I went to. I didn't even think to look there. Thank you.

Peter Nachtwey said:

This doesn't make sense. What do you mean by decipher ST? I think it is possible to write a parser that could parse ST and output LD but that would require a lot of work and then what would be format of the LD program? It would be possible out IL as a text file but I don't think that would help.
Generating a LD file in JSON format seems doable but how would that be converted to a LD image?

Click to expand...

The electrician wants to do a side-by-side comparison, exactly as Ron mentioned, to figure out how to read the ST I had to use for that air flow test rig.

My two cents.

Most importantly, no matter what language you write in DOCUMENT EVERYTHING POSSIBLE as time permits. Documentation is the third most important thing in PLC programming in my opinion only surpassed by 1. Never compromise safety, and 2. Of course have a functional program.
Personally I write code in all languages (except statement list... I hate assembly. Not my cup of tea) I use ST/SCL for complex looping, sorting, math, and some logic if its a super short program. I use LAD when there will be a lot of techs reading my code and understanding it. With that being said, I also try to break my AOIs and FBs into equipment dependent routines, and then tie it together in a control block. But I still use indirect addressing and I still try to make my code as user-friendly as it can be if I wont be the one looking at it.
As of late, I've been pumping out programs that only I look at because the stations I program for are not for an industrial environment. So I've programmed in whatever I have felt like.

I think some of the above posts miss the point.

Someone is paying for the program to provide a function in a commercial operation. The program should be written in the form that will provide the most value to the organization paying for it. That may be the programmer but is most often an operator. Maintenance and electricians, like the programmer, are there to serve the needs of the operators.

That means that in some cases high-level languages and sophisticated techniques are best. This would be particularly true if the program is multiple use for a mostly standard machine or process. The builder is paying for the program directly, and the end-user only indirectly.

Often the program is a single-use custom program directly paid for by the operator's employer. The program, being special, may require verification or upgrade by the operator or his maintenance staff. If they are most familar with ladder then the program is best written in it. That is typical.

I absolutely love these posts and draw a lot of inspiration, motivation and learning from all of them. So very grateful for all of you sharing your experience with the less learned like myself. And the occasional joke makes it all the more fun. I hope many more discussions like these and others will follow.

I don't know about RSL but many PLC's actually compile it into the same compiled code i.e. STL however, in ladder or FBD then it would not use jumps. for example in Mitsubishi a IF ELSE in ST when compiled, uses jumps i.e
In ST:
IF M0 THEN
D100 := 100;
ELSE
D100:= 0;
END_IF;
Compiled code:
0 LD M0 // If M0 = true
1 CJ P2048 // Conditional jump to label
3 LD SM400 // Uses always on bit
4 MOV K0 D100 // to move 0 into D100
6 JMP P2049 // Jump to end of code
8 P2048 //Label
9 LD SM400
10 MOV K100 D100 //move 100 into D100
12 P2049 //Label
However in FBD or LAD then the code is
0 LD M0 //this becomes the if statement
1 MOV K100 D100 //then moves 100 to D100
2 LDI M0 //This becomes the else
3 MOV K0 D100 // so moves 0 to D100
To be honest this seems simpler to me also if uploaded then the latter can be displayed in ladder, no more need to be said.
I think on many platforms the need for ST, LAD & FBD to be competitive then there have been workarounds to accommodate all languages but leave the resulting compiled code in some form of STL that is compatible.

About 15 years ago we had a new water treatment plant installed at the factory I worked at.

All good as the standard for all installations was intouch and Allen Bradley.
Trouble started when halfway through the commissioning the engineer spat the dummy and left site, leaving it up to us to finish the job.
Looking through the code and trying to faultfind why parts weren't operating became a nightmare. For example searching for the ote control bit say B3:1 for a pump would bring up 100's of ote's with same address.
We never found out the guys reasoning for writing it as he did but what he had done was in the code set the bit to start say pump 1. Immediatly after in next line he would reset that bit then reuse it to control the next stage of operation. This went on throughout the program.
Obviously he thought it was smart programming to minimise the number of b3's but if he had stayed on the job and handed it over to us a normal electrician called in to fix it later would have no chance of finding the faults.
Fixed it all up with a few days rewriting and a printout breaking it down to individual sections and individual control bits.

I agree some engineers try to impress with over-engineered code.
I have had similar experiences for example in S5, one engineer created a function block that passed a timer indirectly but the address of the timer was outside the timer range (0-255) in S5, by passing say 257 to a FW100 DO the FW100 load T0 (this took the value of the timer in the D0 instruction and loaded the timer, however, the value 257 was outside the timer range & it took me a little while to realise that processing a timer only looked at the lower byte so 257 actually meant T1. Siemens was a very powerful system in it's time and there are a number of instructions that were not generally documented in most manuals supplied, another was an example of a system where the engineer had programmed the startup OB with code to generate a datablock as big as memory left in the PLC for a print queue, so on initial cold start the DB did not exist, the code checked the size of memory, generated a DB to fill the memory, this was ok until the program was lost due to a battery failure, I was asked to look at it and found that the engineers on site had uploaded the data blocks so that they had a copy of all data, the problem was that on a full download the memory had filled to capacity and S5 requires an area to load new or replacement blocks (when you download a block that exists it places it in spare memory and then during non scan of code removes the header off old block & replaces it with the new block and early S5 required a compress after a number of blocks were replaced). this posed a problem as it reported memory full so I found out that you do not download the very large DB then do a cold start plus a warm start to generate the DB. There was also other clever tricks like relative jumps to addresses instead of labels so that if you tried to add or delete a bit of code the jumps pointed to the wrong place on top of this they had used MC5 instruction set (Machine code values) placed in a datablock to process instructions, nasty as these would change i.e. the running code could change dependant on the Hex values in the words so if L FW200 in MC5 was Hex 2E00 then by changing the hex value it could load FW204 (by the way not actual MC5 instruction but you see my point) self-modifying code?. I used to have a book with all the MC5 instructions and indeed once wrote a program that iterated through a load of inputs coded in a DB so the only reference was to I0.0, but never used this in real life.

Nie moj cyrk, nie moje małpy

sparksy@gage said:

[...]
Trouble started when halfway through the commissioning the engineer spat the dummy and left site, leaving it up to us to finish the job.[...]
This went on throughout the program.
Obviously he thought it was smart programming to minimise the number of b3's but if he had stayed on the job and handed it over to us a normal electrician called in to fix it later would have no chance of finding the faults.
Fixed it all up with a few days rewriting and a printout breaking it down to individual sections and individual control bits.

Click to expand...

Similar to what many are saying, that reminds me of an old saying from the 3rd-generation programming language religious wars of yesteryear:

There is no such thing as a structured programming language, only structured programmers.

Click to expand...

Speaking of which, what does Mr. Beaufort's puzzle/instructive.sig (below) translate to in e.g. ST? Is it any more than [Out := 2-B OR ( NOT 2-B )]?

... hmmm, 2-b or not 2b ... 2-b or ... I just got it!

I have a software engineering background but now primarily do PLC programming and machine design.

The squabbling over ST vs LD is rather silly. Two different tools that, while they have overlapping functionality, should be applied in different situations. Preference should not matter when deciding which to use, only the desired functionality.

ST is invaluable for performing complex calculations which would be tedious and irresponsible to do in LD. For instance, we have a process that requires the optimization of agitator height, rotations/hr, differential pressure, and pressure to complete a process within a specified period of time. This requires solving systems of equations. Can I do this in LD? Perhaps but I'd be a fool to try. Even if I get it working, it's not practical to troubleshoot. So ST is the right tool for the job.

LD is appropriate for visualizing logical flow and elucidating connections between inputs and outputs. The same process that I outlined above uses LD for sequencing, opening valves based on process step, starting and stopping motors based on conditions, etc. I could write the whole thing in ST, sure, but that's just adding a layer of abstraction that is unnecessary. The LD will look quite similar to the actual wiring - why would I intentionally restructure the logic so that it no longer resembles the physical wiring?

The question of if a program can be maintained by a less skilled technician is inherently solved by choosing the appropriate programming language for the job. To use my above example, I want Joe Maintenance to be able to understand why a machine isn't running within the realm of his knowledge and responsibility. I don't expect him to have training in multi-variable calculus, nor should he need it for his job. I do want him to be able to quickly see and understand why a motor isn't running, or a valve isn't opening.

I didn't need to 'dumb down' my program so that Joe can understand it. I just properly organized it and judiciously chose when to use ST and when to use LD. When a contactor fails, or a valve feedback prox gets smashed, then it's well within maintenance's abilities to troubleshoot and this problems are easily identified in LD. If it gets to the point where they cannot identify the cause of an issue in the LD and they suspect it's my ST module, then I actually want that 3AM call. It means I didn't do my job properly, and I didn't test, test and retest.

I'm a bit drunk atm but to summarize (No offence intended):

USA = Hates ST no matter what, but must have no arc'ing ever but can use use gaffer tape as a safety function.

Rest of the World: Write what you like, but make it very safe.

janner_10 said:

USA = Hates ST no matter what,

Click to expand...

That isn't so. Our product uses ST and forces you to use in a state machine. This is excellent for motion and machine control.
There are very few people that insist on ladder especially for motion and machine control.