PLC Simulation Fault Finding

Hi all,


I am just looking for other more experienced opinions on how programmers use simulation to help fault find errors in their PLC program?


How does it benefit you to use this method of simulation to fault find?


Many thanks,


Sean

It depends on what you mean on simulation fault finding. What I do depends on if I'm using a real processor or a simulator.
On a real processor I sometimes include Analog cards and use voltage/ma sources to simulate the signals. If I use no I/O either in a simulator or on a processor I have a block that maps the I/O to internals (what I mean is inputs to internal bits, internal bits to outputs and registers to analogues) then use the mapped bits in the program.
This block is disabled on simulation so that if a real PLC only need the processor and I tend to do the same on simulator programs.
I also write a temporary block that simulates things like analogues incrementing/decrementing, valves opening & closing i.e. use timers to simulate movement so if a valve is told to open then the mapped output starts a timer and the timer drives the mapped input to simulate the valve limits.
So it is possible to actually run the process as if in real time, remove the call to the logic sim block & enable the I/O mapping there you go ready for site.
If you do use this, then it makes sense to document the mapped bits in a similar manner as the I/O for example V001_PX01_Open_PX and the mapped bit as V001_PX01_Open_PX_M, as the real I/O is only used in the mapping block all references to that Input in the program are the mapped bit. As for analogues, again normally the functions for the analogue cards are only called in the mapping block(s) and the internal registers used for the analogues are used in the program. One thing to remember that many simulators have limited functions so some functions or interface cards cannot be simulated directly for example high speed counter instructions.

sean147 said:

How does it benefit you to use this method of simulation to fault find?

Click to expand...

To answer your second question first, consider the following two scenarios:


1. I write the plc program for a machine of total value of £2million. That machine is installed at the end of a production line of value £20million. Start-up begins. The £20million production line is generating product but my machine can't process it yet because I have some errors in my plc program. Tons of product and dozens of people are waiting for me to fix the problem, the whole maintenance dept are gathered round peering over my shoulder - it's not an enviable place to be. I find the errors (I've made some arrays of 0..15 but the program assumes 1..16) and off we go into production. Of course some more errors come out of the woodwork that have to be fixed but at least they don't stop the production line....


2. I write the plc program for a machine of total value of £2million. That machine is installed at the end of a production line of value £20million. A couple of weeks before startup I test/simulate every aspect and scenario that is reasonably possible. I find various errors and fix them. I am as familiar with the code as I possibly can be after all that testing/simulating. Start-up begins. The £20million production line is generating product but my machine can't process it yet because I have some errors in my plc program that I didn't envisage when simulating - I fix the problem in a couple of minutes and off we go. The maintenance dept are gathered around someone else working on a machine further down the line....

sean147 said:

How does it benefit you to use this method of simulation to fault find?

Click to expand...

Simulation benefits via the only metrics that matter in industry:

• it's safer than the alternative*;
• it's cheaper than the alternative.

Expanding:

• Fault finding using the physical process can be expensive
  • Testing parts of the code that deal with anomalous operations (e.g. sensor failure)
    • may produce scrap product
    • may requires paid operators or others to manipulate the process
  • A fault could damage the physical process
• Fault finding using the physical process may be impossible
  • A new, start-up facility may not be complete
  • It may be dangerous: having a particular component fail, to confirm that the PLC can protect the plant is not something that should be tried for real the first time.
• Fault finding using a simulator allows risk-free, low-cost operator training***
  • For a new facility, training can take place while the process is being built**
    • This saves time and trouble on startup cf. the examples given by LD earlier in this thread.
  • Faults in process design may even be discovered**

* It could be argued that the only metric is cheaper, and that attention to safety is a critical metric because it is cheaper, but the result is the same.



** This assumes the simulator is correct at the level of fidelity chosen:

• simulators can be complex, requiring a separate computer, differential equations and I/O simulation;
• simulators can be simple, involving a procedure that manually forces inputs;
• even I/O checkout could be considered a form of simulation

*** I was once involved in a simulation of a petrochemical unit operation, connected digitally to a Honeywell TDC console for operator training. When the refinery engineering representatives came for a review, we expected some feedback to see what further work or corrections were needed. Instead, after the initial demo, they essentially dismissed us, sat down at the TDC console, and started investigating the "process" that had yet to be physically completed.

this is what I do.

I get the customers specs and get familiar.
I write down the sequence
I then go over it again to see if I made any mistakes
I then ask what tells the plc when to go or stop and write down the I/o sensor / valve type.
get with the mechanical designer and discuss the project, what he has in mind vs. what I have in mind. agree on things and proceed.
write down the sequence based on that meeting and add the I/o.
then you be the plc and read your instructions as to what happens. do this and you will learn a lot about your code. don't assume anything, read what you wrote down ad do not deviate from it. make changes if necessary
write the code based on what you wrote down.

you can either use a simulator or go through each line of code toggling the I/o and run the program that way.
this helps before the actual downloading of the program and the debug starts.

if you can ask what if this happens, YOU BETTER HAVE AN ANSWER ! that 1 in a million chance will happen in front of the customer. Never fails.
james

+1 James Mcquade

This is exactly the steps I also take. If it is an existing machine, I would also have discussions with the operators and mechanics that work on the line.
Regards,

James Mcquade said:

don't assume anything,

Click to expand...

This is why we simulate. Because the only near-infallible assumption is that the PLC will always do exactly what we tell it to do, and that may have at best a passing association with what we want it to do.

As already posted, there are many good reasons for simulation, one of the most important is to get the software working as close to what the customer requests. Other reasons not mentioned yet is customer testing (pre FAT testing). One of my largest customers always insists on testing the software before going to site, this used to be a major task as simulators were rare if not not like rocking horse ****. In the early days, testing consisted of the full set of racks, outputs driving banks of relays to simulate inputs switching, bespoke communication software to simulate weighers, temperature controllers etc. One of the first Simulation packages we used still required the main processor and consisted of a card that fitted on the main rack (Siemens S5) a PC interface card and software written so that the I/O could be simulated using pascal. It was written by an ex Siemens engineer in Germany and was called Prosys.
One other benefit was that the customer would send a group of operators to our offices for a week where they could use the simulation to get pre on-site training. This proved invaluable, they learned how to run the system, got comfortable, was good for relations (how many times have you been on site and felt the whole factory staff were against you). It also allows you to find the bubba factors that operators seem to find without destroying a shifts production output. All this is very important as most engineers who have to commission on-site know that usually the project is running late, the time is short & there is nothing worse than some production manager breathing down your neck while your trying to sort a problem.