Cluster to C style struct formatting (Named pipes (Windows), OpenG implementation), best/correct approach?

[NFB_LL]

Greetings, 

I am attempting to send commands to 3rd party software through named pipes (Windows). The 3rd party software sets up the named pipes for me so this approach must be used. The 3rd party software subsequently returns data to me through a separate set of named pipes. The command pipe accepts the following structure as an input:

typedef struct _pipe_CMD

{

WORD wCMD

BYTE bYte[2]

} PIPE_CMD;

An example command has the following values:

wCMD = PIPE_CMD_EXAMPLE 

bYte[0] = 0x0001

bYte[1] = 0

Similarly, the output pipe returns the following structure:

typedef struct _PIPE_OUT_PUT

{

double x

double y

double z

} PIPE_OUT_PUT

Question:

What is the best/correct way to imitate the typedef structure above in/from LabVIEW? Note that the named pipe (OpenG implementation) for Windows takes string as input (and similarly returns a string output). 

In the below attempts, I am using a named pipe created by LabVIEW to test what can be read after I write my command to the named pipe. At this point in time, I have not been able to get the 3rd party software to respond to any of these commands, when I address the command named pipe and listen on the output named pipe, but I can successfully tap a named pipe providing house-keeping information (read-only). 

Attempt 1: Typecasting

See Screenie 1. I cast each of the values to a string and concatenate it for sending through the named pipe. One of the problems here is that I believe type casting 0 creates a NULL character, which is not the intention. The other problem is that I can't actually get the 3rd party software to acknowledge I sent a command!

Attempt 2: Flatten cluster to string

See Screenie 2: I create a cluster and flatten it to a string to send it through the named pipe. Here a number of unrepresented characters are apparent in the output. Again, I fear that these are not representative of what I seek to send (i.e. wCmd and bYte[2]). Again, no acknowledgement from the 3rd party software that I sent a command.

Thoughts:

Do I need to modify the named pipe call library function node to accept clusters/structs to send what I want? Will this break something else down the line? My attempt returned "gibberish" (Screenie 3), but the same "gibberish" regardless of whether I used method 1 or 2 from above, indicating that perhaps I just don't know how to read what is returned? (Could be saying "You fool, stop that")

Many thanks in advance for any feedback!

Nicolai

[rkm44]

Hi NFB_LLNL,

What 3rd party software are you using? Have you tried taking the elements out of the cluster and working with them individually? There are ways to unbundle a cluster by name, but this method will only get the name of the element, not the value contained in it. This can be seen here: http://digital.ni.com/public.nsf/allkb/5241204E2FB8F3C586256D19004F6599?OpenDocument

Thank you for contacting NI!

[NFB_LL]

Hi Rachel,

I believe my primary problem is sending something that the named pipe will recognize as being a word/byte/byte structure, particularly since the .vi's I'm using (OpenG named pipe implementation for Windows by rolfk) only accept "strings". The question of parsing what I receive is not so pressing yet, as, due to my inability to tell the 3rd party software to send me data, I have yet to even see how the data (a double/double/double/double structure) looks when it is returned. (I have, on a different pipe, received simple string based data letting me know that the 3rd party software is running). 

I believe this puts my quandry primarily on the shoulders of people familiar with named pipes in Windows and LabVIEW. And opens up for my pleading to have NI implement and support named pipes in Windows!

Unfortunately, I cannot disclose the 3rd party software. 

Nicolai

[nathand · Accepted solution]

If your named pipes are passing binary data - and it appears that they are - then you should not expect to get an ASCII string back. You also need to be sending binary data. The wCMD parameter is a WORD (2 bytes, or 16 bits) - so why are you sending 15 bytes (the length of PIPE_CMD_EXAMPLE)? Also, since the data is a fixed-size 2-element array, it would be better to use a 2-element cluster for the Byte element, and not a LabVIEW array. That will flatten correctly, whereas an array may not (depending on whether you set the flag to prepend array size). For the data you read back, you'll need to unflatten it into a cluster of 3 double-precision values, and there's a possibility you'll need to reverse the byte order of each element to get the correct values.

[rolfk · Accepted solution]

You want to do something like this:

Since your server application is a Windows app, it's likely that it transmits the binary data in little-endian format, but you need to make sure. The PIPE_COMMAND_EXAMPLE must be a C define that maps to a number! You have to search in the description what number that is and insert them in the ring control accordingly. The protocol expects the number as binary formatted number, not a string.

In LabVIEW Strings are so far simply a byte array but the controls have special features to display that byte array in different formats. Strings were the common way to represent stream interfaces, independent if they represent ASCII or binary data. This is most likely going to change in future versions of LabVIEW as Strings are at some point going to support Unicode and then a Character is not equal to a Byte anymore. But for now you need to live with what is there and the OpenG Pipe VIs were created over 10 years ago using the same principles as used through VISA, File IO and similar functions in LabVIEW, which also use Strings for binary data.

[NFB_LL]

Hello,

Some great info here, thanks all for the feedback. In the end, the named pipes have proven too unstable to use for the application and we've decided, for now, to use a collaborator's Visual Basic server to handle the named pipes and have the VB throw everything relevant into (and accept commands from) a TCP connection. 

Given deadlines, this is acceptable for now, but I may return at a later date to investigate more indepth if the named pipes can be used. Specifically, we had issues with the buffer not clearing completely/fast enough, closing the pipe (in LV) resulting in it no longer being available from outside the 3rd party software and properly flattening the command cluster. The last item I think is just a matter of throwing some thought into it, but the two former I already wrestled with much more than I would have prefered. 

Thanks again. I'll try to accept both answers as solution.

Nicolai