Ancient History. A good idea that was never properly used.

[Peter Nachtwey]

I got involved with Modicon when we were asked to make motion controllers for the old 984 PLCs. Back then the programming was done using Modsoft which was kind of clunky. What made it really strange was the scan order. However, the Modicon PLC had a very cool feature that was never or rarely used. The program could be divided up into segments. A program that might take 30 ms to scan but had code that needed to updated even 10 ms could be broken up into segments. Usually I would tell people to divide the program into 3 segments but 4 or more were possible.


Why?


We made motion modules for Modicon. The problem was that most users did not understand or even know about program segmentation.
Most users would write their PLC program in one big segment/program. The problem was that the scan time might be 30 ms and the motion modules needed to be updated faster than that. Every 10 milliseconds would be better. The solution would be to break the program into 3 segments. The motion control code could be put into segment 1 and the other code that didn't need to run as often in segments 2 and 3. Modicon allowed one to schedule the order of running the segments so it was possible to run segment 1, the motion code, then segment 2, then segment 1 again, then segment 3. This would extend the scan time a bit but the motion could run every 10 ms or so. If another segment was added then the segment execution order could be segments 1,2,1,3,1,4. If each segment takes about 10 ms to execute then the total scan time would be 60 ms but the motion code could still run every 10 ms. Most I//O didn't need to run that fast it is it just looking a push buttons and doing safety things.


Another thing that Modicon did right is that the inputs for a segment would be read just before the segment executed. This means that the motion control inputs were always recent. Also, as soon as a segment finished updating, the outputs would be updated. This means that the inputs for segment 2 were being read while segment 1 was just ending and the outputs from segment 1 were updated while segment 2 was executing. This avoided the problem were the input data was 50 ms at the end of the scan.


The engineers that came up with this had vision and knew how to make the best of what they had back in the 1980s. The problem is that Modicon's technical people or sales force either didn't know about this advantage or didn't understand it. Obviously the PLC users were clueless.


BTW, the first Modicon PLCs used AMD bit splice processors to emulate a PDP-11. PDP-11 were made by Digital Equipment Corporation back in the 70s. These were good mini computers at the time and an inspiration for the Motorola 68000 that AB used in their PLC-5s. Both the 68000, and PDP-11 were big endian computers were the high byte came first.

 

[Soggy Canuck]

I retired the last PDP-11 under my care in 2010.

I still have 3 winchester drives I can't bring myself to scrap. I keep thinking I'll run across a still functioning PDP in need of one. The computer was damn near bullet proof, except for the drives.

 

[parky]

Nice bit of history there, it's interesting about segmented code, in the 80's I was tasked with writing a program for a sausage filling machine, this was on a Siemens S5 115, there were some high speed requirements i.e. measure the length, & count them into a can via s linear feeder & diverter (rather clever as the last sausage went into the can, the diverter moved back to place the next sausage into the can behind, and move forward as the can came into the loading position), this was so fast that we had to use a high speed camera to set up the timing. Anyway, Siemens already had some very good features, organisation blocks, FB's & program blocks, we did the same thing i.e. the fast response was programmed into a block that was called if I remember rightly about 8 times during the OB1 scan, the PIO was updated in the first line of code etc. So Siemens had this ability even then to portion scans so that fast operations could be done, I suppose a number of PLC's could do this in a roundabout way, Mitsubishi also had this way of working by using sub routines i.e. some of the code was after the main end instruction & conditional (or un conditional ) calls made to the code segments. In all those years I did not come across many systems or programmers that were aware of these features, although probably they never needed them.

 

[cardosocea]

Nice bit of history there, it's interesting about segmented code, in the 80's I was tasked with writing a program for a sausage filling machine, this was on a Siemens S5 115, there were some high speed requirements i.e. measure the length, & count them into a can via s linear feeder & diverter (rather clever as the last sausage went into the can, the diverter moved back to place the next sausage into the can behind, and move forward as the can came into the loading position), this was so fast that we had to use a high speed camera to set up the timing. Anyway, Siemens already had some very good features, organisation blocks, FB's & program blocks, we did the same thing i.e. the fast response was programmed into a block that was called if I remember rightly about 8 times during the OB1 scan, the PIO was updated in the first line of code etc. So Siemens had this ability even then to portion scans so that fast operations could be done, I suppose a number of PLC's could do this in a roundabout way, Mitsubishi also had this way of working by using sub routines i.e. some of the code was after the main end instruction & conditional (or un conditional ) calls made to the code segments. In all those years I did not come across many systems or programmers that were aware of these features, although probably they never needed them.

One thing that I haven't seen used anywhere by people that use Siemens is that you can assign part of the PIO to be updated within a specific OB instead of running an instruction to update it or use the PI address space. I haven't seen that in TIA Portal, but to be fair haven't looked for it either.

 

[parky]

Yes I have used it, long time now but I think it was OB2 or something like that, it was an interrupt remember using a 32 way High speed input card on an S5. The other one I remember is OB10 was the 10ms time one. Bearing in mind there are 255 OB's for all a manner of diagnostics, PID setting etc.

 

[Peter Nachtwey]

The early Modicons EMULATED PDP-11s. They weren't true PDP-11s but they used the PDP-11 instruction set internally.


Running a function 8 times in one loop doesn't do much good if the I/O isn't updated just before and after each call. Most PLCs back then only updated I/O once per scan. Some PLCs had an immediate I/O capability.

One thing that I haven't seen used anywhere by people that use Siemens is that you can assign part of the PIO to be updated within a specific OB instead of running an instruction to update it or use the PI address space. I haven't seen that in TIA Portal, but to be fair haven't looked for it either.

Perhaps it isn't as important now that scan times are so much faster but it would be good to know.


My point is that people often don't take advantage of all the PLCs capabilities. In Modicon's case I doubt if the local sales engineer knew about the just in time I/O. They were probably told then then forgot.

 

[ndzied1]

In CoDeSys (at least the flavors we use) the execution of code is controlled by a Task Manager.

Many times, I think because many of us have RSLogix 500 in our backgrounds, you have a main task that calls your other task (Like JSR in RSLogix)

But, It is probably a better idea to break up the application as you say and put each separate routine in the Task Manger separately. There is a priority assigned to each task to manage conflicts as well as interval timers and configurable watch dog timers.

 

[diat150]

I got involved with Modicon when we were asked to make motion controllers for the old 984 PLCs. Back then the programming was done using Modsoft which was kind of clunky. What made it really strange was the scan order. However, the Modicon PLC had a very cool feature that was never or rarely used. The program could be divided up into segments. A program that might take 30 ms to scan but had code that needed to updated even 10 ms could be broken up into segments. Usually I would tell people to divide the program into 3 segments but 4 or more were possible.


Why?


We made motion modules for Modicon. The problem was that most users did not understand or even know about program segmentation.
Most users would write their PLC program in one big segment/program. The problem was that the scan time might be 30 ms and the motion modules needed to be updated faster than that. Every 10 milliseconds would be better. The solution would be to break the program into 3 segments. The motion control code could be put into segment 1 and the other code that didn't need to run as often in segments 2 and 3. Modicon allowed one to schedule the order of running the segments so it was possible to run segment 1, the motion code, then segment 2, then segment 1 again, then segment 3. This would extend the scan time a bit but the motion could run every 10 ms or so. If another segment was added then the segment execution order could be segments 1,2,1,3,1,4. If each segment takes about 10 ms to execute then the total scan time would be 60 ms but the motion code could still run every 10 ms. Most I//O didn't need to run that fast it is it just looking a push buttons and doing safety things.


Another thing that Modicon did right is that the inputs for a segment would be read just before the segment executed. This means that the motion control inputs were always recent. Also, as soon as a segment finished updating, the outputs would be updated. This means that the inputs for segment 2 were being read while segment 1 was just ending and the outputs from segment 1 were updated while segment 2 was executing. This avoided the problem were the input data was 50 ms at the end of the scan.


The engineers that came up with this had vision and knew how to make the best of what they had back in the 1980s. The problem is that Modicon's technical people or sales force either didn't know about this advantage or didn't understand it. Obviously the PLC users were clueless.


BTW, the first Modicon PLCs used AMD bit splice processors to emulate a PDP-11. PDP-11 were made by Digital Equipment Corporation back in the 70s. These were good mini computers at the time and an inspiration for the Motorola 68000 that AB used in their PLC-5s. Both the 68000, and PDP-11 were big endian computers were the high byte came first.

I still have some 984 that i service. they are tanks

 

[Lare]

One thing that I haven't seen used anywhere by people that use Siemens is that you can assign part of the PIO to be updated within a specific OB instead of running an instruction to update it or use the PI address space. I haven't seen that in TIA Portal, but to be fair haven't looked for it either.

I think that it can be done with addressing IWxx or QWxx on TIA portal instead of old PIW / PQW addressing on classic.



Jesper can correct.

 

[Steve Bailey]

Was that feature introduced in the 984? I did a couple of 484 projects and one 584 project early in my career. This was when programming was still done with the P190. I don't recall our rep pointing the feature out to me.

 

[Liam Moran]

I remember years ago working on a German machine which had an S5115u with a 942 CPU. I could not understand why the edits I did in a program block did not work properly.

It took me a long time to figure out that there were 2 program blocks containing the same code. Lets say they were PB20 and PB40. (This was over 30 years ago I am unsure of the exact numbers)

They were being called sequentially in OB1. So each block was being called 2 times in the scan.

I dont know why they couldnt have called the same block twice and save the memory the second block used,

obviously the engineer commissioning the plant was having difficulty with consistency in stopping positions with parts of the machine.

There were loads of L PI/Q and T PI/Q instructions in the code too to try speeding up the I/O updates.

This was because the old 942 cpus were a lot slower than the later 942B. It seems ridiculous nowadays, but that is what we had to work with at the time.

Try explaining all that stuff to the younger guys nowadays. They would look at you like you have 2 heads.

 

[Peter Nachtwey]

Was that feature introduced in the 984? I did a couple of 484 projects and one 584 project early in my career. This was when programming was still done with the P190. I don't recall our rep pointing the feature out to me.

I never used a 484 or 584. I don't know what they could do.
The first 984s were the 984A and 984B. They were big units. Tanks/boat anchors.
I have a few newer 984-685s and 385s.
I want to point out again that scheduling something many times makes no difference if the inputs and output are updated only once per scan.
This is the part that people ignored.