I've recently finished my ToddySoft Connect PROFINET driver and as I am planing on shipping almost all of my drivers as Ignition modules, I have a few questions on prioritization.
Is there interest in something like this? I'm also working on an EtherCAT driver which is coming along nicely.
In contrast to regular PLCs where usually there are hundreds to thousands of tags, with PROFINET or EtherCat I usually have very few IO points per device. This would result in users having to define loads of Connection in Ignition (I know as most devices only support one controller the number will not be that big however). I was thinking of allowing to add one "PROFINET" or "EtherCat" device, where you select the list of devices that you want and they all appear in one browse tree.
Would you like that? Or stick with one-device-one-connection?
Combining into one device is how I run EtherNet/IP Scanner mode in my driver. Mainly because they have to share a UDP socket, but the convenience is worth it. (At least one host device per gateway IP address.)
IO driver ignition device would be probably expose few tags, but each devices have probably custom settings like IP address, or a slave number...
If possible you could create 2 types of devices in the driver module:
one ignition device for one profinet device
Classic ignition approach
one ignition device for multiple profinet devices with shared settings and some shared ressources in Ignition device implementation.
A sub folder per profinet device in opcua address space
Accordung to the number profinet devices, user could choice what is best suited for its use case!
The classic approach is perhaps the first to implement.
Yeah ... well ... unfortunately that pattern doesn't quite match my reality in my test lab. I've got a Wago PN bus coupler, two Adam IO modules and a Siemens Simocode Pro VPN. All devices start up without an IP. It seems that only the provisioned PN device name is persisted. Also does the contoller/master need to parametrize the device before it's able to do anything ... this is setting the network settings and the config of the device itself.
For that I have developed a driver that uses TIA portal exports (the type you get if you provision a PROFINET Software Controller and hit compile).
With this you connect via PN station name and it takes care of the rest.
So my idea would be: You hit "Scan" and get a list of devices for which configuration is available. You select the ones and the station name becomes the first level in the browse tree.
For EtherCat things are simpler (Don't have a single device that I need to configure externally yet), but very similar.
And as getting such a "Scan" dialog into the configuration UI in Ignition 8.1 would probably cost me most of the sanity left in me, I'd focus on 8.3 for that
I am fairly sure profinet or Ethercat are not a good idea for an ignition driver.
Neither of these protocols are routable, meaning all the traffic has to be on the same L2 segment, also they are timing critical, which doesn’t work with garbage collection. On top of that, there are hardware restrictions on Ethercat network cards due to driver incompatibility.
I won't discourage him. I looked at both of these myself, and only shelved the ideas due to the difficulties with raw ethernet frames in Java. If that is solved, the rest should be relatively easy.
I built the drivers and they are already fully operational ... So it's not much more work to make a module out of them. (I'm not building only Igntion modules).
I let them run on my systems and threw loads of different things at them ... I really couldn't get the connection to drop. I guess modern GCs are quite different to the old ones.
I know everyone told me to not focus on PN and EC, because java can't handle it ... turns out modern Java can absolutely perform well enough to keep connections stable.
I wouldn't go for PN class 3 (IRT) ... but my class 1 and 2 connections were rock-solid. I should probably try out how low I can get timing-wise ... currently running on a cycle time of 32ms ... 16ms worked fine too and should be more than enough for use-cases like Ignition integration.
EtherCat wise, I delayed the DC syncronisation ... first I don't have the hardware and secondly I don't know if anyone even uses that in use-cases that would make such an integration useful.
Yeah ... but I doubt you want to implement a PLC in Ignition, right?
Initially I thought it would be cool, if you could buy some PN IOs and attach them to a brown field production system to provide extra data without having to modify the machine and it's programming. And EtherCat and Profinet IOs are available in all sorts and sizes and made for the harsh conditions in Industrial automation. So no: Sticking of cheap IOT devices with arduinos or raspberry in environments they almost instantly die.
However playing around with my drivers certainly did give me the idea of playing around with building my own multi-threadded Java vPLC (just for fun)
People do this all the time with various Modbus devices, and can do it with proper I/O protocols with my EtherNet/IP driver. Having real industrial-grade I/O devices makes PLC-ish operations in Ignition practical. You just can't trust Java to have extreme low latency at all times. (And you have to write your PLC-ish code in jython.) Adding ProfiNet to the mix gives end users more options.
