Hi there,
I want to know what the usually used method to exchange real time data between ignition and PLCS. For exemple, my ignition application is developped to control a clamshell bucket to move some rubble. Through the app, I need to be able to send commands and get current status. I thought of making a csv file of exchange tables to achieve that. But since I'm a beginner, I believe there might be other efficient solutions. Can you tell me about it ?
Thank you.
The generic modern standard is OPC/UA. If your PLC supports that natively, Ignition will connect directly to it.
Otherwise, there is a plethora of branded communication protocols across all PLC types. Ignition supports several of these, documented here.
Summary:
Siemens has an older semi-open protocol that Ignition can use, and a newer encrypted protocol that Ignition cannot use. But for its modern PLCs, supports OPC/UA.
Rockwell use the open EtherNet/IP protocol to wrap its vendor-specific tag read/write services, which are also openly documented (mostly).
Omron NJ/NX family also use EtherNet/IP, and follow the simpler parts of Rockwell's publicly documented tag services.
Other Omron devices use the FINS protocol.
Many brands use the legacy Modbus protocol (and the newer Modbus TCP), possibly with vendor-specific extensions.
DNP3 and IEC 61850 round out the main protocol support.
Mitsubishi "MC" protocol is a newcomer not yet shown on that page.
Third party modules can add more protocols.
Thank you @pturmel
Coming from a software engineering background, it's a bit complicated for me to understand. What about an ET200SP CPU 1512-SP 1 PN ?
Pretty sure that would need Ignition's Siemens 1500 driver. (I don't think those little PLCs have the OPC UA server option--but I avoid Siemens like the plague, so others here might know.)
The data sheet lists it as a licensing option just like the other models.
I don't think we have that. So I need to find another solution ? Do you have any suggestion ?
Ok. Good to know.
files that away in the furthest back of my brain
Use Ignition's native S7 driver, as I recommended. You will have some hoops to jump through in the PLC configuration to enable that legacy operation.
When choosing a PLC, IO is the most important (quantity and type), maybe you need to watch a few PLC video tutorials first. Even if you're not responsible for writing the PLC program, that's a big plus.
Yes, I'm struggling right now to get through this but I do want to understand the necessary for me to not miss out ignition functionnalities. Can you recommand me a video ?
You probably need more than a video... https://inductiveuniversity.com/
Siemens PLC 1500 series have two ways to communicate:
Okay thank you but we do not have a license for the OPC UA server. What can I do then ?
Sorry, I didn't learn PLCs in English. But, I choose these two videos, one about hardware, another about software. You can think of Ignition like any other SCADA software (but better), that is, configuration and interfacing of Ignition to a PLC is very easy to handle.
The Inductive university contains guidance on the specific connection process.
Legal way:
Update the firmware to >2.9 (TIA17), go to CPPU set up, and enable the OPC/UA server (there are many options about the certification; leave all by default, but in the future, take a look at how to protect). Go to CPU setup license and say that you have the license. Now order a license from Siemens.
Not legal ways:
Do all the same except the last action.
Hi @pturmel, I do not recommend using the legacy operation for many reasons: Siemens has worked very hard in the last couple of years to give a robust and safe industrial CPU with the possibility to use a certificate to communicate using modern communication ways. (maybe 
) That means it is a little more challenging, but... "This is the way"
I honestly don't care. For those stuck without the OPC UA option, it is there and works. It would be better if Siemens was more open about their newer S7 protocol, but $$ apparently are in the way.
This kind of [expletive] is just one of the many reasons I avoid Siemens like the plague.
The specificity of @AMA_nylon's comments suggest the PLC identified is already deployed, and wasn't his choice, and simply has to be dealt with.
Is Rockwell any better here? They don’t even have OPC UA, and what they do document about tag access is crippled to maintain first party advantage. It’s barely different than S7 and especially S7+ being undocumented.
indeed. Siemens tries to provide high value-added products to increase profits. But these features are pretty much useless to me. And the features I really need it has been unable to provide.
I would say Rockwell is clearly better.
Their "undocumented" stuff is more "obfuscated" than "protected". Not necessarily "easy", but accessible. The encapsulation technology is openly documented at a very reasonable price point. My driver is proof thereof. In contrast, as I understand it, S7+ requires knowledge of a private key corresponding to the public keys embedded in their products. So not only entirely undocumented, but utterly unusable without being able to sign the messages.
Meanwhile, Rockwell's tag access protocol, whether the public core or the obfuscated parts, requires no special setup in the PLC, nor disabling of that PLC's modern features. And is fully symbolically browseable. Rockwell's modern TLS support is implemented in the openly documented encapsulation, and gives the user total control over the keys.
I don't think the comparison is even close.
I have a further gripe against Siemens that is a bit orthogonal to this discussion: The I/O part of ProfiNet uses a custom Ethernet frame type--unroutable, unusable in Windows outside of Microsoft signed drivers, and very java unfriendly. In contrast, EtherNet/IP I/O is carried by bog-standard UDP packets. But hey, Siemens managed to sell a whole bunch "ProfiNet" switch hardware. Infuriating.