Can you provide some basic set of steps to follow to setup the example for multiple targets on two PC over Ethernet. Including enough detail to known if it needs to be built into an .exe and I do or don't need labview development environment on both pcs. What ip address to use and do I need to configure a port number. what gets started first and is there a separate PC for collecting the messages and reading the queue or queues. What vi runs where and when. this could just be a few sentences probably.
Thank you for your time!
After experimenting with AMC there was to much over head for what I was trying to do so I abandoned that method and went and used the UDP set of icons. One of things that I could not understand was what is a key and what is a value. I read as much of the manuals that I could find. Also what is a Message value. This was not defined any where. Looks like a great method if I could understand what the inputs were. Thank you for your response.
I am using the AMC to drive an application with a main loop that talks to a vi using AMC, this vi is reentrant and has 30 clones in memory. When the appliction is running i have very low CPU usage but when I try to edit and save or even start the top level vi i have to wait for LabVIEW to respond for upwards of 5 minutes. Can you think of any reason for this to be caused by using AMC in reentrant vi's? Im starting to grasp at straws.
What happens when I am using AMC and UDP decides to drop one of my commands to a target? UDP does not guarantee a message will arrive at any specified target. Is there a TCP version of AMC?
After experimenting with AMC, I find the same results as reported earlier:
AMC does not work for communicating between two executables on the same computer.
It will work for two processes running under the same executable on the same computer (using Local Process example)
It will work for two executables on two separate computers (using Multiple Targets example)
I have an application that has a server executable that is headless and runs 24/7 whenever the computer is booted. The multiple client executables run when desired and display information from the server executable. I cannot get AMC to work in this application because the client executables may be running on either the same computer as the server executable, or on a remote computer.
Does anyone know how to make AMC work in this application? Or is there another supported framework that I should use?
The issue with two executables is that each EXE is considered a separate LabVIEW application instance. It is basically the same as running the LabVIEW development environment twice, with each one hosting one of your projects/applications. In this case LabVIEW can not use named queues (which is what AMC uses under the hood) to share messages between processes in your different applications. In this scenario you need to treat your two applications as if they were running on two separate machines.
However, the second problem then will be that the AMC dispatcher in each application instance can not use the same UDP port to receive message. So you will need to update the AMC Dispatcher to be able to change its UDP port in one of the applications. In amc_UDP Port.vi you will need to pass a different UDP port number to the UDP functions in one of your application instances. In the other application instance you will need to use this different UDP port number when sending messages over UDP in amc_Send Message over UDP.vi.
We are planning ion adding this change to the 'official' AMC version, but do not have a specific date for when this will become available.
Talking about formats, I want to share with you a bug that a customer found a few months ago. Here is the description of the problem:
We are reading from a numeric in the front panel, then we are converting this numeric to string and send it along the message (using the field value). We are reading this numeric, then we are converting it to string with the function Flatten to String. Then we are creating the message with AMC Create Message.vi and sending this string that represents our numeric. Then the message is sent with AMC send message.
To receive the message we use AMC Read Next Message. The message does not arrive at this point if the content of the message is the string that represents the value 9 or 30 (double).
I forward also a simple .vi that reproduces this behavior: when the number to send is set either to 9 or 30, the indicator that shows the received number does not update. Inside the cluster the representation is double, so we don't receive anything. The other numeric has a representation of single precision, and we see that all the values are sent ok. We found this workaround, to change the numeric type of the data, but that was a bit annoying for our customer application and we ask you to see if there could be a fix to this bug.
this is because AMC uses XML to send messages over UDP.
A XML message looks like: <amcmessage name="Numerico" value="@ " receiver="Process1"/>
If a string inside "" contains a XML Character like " or > scanning of the message will fail.
A double value of 9 will be flattened to @" and a double value of 30 will be flattened to @>, so in both cases scanning fails.
This was discussed earlier in this thread in messages 8 to 10 by wireman and Christian L.
Another workaround would be to use another number/string conversion function.
Hello, I checked all the messages and this question wasn't listed. It's an easy one I hope.
I have a program running using AMC functions to communicate with a cRIO on the local network. I want to also send messages to a cRIO on an external network but so far this has not been successful. I suspect that I need to forward an additional port on the remote cRIO's router because its shared variables work fine. Also the Distributed Systems manager can see it.
So, what port should I enable for AMC to send messages to the remote device? I am using Labview 2012.
Dave Clark CLD
The latest version of the AMC Library (220.127.116.11) is now available on the LabVIEW Tools Network repository. You can install it through VI Package Manager by clicking Here. It is compatible with LabVIEW 2009 or later.
The newest version of AMC is not code compatible with earlier versions (2.x or earlier). If you have code that was written with an earlier version of AMC, installing the latest version will break your code until you manually relink to all AMC sub VIs. You can still download the previous version (2.1.4) of AMC here if you do not wish to upgrade to the latest version.