drjdpowell

I tested back-saving a significant feature that I want to add the Messenger Library, the "Graph Augment" UI stuff mention above.  Going to 2011 gave a long list of problems due to missing features (such as "Get Control Values by index"), but going to 2013 gave no error.

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011).  So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

2 hours ago, Thoric said:

What's the reason for the upgrade, there a particular feature you want to adopt that's not available in 2011? Or are you simply abandoning older LV installs on your dev machine ;-)

Bit of both.  My work code is 2015 (except for one 2013 client that I'll soon upgrade), and when I think I want to incorporate some of it into Messenger Library I am inconvenienced by the lack of some features I have used (such as the Concatenating-tunnel indexing option, or the "VI Deactivation" Event).  Spending time recoding to support LabVIEW versions that I don't intend to use doesn't make much business sense.  I don't think there is anything that 2015 has over 2013 that matters much, so I'll probably go to 2013.

BTW, did you finish your big comparison of frameworks?  If so, care to give Messenger Library a review on LVTools?

I am considering changing the LabVIEW version I develop Messenger Library in from 2011 to either 2013 or 2015.  Does this cause a problem for anybody?  Older versions would still be available through LAVA-CR.

18 minutes ago, JamesMc86 said:

Obviously if the current version could be archived somewhere just in case that would add a bit of security

Past versions are all archived on LAVA.

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

12 minutes ago, ShaunR said:

Basically. If you try and use events in "Event Driven" languages, the same way you use them in LabVIEW for 1:1. Everything falls over because the assumptions about the underlying mechanisms are incorrect. I think architectures should be language agnostic.

How do they manage not to (implicitly, at least) queue up "events" that affect a serial-access resource?  Real-world events do have time-ordering (pick up the ball, throw the ball, catch the ball) so I'd be surprised if it would be useful to be agnostic about this.  Other LabVIEW features, like parallel calls on non-reentrant subVIs or DVRs, are all implicitly queued.

On August 6, 2016 at 2:33 AM, smithd said:

Seeing the command Macro::DoSomething makes me on the inside

JKI State Machine “states” are actions that are executed internally by the loop.  Unless one deliberately calls the “idle” state, “macros” of states execute in an atomic and isolated manner.  That is not the same as sending a set of messages to another process, where you have no control over what other messages are executed intermixed with yours.  

7 hours ago, smithd said:

Do you have any additional thoughts on the pros and cons of each? It seems like if you always to the N:1 case, queues are almost always better (except UIs of course).

If a component doesn’t have a UI (including a “debug UI”), and doesn’t use DAQmx or IMAQdx (which interface with Events), and doesn't have a reason to want multiple incoming message channels (you can’t wait on multiple different Queues like you can with Event-registrations), then I often use a Queue.   Though the benefits of using a Queue are, to my mind, very minor even in that case.  Queues are slightly faster, and have extra features that I either usually don’t really need or I actively think should never be used with interprocess messages (like enqueuing on front or flushing).  

Just an aside, but I almost never use User Events as 1:N.   I use both Events and Queues as N:1 message carriers.  Each receiver creates the communication method it prefers, preloads any initial messages, and then passes it to the sender(s).  For 1:N I use arrays of these Events/Queues.

My two thoughts on this were:

1) is this actually a bug?  Having the top end of a range be exclusive is not unusual, I think (if unintuitive at first).

and

2) who uses this function?  I can’t think of a use case.

Latest version has an improved Object Cyclic Probe that uses XML flattening to display the contained data in arbitrary objects.  An example is below, where I am debugging the command pattern in the Cyth SQLite Logger:

Can I see some code?   I’m having a hard time understanding because an Error is “something goes wrong” which then needs to be handled.  If something has gone wrong with your POST response then you should already have an error, and either you pass that through Read Array.vi or you just leave the Error out of Read Array.vi unwired (since it will return an empty array).

Can you go into why you want this behavior?  An empty string is not a JSON value of any kind, so the error seems appropriate.   I can see some possible value in accepting null as being equivalent to an empty array or empty object, but why is entering nothing not an error?

8 hours ago, John Lokanis said:

Why are classes locked after running and stopping the application even though no VIs are still running?

Possibly related (if you use ACBR): https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/

19 hours ago, 3esmit said:

I'm looking for a repository to pull request, but seems like there is none (https://bitbucket.org/tcplomp/json-api-labview is 404),

It’s at https://bitbucket.org/lavag/json-api-labview now.

10 minutes ago, hooovahh said:

Yeah but what if you have more than 100 elements in a cluster...yeah...I'm not saying it won't happen, but if it does you probably have other issues that are more pressing.

The technique works up to 255, but I have yet to summon the effort to do that many cases.

On July 6, 2016 at 1:46 PM, hooovahh said:

 Oh and if you update the cluster you need to set the Cluster size in the Array to Cluster to the right number of elements, the wire will be broken if it doesn't match.  I made and XNode to do this but didn't want to add another unknown into debugging this.

In Messenger Library, under the Utility sub pallet, I have an "Array of Variants to Cluster” VI that will dynamically handle the number of elements (up to 100).  Useful in reuse code where you don’t know the specific number of elements.

On June 4, 2016 at 6:28 PM, pato7 said:

Thank you for your reply. I meant for example if I have a server with 5 sensors related to it and another server with 10 sensors related to it. Is it possible to connect these two servers or let them communicate and share data in a labview VI on the same PC? how? is there a special VI for that? can I use the "connect" Vi found at the OPC UA client palette list?

It’s unclear to me what people in this conversation are meaning by the “server”.  If the OP means a LabVIEW program that is serving up data via a created OPC server, then that same program should also be able to connect to other servers via the OPC client VIs.

LabVIEW bug would be my guess, as I don’t think those OpenG VIs use any references.

Experimenting some more.   I don’t really like either of my switch designs, as they seem too flat to identify as controllable objects.   So I’ve worked on a new one (second from the left, below).  This seems “just enough” non-flatness to aid in identifying it as a switch.

Thanks.   Is there anything you could suggest to improve things (new examples, for example)?

I don’t think you can meaningfully get a generic system, beyond a straight “front-panel manager” thing that has no concept of anything beyond front panels.  You’ve already mentioned specific concepts like “launch” and “done” and assigned Panel Close to meaning some kind of “cleanup” is required.  Any implementation of that, however done, will make your framework non-generic.  I looked into the VIBox XControl that smithd linked to, and I could not use it because it has specific assumptions and implementations of “stoping” a VI.

My own Front Panels that go in subpanels-that-look-like-tabs are a mix of Messenger-Library actors, on the one hand, and subVIs with no internal loop on the other, so no system that assumes Front Panels be “launched” or “done” can ever be generic enough for me to use.

Now you COULD do a framework for "actors with one front panel each (not necessarily AF Actors)”.

Can the User even close a VI in a subpanel?   What are you wanting an event for?

I like it, thanks.