Using Microsoft Message Queues (MSMQ) with LabVIEW

[P.C._Lindsey]

Brian:

I'm currently working with LabVIEW 7 so I can't open your VI.

I'm beginning to think that that I'm going to have to upgrade to LabVIEW 8. I understand that the .NET Class - "Message" should cause the invoke node that it is wired to show the Method "Object" that will then let me select the property "To String". However, that doesn't seem to work in LabVIEW 7 and I haven't been able to find an "Object" Method in any of the other Classes of .NET that I can access.

Thanks for your help.

P.C.

[Coal_Man]

P.C.

It sounds like you have the .NET 2.0 framework installed.  Unfortunately, as some people have discovered, LabVIEW 7 is not compatible with .NET 2.0. This has to do with the fact that Microsoft has completely redesigned the way the framework is installed (specifically the GAC) and this has broken the code that provides you with the list of installed assemblies.  This would be the reason that you can't see any of the property nodes or invoke nodes for that particular class. The workaround for this problem is to not install .NET 2.0 or use a newer version of LabVIEW, such as 8.2.1.  Even if you have not manually installed .NET 2.0, it has probably been installed on the system as part of another application that requires the .NET 2.0 framework.

[P.C._Lindsey]

I have installed LabVIEW 8.5 and NI-DAQmax 8.6 on my computer. I am using
Windows XP. I have both .Net 1.1 and .Net 2.0.

I am attaching the send and receive VIs that I am using. When I run the
send VI, I can see that I have successfully put a message in the Message Queue.
However, when I try to read from the Message Queue, I get the error message
that I have attached.

Has anyone seen this problem and knows a solution?

Thanks,

[Jason_Whaylen]

P.C.,

Here are a few things I have found that cause this error code.  I would verify that you have this identical structure.

From a KnowledgeBase I found to resolve this error, try the following:

• Make sure you saved the VI in the same directory as the .NET assembly.
• Add the .NET assembly as a reference to LabVIEW

In LabVIEW 8.5 however the second half of this is inherent in the creation.  Let me know if you have tried this and are still experiencing problems.

Jason Whaylen

Applications Engineer - National Instruments

[P.C._Lindsey]

Jason:

Thanks for your response.

 I have moved the entire Microsoft .NET folder into the LabVIEW 8.5 folder. I have also moved both the .NET 1.1 and the .NET 2.0 folders into the LabVIEW 8.5 folder.

 I have written a configuration file to specify that I am using .NET 1.1 and a configuration file for .NET 2.0 and put each, in turn, in the LabVIEW 8.5 folder.

I can see the dialog box indicating that the DLLs are loading when I open the MSMQ Send and the MSMQ Receive VIs. I can successfully send a message to Message Queue. The problem occurs in the MSMQ Receive VI when the data flow reaches the property node "Message" with the property "Body". I get the error message when this property node starts to run. If I check back in Computer Management, I see that the message has been removed from the Message Queue before the data flow enters this property node. This would suggest to me that the problem is not in addressing Message Queue, but in finding a way to get the message from the Message Queue format to a string that my program can use.

Can you run the two VIs that I attached to my last posting on your computer to see if they work there?

Do you have any other ideas I can try?

Thanks,

[JonathanN]

HI P.C. Lindsey,
 
I just saw this post and thought I might chime in here.
 
First off, you don’t need to move those folders you mentioned into the LabVIEW 8.5 folder. I am not sure which KnowledgeBase Jason was referring to, but the requirement for placing your .NET assemblies in the same folder as your top-level VI is no longer valid in LabVIEW 8.0 and later.  This was a requirement for LabVIEW 7.x because we created an AppDomain for each top-level VI. In LabVIEW 8.0 and later, we create separate AppDomains for LabVIEW projects and thus it’s recommended that any VI that uses .NET assemblies be part of a LabVIEW project.  Additionally, you will want to put any private .NET assemblies you are using in the LabVIEW project directory or any of its subdirectories. As a side note, we also store the relative path to the .NET assemblies (for non-GAC assemblies) inside the VI so we do attempt to locate the assembly that way as well if needed.
 
Now in your case, you don’t have to worry about placing .NET assemblies in the project directory because you are referencing assemblies that live in the GAC.
 
To address your real question, by default when an instance of the MessageQueue is created, an instance of XmlMessageFormatter is created for you and it is associated with the MessageQueue. By default, the XmlMessageFormater instance can be used to write to the queue, but it cannot be used to read from the queue until you set the TargetTypeNames property on the formatter. To do this, I created a new instance of the formatter and set that value automatically by passing them as arguments to the constructor.

Basically, the C# code that you will be doing would be something like:

 myQueue.Formatter = new XmlMessageFormatter(new Type[] {typeof(String)});

I have attached an image that shows how to do this in LabVIEW. I tested the VIs out with my new addition and it worked fine.

Best Regards,

[P.C._Lindsey]

Jonathan:

Thanks for your suggestions.

Can you either tell me where to find the Invoke Node "Type" or attach a copy of your VI to your reply rather than the image of the VI.

Thanks,

[JonathanN]

Hi P.C. Lindsey,

The GetType method I am using is a static method associated with System.Type class. It is found in the mscorlib assembly under the System namespace. I have attached the updated MSMQ Receive.vi.

Best Regards,

[PJS]

This has been kinda dormant awhile, but I have attached the complete receive VI with the slight enhancement of a timeout on the read.  NOTE: Even if an error is input into the read method, the VI will hang if there is no message in the queue.  Hey, don't shoot the messenger.  But with the Send VI above, those that wish to use this will be set.

NOTE:  For more advance intercomputer Non-active directory usage, there is a bit of a learning curve to overcome.