drjdpowell

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).

2 hours ago, hooovahh said:

Nope you can just drag and drop the VIM I attached to a BD and it works as expected.

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.

On September 3, 2017 at 4:25 PM, bbean said:

Is there a downside to simply flattening to the lowest LabVIEW version Messenger Library supports? 

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.

On August 29, 2017 at 6:50 PM, smithd said:

For moving to 2017, was it just VIMs on the palette? Or did you encounter actual bugs with vims in 2015?

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.

On August 29, 2017 at 6:50 PM, smithd said:

what was the reasoning behind using 15 digits

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.

On August 25, 2017 at 10:24 AM, candidus said:

Currently I see the following options:

1) User events from/to the state machine. This seems to be a quite clean
approach but means a lot of work.

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.

Here's an interesting UI trick, as an example of what one can do with "filter" events:

Problem: I like right-click menus to add lots of options to graphs, but the Users seldom discover the right-click options.   I would like an obvious menu button for the User to see, but have any click on the button open the graph menu.

Solution: put the button on the graph.  On "Mouse Down?", hide the button and make the mouse click a right click.  The Mouse Down then falls on the graph and triggers "Shortcut Menu Activation?", where I make the button visible again (the User never notices it being hidden).

Example Chart Menu Button.vi

LabVIEW 2015; controls from Flatline

I think sktthemes is a bot advertising something about photography promotion, as it just copied what I posted earlier.

Any comments on the new JSONtext library?  Bugs?  Unclear or confusing parts?  Missing functionality?

33 minutes ago, smithd said:

but it looked like the VIMs just wrapped the variant functionality

Eventually I want to expand the use of VIM features, but getting rid of the variant-to-data boilerplate is a good start.

29 minutes ago, smithd said:

I didn't dive too deep, but it looked like the VIMs just wrapped the variant functionality, so it probably wouldn't be too much of a challenge to remove the vims and just use one layer lower -- unless I missed something important.

Actually, you can just back save the entire package and use the VIMs unchanged as regular Variant-output VIs.   The only issue that forced me to use 2017 to build the package was that the VIMs wouldn’t appear on the pallets if I built in 2015.

3 hours ago, Tim_S said:

I'm back on LabVIEW 2015, so can't test it... what kind of performance does this have versus the JSON API?

Sorry for the jump to 2017, but the new VIM functionality was just too tempting.   I need to repeat a performance comparison, but here was my earlier tests.  Depends on the use case, but roughly an order of magnitude for the typical cluster to/from JSON use.

Might be something to do with the new VIMs.  I couldn’t build the package without excluding examples that used VIMs.  Did you use VIPM 2017?

And, does anyone else have this problem?

I've just added the (almost-out-of-beta) 0.8 version of JSONtext to the CR.  I have used it in real-world projects but not exercised every feature.

1 hour ago, Paracarro said:

as the 1st thing to do, it executes a "reinitialize all to default"

That's never been true, as far as I know.  The reason to use shift registers is that a local variable will involve a data copy, while a shift register does not.

On July 25, 2017 at 2:58 PM, Tim_S said:

Did you try to get ODBC working with PostgreSQL? Having some out of the box issues with that and see you posted a communication package you were working on in the other thread.

I didn’t try ODBC, as I was using pq, a dll that takes to Postgres more directly.  I would think that ODBC to Postgres would work, though.

1 hour ago, ensegre said:

I actually observed this most, while developing an Xcontrol built around a picture indicator.

That queueing behavior is a know issue with XControls, which are running even when the VI is stopped, so it may have nothing to do with the picture per se.