.NET Exception with Write Multiple.vi using opensource TwinCAT ADS Toolkit for LabVIEW

[stephaneLET]

Hello, 

I'm new to automation and plc programming, so if any of the information I provide is unclear, please feel free to correct me and explain.

I'm trying to develop a LabVIEW application to communicate with a local Beckhoff TwinCAT 3 soft-PLC using the open-source TwinCAT ADS Toolkit for LabVIEW (https://github.com/fisothemes/LabVIEW-TwinCAT-ADS ) . I'm using this toolkit because the official one isn't working well either and provides less access to the sub-VIs, which makes debugging difficult.

The main goal is to control three EPOS4 slaves. My immediate objective writing and reading from labview to the EPOS4 through the PLC,

Im trying this by writing a WORD value to an indexed element of an array variable, specifically P_Test.EPOS4_ControlWord[8]. I've also attempted this with other variable names, including simpler ones like "Statusword" or "Controlword" "EPOS4_Controlword" the whole initialisation Vi is displayed here : 

The PLC is working and diplays the info Net id etc.. so I assume the connection is not blocked by a firewall on the computer.

it's just the steps after that blocks.

For this communication, I'm using the Write Multiple.vi from the library, but I have also tried the Write.vi with the same unsuccessful result (it's the same thing but with an For structure added to it, photo attached).I did the wiring the same way 

On the TwinCAT 3 side I'v tried the PLC exemple given by the open source library (I can't send it here) also tried my own TwinCAT PLC programm. 

By what I searched it means that the VI sends a U8 and the .NET method expects a UInt 16. I used DebugView but nothing interesting on that side 

What I’ve already verified:

• Symbol name is correctly formatted and non-empty on the interface and also in the graphic view (verified with a prob) 
• The array of symbol names and the array of values both contain exactly one item
• Replacing %d with a literal value yields the same issue (also tried deleting that and using a unique EPOS4 
• Tried various values (0, 6, 15...) → same result
• Tried various names (always the same that the ones named in the PLC) () → same result

Has anyone encountered this type of error when using Write multiple.vi, or any of the sub-VIs that interface with .NET?

Could this issue be caused by a mistake on my end, or is it related to TwinCAT 3 or LabVIEW?

Are there any known limitations or special considerations when writing to indexed variables or arrays via ADS? Or more generally, when performing read/write operations to PLC symbols?

Thank you for taking the time to read through this explanation  I hope it was clear and not too lengthy.

Any insights or suggestions would be greatly appreciated.

[Walker34]

You have a null value exception on TcAdsSymbolProperty (Key ne peut pas être null).

Why is this reference null?
Is your Symbol right written? If it is a Global, you might write Global.Var123, or maybe just .Var123.

Have a try with reading first. Then writing single, then writing an array.

In your example, you are using events, isn't it? Why? You don't need events.

[Walker34]

Here is a basic example.

Can you test it on your side? By me, it runs local. Twincat is running on my computer.

[stephaneLET]

Thx a lot for your answer. Your example runs perfectly on my setup, no issue with the VI or the PLC declaration. Then I tried extending it with Write Multiple.vi, added a loop, and after some testing I found the issue (spoiler: human error).

The idea was to control three EPOS4 motors using ADS symbolic addressing in LabVIEW, formatted like this :

These are symbolic ADS paths, not arbitrary strings — they follow the standard naming from the CiA 402 profile for drives. The Format Into String node dynamically replaces %d with the target motor index (0, 1, 2…), allowing a looped structure to write to each axis individually.

The cluster sent from LabVIEW contains parameters like:

• ControlWord (WORD), value 6
• ModeOfOperation (SINT), value 1 for Profile Position Mode
  
  

Here’s the relevant declaration on the TwinCAT PLC side:

PROGRAM MAIN

VAR

   ControlWord  : ARRAY[0..2] OF WORD;

   bOutput1     AT %Q* : BOOL;

   StatusWord   : ARRAY[0..2] OF WORD;

   bOutput2     AT %Q* : BOOL;

END_VAR

At first, I thought I could directly pass formatted symbol strings for indexed array elements via Write Multiple.vi. However, ADS communication doesn’t support passing an array of symbol names and array of values in a single bulk write in this context — or more precisely, LabVIEW’s ADS implementation doesn’t resolve symbolic names dynamically like that at runtime over multiple indexed accesses.

That’s where the bug came from in the first place.(Humain arrogance makes wonders, I jsut din't think) 

But then a new question arises: Are there any other limitations in ADS writing that I'm not aware of? If I want to automate three different axes in LabVIEW, I need to do this in the PLC:

PROGRAMM test

VAR 

EPOS_ControlWord_0 : WORD;
EPOS_ControlWord_1 : WORD;
EPOS_ControlWord_2 : WORD;

EPOS_TargetPosition_0 : DINT;
EPOS_TargetPosition_1 : DINT;
EPOS_TargetPosition_2 : DINT;

EPOS_ModeOfOperation_0 : SINT;
EPOS_ModeOfOperation_1 : SINT;
EPOS_ModeOfOperation_2 : SINT;

END_VAR

It's not very clean.

Thanks again for answering in the first place.

[Walker34 · Accepted solution]

You can write an array with index, like that, without problems:

Or you can write it with a stream of bytes like that. But you have to care about array size :

[Walker34]

Or better and simple :

[stephaneLET]

Thx for the help. I'm encountering an "other" issue where the ADS port from TwinCAT 3 closes unexpectedly after a random delay.

The setup remains unchanged between runs, and the problem occurs regardless of whether the application is running in debug mode. Sometimes the connection drops after 30 seconds, other times it lasts several minutes. Initially, read and write operations succeed, but eventually the port returns an error and communication fails.

In my opinion this behavior suggests a possible buffer saturation or a limit on the TwinCAT side. I'm considering redesigning the communication to be event-driven rather than continuously polling, in order to reduce traffic and avoid flooding the port. Any insights on the cause of this instability or best practices to maintain a stable ADS connection. Thx

[rolfk]

---

@Walker34 wrote:

Or better and simple :

---

Yes, since all currently still supported LabVIEW platforms use Little Endian format, this works.

However there used to be platforms that were Big Endian: MacOS 68000 and PPC, cRIO PPC, Sun Sparc, HP Unix.

I'm still regularly working on cRIO PPC controllers although that excludes of course the use of software with .Net components. But ADS as a pure TCP/IP based protocol is fairly easily implemented in pure LabVIEW. I have my own version of such a driver but there is also a commercial toolkit from Ackermann Automation including that.

[Walker34]

Twincat ADS is a very very strong and robust protocol. I work on a project with hundreds and tousands variables. It works absolutely fine. You don’t have to close connections. Just keep it open. 

polling is not a problem. Just poll what you need when you need it, with a read. Events are not a requirement.