I am new to opc ua. I need a signal simulator and connect it/send data to opc ua server.
I am thinking to write a program as the signal simulator or if there is a recommendation for existing simulator. The requirements for simulator is sending some signals simulating a production line. Signal examples includes packing_package_started, packing_package_finished, sending_package_start, sending_package_finished.... As you can see, those signals need to follow a specific order. I am thinking to write a python program(or nodejs program, it can be other languages) to generate these signals, but I don't know if it is possible and easy to connect this python program to the opc ua server? Or if there is an existing simulator that I can configure and send data to opcua server?
I do not know a simulation client for that but if python work for you fine you can use the asyncio-opcua package. I think for a simple application like you plan, writing a python script should be good.
If you want something more "graphical" you can also use node-red
Related
I am working on a legacy modbus program for an industrial SCADA system.
Currently, the c++ program acts as both a modbus TCP server and client.
Client behaviour:
It reads from a number of vendor PLCs (servers) on site, performs calculations and sends control commands back to the PLCs based on the data received across the site.
Server behaviour:
responds to a variety of TCP read and write requests from web interfaces and laptops on site.
Until now, this has worked fine, but we have recently installed a logging client on the network which polls our program very frequently (sub-second) and this has revealed timing issues: the program can potentially take a very long time in its client loop performing calculations and reading PLC values before acting as a server and responding to incoming requests.
Easy solution would be to split the programs into a modbus server and client instance, and keep them both running on the same embedded PC.
The issue I have is that the remote web interface (HMI) must be able to control the behaviour of vendor PLC 2 and Vendor PLC 2 will only allow one TCP connection from the embedded PC. In the past the program has handled writes requests from the HMI by forwarding them on to the PLC 2 via the open socket.
I'd be keen to gather thoughts on best practices here.
My thinking:
the modbus server program will need to respond to the HMI requests and somehow store the information required for vendor PLC 2, and it will also need to set a status register to inform the modbus client that there is data for vendor PLC 2.
The modbus client program will need to read the status register (and data) from the server and pass this on to vendor PLC 2.
Am I heading in the right direction?
Without having details on your implementation I can only guess the problem is that your program is single-threaded, and delays are caused by waiting responses from PLCs.
So, if my assumption is correct, you need to switch to 'select' function and redesign your software to be totally async. You have to put all sockets (both connected and accepted) in a FDs set and wait events on them.
win32:
https://learn.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select
linux:
https://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=select&category=2
I've written the same app ages ago on win32 (but without calculations) and it easily processed about 200 PLCs, working on the same machine with SCADA.
I am expected to design the solution for collecting/processing samples from a PLC device, and working with some control tags of the device. Please, suggest the approach. Sorry for the long question. I will split it to more questions after learning what are the smaller and more reasonable subjects/questions.
The solution for the company is built almost from scratch. There are some PLC devices, and there is a KEPServerEx (without the IoT Gateway). The PLC devices are already used through the third party proprietary software. But there is no "bigger framework" for future. From that point of view, I can introduce a modern design, but the budget is restricted.
From what I have learned so far, it seems that the KEPServerEx is a good choice for accessing PLC devices, but I have no hands-on experience with it. It seems to me that the OPC UA should be the choice over the older OPC (DA). I am also aware of the ladder way of working with PLC.
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
What is not clear to me is, how to do that without the IoT Gateway. I assume that it must be a basic operation. Is the (tagID, value, quality, timestamp) generic for working with PLC through any OPC server? Or is it generic only for KEPServerEx, or is it special for the IoT Gateway (optional) plugin?
I have learned that OPC Foundation added recently the Publih/Subscribe mechanism to the OPC UA. Does it require also newer version of KEPServerEx? Or can it be used with any earlier OPC server?
I am fairly experienced in programming and database things. I also have some technical background in industrial sensors, actuators,... However, I have never worked with digital automation in industry.
Thanks, and have a nice day.
Depending on the PLC you want to communicate with, and the communication network your devices will be transmitting data on, you need to purchase the appropriate driver package so that KEPServerEX can communicate with it.
For example:
If your PLC is an Omron NJ PLC, and it is on an Ethernet network with the server that KEPServerEX is residing on, you will need to use the "Omron NJ Ethernet" driver in the suite package Kepware offers called the "Omron Suite".
Regarding your question about the IoT Gateway:
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
This can be done without the IoT Gateway, by using the appropriate aforementioned driver, and then using another driver package to send the PLC data to wherever you would like (ODBC client, SQL Server database, etc.). It depends on what you want to do with the data you are acquiring.
When you talk to a specific device you need to know the protocol that the device uses and those protocols can vary really much.
Sometimes the manufacturer of a device provides an OPC server that shields you from this or as you mention a 3rd party Connectivity server like KepServerEx or Matrikon can be used presenting an OPC interface for your client to use.
I don't know anything about the KepServerEx or your particular requirements but normally an OPC server has a cache where values are stored from which the client can read from alternatively read directly from the hardware. Subscriptions can be configured similarly e.g. frequency, threshold etc.
The protocol from the OPC sever/3rd party to the device determines the frequency in which you can sample values. E.g. some protocols need the device to be polled for values, some are more elaborate.
If you create an OPC client then you are pretty much free what kind of OPC server you connect to whether it is a 3rd party or an OPC server from the manufacturer and having the client storing values whenever items in a subscription changes is pretty trivial.
If you are familiar with Visual Studio, then AdvancedHMI may be a possible solution. You did not mention any specific PLCs, but AdvancedHMI includes many PLC communication drivers as part of the free package. This gives you the ability to write VB or C# for transferring the values from the PLCs to a database. The drivers are not OPC drivers, but are designed to be much simpler to use and more efficient.
I need to create a hardware-in-the-loop test setup. I will be using Modelica (Dymola) to do a real time simulation of a system. Dymola should send/receive data to/from some hardware and where the received data will be input to the model.
I am trying to communicate with Modbus over a serial connection. The hardware is a PLC-like device so this seems like the preferred method.
I do not have the hardware yet, so I am testing with an Arduino Uno. I have installed a Modbus-slave library from here on the Arduino, and tested it with it with an Modbus tester.
I cannot figure out how to communicate with Dymola. I have tried the Modelica_DeviceDrivers library and was able to send or receive (not both together) data from the arduino but not by the Modbus protocol. My question is if there is any modelica library for modbus communication or any other way to accomplish this from Dymola/modelica?
The free ModelPlug library will connect SystemModeler (and potentially Dymola too) to an Arduino board for I/O. You can download it here: http://www.wolfram.com/system-modeler/libraries/model-plug/
If you want to write your own drivers, you could go to the Resources\Include folder under Modleica_Device_Drivers library, there is a bunch of c header files, and they are very good examples of how to write your own driver. If you can write it in the way that it could be compatible with Modleica_Device_Drivers "package", then it will be quite easy to assemble/disassemble your data messages.
If you just want something quick, you can write a C function and reference it in Dymola.
Both methods may require when(sample(...)) clauses in order to sync your sim time with real time. But this means event generation, tho it is a time event, but for big models with a lot of states, it may slow down your simulation.
I would prefer to create several inputs and outputs around the model, then export the Dymola model as a C or FMU model, I'll write another communication program to control the data flow.
How can I interact with a PLC to send and receive data to/from a remote server(PC).
For example a robot that have a PLC and want to interact with a server that placed at near room with a wireless communication.
Data must move all over the time. PLC sending the data to the server and server must sending back the result of computation on the data to PLC.
review : My PLC brand is Delta but its model has not been selected yet .
A common scenario is that the manufacturer provides an OPC server for the PLC. You should check their website once you know the model. Then it is just a matter for you to create an OPC client.
A good way to start is to get a free OPC server simulator like the one from Matrikon. It doesn't need any hardware. OPC is a standard interface (although there are often some minor variations between manufacturers) - if you can get your client to work with the test server you can probably get it to work with the PLC.
I am communicating across USB, using a proprietary protocol, with some custom hardware I've built. I have a GUI that handles all the communications/interaction with that hardware and a (C#) DLL which exposes all the relevant USB functionality. I need to write a LabVIEW driver (VI) for communicating with the hardware. My thought is that I just use LabVIEW to open up my GUI and have a socket with which I expose all the relevant control to LabVIEW with. Is it possible to open a socket in LabVIEW and communicate with my GUI? Is this a bad approach or should I just try and make LabVIEW invoke the DLL and handle the hardware control instead of my GUI (polled communications, solicited/unsolicited commands, etc)?
IS there a reason you want to use your GUI only? In terms of time, I would say build a good front panel in LabVIEW and just communicate to the hardware directly using the DLL. Adding the GUI is just an added layer of complexity which might be difficult to maintain later on? Why not do everything in LabVIEW if you can?
Yes, LabVIEW supports sockets using both TCP/IP and UDP.
You should be able to create a program/service that continually runs acting as TCP/IP server. You can send commands and receive responses as strings. If you need to pack data, you can use the flatten to string command.
Essentially, your application should be structured as a loop running the TCP/IP server, and another loop that actually communicates with the instrument. This might change if you need to get data back from the devices to your TCP client. A producer consumer model, if you will :)
To get you started off, open up the NI Example Finder (Help -> Find Examples) and browse to Networking->TCP and UDP-> Simple Data Server.vi
It depends who is going to be using the LabVIEW driver and for what. If you're handing over this hardware to someone else who is going to want to create their own application(s) for it, they would probably prefer to talk directly to the DLL rather than go through your GUI. If it's more about automating your existing software from LabVIEW to do testing or repetitive tasks on the hardware, for example, then driving your GUI from LabVIEW might be less work.