Terry Woods
Member
- Join Date
- Apr 2002
- Posts
- 3,170
Over the past several years, on PLCnet, I've seen many calls for simulators. Responders have referred posters to various canned simulators. Those simulators are fine if you are simply trying to become familiar with PLC programming. However, if you are trying to develop a program for slicing pickles, an Elevator Simulator or a Traffic Light Simulator is absolutely, useless.
It seems that many don't really understand the "simulation" concept in terms of process development.
In general, there are six ways to look at "simulation". Some simulators are for purely theoretical exercises. Others are for verifying code on a bench-mounted PLC without driving any real activity. Others are for actually exercising a process without running any real material through the process. And then there is one more... this simulator exercises code on an actual Process PLC, with real outputs, without driving any real output activity... I call this "Shadow Coding".
The theoretical type simulators (SIM #1) are essentially "closed". That is, you don't get to see how the simulator does what it does. You can only manipulate certain input conditions and then wait for the results. This provides an imperical method for examining cause & effect relationships. This type of simulator is a program on a PC. All Video Games (including some Elevator and Traffic Light Simulators) fall under this type of simulation.
The "code verifying simulators" (SIM #2, #3 & #4) are "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the code is tested. These simulators run on bench-mounted PLCs and do not drive any real output activity.
The "process simulators" (SIM #5) are also "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the process executes and tests the code. These simulators do drive real output activity.
The "Shadow Code Simulators" (SIM #6) are also "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the code is tested. These simulators run along side the real process code without affecting any real outputs or conditions that might otherwise affect the process. This method is most effective on PLCs that allow on-line programming. It can work on those that don't allow on-line programming but it will take much more planning and consideration since you can not easily modify the Shadow Code without stopping the process.
.
Simulator #1:
This simulator uses a completely artificial environment. The Inputs and Outputs are completely artificial. Think... Video Game. This can run on a PC with no PLC in sight. Of course, simulations like this are very common. However, it takes a great deal of effort on the part of many developers to bring this all together. Depending on the complexity of the process, this can be an absolute nightmare to develop... especially for one guy.
Another thing to bear in mind is that an Elevator Simulator or a Traffic Light Simulator is useless if you are trying to develop a program for slicing pickles. The simulator must match your particular process. And since more than 90% of the processes out there are unique, it is virtually impossible to develop a practical and reasonably priced general-purpose simulator.
Simulator #2:
This simulation occurs on a bench-mounted PLC Processor. This processor should be a duplicate of the processor in the field, or at least as similar as possible without any critical differences.
This simulator does not need any Input or Output modules. A program residing on a PC provides all Input conditions and data. The program on the PC "writes" conditions and data to the PLC. The program also "reads" conditions and data from the PLC. Depending on the PC program, the PC program might simply feed conditions and data to the PLC according to the timing in some model of the process. It might be the case that the PC program then "decides" what conditions and data to feed based on particular conditions and data read from the PLC... this, of course, is bogus. Since all subsequent responses by the PLC are based on the conditions and data passed by the PC, the conditions and data will always be the same... unless you develop some sort of "random generator"... there's a headache.
The PC program might provide for "Stop-Points". That is, after executing a particular portion of the process program the PC program might stop feeding new conditions and data. At that point, the PC screen might display particular current conditions and current data. Although conditions and data are no longer changing, the PLC program continues to run. The PC program might then provide for "Quit" or "Proceed to Next Stop-Point".
YOU must develop the PC program! Only YOU know what your process is.
Simulator #3:
This simulator is certainly much easier than developing a PC-based simulator. This is a very good simulation scheme if you prefer doing all of your condition manipulations through software.
This simulation also occurs on a bench-mounted PLC Processor. Again, this processor should be a duplicate of the processor in the field, or at least as similar as possible without any critical differences.
Just as in Simulator #2, this simulator does not need any Input or Output modules. All simulations are performed through the Programming Interface via "Force" and/or "Write". In this case, YOU are the simulator. YOU change the Input conditions according to your understanding of the process. You might also need to enter data, now and then, to affect the process.
All results are monitored in the Process Program, through the Programming Interface (to whatever extent the Inferface allows). If your Programming Interface allows, you can build a Status Page where you can monitor and control the status of various Inputs as well monitor the status of various Outputs.
In some cases, the PLC might provide for "stepping". "Stepping" provides a means to impose a change in conditions and then "step" through the program while watching the effects develop. In some cases, "stepping" executes one instruction at a time. In others, "stepping" executes one line of code at a time. In either case, this is a very laborious effort. However, sometimes it is the best method.
This method is inherently equipped with "break-points". That is, as long as YOU don't change any of the Input conditions, the process will "wait" for the next condition change. Of course, the process program will continue to run, however, unless you have a problem in your code, the current conditions should be stable... except for any intentional repetitive timer conditions that you might have.
Some Program Interfaces allow you to define "break-point conditions". In this case, at the appropriate part of your code, you activate a control relay, which indicates to the processor that you are at a "break-point". When this condition occurs, the process stops. You can then look at the resulting conditions. Of course, this does not allow you to see everything that has happened up to that point. It would be like handing some data to some guy who then leaves the room and then returns with the result... you have no idea what really happened while he was out of the room. The result might actually be what you expected... however, you can only "assume" that the result was developed in the manner you prescribed. Alternatively, you can "step" through the code and watch everything.
Even if you go through the pains of "stepping" through the code, you still need to develop a sense of confidence in that code; you need to test extreme cases. That is, provide data that is clearly outside of the acceptable range and then check the results. You should also test the "zero" and various "window-edge" conditions.
The "window-edge" conditions should also include checking the "plus-or-minus off-by-one" effect. That is, is the "window-edge" an exclusive condition or an inclusive condition? If the lower "window-edge" is inclusive then what happens if the data is one-unit less? If the upper "window-edge" is inclusive then what happens if the data is one-unit more?
CONTINUED IN NEXT POST
It seems that many don't really understand the "simulation" concept in terms of process development.
In general, there are six ways to look at "simulation". Some simulators are for purely theoretical exercises. Others are for verifying code on a bench-mounted PLC without driving any real activity. Others are for actually exercising a process without running any real material through the process. And then there is one more... this simulator exercises code on an actual Process PLC, with real outputs, without driving any real output activity... I call this "Shadow Coding".
The theoretical type simulators (SIM #1) are essentially "closed". That is, you don't get to see how the simulator does what it does. You can only manipulate certain input conditions and then wait for the results. This provides an imperical method for examining cause & effect relationships. This type of simulator is a program on a PC. All Video Games (including some Elevator and Traffic Light Simulators) fall under this type of simulation.
The "code verifying simulators" (SIM #2, #3 & #4) are "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the code is tested. These simulators run on bench-mounted PLCs and do not drive any real output activity.
The "process simulators" (SIM #5) are also "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the process executes and tests the code. These simulators do drive real output activity.
The "Shadow Code Simulators" (SIM #6) are also "open". YOU create the process code and YOU create the environment for testing the code. YOU control the manner in which the code is tested. These simulators run along side the real process code without affecting any real outputs or conditions that might otherwise affect the process. This method is most effective on PLCs that allow on-line programming. It can work on those that don't allow on-line programming but it will take much more planning and consideration since you can not easily modify the Shadow Code without stopping the process.
SIM #1 SIM #2 SIM #3 SIM #4 SIM #5 SIM #6
Input Sensors:
Material Simulated Simulated Simulated Simulated Simulated Real
Machinery Simulated Simulated Simulated Simulated Real Real
Outputs: Simulated Real(1) Real(1) Real(1) Real(2) Real(2)
Environment: PC PC<->PLC Bench PLC Bench PLC Process PLC Process PLC
(Bench PLC) w/Prog I/F w/Prog I/F w/Prog I/F w/Prog I/F
Stimulator: PC PC YOU YOU YOU/PROCESS PROCESS
Note: The last item is "stimulation", as in stimulator, not "simulation".
Real(1):
The Logical Outputs actually operate within the PLC.
However, there are no physical Output field devices.
Output Modules might or might not exist.
Real(2):
The Logical Outputs actually drive existing Output field devices.
Output activity is REAL!
.
Simulator #1:
This simulator uses a completely artificial environment. The Inputs and Outputs are completely artificial. Think... Video Game. This can run on a PC with no PLC in sight. Of course, simulations like this are very common. However, it takes a great deal of effort on the part of many developers to bring this all together. Depending on the complexity of the process, this can be an absolute nightmare to develop... especially for one guy.
Another thing to bear in mind is that an Elevator Simulator or a Traffic Light Simulator is useless if you are trying to develop a program for slicing pickles. The simulator must match your particular process. And since more than 90% of the processes out there are unique, it is virtually impossible to develop a practical and reasonably priced general-purpose simulator.
Simulator #2:
This simulation occurs on a bench-mounted PLC Processor. This processor should be a duplicate of the processor in the field, or at least as similar as possible without any critical differences.
This simulator does not need any Input or Output modules. A program residing on a PC provides all Input conditions and data. The program on the PC "writes" conditions and data to the PLC. The program also "reads" conditions and data from the PLC. Depending on the PC program, the PC program might simply feed conditions and data to the PLC according to the timing in some model of the process. It might be the case that the PC program then "decides" what conditions and data to feed based on particular conditions and data read from the PLC... this, of course, is bogus. Since all subsequent responses by the PLC are based on the conditions and data passed by the PC, the conditions and data will always be the same... unless you develop some sort of "random generator"... there's a headache.
The PC program might provide for "Stop-Points". That is, after executing a particular portion of the process program the PC program might stop feeding new conditions and data. At that point, the PC screen might display particular current conditions and current data. Although conditions and data are no longer changing, the PLC program continues to run. The PC program might then provide for "Quit" or "Proceed to Next Stop-Point".
YOU must develop the PC program! Only YOU know what your process is.
Simulator #3:
This simulator is certainly much easier than developing a PC-based simulator. This is a very good simulation scheme if you prefer doing all of your condition manipulations through software.
This simulation also occurs on a bench-mounted PLC Processor. Again, this processor should be a duplicate of the processor in the field, or at least as similar as possible without any critical differences.
Just as in Simulator #2, this simulator does not need any Input or Output modules. All simulations are performed through the Programming Interface via "Force" and/or "Write". In this case, YOU are the simulator. YOU change the Input conditions according to your understanding of the process. You might also need to enter data, now and then, to affect the process.
All results are monitored in the Process Program, through the Programming Interface (to whatever extent the Inferface allows). If your Programming Interface allows, you can build a Status Page where you can monitor and control the status of various Inputs as well monitor the status of various Outputs.
In some cases, the PLC might provide for "stepping". "Stepping" provides a means to impose a change in conditions and then "step" through the program while watching the effects develop. In some cases, "stepping" executes one instruction at a time. In others, "stepping" executes one line of code at a time. In either case, this is a very laborious effort. However, sometimes it is the best method.
This method is inherently equipped with "break-points". That is, as long as YOU don't change any of the Input conditions, the process will "wait" for the next condition change. Of course, the process program will continue to run, however, unless you have a problem in your code, the current conditions should be stable... except for any intentional repetitive timer conditions that you might have.
Some Program Interfaces allow you to define "break-point conditions". In this case, at the appropriate part of your code, you activate a control relay, which indicates to the processor that you are at a "break-point". When this condition occurs, the process stops. You can then look at the resulting conditions. Of course, this does not allow you to see everything that has happened up to that point. It would be like handing some data to some guy who then leaves the room and then returns with the result... you have no idea what really happened while he was out of the room. The result might actually be what you expected... however, you can only "assume" that the result was developed in the manner you prescribed. Alternatively, you can "step" through the code and watch everything.
Even if you go through the pains of "stepping" through the code, you still need to develop a sense of confidence in that code; you need to test extreme cases. That is, provide data that is clearly outside of the acceptable range and then check the results. You should also test the "zero" and various "window-edge" conditions.
The "window-edge" conditions should also include checking the "plus-or-minus off-by-one" effect. That is, is the "window-edge" an exclusive condition or an inclusive condition? If the lower "window-edge" is inclusive then what happens if the data is one-unit less? If the upper "window-edge" is inclusive then what happens if the data is one-unit more?
CONTINUED IN NEXT POST