drjdpowell

Is any early adopter using the “From JSON Text.vi” polymorphic vi (or its individual instances)? I want to completely deprecate those in favor of only using the “From JSON text.vim” malleable VI. Also, is anyone using any off-palette subVIs? Because I’m about to reorganize them and make them all private.

How about these? New Flatline mods.vi

Try from different site. —> uploading images works. So it must be something to do with my home internet connection.

Test from different computer. Both are Macs; I've also tried a Windows 7 in a VM. Seems to be the same issues.

“Messages” on LAVA also does not work (no error; just no message recorded as being sent).

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