19 posts in this topic

We have been working with PLCs for long time. We used to develop PLC logic, partly test it on an emulator and test the rest on the partly energised equipment. From time to time working with computer software development (C# and JavaScript) I was always looking for something similar to unit testing in the PLC world. As I couldn't find anything at that time I've started developing own automated testing tool. Now we use this tool, which basically simulates PLC inputs in defined actions and checks expected behaviour of internal tags or/and PLC outputs. If it behaved the way we expected, it's PASS, otherwise it's FAIL. We break complex logic into small parts and create unit tests for it. By creating more of these unit tests we can test PLC logic of any complexity. The software called PLC Logic Prover and it's free at https://www.controlx.io

Recently, I've been told that there is no point to develop anything new if there are already great tools on the market. Honestly, I didn't do proper research earlier, so I'm here asking the experts. What do you use to test PLC logic? What automated testing tools do you use? Is it using IO simulation or it can test logic by other means?

Your replies are appreciated. Thanks, Alex

Share this post


Link to post
Share on other sites

Alex, 

Here are a few options, I did in the past:

  • Allen Bradley version of their simulation tool is emulate. You will be inhibiting io modules in order for specific code to work. Servo motion does not work and you will be deleting those out of the code and creating virtual axis instead of the actual servo. Also real world is always better than simulate environment. The emulate can help with troubleshooting some basic code such as strings parsing, simple boolean logic, ascii conversions,... 
  • you download to another standalone ab plc and you can look at timing issues (scanrate or a copy instruction that was defined wrong) on the actual plc - a hard to find copy instruction because you mistyped .LEN
  • 3rd party software or your own homebrew version of IO simulation - opcs, kepware, C#, ...

Seems like almost every PLC manufacturer has their own emulate/simulate software version available that I don't put that much effort into in coming up with my own homebrew version. Also, real world troubleshooting and debugging is better in my opinion.

I am more in favor of what Siemens offers than what Rockwell. The benefit is that with siemens you are not inhibiting IO modules and you can write to the tags as memory registers. 

 

Also, there are a few earlier posts on this forum about this topic.

Hope this helps :-) 

 

 

Edited by Izzybe

Share this post


Link to post
Share on other sites

Yes it does, tanks Izzybe. Can you elaborate on Allen Bradley emulator, I haven't used it much. Can it trigger digital inputs and write to analog ones? In a pre-defined sequence like S7-PLCSIM from Siemens?

We used the second approach all the time. Running the main program on the actual PLC, which usually goes to the client in the end of project development. While having a spare one with testing routines, connected to the production PLC over Ethernet.

Have you used any 3rd party software? Can you recommend any?

(thanks for the links to other posts with similar topics)

1 person likes this

Share this post


Link to post
Share on other sites

If you're wanting to test the code you're developing for a machine without physically actuating the machine, simply put the Allen Bradley controller in "Test" mode. The controller's operating mode switch must be in remote ("Rem"). When you go online with the controller, use your laptop to change the controller's operating mode to "Test", which disables all of the output cards that controller owns. This allows the controller to interact with all of the machine's operator & process inputs in real time, while you're monitoring the code from the laptop, without actuating any of the real-world outputs. When you're done testing the code and are ready to fully deploy, change the controller's operating mode to "Run".

This feature exists in RS500 and Studio 5000, so no additional, third party software tools should be needed.

Also, as far as I know, Emulate only runs on the laptop on which it is hosted. I don't believe that emulate has any means of connecting to or interacting with an actual controller. If you're a fulltime project developer, it can be a useful tool but all the code you develop will have to be migrated to an actual controller when you're ready to launch. Since emulators usually cost just as much as the regular programming tools, it's an expensive option considering the "Test" tool already lives in the software you have.

Share this post


Link to post
Share on other sites

Thanks ElectronGuru. Yes, Test mode is great option, if you don't want to have your outputs to go crazy on the first run on the real machine :-) (it doesn't not happen all the time, once one output was flickering due to simultaneous latch and unlatch in the code)

Do you test PLC logic mostly on the emulator or on the real PLC in the Test mode?

 

 

Share this post


Link to post
Share on other sites

Due to having to eventually migrate the code over the actual Studio (for real-world controllers) environment, I rarely ever use Emulate. I always develop code for and on the controller I'm putting in the cabinet, and use test mode when I'm not 100% certain of the outcomes.

I do use Emulate to prove concepts to a myself or a customer before committing resources to a new project. Also, it's a great tool when I'm on a long flight and want to bang out and test some new ideas. 

Share this post


Link to post
Share on other sites

When you developed part of the code, uploaded it to the PLC and ready for testing, do you do it manually by creating a simulation logic and toggling (CTRL+T) its bits? Have you ever used any 3rd party software for IO simulation such as opcs, kepware, etc... mentioned by @Izzybe  above?

Share this post


Link to post
Share on other sites

No, I've never used third party software. 

When you download from the PC to the controller, you actuate the controller's real-world inputs with the controller in test mode, or in run mode if you're feeling confident or adventurous. Very few things would need to be simulated if the actual inputs are available. The whole point of having the Test mode is to test the real-world inputs against the code and watch how the outputs respond in code only, without actuating those outputs on the machine. 

If you're running code in an emulator, most of your inputs will be manually simulated by the programmer by toggling Boolean instructions on a rung or in the tag monitor, or by typing in analog values on a rung or in the tag monitor. Again, I rarely use the emulator and therefore, I'm not an expert at it. It can probably do a million things I don't know about but since it can't talk directly to a real-world controller (that I know of), I only use the emulator for testing small portions of proposed logic when the actual controller isn't available. 

Share this post


Link to post
Share on other sites

I was on the phone with Tier 1 of Rockwell support and they havent been much help so far. They are supposed to call back today with more ideas. In the mean time I decided to focus on the PLC CPU to see if I could see how hard it was working and what it was doing. I ran across the Logix 5000 Task Monitor and I see that the CPU usage is around 94% on most of these PLC's. Occasionally I see a downward spike and one of those spikes coincided with a comms dropout. mobdro

Regards, tubemate

Edited by krankins

Share this post


Link to post
Share on other sites

Thanks @ElectronGuru The stage you described we call commissioning. Yes we check the inputs and outputs as it is part of getting the equipment up and running safely. However we prefer conduct as much testing as possible before the commissioning.

We download the program into a bench PLC and run tests. Mostly the PLC has no IO cards or if it has we just inhibit them. And we run specially developed software with predefined test cases. Try our free software from https://www.controlx.io 

I've been told that there are plenty of testing tools and I should stop the software development. So I'm trying find out more about the emulator and other 3rd party software tools. Thanks for your replies.

Share this post


Link to post
Share on other sites

On simpler projects, I would download the code to a bench PLC with all I/O inhibited and then add a "Simulate" program that simulates the real world. So if an output makes a cylinder move, I put a timer on that output and have the timer DN bit turn on the input for the cylinder sensor. This is kind of crude, but for simpler machines, it's adequate. I can extend the timer presets to simulate a dying cylinder or use a toggle bit to disable them altogether to simulate a dead cylinder sensor to see how the logic reacts and recovers. The PLC is in Run mode, and the HMI (usually on the bench next to the PLC) is also being tested.

This method is rather brute-force and inefficient and would be cumbersome with more complex machines or processes, of course, but it's served me well on the projects I've used it on.

1 person likes this

Share this post


Link to post
Share on other sites

@ElectronGuru - yes I have used the test mode as well on AB for the same reasons you mentioned during commissioning of equipment. 


Recently, where I have seen the OPC and simulate IO is for major plant floor layouts (in order to calculate oee, simulate production rates, full machine simulations). It is for virtual commissioning of machines, plant layouts, ... - there is a demand for this and with microsoft's hololens integration, train operators that way.  Companies that provide those simulation models are tecnomatix, factory I/O, ptc, ... In the last few years, what I have noticed: there is a move away from people understanding hardware (servos, io, ...) and a bigger focus on software and networking. 3d plant layouts have been taking off in the last 6 years and is for me fairly new item in the automation market.

Edited by Izzybe

Share this post


Link to post
Share on other sites

@Joe E. this is how we used to test our PLC logic. We even had the same approach for complex machines or processes, however it becomes messy and testing logic become too messy.

@Izzybe thanks for suggestion with the simulation packages. However, it seems like these packages are more about the plant simulation, not a simple PLC logic testing.

 

Share this post


Link to post
Share on other sites

I am trying to give you a different viewpoint on where I see it used and it can be useful. I dont even believe in the 3d software - because mechanical engineers tend to turn off those pesky interferences off as warnings on solidworks, autocad (LOL). 

1 person likes this

Share this post


Link to post
Share on other sites

@Izzybe I appreciate this. This is what I'm looking for, the different approaches in improving my PLC logic development.

Share this post


Link to post
Share on other sites
On 7/15/2020 at 9:00 AM, Joe E. said:

On simpler projects, I would download the code to a bench PLC with all I/O inhibited and then add a "Simulate" program that simulates the real world. So if an output makes a cylinder move, I put a timer on that output and have the timer DN bit turn on the input for the cylinder sensor. This is kind of crude, but for simpler machines, it's adequate. I can extend the timer presets to simulate a dying cylinder or use a toggle bit to disable them altogether to simulate a dead cylinder sensor to see how the logic reacts and recovers. The PLC is in Run mode, and the HMI (usually on the bench next to the PLC) is also being tested.

This method is rather brute-force and inefficient and would be cumbersome with more complex machines or processes, of course, but it's served me well on the projects I've used it on.

This is the way I have always done simulation.  Maybe every project I have done would be considered simple to people here, but I have simulated full chemical plants fairly easily with this method. Every program has logic that automatically puts all I/O into an inhibit mode when simulation is selected.  Simple items like valves, motors and drives have blocks that handle I/O transfer.  Simulation of that module is part of that block.  Batching, temperature control, flow, pressure, etc. are not really hard to simulate in a basic manner.  Generally the simulation is to wring out the program so I never had to actually model the process.  My purpose was not really to assist the chemical engineers in figuring out their process as it was to make sure my system could control the process properly when it was installed.  In addition to simulation, this allowed me to train the operators on the system before the actual startup.  I really never have run across a system that I could not effectively simulate this way.  Someone did mention servos.  That is an area I never had to simulate, but over the last 30 years I have put together some pretty complex systems and never found a third party system that added value to what I was already doing.  Most of my recent systems were Logix systems and they are particularly suited for this type of simulation.

1 person likes this

Share this post


Link to post
Share on other sites

@PLCMentor.com do you run test/simulation only on the completion of the PLC logic development? What if you have done changes after the simulation, do you do the tests again? Or you test only the changes?

Share this post


Link to post
Share on other sites
On 7/18/2020 at 6:44 AM, Alex_Sh said:

@PLCMentor.com do you run test/simulation only on the completion of the PLC logic development? What if you have done changes after the simulation, do you do the tests again? Or you test only the changes?

I run the test versus a test document for functionality.  Retesting is a case by case basis.  Most of my logic is very modular so just rechecking the module will ensure good results.  I had full chemical plants come up and run perfectly after an I/O field checkout. Just don't see the need for a separate piece of software to do what is already manageable in the controller itself.  In addition it cuts down on training as engineers already understand how to program the Logix.  These other packages will need training and time to come up to speed on the simulation software configuration.  Simple is always better in my book.

1 person likes this

Share this post


Link to post
Share on other sites
On 19/07/2020 at 9:52 AM, PLCMentor.com said:

Most of my logic is very modular

@PLCMentor.com this sounds like a great approach.

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now