drjdpowell

FYI: the Issue Tracker for Messenger Library is on Bitbucket. Users are welcome to comment.

Yes. I changed that (in Dec, 2014, I see). I found it caused problems in some cases, where I would send a message to change a state value, the change would be rejected, but no message would come back to reset the control (this is the Controller-Model-View technique).

The honest answer is that the work projects I have don’t use network communication, and so I haven’t had the time to add features. Although I do want to keep things simple. I think people are too quick to try and build complexity into the “middle layers” of communication (and too quick to work against TCP, rather than with it). Ultimately, the Application layer needs to be able to address unreliable communication, as only it knows what a communication interruption requires. My plans for further development of the TCP Messengers involves adding the ability to register with RemoteTCPMessenger for TCP-related notifications, in particular a “Disconnected” event. The server side would have notification like “Number of Clients Connected”. I could build a “ping” system into that, with notifications if the ping time increased beyond some threshold. Then the Application can be informed of any problems, and choose to act on this. However, if you really need reliability, you need to implement it at the Application level. Just because a message has been successfully delivered does not mean it has been handled correctly. Only a Reply message saying “Job done, results saved to database” tells you your message was handled.

Try this version. See the TCP Example "Test Client with Async connection. It will poll waiting for TestServer to start. Also uses a Watchdog to identify when the Server shuts down. I found and fixed another issue (Issue #6 on bitbucket), so I'd like you to test it before I put this in the CR. drjdpowell_lib_messenging-1.9.1.88.vip

A favour to ask: Can all you guys who use Messenger Library give me a quick review on the Tools Network? I only have a single review (thanks "burd from berkeley"), whereas the DQMH has 15!!!

I just confirmed I can build in 2017, no problem. I suggest you try uninstalling then reinstalling Messenger Library using VIPM. And try build options like "Use Fast File Format".

I'm working in 2017 and building EXEs, so it can't be a fundamental problem. Have you created any custom Async Actions? And what version of Messenger Library are you running?

Question: is anybody using Messenger Library in a LabVIEW version before 2013? I would like to move up from 2011.

Sadly, NI has removed the ability for me to repair any NI installation. I’m not happy.

Fantastic idea! That worked. LabVIEW 2017 now opens. Why was I searching through that folder for suspicious items when I could nuke the whole thing?

Thanks, I got those caches. New symptom: MAX wont start either (just hangs and the splash screen). Earlier version of LabVIEW (2015) works fine.

Has anyone ever had a problem with LabVIEW crashing on start even after you reinstalled LabVIEW (and tried Windows System Restore to revert to a point before the problem happened)? I believe there must be some corrupt file somewhere; I've tried manually deleting the compiled-code cache and the LabVIEW INI file but to no effect. Can anyone think of any other file that LabVIEW might read on startup? Where does LabVIEW save the backup copies of VIs (that, after a crash, it asks you if you want to recover)? I think it could be that. Crossposted on NI.com

Is the NI Service Locator not running on the remote machine? When I run the example Clients with no Server running, they quickly return error 1510: "The requested service was not found as a registered service with the NI Service Locator.” The problem you’re having is because the TCP Client actor is launched as an “Autoshutdown slave”, meaning it will shut itself down when it’s caller dies. See below. As the caller is your short-lived Async Action, it shuts down immediately. However, you don’t need an Async Action, as you already have an async actor (“TCP Client”). You just need an async Request-Reply instead of the sync Query currently used in RemoteTCPMessenger:Create.vi (see below). Replace the Query with a Send, and supply your own Reply Address. The TCP Client Actor will send you a reply (containing the string “connected” if it was successful, or an Error Message if it isn't). You can then decide to restart it if it failed to connect, or start sending messages if it did connect. Let me know if this works, and I’ll make a Messenger-Library addition of an async way to start the RemoteTCPMessenger (I would do it in a slightly more complex way, where the RemoteTCPMessenger is returned in the Reply message, so there is no way to send it messages before it’s connected).

I had the INI key. I eventually found that I had to have the VIM in user.lib/macros, and drop the VIM from the palettes (dragging from the project or other source doesn't activate the VIM feature). Having to save in user.lib is very problematic, so I am not going to back save JSONtext to 2015.

I don't seem to have this problem, but I always use "Edit Items..." and I'm careful to only make one change at once (rename one thing; or move one thing; don't ever rename and move).

Can’t seem to get it to work; must be missing something.

Added a new version 1.8.4.85 to the Code Repository. Tested that this works between 2011 and 2017 using the TCP Client/Server example that comes with the library (with either side being the Server or Client). The TCP Connection and TCP Client actors now send an initial message to each other containing a flattened variant, and they each determine if the other is running an older LabVIEW version (if so, they use bean’s fix from above). Note that this only affects the VariantMessage class. If you flatten Objects containing Variants then this won’t work, and I don’t know what happens if your VariantMessage contains a cluster that contains nested Variants. Please report any such problems, and we can look into a solution. Personally, I don’t tend to use Variants internally to other data structures, but I know others do. Also note that both sides of the connection will need to be running this latest Messenger-Library version, otherwise the initial exchange of version messages will fail.

Hooovahh, Doesn’t VIMs in 2015 require the VIMs to be saved in User.lib?

But is JSON a serialization format for IEEE floating-point binary numbers? Or is it a decimal notation format for data that can be used as interchange between programs (or humans) that are not necessarily using IEEE numbers? My humans are going to be annoyed that the number 0.6 they intended is saved as 0.59999999999999998.

Although strict-typing is a valid reason to argue for separate User Events for each “message”, the freedom to Register selectively for messages is something that can be achieved in other ways. The “ObserverRegister” in “Messenger Library” allows selective registration. Also the flip side of the advantages of strict-typing are the advantages of being able to write generic code.

There must be something, otherwise why up-rev the format with each version? Anyway, I’m thinking of having the the two TCP communication actors exchange two initial messages to tell the LabVIEW versions they are each running in, then have each use the lowest version for flattening. Then they will use the highest version available to both sides. If that is too much work I could just set the version used to 2011.

In 2015, the “VIMs” just worked as regular Variant-typed VIs. You would have to use Variant-to-Data primitives to convert to desired type. As in the wiki, beyond 15 digits not every decimal number has a IEEE 754 representation.

I'm thinking of modifying the TCP Messengers to optionally accept a LabVIEW version for use in flattening. Then you can set whatever version you need.

Hi guys, I'm on holiday this week, sans LabVIEW, so I can't help. But question: is there a way to flatten to an older version of LabVIEW? So tell 2016 to flatten to 2014 format? I vaguely recall reading this. If so, we should be able to make usingly an older format an options, allowing communication with an older version of LabVIEW.

Note that there are two schools-of-thought on how to use User Events. One is to have a separate custom Event for every different message (about 40 in your case). For examples of this see the DQMH or JKI’s “State Machine Objects”. These rely on scripting tools to manage all the custom subVis that need to be generated. The other school is to use a single User Event to carry all messages, using something generic like a string “message label” and a Variant “data” payload. “Messenger Library”, if you look under the LVOOP hood, is basically this. At its simplest, you can do this later method with only a single “Send Message” subVI (with “label” and “data” inputs) that you place everywhere you were previously setting a control. So this is not a lot of work, or at least, not more than any other possible method.