drjdpowell

Took me 7 goes to post that last reply.

I get "There was a problem uploading the file.” Though in trying it just now, to get the exact message, I managed to load one image (but only one, then it failed again). With replying, it just does nothing, except the “Submit Reply” button says “Saving...” for a moment.

Used to have to do that. Now even that only works about one time in 5.

Both. And I’ve tried multiple browsers.

Does anyone else have problems uploading files to LAVA? I just get an error message.

That’s not my understanding, but I don’t have a device to hand to check it, so I might be wrong.

A thread-blocking operation. Both options are blocking operations as far as the LabVIEW code is concerned.

It’s not likely to be related to the Async Calls, per se, as those don’t have anything to do with threads (async-called VIs run on the same threads as all other subVI calls).

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.