I am using open62541 C library.
Need to check connection and read parameters with PLC's of SIMATIC controllers, Allen Bradley PLCs and Programmable Controllers MELSEC in case there in no OPC-UA server running on it.
What approach should I follow to avoid any third party tool ?
If you want to avoid third party tools then you need to develop implementations of the native protocol for each of the PLCs you need to communicate with.
Good luck. This is why products like Kepware exist instead.
Related
I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's
I have an application whereby I need to read data from a PLC into a database and whereby I need to develop my own application to do this. I just need to read 5 values from the PLC and log it to a DB. I have a demo OPC server running and can access it via UA or DA.
After looking at many different approaches I settled on using an OPC server to connect to the PLC and then to write an OPC client to interface to the OPC server and then write the data to the DB from my app. My language of choice is C# with .Net and the only licence fee I am able to pay for is for the OPC server from my PLC vendor.
What I am however finding extremely frustrating is getting the right info on OPC to get started. I dont want to buy any stacks but would prefer an open source stack. The information seems very fragmented and all over the place. Most of the info about OPC seems to be hype about how easy it is to use etc.
The best post on Stackoverflow that I could find is: Noob guide to OPC: how to write a C# Hello World client? and some of the links are not active any more.
My question is therefore are there any good tutorials showing how to build and OPC client from scratch in .net and what is the best open source SDK to use without having to buy a vendor's stack?
Is DA also worth learning or should one stick with UA?
The big question is why is OPC so frustrating when its marketed as being so easy?
It would also be nice to have a nice high level guide on the theory that one needs to know to build a client. I do realize that with time its possible to eventually figure this from the resources available but with limited time to make sense of all the scattered resources a quicker guide would be helpful.
Stick with OPC UA.
Luckily for you, the OPC Foundation's C# reference implementation has the capabilities of both stack and SDK, whereas other language reference implementations are typically just stack functionality.
The code is available on GitHub: http://opcfoundation.github.io/UA-.NET/
If you're not a member of the foundation the code is available under GPL2.
As for your concerns about the ease of use and marketing... I assume it's because OPC UA is marketed towards end users, who will just be hooking up various OPC UA compliant applications, which is easy. As a developer I think its fair to say there's a little more assumed about your ability to figure things out... from code examples, the specifications, books that are available, etc...
I will be developing a protocol that will encompass a client and a server module.
Several protocols that are close to the one I have in mind exist, but I want to make something simpler with less overhead and with something I have more control on.
The protocol I will be doing can and will be run almost in any scenario, local, web, lan, internet, etc. It can also run on a single box.
My question is, how can I start developing for the server side of the protocol?
Any ideas, insights, key words, starting points would be appreciated.
Regards
Do you want to develop the protocol yourself and then use it? or you are looking for a good protocol to use?
If second, I have recently worked with "Websocket" protocol which enables clients to communicate with each other via a server. It is a really good protocol and there are libraries in .NET ( >= 4.5), JAVA, Javascript, ... It is also supported in many browsers.
Basically, I would like to creat my own piece of software something a la communication protocl between PC and PLC.
I would like to read real time values from PLC and display them in a table for example Data Base, OPC table, Excel and write to PLC from PC in real time mode as well.
The whole point is I would like to access this data via ethernet port. How I can do it ? I do not want to use 3rd party software. I want to create something my own.
Choose any programming languages like C#,VB.NET and use opcdaauto.dll ,it is free dll for OPC Foundation members
You can easily get the live data from the OPC
or use dll provided by the OPC Server which you are using
As already mentioned, OPC-UA is probably more preferable, otherwise, there are commercial libraries such as InGear and open projects on GitHub.
If you actually want to implement your own low level drivers, they will depend on the PLC manufacturer. For example:
If you are working with Allen-Bradley, you will have to implement Common Industrial Protocol (CIP).
If you are working with Siemens, you will have to implement S7 Communication (S7comm or S7 for short).
If you search GitHub for various search terms related to Allen Bradley CIP and Siemens S7, you will find many starting points for communicating directly with these controllers.
I want to try developing an XMPP server component using XEP-0114: Jabber Component Protocol.
Which server do you recommend and why? I'm talking about ease of development, community support, documentation, examples, etc.
That's a hard question to answer, because I doubt there are many developers involved in developing across multiple XMPP projects and languages.
I can throw out a few personal perceptions but... I could be off-base!
What you're really looking for is which libraries would be recommended for component development. All the servers support the component protocol, so all you really need is a socket connection to the server and some helper routines to make the repetitive stuff like message parsing easier.
Where the server might matter is if you need tighter integration.
For example if you want your component to scale the same way as Ejabberd then you'll probably want to use exmpp.
If you need to deploy your component alongside Openfire into Java only enterprises, then you'll probably want to use smack.
If you are familiar with Python and want to prototype quickly use Wokkel.
I don't think documentation is going to be great for any of the libraries (haven't looked at them all though!) but that shouldn't be a huge burden. All you really need a good book on how the XMPP protocol works and then some sample code from the library and it's fairly easy to move on from there.
For an easy-to-use testing server I like openfire. Good instructions, easy to hook in components, and a good web interface for administration. Debugging is more of a "tail -f" on the logfiles, slightly java-ish.
I've used XCP professionally, but that's really for commercial use. It works well but if that's not your target deployment it's not worth the effort. I'm not sure if you can buy it separately any more.
I tried using ejabberd and I gave up quickly. I found the documentation for setup and administration awful. The config files are not self describing and there's no good walk through on the ejabberd site. It may be able to even fry my eggs in the morning for breakfast, but I couldn't get past install with the time I'd allotted to it.
For Openfire, there is something called Whack, which is a Java library for creating server components (XEP-0114).
Since the communication is over sockets, I presume the same code should work for any well designed XMPP server (such as ejabberd). However, I have only tested it with Openfire and it works quite well.