From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Components

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Yep, that issue was reported by me a few months ago. If I can find the issue I'll publish a fix in the next few days.

 

Regards,

Ian K.
Software Developer
Data Ahead AG
0 Kudos
Message 81 of 104
(5,654 Views)

There is a small bug (I think) with the "Create Message Queue.vi" in that you should be able to use that VI to get the reference to the named AMC queue.  I simply modified my local version to switch off the "created new?" output to bypass the register and flush VIs when I just needed to get the reference from another VI for example.

 

For my application I am using two different AMC messengers.  One to communicate within the local process VI and one to send messages between another VI process (on same machine so no UDP etc. just the standard queues).

 

The problem with the default VI here is that it clears out the queue when sending a remote command (flush queue below) and I simply need to add a message and not interrupt that VIs current queue processing.

 

I know the expected answer is to just use the LV queue primitive, but in my design I like to denote when/where AMC is being used (and is based off TLB Prime etc.) so I think it should be added to this VI.

 

Regards

 

Create Message Queue.png

Head of Systems Integration
Carnegie Labs - Austin
Certified LabVIEW Architect
Certified TestStand Architect
0 Kudos
Message 82 of 104
(5,407 Views)

Hi! 

Could you explain me the mechanic of getting source host from the  received message? It has behaviour which I find relatively strange. I have host Windows 7 system and cRIO-9031, both connected in LAN through the router. Windows host sends message to the specified machine ( cRIO with static IP 192.168.0.5), and this machine should answer to the source host, whatever address it has. It all works fine with Windows system running programm from the IDE, I receive my packet and the correct source is seen. But wherever I try to build an executable, the receiving side can't quite identify the right source host. So message is received but could not be answered back.

For example, I configure WIN for IP1:192.168.0.1 but the target gets the source host IP2:192.168.8.65. Then target sends answer to the IP2, and I never receive it. Machines were connected directly and through the router. Both times error occured.

I've "fixed" that issue by setting constant IP for the answers (luckily I have only one windows client) and already deployed the solution. But it stills bugs me everyday.  

 

0 Kudos
Message 83 of 104
(5,215 Views)

And I have another not so interesting question.

My application uses TestStand to provide flexible automative testing functionality. In TestStand I create new queue called "Teststand" and start new Dispatcher. Starting new Dispatcher was needed for the situation wherever tests were started directly from the sequence editor, not the my own application. All functions which I use are packed to the Packed Library. 

Application runs as executable, and tests are called within IDE and it's working fine (if not considering that there should not be any IDE on that machine) . The I switch TestStand Adapter to the Run-Time, and again I can't receive answers from the target to my TS functions. In this case starting new dispatcher in the same instance twice might be (and most likely is) the problem. 

But as I mentioned in previous post I've already deployed the solution, and no longer have access to the system. So I can't test it myself. If my assumption is correct, there could possibly be only one dispatcher within single LV instance (please correct me I'm wrong). Will removing second dispatcher solve the problem? 

Thanks in advance!

 

0 Kudos
Message 84 of 104
(5,215 Views)

Hi Knoxberry!

I've tried pining a IC-3173 from my computer using the code posted earlier (Pingtest), but I only get the reply "Ping acknowledge not received."

 

Is the ping-issue fixed?

0 Kudos
Message 85 of 104
(5,060 Views)

Does anyone have any example code for using the AMC to communicate between two executables running on the same machine? 

 

It's straightforward to do this as VIs, and in general I understand the operation of the AMC.

 

But I have been messing around for hours, trying what seems like every possible configuration, to get even basic things like dispatcher ping to work across multiple EXEs on the same machine. 

 

I don't need the AMC explained in general, I just need to know the bare minimum to ping a dispatcher running within another application instance on the same machine, or send it the most simple message.

 

Thanks. 

0 Kudos
Message 86 of 104
(4,595 Views)

I don’t use the AMC library, but you should try running your two VIs as source code, but under two different projects.  This prevents any local communication between them, and may help you identify the problem.  If they can communicate between projects but not between EXEs then I can’t guess what the issue is.

0 Kudos
Message 87 of 104
(4,587 Views)

Hello,

 

in the comments of 'Asynchronous Message Communication (AMC) Library' someone said this is because of udp port number:

 

Got to work with 2 targets (exe) on the same computer  - 25.07.2010
Very interesting toolkit but it doesn't allow to pass data between two independent exe on the same computer. This is because the udp port number is fixed I guess. I hope it will be implemented in a future version.

I'm not sure if this got changed over the years, but it is a point you should look at.

 

 

UliB

0 Kudos
Message 88 of 104
(4,576 Views)

Yeah, you can now specify the UDP port number; they specifically mentioned this issue in the release notes of the relevant version.

0 Kudos
Message 89 of 104
(4,568 Views)

@drjdpowell wrote:

I don’t use the AMC library, but you should try running your two VIs as source code, but under two different projects.  This prevents any local communication between them, and may help you identify the problem.  If they can communicate between projects but not between EXEs then I can’t guess what the issue is.


Thanks for this tip. I had know idea this was true, but I can verify that it definitely is!

0 Kudos
Message 90 of 104
(4,566 Views)