Queued Message Handler (QMH) and Asynchronous Message Communication (AMC) Reference Library

[marshaul]

Thanks to that tip making it WAY easier to mess around, I finally figured it out. 

My current application is a strict consumer-producer architecture, so I was using that in my simple test program as well. On a lark, I tried replacing the "Start Dispatcher" vi with the static "UDP Dispatcher", which, it turns out, usefully provides a front panel indicating its status, messages received, etc. From this, I was able to see that the consumer dispatcher was receiving ping requests when the target was either "localhost" or my local subnet IP, or my computer's proper hostname, and yet in none of these cases was the producer receiving the ACK. 

Thus it dawned on me: you need a dispatcher running on BOTH ends, each using a separate UDP port.

On the other hand, it's quite flexible with the "receiver host" parameter. I hope this helps anyone trying to figure all this out. 

[marshaul]

Sorry to post multiple times, but post editing seems to be disabled after a few minutes.

So, I can definitely do basic stuff like ping and confirm the existence of queues across application instances, but I cannot seem to get the "Send Network Message" vi to work. From what I understand, if I give it a queue input, that message will be put into that (local) queue. To send messages actually over the network, I need to instead give it inputs on "receiver host", "receiver port", and "receiver process". (Although I'm not even 100% certain that I should leave the message queue input unpopulated, as looking at the source code of things like the ping VI, this is used even remotely. )

The first two I have nailed down due to the previous experiments, but it's not especially well documented otherwise. What exactly defines the "receiver process" string for a built executable? What about a vi running within labview? I've tried most of the possibilities/permutations which are obvious, but so far nothing.

Also, it's also not explicitly documented which receiver-end queue I should be reading when sending messages over the network. It appears that the dispatcher creates at least two queues (AMC_Dispatch and dispatchwait:), though neither of these seem to work (though with the additional uncontrolled variable of "receiver process" name I can't say for certain). 

So, I still have too many degrees of freedom (uncontrolled variables) for me to figure this out, and the documentation is frankly only complete for local use. 

Does anyone have any example code for using "Send network message" properly, or can they at least answer the above-mentioned two points of confusion definitively? 

[marshaul]

OK, so evidently the correct receiver "process" is AMC_Dispatch. This isn't even sort of obvious to me (nor is it documented; I had to play around with the sub-VIs to learn this). 

I have what I need so I will stop blowing up this thread with excessive posts :).

If anyone continues to have trouble with this and can't follow my several posts on the subject, feel free to PM me and I'll share my example code. 

[DLClark]

I don't mind staying public for a bit longer.

I made a test project using the AMC functions and it does have some odd behavior when sending message between independently running VIs. Whichever program starts first can send a message but the second one to start cannot. Also, if I tell the dispatcher to pick its own port number both program pick the same number unless I stop one and restart it. I am using localhost as the host and the queue name for the process. AMC_Dispatch didn't work. The final version prints the actual port to the front panel then I manually copy that to the other program. I thought the addition of the port input on the dispatch function was supposed to fix this.

[manoloco]

Hello, DLClark: I 'm working with LV 2014, so could you please send TestAsync.zip for my LV version? ( I use AMC in my projects with bidirectionnal communications beetween independants VIs and all work fine!). So, i can correct your test project.

Regards

[DLClark]

Hello manoloco,

I can send the test program in LV14 to you if you'd like to see it but I believe my problem is solved for now. In fact the TestAsync program is working fine as long as I keep track of port numbers.

Thanks for your offer of help though.

Dave

[marshaul]

---

@DLClark wrote:

I am using localhost as the host and the queue name for the process. AMC_Dispatch didn't work. The final version prints the actual port to the front panel then I manually copy that to the other program. I thought the addition of the port input on the dispatch function was supposed to fix this.

---

So my program (described above) suddenly failed to operate when I moved it to the destination computer. I messed around, trying everything, until I saw this post. Using "localhost" as the queue name resolved the issue, and it still works with this change on my development computer.

On the one hand I'm glad to have discovered this, on the other hand the more I use the AMC library, the less comfortable I become with its use. So much of this is entirely undocumented, with underlying functionality buried across a slew of sub-VIs at varying depths, each new step as undocumented and uncommented as the previous. And so many of these results seem completely illogical. At this point I seriously expect that next time one of this sort of error comes up I will revert to using the core UDP VIs and try to implement a async message dispatch/handling myself. I hate to say it, but it's nearly impossible to imagine a worse implementation from the end user's perspective. 

[marshaul]

Well, I attempted to deploy the version using "localhost" as the queue name on the actual target PC, and it still doesn't work. Here is the status on the 3 PCs I've tested my program on:

PC 1: works with either "localhost" or "AMC_Dispatch" as the queue name.

PC 2: Only works with "localhost" as the queue name.

PC 3: Doesn't work in either case.

Now, it may be that PC 3 has some other configuration problem which is outside my awareness/control. But the inexplicable and undocumented difference between PCs 1 and 2 remains, along with the fact that the only error thrown during any of this is the one I generate upon the producer's failure to receive ACK. 

At this point I feel that I have no choice but to abandon any attempts to use the AMC (and by extension the QMH) in our applications. Which is a shame, because Labview really needs this sort of functionality.

[DLClark]

#marshaul 

When you refer to PC1, PC2, PC3 do you mean that you are sending messages from one PC to the another? This design works very well for me. Or do you send messages from one process to another on the same PC? What is your exact arrangement for this application?

I use AMC and TLB' exclusively in my projects so I depend on everything to work and so far it has. Maybe we can find a solution and you won't have to create your own messaging system.

Regards,

Dave

[Larry_Kubier]

I am running LabVIEW 2015 (32-bit & 64-bit) on a PXI Chassis that is not networked, and is not allowed on my network.  I am looking for a downloadable version of NI AMC reference library to install on this machine for code development.  Where can I find it?