LabVIEW
Labview and Beckhoff Twincat3 communication
Solved!
I'd go with .NET. It's the most modern form and should have some more failsafes (at least not less).
DLLs are messy and sensitive and hard to get running in my experience. If you already have wrappers for them, fine, but i've had DLLs stop working after windows updates so they're still more sensitive.
ActiveX is in between in issues. 🙂
@Yamaeda wrote:
ActiveX is in between in issues. 🙂
Well, I would disagree. ActiveX is a legacy technology, that Microsoft would rather like to discontinue if they could. 🙂
Each of the three has it's pre's and con's.
DLL, Most low level, very fast if done right, uses minimal resources compared to .Net but yes you need to understand C programming and many of its intricacies in order to be able to make a reliable LabVIEW binding. It's not hard if you know how, but very hard for casual programmers who had no in depth exposure to C programming before.
ActiveX: Legacy technology. The pre is that it comes with typelibraries that allow LabVIEW to create the interface nodes automatically so that you only need to understand how the functions work, not how you have to properly interface to them in LabVIEW. ActiveX offers no advantages to the .Net interface nowadays so I would consider it pretty useless.
Extra negative point: Due to a bug in the typelibrary for the Twincat ADS ActiveX library, the Read function does not allow to read an array but only one byte per call. So you would need to put that node in a loop to read an array of bytes. I managed to hack the typelibrary in the ActiveX DLL so that it declared the data parameter properly as byte array. But that is of course not a solution and Beckhoff never reacted to my inquiry about fixing that, which is more than 10 years ago now.
.Net: Similar to ActiveX it contains a type interface description that allows LabVIEW to create the access nodes automatically. It is the choice for people who can't or don't want to have to worry about creating the Call Library Nodes and configuring them correctly.
.Net tends to be more resource hungry and often pulls in many dependencies which makes it slower to load. That is why I prefer DLLs, but for many others the mileage certainly will vary.
@rolfk wrote:
Well, I would disagree. ActiveX is a legacy technology, that Microsoft would rather like to discontinue if they could. 🙂
Each of the three has it's pre's and con's.
DLL, Most low level,
ActiveX: Legacy technology.
.Net: Similar to ActiveX it contains a type interface description that allows LabVIEW to create the access nodes automatically.
.Net tends to be more resource hungry and often pulls in many dependencies which makes it slower to load. That is why I prefer DLLs, but for many others the mileage certainly will vary.
No, we agree. 🙂 Apart from me not saying it's a Legacy technology we're on the same page. I'm not fluent in C so i prefer .NET to DLLs. But just like i can see the beauty of assembler i wouldn't recommend it to people. 😄
@Yamaeda wrote:
No, we agree. 🙂 Apart from me not saying it's a Legacy technology we're on the same page. I'm not fluent in C so i prefer .NET to DLLs. But just like i can see the beauty of assembler i wouldn't recommend it to people. 😄
Well, at least for the TwinCAT ADS library, that bug in the typelibrary makes it pretty useless. Sure it won't crash like a badly configured Call Library Node (which my library doesn't 😀), but having to put a Read in a loop to read multiple bytes simply hurts my OCD and several other issues that I seem to have.
Nevertheless I implemented all three of them and a fourth that implements the ADS protocol on top of the native LabVIEW TCP nodes as classes with a common ancestor class with class factory that allows to select which of the 4 interfaces should be used (LabVIEW RT only allows the native TCP nodes).
That said, if you want to save yourself some headaches and don't mind to fork over some Euros, you can also checkout the Ackermann ADS library in the tools network. It seems to also implement the native TCP node approach that allows the library to run on any LabVIEW platform, not just Windows machines.
And Assembler is cool. I have a few projects where I did make use of (inline) assembly instructions for certain low level functionality.
Hi Andrew,
there is another option now available from Beckhoff if you would like to read/write variables from LabVIEW via ADS: TF3710 Interface for LabVIEW
It could make your live easier it handles the communication to the Beckhoff hardware for you, including different communication modes. LabVIEW examples are included in the installer and will pop up in the examples section.
Best regards,
Christian
@hosmo wrote:
Hi Christian,
Do I need to install TWinCAT software on the same machine, which is used for LabVIEW software development, even though TF3710 is installed?
As you can see in Chapter 2 of the linked document it states:
The TF3710 TWINCAT 3 interface for LabVIEW™ product consists of the following components:
• LabVIEW™ Virtual Instruments (VIs) for your function palette
• Product-specific dynamic-link libraries (DLLs)
• Example VIs
When installing on a system with LabVIEW™ runtime, only the DLLs are installed; otherwise, all components are installed.
So it would seem that this installer also takes care about installing the necessary runtime libraries. Most likely this is more or less the TC1000-TwinCAT ADS Runtime components.
And when you deploy a LabVIEW built application to a different computer you also have to run this installer again on that computer too.
