I would like to develop an application to read data from PLC machine (MELSEC-Q Series). Currently, I am reading data using kepware. However, I have to specify which PLC address I want to read in advance. I want to build my own application thus I can specify at that particular moment which PLC address I want to read. How can I do that (any programming language is OK)? Is there any module to do that?
NB:
Actually, I want a function in a programming language like:
function (Read PLC Addresses X2, Y8 .... )
{
//read value of those PLC addresses
// report to excel file
}
I am very new in this field. So, correct me if anything is wrong.
You could use MX Component by Mitsubishi which an official API for communication with MELSEC-Q Series PLC (among others). The API is basically a COM layer that implements the MELSEC Communication Protocol using sockets (TCP or UDP) or serial communication.
It is possible to use the API using any language that supports COM, such as C/C++, VB6, C# and VB.NET
You can setup predefined configurations in the same way as a Channel/Device pair in Kepware KEPServerEX or you could setup communication dynamically at runtime like you want to.
Just like Kepware KEPServerEX, the MX Component API is a commercial product.
You should be able to set-up multiple connections in Kepware, and call them as needed. In Wonderware (the HMI application I am most familiar with) each PLC then becomes a topic that you address to get the data.
Kepware has examples and sample code for VB here Kepware VB Samples
Related
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 am planning to make some microcontroller boards which would do miscellaneous tasks. For example measuring analog voltages or controlling other instruments. Each board needs to be controlled/downloaded it's data from one place. For that purpose I would use an ethernet interface and do the comnunication over that. So my question is: which would be the most suitable method of achieving that. My ideas are: run a webserver on each module and communicate with POST/GET, or run a telnet server on boards and communicate with a telnet client. The security and speed/latency is not an concern but the data integrity is.
I don't need a html based gui for modules because I will implement an application which will communicate wizh the modules periodically, gets the data from them and stores in a database. And the database is what I will use later, for examining the data for example.
An other example:
I have a board which measures measures temperature. There is a server on the board itself run by the mcu. It is connected to a router via the ENC chip. I have my pc also connected to that router. I have an application which connects to the server run by the Atmega328 and collects the data then stores to a database. It repeats this let's say in every hour. I would use an Atmega328 and an ENC28J60 ethernet interface chip. What do you recommend?
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 connect a windows phone 7 device with a WiFi-enabled micro controller. Should i use socket programming?? If yes then how?? I actually want to send a text file or a text message to the micro controller using WI-FI??
Your question is a bit vague. Are you trying to write a app that enables you to send a text file/message?
or are you trying to accomplish this by connecting to the microcontroller with the default connection your phone provides.
If you want to write your own app, you can do this by using a windows socket function. Have you looked into the standard code examples windows provides? They provide good examples about the basis of windows phone wifi connectivity
in example:
Example 1
Example 2
Edit:
You should take a look at this example.
Example
In this microsoft example, they make the game tic tac too between two windows phones. For your cause, you can read the data form file. Temporarly store it in an array. And send it over wifi. if you customize the example to fit your needs, so in steps:
Declare a socket (with the right ip adresses, ports etc)
Read file
Store in array
Send array by the wifi (using your previously declared socket)
And then on the microcontroller, you need some way to filter your data out of the incomming wifi buffer. I looked into one of my older projects where i did something like this. But i couldn't find it anymore. So i must have deleted it at some point "sorry :( " i you can work this out using the example
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.