Hi,
Does Ignition have a native ADS communications driver for Beckhoff TwinCAT or is OPC UA the only option?
Thanks.
1 Like
I believe OPC UA is it. We run TwinCAT OPC UA on each PLC. You can also use one TwinCAT OPC UA installation to handle OPC UA for all TwinCAT PLCs at a location, though if that goes down it takes all lines down instead of one.
1 Like
@Kevin.Herron, I this on your to-do list? The outline of the protocol looks pretty straightforward. I suppose the devil is in the details…
1 Like
It’s on the radar. I hadn’t seen a complete documentation of the protocol like this until now, just bits and pieces.
I’m out of office but if this is the full spec the priority may go up.
2 Likes
It isn’t the full spec, but Beckhoff has apparently released this under an MIT license:
(:
Ok, so it isn’t quite so simple, but a full working C++ implementation is very helpful.
1 Like
Yeah I have seen that.
My understanding is they want people to use their DLL.
The readme clearly promotes it for non-Windows environments. Java is a non-Windows environment even on Windows. (:
1 Like
It is not quite necessary to use their dll. It is possible to implement the entire stack on you own. There are some references:
in python:
in javascript:
in java:
https://plc4x.apache.org/users/protocols/index.html
Perhaps integration of the PLC4X stack could provide most benefit, because of the extra drivers it provides.
1 Like
We currently use TwinCAT OPC UA to interface between the PLC and Ignition on our Beckhoff IPCs. A communications driver would be great though. Beckhoff is quickly gaining momentum in the automation sphere and we have found out (via some costly R&D) that Alan Bradley or Modicons IPC/PLCs cant perform even close to what Beckhoffs IPCs can.
1 Like
Can you share the performance differences you noted, at least for AB (I assume CpLX/CLX)?
Meh. Rockwell had (has?) a product called SoftLogix that applied the same "PLC in Windows" technology that Beckhoff pushes. It ran rings around Rockwell's flagship hardware. But you don't see it around because nobody in their right mind trusts critical 24/7/365 processes to Windows, however hardened it may be. IMNSHO.
I recommend you learn to partition your applications into the parts that need to go fast and the parts that need to be reliable. Make your process tolerate reboots of the former. (I count SCADA in the former.)
Oh, and if your R&D didn't include Rockwell's I/O and Producer/Consumer technologies, you aren't done.
1 Like
+1, I don't normally even have a continuous task anymore. It's all periodic or event driven and code placed strategically for best performance. I'd still like his take as I've heard this more than once... but, I don't see the issue.
Since few years, the PLC Runtime can use FreeBSD instead of Windows 
I’ve never used this flavour of TwinCAT.
For me the big drawback of this kind of PLC for critical process, is the lack of a redundant CPU version.
2 Likes
I would first like to caveat that I have been a long time fan of Rockwell and their products. I still program on their devices, but for some business cases, they lack. The more research I did, the more I found that they are starting to box themselves in rather than grow to market needs. At this point in my career, I have programmed on GE, AB, SE Modicons, BRX, Red-Lions, BNR, Beckhoff and a few other systems. I say that as a reference point that I have a large familiarity with products with AB and SE being my two favorites for the last 12 years…up until last year.
I used a AB CP5380, maxed out with options. It ran slower than a Raspberry Pi 4 8G. It appears that the AB CP5380 is a modified BeagleBone that is able to run Windows but not Ignition as well as other systems.
In a personal performance test that I conducted on my own, the RPI was able to process around 67000+ tags to a tag historian in Ignition Edge, no problem. Where the RPI lacked was in dynamic creation of instances but quickly caught back up. The AB system had issues with dynamic creation of instances probably because of hardware limitations. It just couldnt keep up. A lot of this is attributed to way AB interface with the hardware and limitations in hardware AB integrated into their systems.
The Beckhoff I use has an i5 quad core 2 Ghz processor with a 8 Gigs of ram or a variants of that device. You can spec out many processors including i7 or i9. With Beckhoff, you can dedicate cores, so if I want 1 core to handle TwinCat and the rest to handle Ignition, I can set it up that way. The AB does not have that option. That causes your processor to share resources with you back end and therefore compromising your processing power.
Thats just one case but there are many other cases as well. With the Beckhoff clone tool, I can copy the windows, and TC program over in about 5 minutes from one system to the other. I then change my IP address and Ignition license to match and I am done. about 10 minutes from Start to Finish. With the AB clone tool, you cant do all of that. It took me 8 hours and bricking 4 usb thumb drives to get something close to clone, and when I finally got it to work, most of the files were corrupt.
AB is a great solution for many application however with Beckhoff, I leverage .Net, C++, C#, Python, Java and many other languages to bring out some really cool programming. This changes the types of programmers we hire as well. Our programmers are full stack with automation not just one or the other. In the IoT world, this allows us to be more flexible. We have an automation group which specializes in typical ladder logic but then he have a bunch or “Hybrid” guys to bridge IT/OT every day.
AB is behind in the IT/OT world, but most then again, most Automation companies are. This was focused at AB products but I saw similar results with other products as well. I have not played with the OPTO 22 yet, so if anyone from OPTO wants to loan me a kit I can test against, I will gladly do so and send feedback
We’re getting dangerously off topic… but I will say if you are looking at cost/performance, there’s no contest. All the optimization for speed in Allen-Bradley is unnecessary in a comparatively inexpensive Beckhoff unit that will run the entire project faster than the fast task in the Allen-Bradley PLC. This makes it easy to spec a Beckhoff PLC with performance to spare rather than debating whether you need the next step up of an Allen-Bradley PLC with the corresponding budget hit.
I started with Allen-Bradley years ago and gained high proficiency with it before being introduced to Beckhoff. Allen-Bradley works and I still use it. Beckhoff makes the job easier and saves time specifying/budgeting, programming, and maintaining/updating while also reducing cost.
Rockwell/Allen-Bradley software installation and activation can be brutal. Beckhoff TwinCAT installs relatively easily–more like Ignition. My recent experience with Rockwell support has not been positive (manual readers–may as well have been robots, though a well programmed robot could pay more attention to details sent). Beckhoff support–which is free–has been far superior.
I haven’t seen any real reliability difference between Allen-Bradley and Beckhoff, The only thing that comes to mind I don’t like about Beckhoff vs. Allen-Bradley is trying to maintain Windows somewhat up-to-date on PLCs. The TwinCAT/BSD option looks interesting, though I haven’t tried it yet.
3 Likes
Do you mean the CompactLogix 5480 w/ Window 10 IoT onboard? If so, I think you missed my point.
1 Like
I will have to check to confirm the model numbers when I get back to my lab. That was just one of the systems we tested against and one I remember off the top of my head.
Hi Kevin , is still on the radar?? I have an urgent use case for ADS .
1 Like
Use Kepware or Beckhoff software. On the radar isn't on the schedule.
1 Like
Kepware does not appear to give full access to TwinCat tags, for anyone considering that option. Believe that the TC OPC-UA is your best bet.
2 Likes