I have one of those pain-in-the-neck jobs that is constantly haunting me, trying to solve problems on a unit with an S7-200 PLC. The code was written more than ten years ago, not by me, and classically, is indifferently commented. It is a bit of a bottomless pit for hours that I just cannot afford.

One of my difficulties is with these sequencing flags that are an in-built part of the MicroWin language. I have to say, it is not my preferred method of sequence control, but I accept that does not necessarily mean it wasn’t a valid technique to use, particularly at the time. The problem is that sometimes you look at the logic for a particular flag, and it really makes no sense at all, until you realise that it is only being scanned at certain points in the sequence. It really makes program analysis, and tracing the cause of troublesome problems a lot more difficult.

One problem I had was with two separate sequences, let’s just call them ‘sequence a’ and ‘sequence b’. ‘Sequence a’ can be run independently at any time, provided only that the equipment is not otherwise engaged. When you run ‘sequence b’, after some initial setup, it then runs ‘sequence a’ and waits for a signal of ‘sequence a’ successfully completed before it continues. ‘Sequence a’ can fail or be aborted, in which case ‘sequence b’ also aborts.

So, a third party responsible for equipment with which this PLC interfaces, wanted to run some tests, involving ‘sequence b’, but they wanted to be able to bypass ‘sequence a’, because it isn’t necessary when testing, and is a significant time waster. I had two separate attempts at achieving what they wanted, whereby, with test mode activated, the call to ‘sequence a’ is inhibited and the ‘passed’ token is immediately generated to allow ‘sequence b’ to continue. Both times the sequence gets to that point and just stops. I cannot see what the problem is and I have a feeling that there is something I am missing about getting the sequencer to sequence, although, clearly it is sequencing up to the point when the control would pass to ‘sequence a’.

I know it is difficult to comment without actually seeing the code, but I’m afraid I cannot post it. Actually, on a completely different problem, I had thought of trying to use the in-built data logging to attempt to track the status of the sequencing flags and certain other program flags, but it is one of those situations where the slightest program change requires masses of documentation and a great deal of time, and they won’t be convinced by the argument that it is only a temporary change for test purposes.

In any case, I won’t be surprised if no-one has any responses to this, but I would be interested in any thoughts anyone might want to offer…

I sympathize: back in the day I experimented with Machine Stage Programming (use of the sequence flags) in the S7-200, but came to the conclusions:

1. It is faster to write than standard RLL because it implements the state machine for the controlled process
2. It is significantly more difficult to maintain because you have multiple rungs controlling the same output, and it is difficult at runtime to determine which sequence's controlling rung is active at any given point in the process.

I've got no magic bullet for the problem you are fighting: it sounds like there is something that sequence a is doing that sequence b gets interlocked with, so if sequence a doesn't run, sequence b will halt waiting for it.  My recollection is that the S7-200/MicroWin had a pretty good scan-by-scan capture capability, but it has been long enough since I used one that I don't remember the details.

Hello.

I know there was a technique of doing sequencing that was meant to confuse 3rd party debuggers. People who knew the recipe did not have any difficulty. For the rest of us it takes some effort every time.

The 'watch table' / status table allows you to show data in a graph. It may be worth your while to record the data vs time in this way. Keep in mind that VW / MW overlaps with Vx.x / Mx.x. Shift and Move of DWORD / WORD / BYTE can make things difficult for tracking progress.

The symbol table notifies you when there is an overlap. This alone makes it worth the while to have all used addresses be assigned to symbols. The cross reference is also good for that. 

~

Hi mmckay, you are touching on one of the key problems when I try to read programs written by my predecessor. I don’t want to fall into the trap of simply disparaging him and blaming him for all the problems, of course I wasn’t there at the time the programs were written and don’t know anything of the problems and pressures he faced at the time. But, even when not sequencing, his programs are littered with –(S)– type sets and –(R)– type resets of the same flag, often across multiple routines. Let’s say, it certainly doesn’t make program reading any easier.

In a previous job, I had to support old equipment controlled by Texas Instruments PLCs, and they used this ‘Drum Instruction’ for sequencing. Some of my colleagues, who were more used to dealing with Texas Instruments PLCs, sang its praises. It always seemed to me to be peculiarly designed to make reading a program close to utterly impossible.

My preferred method of sequence control is the integer code. I always find it easy to write, very reliable in execution and, I believe, very easy to read for another engineer that didn’t write it. Indeed, you can very easily produce a table in Excel that explains exactly how the sequence works to someone who knows nothing whatever about PLC programming. And even with complex sequences involving jumps back and even jumps forward, if you do it right, your code looks remarkably like your flow diagram.

And thanks qwazee, if I had access to the equipment and the freedom to play (exactly what I told them I needed) the techniques you mention are exactly what I would be doing to try to isolate the problems. But I don’t have that access or freedom. It is some time ago that I suggested that the solution was probably going to require a good, old fashioned, time stamped event log. Ah, nostalgia for the Dot Matrix printer. There has been a proposal to use an S7-1200 PLC simply to monitor the status of the external IO to the S7-200 PLC. It might produce some answers but I am not convinced that it is not going to need to be possible to read the status of internal flags, particularly the sequencing flags. There does seem to be some acceptance of the impossibility of this situation for me, but that doesn’t get the dragon off my back.

And yes, the idea has been put to them for a retrofit S7-1200 upgrade. They have made noises of encouragement that it might be something that they will consider. Trust me, I’m not holding my breath…

Ah ha! You see, the key insight I needed was within your post mmckay, it just rather passed me by on first reading. It is your use of the term ‘Machine State Programming’, at first read I just took it to be your term for it. But then I suddenly realised that there could be significance in it, and did a google search for ‘Machine State Programming in S7-200’ and it immediately turned up the right manual. Understand, I had previously tried to find the manual, but had only turned up third party website references to it. In any case, I found the section in the manual ‘Sequence Control Relay (SCR) Instructions’ and there was great significance in the bit about restrictions and in the bit about the ‘S stack’ and the ‘logic stack’. I’m not suggesting that it is all a magic wand that is going to solve all of the problems, but it is the bit that I had the feeling I was missing, and I certainly need to now review the code with this new, better understanding. Many thanks.