LabVIEW: (Hex 0x2A) Generic Error with Network Streams (LabVIEW RT)

[Rick_CythSystems]

When using LabVIEW Network Streams connection from a host VI (Windows 11 Pro) and LabVIEW Real-Time target (sbRIO, cRIO, etc.) we encountered this super descriptive error code 🙄 when sending string + variant data as the data input cluster type.

Couldn't find anything documented about this specific error online and it was not a Network Streams specific error (Generic LabVIEW error).  But it appears to be related to trying to send a VISA resource data type along with the string data in typedef cluster.

The solution: replace the VISA resource control with a string control instead.

NS Writer data type used:

Here is the cluster being sent down thru the variant "VarData" along with a string command "Cmd":

Before

After

No clue as to what/why/how this resulted in a generic LabVIEW 42 error code, but some simple debugging/testing with other data types that were working revealed the issue here.

[Bob_Schor]

I was going to comment about not seeing your code, but you provided the answer, yourself.  According to NI, the only version of LabVIEW compatible with Windows 11 is LabVIEW 2022 Q3 (and, presumably, later versions).

Try installing LabVIEW 2018 SP1 on a Windows 10 machine, instead.

For what it is worth, I've got a LabVIEW RT routine running between a Windows 10 PC and a myRIO using LabVIEW 2019 and 2021, with 4 sets of Network Streams running between them.  A pair (Host->Target and Target->Host) channel Messages between Host and Target, while the other two stream data from Target to Host (for, among other things, spooling to disk).  Works like a charm.  [Once NI fixed a Network Stream bug that generated "We apologize for the inconvenience" error when editing Network Stream code in, I think, LabVIEW 2011, I've been using this technique in all the LabVIEW RT projects I've created].

Bob Schor

[Rick_CythSystems]

Yeah I don’t think has anything to do with windows version (and mine was on a VM as well).  Not a big enough error to go down that road to prove out lol.  At some point I will try that same data type with STM and AMC and even just the queue primitives to see if it’s a LabVIEW issue or just with using NS.

No other issues with NS and we have the connect/disconnect logic pretty solid as well for picking back up if PC or network goes down and comes back up etc.

No issues with the network streams themselves.

Thanks!