12-26-2008 03:16 PM - edited 07-23-2009 10:18 AM
Please post your questions, feedback, and comments on the Queue Message Handler and Asynchronous Message Communication reference library here.
02-20-2009 10:20 AM - edited 02-20-2009 10:23 AM
Could you outline for me what it would take to publish the QMH for other platforms? I have attached an OpenG package that can be used with VIPM (at least on Windows).
You need to rename the attached ZIP file to "nise_lib_qmh-1.0.7-1.ogp" as DevZone currently does not allow *.ogp files.
07-28-2009 04:24 PM
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.
02-18-2010 04:58 PM
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.
03-04-2010 10:17 AM
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.
03-04-2010 12:56 PM
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!