I have an existing project in Automation Studio 4.12 with all hardware modules configured.
For development and testing I would like to run the same project in ARSim and interact with the hardware IO from an external application such as Python or MATLAB.
The goal is to read and write the ARSim IO programmatically so that tests can be automated and hardware behavior can be simulated from outside the PLC application.
Ideally this should be a simple and fast way to simulate the system, similar to what can easily be done in MATLAB. For example it should be possible to inject signals, run simple simulations, or replay recorded data.
Are there recommended approaches to access or manipulate ARSim IO from an external tool when the project already contains configured hardware modules?
This would be my approach, but there are probably many other possibilities.
You could create a program to transfer I/O data to different places depending on if you’re in simulation or not. For example, say all of your I/O variables are in a global structure variable called gIO which has both inputs and outputs (gIO.Inputs and gIO.Outputs). All of your tasks use gIO to read/write I/O variables. You could then use a program (e.g., IOPrg) to populate gIO with either variables mapped to the I/O modules (e.g., IoChannels) or simulated variables (e.g., SimIo).
Such a program would look like this:
IF DiagCpuIsARSim() THEN
gIO.Inputs := SimIo.Inputs;
SimIo.Outputs := gIO.Outputs
ELSE
gIO.Inputs := IoChannels.Inputs;
IoChannels.Outputs := gIO.Outputs;
END_IF;
The advantage of this is that while you’re in sim, you can populate the SimIo variable from somewhere else (e.g., a Python script accessing it via OPC UA) and the data will be transferred to other programs like normal. You could also write programs in Automation Studio that access this simulated I/O structure without getting overwritten by the real I/O mappings.
1.) If you need real time simulation data (every cycle matters) write to the variable connected to the forced IO- datapoint by _CYCLIC application code.
Automation Studio uses plain text files for source code, which can also be created using external tools and filled with simulation files (e.g. fill an array).
just as information to others reading this thread:
there’s also a protocol named “WinIO” available inside the Automation Runtime, which can be used for non-realtime IO simulation (based on a TCP connection) for appropriately configured IO modules (it’s just for use with IO modules, not for axes, fieldbus devices, and so on).
As B&R just deliveres the AR-integrated part and a protocol spec., but no simulation server or so, using that protocol means that you have to develop the simulation server on your own!
The protocol specification is availiable in the local Automation Help, you can find the document unter this AS help GUID:
80ad04d2-7ee2-490b-a4fa-e593358de020
Some more information about this IO simulation can be found in the AS online help:
I would definitely be interested in using a simulation server that I can spin up for when I am doing UI testing using python unittest via OpcUa with the asyncua library (where I can write the simulation interaction then in python instead → because that would remove unnecessary testing/simulation code from the PLC once I compile a release).
Currently the way I am simulating IOs is basically the same as what Marcus is saying. Additionally I usually have a Simulation Task that I offload connected IO interactions to, by doing PV-mapping instead of IO-mapping, for the respective IOs.
I tried the WinIO protocol and implemented a small simulation server using GNU Octave.
It works in principle and seems practical for simulating I/O, but I still need to test it in more detail.
However, my production code is based on AppModules, and this leads to the error:
“IO simulation is not available in application modules. 6767”
At the moment I can only test single modules, not the whole system, and I have not found a practical solution yet for simulating the complete application.
