Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense

Attached are the VIs saved back to LabVIEW 8.0. There will be some broken VIs when you first open the examples and library VIs as the code released on DevZone does use some newer features in LabVIEW which did not exist in LV 8.0, but these should be pretty easy to correct.

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense

The AMC Send Message and AMC Dispatcher apparently send message data by formatting to XML and parsing the resulting data via user.lib\AMC\subVIs\amc_Format XML.vi and user.lib\AMC\subVIs\amc_Parse XML.vi. It's not clear to me why the architecture makes use of XML at this level. It is true that the calling VIs don't care how this implemented--unless you are trying to send and receive characters that are normally reserved for XML, such as <> or "". Unfortunately, there does not seem to be a way to escape these special characters.

Incidentally, if you send a message that uses the special characters,

e.g. A diagnostic message such as

"" is not a valid cmd

the user.lib\AMC\AMC Send Message.vi does not throw and error or warning and the Dispatcher on the other side filters out the message and you don't see an error or warning there either.

It seems to me that the messages should be formatted in a such a way so that any kind of data can be sent through the mechanism without regard for the formatting that is done to it. i.e. I should be able to send any string value in one end and expect to get it verbatim on the receiving side.

Thanks for the feedback. I choose XML initially because I wanted an open protocol that could be easily implemented and supported in other programming languages. i.e. I want AMC to be able to communicate between LabVIEW and an application developed in C. I agree that it needs to do better error checking if the data contained in the message will cause a problem in the XML parsing. I will add this to the list for the next update and see if we can support any arbitary strings or binary objects. It may require the use of an alternate underlying transport protocol.

Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense

Thanks for your response. Since we do not have requirements for working with C code, we modified our AMC to use the LabVIEW flatten and unflatten. Thanks for making it for us and allowing it to be open source so that we can do this!