Simulator, Simulation, Shadow Code

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.

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
 
Simulator #4:

This simulator is also much easier than developing a PC-based simulator. This is a very good simulation scheme if you prefer the "feel" of real inputs.

Like Simulator #3, this simulation 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.

However, unlike Simulators #2 and #3, this simulation requires at least the Input Modules. Using the Output Modules is optional.

Just as in Simulator #3, 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.

This simulator provides a feeling of "realness" using real input devices even though they are not the actual input devices. This simulator uses a bank of multi-position switches, toggle switches, momentary switches, or pushbuttons (any combination thereof) connected to the Input terminals. The switches and pushbuttons mimic the actual switches, limit switches and sensors in the field. You should carefully consider which type of faux-input device you are using to mimic the real field device. If you have a multi-position switch in the field then it wouldn't do to use a pushbutton or toggle switch to mimic that switch.

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 somewhat stable... except for any intentional repetitive timer conditions that you might have.

As you change the input conditions (via Force or Write), or vary the input data (via Write), you can monitor the results in the Programming Interface. If your Programming Interface allows, you can build a Status Screen where you can monitor the status of various inputs and outputs. Alternatively, if you have Output Modules installed, you can monitor the Output lights.

If this is the only process that you have to maintain, then, except for the pain of building the Input panel, this is a very simple scheme to operate and maintain. You only have to build the initial panel once. You can then modify the Inputs as you wish.

If, on the other hand, you have multiple processes using the same processor, then, unless you can afford to build a test-bed (including a processor) for each process, you'll have to consider maintaining separate Input panels, one for each process. In this case, you'll have to go through the pains of disconnecting one panel and reconnecting the other. This could be quite painful if you have a substantial number of Inputs.



Simulator #5:

Eventually, once you have gone through all of the code-only verification simulators, you are going to have to run the code on the real process. This simulator allows you to run the process without any real material flowing through. In some cases, passing material through the process with poorly written code might cause the destruction of the process machinery. In this case, there is a great advantage in testing the operation of the machinery without material. Of course, you must consider carefully those portions of the process that cannot be "run dry". The purpose of this simulator is to exercise those portions of the process that can be "run dry".

This simulation occurs on the actual Process PLC. This simulator is very different from the previous simulators. In this simulator, the Input signals are divided into two groups; Material Sensors and Machinery Sensors.

In this simulator, only the Material Sensors are simulated. The simulated Material Sensor Inputs cause actual Output activity. The actual Output activity causes the output field devices to operate. This, in turn, causes the Machinery Sensors to change state as the machinery actually operates. The program responds to the changing states of the Machinery Sensors.

In this simulator, you can control your simulated Material Sensor Inputs in a couple of different ways.

You can manually simulate the sensors yourself by turning on (via Force or Write) various simulated Material Sensor Inputs. This will bring the process to the next inherent "break-point". The process will wait for you to change various simulated inputs before moving on to the next "break-point".

You can use a semi-automatic method to change the state of a limited number of Material Sensor Inputs. You might use a single bit to change the state of several simulated input bits simultaneously, or you might use the single bit to activate a timer, which will then activate the various simulated inputs in a particular sequence.

You can use a fully automated method to change the state of any number of simulated inputs. In this case, the process modifies the simulated inputs as it continues to operate. At some point, the process reaches the end of the particular simulation. At that point, you can design the process to stop (this would be like a single-cycle exercise), or you can design the process to restart the simulation (this would be like a continuous exercise).

With careful planning, you could set up your program to run simulated cycles by simply turning on a single bit, "RUN SIM". This could be modified to "RUN SIM: Single Cycle" or "RUN SIM: Continuous".

You can apply this scheme to a limited portion of the process or to the entire process.

You would do well to create a set of Simulated Fault conditions as well. While the process is running in Simulation Mode, turn on a particular Simulated Fault bit and watch how the process handles the fault.

This is a great simulator for "showing off" your handiwork to the big-wigs before bringing the process on-line.



Simulator #6: Shadow Coding

In those situations where there is no bench-PLC available and there is essentially no such thing as down-time, or if you really need to have real-time process inputs to feed conditions to some code that you are testing, then a Shadow Code Simulator provides the means to test your code. This simulation occurs on the actual Process PLC.

WARNING!!! This is most effective on a PLC with on-line programming. You had damned well better KNOW how to do on-line programming without affecting the process! AND, you had damned well better KNOW how to develop code that won't cause a Processor Fault! (I don't develop my code on the screen... I develop my code with a word processor, and a pencil and paper.)

Yes... this is a damned scary simulator. It is scarier than SIM #5. This isn't for the weak-hearted.

Whether, or not, you are using actual input and/or output conditions or current process data, this simulator runs along side of the actual process code.

I use this method to test code that I plan to use to replace or enhance existing code. Sometimes I use it simply for data gathering or condition trapping. While the code is still under test, it in no way affects the status of any process conditions. If the activity in the Shadow Code might affect any portion of the process, I create a duplicate environment of that portion of the process. All activity produced by the Shadow Code affects the duplicate environment and not the process.

When I am satisfied that the Shadow Code is working as expected, insert a pair of control-bits into the particular active rungs. I insert the first bit in series with the output of the rung. I insert the second bit in series with the output bit from my Shadow Code, and both in parallel with the entire rung.

OLD CODE CTRL-BIT
----| |-------------|/|-----+-----( Actual Output )
|
SIMULATED |
OUTPUT FROM |
SHADOW CODE CTRL-BIT |
----| |-------------| |-----+


.
While the process is running, I simply turn on (via Force or Write) the Control-Bit. If at any time a problem develops, it is simply a matter of turning the bit off. It is best that these changes occur in small steps.

This process repeats until all changes are accomplished. If there are a large number of changes then I include a Master-Control-Bit. This bit allows me to add changes incrementally, but then, if necessary, I can cause all changes to revert to the original with a single bit change.

Once all of the changes have been made and I am satisfied with the performance, I replace the Simulated Output in Shadow Code with the Actual Output, and delete the original Actual Output. It wouldn't do to have two instances of the same output. Then I delete the old code.

All of this occurs "on-line" while the process is running. Yes, it is scary and very stressful. However, sometimes you just have to do what you have to do! This is the only way I know of, in a system that runs continuously, to have continuing improvement without affecting production time.

I use this method more than any other.
 

Similar Topics

Hi, I state that I am quite a beginner, but I was wondering if there was a way to simulate an NB hmi display by connecting it in some way to...
Replies
3
Views
1,302
Hello, first of all I introduce myself, my name is Manuel and I have recently entered the world of the plc's, sorry for my English. I would...
Replies
3
Views
5,854
Showing a new guy basic programming and remembered the simulator here. But nothing happens when selecting the link. "Try our online PLC Simulator-...
Replies
25
Views
1,267
My PLC (S7-1200) and HMI (KTP-1200 Basic) has been delivered on-site to the customer. To be able to do "off-line" updates to the code, I am using...
Replies
4
Views
198
hi everyone please give me a solution to timeout error in delta plc simulator,i have a doubt about firewall and antivirus we r using.
Replies
2
Views
623
Back
Top Bottom