Named pipes Windows (OpenG implementation)

[NFB_LL]

Greetings,

I've run into a few issues with the OpenG Named Pipes implementation (by rolfk). I am unsure how much of this is due to my inexperience with pipes and how much is caused by the aging OpenG (beta) implementation.

Usage:
I want to pick up existing named pipes with LabVIEW to read data from them. Basic test case (simple example .vi from OpenG library) works (attached screenie 1).

Problem:
If I try to pick up pipe opened in separate .vi (or external to LabVIEW by third party software) I get error 42 when attempting to read it (screenie 2)

Questions:
Is there a resource to determine what the error codes cover? (I've also seen error 8, screenie 3, but only found description for error 6)
Is there reason to believe that the named pipe implementation no longer functions in Win7/LV8?

Am I butchering proper named pipe procedure and use?

Thank you in advance for your consideration!

Nicolai

[rolfk]

Pipes are point to point communication endpoints. That means you get undefined behaviour if you try to read the same pipe from multiple locations. In fact already the opening of a pipe for the same direction more than once might fail although it seems to work here (at least in screenie2), but if it wouldn't fail the Read that happens first will see the data that was sent and the rest won't see anything. You should definitely try to disable the ENTIRE Read pipe handling in your first VI in order to allow for the second VI to have any chances of working.

Error 42 is the LabVIEW error "generic error" used by the shared library when an error occurred that it doesn't specifically recognize. So that is not so helpfull when one can't go into the shared library itself to see what Windows API error happened.

Error code 8 is the LabVIEW errro code "file not found". The code tries to detect if a pipe with the name does already exist and if so it tries to connect to it. This could fail if the path to the pipe was invalid or if the pipe was opened with higher privileges than what you currently have or if it was opened by the other process for that direction already. This will generailly result in the error 8.

The OpenG Pipe library is indeed not a fully stable product. And it interfaces to a Windows part that is somewhat unknown and not so often used, and Microsoft is continously changing small parts of its implementation so that the library may indeed stumble over subtle changes in Windows over the time. Principially there shouldn't be any reason that it couldn't work in even Windows 8 since Pipes are a mechanisme that is used by many Windows components quite extensively it's just a little known feature for non-Microsoft applications and its semantics (details of operation) look a bit weird to the casual programmer. It originally (Windows NT) was trying to mimic the Posix standard but having been always different enough to what the normal Unix way of how pipes work is.

[NFB_LL]

Hi Rolf,

Thank you for the feedback. While your response makes me a little worried that it's server side (in my 3rd party software) that my trouble arise, I would like to understand what I'm missing regarding implementing a test case in LabVIEW. In Screenie 4 is a functional implementation of the read/write. The loop simply checks if anything was read and exits if yes. The booleans are used to determine whether the .vi is a reader, writer or reader/writer. Screenie 4 shows the reader/writer case. In Screenie 5, I am running a reader (readloopPipe.vi) and a writer (writeloopPipe.vi) simulatanously. 

But I am not picking anything up written to Test2 pipe. Perhaps this is a lack of understanding about the difference between client and server for pipes and whether that needs to be configured? The MSDN clearly states that named pipes allow for "communication between the pipe server and one or more pipe clients" (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx), but I am unsure I have any actual "servers" involved here, unless "writing" automatically defines you as the server. 

Concerning my worry about my 3rd party software, it appears as if when I start the 3rd party server, I can read from it only once (using readloopPipe.vi). Attempting to read or write it again gives error 42 until I reboot server. As this doesn't happen when I run pure LabVIEW test case (reader/writer), the implication I believe is that I must keep the pipe open from first connection and until I can argue for rebooting server software.

Thanks again for your time. 

[rolfk · Accepted solution]

It's not trivial to debug pipes. They do behave at times a little strange and I haven't really figured out where the problem lays. Sometimes they seem to miss the first data element that was sent which is the sole reason that I never went to the point of releasing the software and making an official OpenG package from. They worked fine for what I needed to do and nobody else with enough knowledge on the C side seemed interested enough to do more testing so I left it at that.

I'm wondering in your 5th case if you might have a timing issue.The fact that you run everything in one VI or in two seperate VIs really shouldn''t make any difference at all (provided you do use the same pipe name of course). You might want to use a timeout on the Read function to avoid it running through the 10 attempts you allow before the loop stops.

[NFB_LL]

Hi Rolf,

I thought I'd tested for it being a timing issue, but with you also thinking of that, I tried some more. I was able to once get the text read out (luck of the draw) and decided that's all the proof I need. I'll mark this question as answered and post a new thread concerning formating of commands sent through the pipe (write). 

Many thanks once more,

Nicolai

[ValeoGuy]

Hi,

I am looking for the link for the OpenG Toolkit for Windows Named Pipes please.

Kind regards

Rob C

[AaronTheAE]

After looking around I believe this is the closest link to what you were looking for: http://opengtoolkit.cvs.sourceforge.net/viewvc/opengtoolkit/pipe/

[ValeoGuy]

Super Star 

Thanks

Rob C

[AaronTheAE]

No problem! 

Good luck with your application!

[croohcifer]

I realize this is a very old thread, but for anyone who wants to do this in the future, there is a .NET API for it that JKI has conveniently already wrapped for use in LabVIEW: https://www.vipm.io/package/jki_lib_dotnet_system_exec/