bbean

what kind of hardware is the application running on ?  eg desktops, rackmount computers, pxi racks?

Question regarding the Notify (state).vi in the Observer Register Palette.  Underneath the hood, the code looks like its sending a message every call (vs only when the data changes).  Is that correct?

9 hours ago, drjdpowell said:

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.

Ok makes sense..

I had some more time to test today.  I tested the following and they seemed to work:

TestClient with Async connection.vi (LV2014)--->LAN--->TestServer.vi (LV2014)

TestClient with Async connection.vi (LV2014)--->LAN--->TestServer.vi (LV2016)

TestClient with Async connection.vi (LV2016)--->LAN--->TestServer.vi (LV2014)

One potential "bug" in the package.  When I click "Show Example" button in VIPM.  It opens the following path:

...\examples\drjdpowell\Messenging\TCP Example

instead of what I imagine the intent is to open:

\examples\drjdpowell\Messenging

Also when I search for Messenger examples from the LabVIEW help window, the Messenger keyword doesn't appear anymore and I can't locate the examples from LabVIEW help.

Thanks for all your help!

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

I tried a quick test of the new build only traversing the local host from client to server and it worked well.  I will try a more extensive test across a local network tomorrow.   I need to update VIPM to 2017 on all the machines to get the package installed.

 The ping feature of the example is nice because previously when I set up a test with only server-->client messages, if you pulled the network cable the TCP actor on the client side wouldn't timeout or error so you didn't know something was wrong.  Quick question, is there a reason you decided not to implement the ping and "keep alive" features as an option in the TCP actor itself.  Were you worried it would interfere with overall throughput from the TCP Actor's callers? 

1 hour ago, Thoric said:

2014 upwards, including RealTime.

same here

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.

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

 

Replacing the query with a send and wiring in the reply address worked.  I just temporarily created an asynch create VI (without dynamic dispatch to test). 

If you are updating the RemoteTCP Messenger class, can you expose (make a datamember of the class) the timeout value the Actor uses during communication to the Remote Service.vi?  It would be nice to be able to adjust this timeout if necessary.

Thanks for your help

On 9/5/2017 at 0:14 PM, drjdpowell said:

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.

Thanks for the mod

Sorry for peppering you with questions, but I have another one. I'm trying to connect to a remote server that may or may not be there.  I want to have the capability to attempt and retry the connection in a non blocking fashion (since it may not be there at all). Since the default timeout is 5 seconds and timeout is not exposed in the Remote Service.vi a synchronous approach can hang for a long time.  I tried creating an asynchronous remote connect lvclass in the attached example (mods your TCP client server example) that inherits from the Action.lvclass in your library.  I am able to launch the remote service ok and establish a connection in the TCP Client Actor, but when the Async Execute.vi finishes, I think the messenger queue that was created during execute "goes bad" or is destroyed when the Async Execute.vi goes out of memory.  

Did I miss something simple or is there a better approach?

Thanks for all your help, 

Brian

TCP Control Client Asynch Launch (Messenging).zip

1 hour ago, drjdpowell said:

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.

That sounds good.

Is there a downside to simply flattening to the lowest LabVIEW version Messenger Library supports?  Based on my limited testing it seems like the unflattening in higher versions of lower versions works without code changes on the unflattening side.   It might be less effort for you this way.

I modified the following VI in the library as a test and it seemed to "work" with messages between 2016 and 2014:

C:\Program Files (x86)\National Instruments\LabVIEW 2016\vi.lib\drjdpowell\Messenging\Core Messages\VarMessage\Flatten Data.vi

I am not sure if any information is lost flattening 2016 variant data to 2012 data.  Need to research further, but thought I'd throw the VI up for discussion

Flatten Data.vi

15 hours ago, drjdpowell said:

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.

Yes there is a way as to tell 2016 to flatten to 2014 (and lower) described in Thorics link above.  Enjoy your holiday we can look at when you get back.

3 hours ago, Thoric said:

Unbelievably, I'm encountering this exact same complication today.

As far as I can tell, the reason is that variants are flattened to strings differently in every version of LabVIEW. Althoug the schema is the same, the actual version of LabVIEW is prepended in the flattened string. Thus, when a 2016 flattened string is passed to LabVIEW 2014 it does not assume to know the schema and throws error 122.

NI's white paper on using "Variant Flatten Exp", which allows you to set the flattening format structure, is their recommended approach. Thus you can set your 2016 code to create 2014-style strings.

Note: I think this only affects the flattening of variants. All other datatypes are unaffected.

However. I am still noticing differences between my 2014 strings and 2017 strings. For me, the issue is now down to the links to the typedefs controls in the clusters that I use. when flattening clusters (that contain variants) to strings, that are linked to typedefs, there is still a problem when passing between LabVIEW versions...

Hi Thoric,

Are you having the variant problem using Messenger specifically or just the same generic problem with flattening variants between versions of LabVIEW?

I took a little peak under the hood of the Messenger Library flatten / unflatten VIs and they have a U8 byte to define what items are present in the flatten data.   Maybe you already tried this based on your message, but one possible workaround would be to embed the 5 bits of version data (would only work up to LV2020 ) from the white paper you referenced into the upper portion of the U8 in the messenger library.  Not sure if drjdpowell would be up for that and not sure if the upper 5bits of that U8 are used for anything else since I only did a cursory check.   Also the added version stuff on the front and backend would add overhead.

I have a scenario where I'd like to use Messenger to send TCP messages between a LV 2014 machine/app to/from a LV 2016 machine/app.  I started experimenting using the examples provided with the Messenger library.... Starting TCP Control Server (Messenging).vi on the 2016 machine and TCP Control Client (Messenging).vi on the 2014 machine.  On startup, the first message from the client (2014) goes through to the server (2016) fine, but when the 2016 machine replies back the received message on the 2014 machine is not unflattened properly in the "Route Back Reply" case of the TCP Client Actor  and returns an error 122:

Error 122 occurred at Unflatten From String in SendMSG.lvlib:VariantMSG.lvclass:Unflatten Data.vi:280001->SendMSG.lvlib:MSG.lvclass:Unflatten.vi:3130001->TCP Client Actor.lvclass:Actor.vi:6640001->Dynamic Launch Shell.vi:5450003->Dynamic Launch Shell.vi.ACBRProxyCaller.5F500036

Possible reason(s):LabVIEW:  The resource you are attempting to open was created in a more recent version of LabVIEW and is incompatible with this version.

Is there a work around for this or do you have any suggestions for using Messenging library between different version of LabVIEW?

Take a look at drjdpowell's Messenger library (available in VIPM).  I believe the demo shows an example of how to do what you want.  Its relatively easy to learn the basics, and its even more powerful under the hood.

23 hours ago, viSci said:

Shaun - Thanks for the link.  There is a DirectShow rendering example given for mms video stream but I could not get it to work.  I tried to modify the URL for local media but no luck.  I will try to contact the originator of the library...

bbean - Yes Blackmagic does have a nice app that works great.  I can use it to stream uncompressed AVI files to my SDI output.  The problem is that I need to do this programatically...

viSci....I was asking if you can get playback to work through any 3rd party players (not just Blackmagic).  VLC and Windows Media Player have activeX controls that can be used in LabVIEW.  But if your only luck is with the BlackMagic application, then you should probably talk to the vendor.

Also have you looked at the Developer SDK?

"Developer SDK
Available free with all UltraStudio models is an advanced developer SDK free of charge for Mac and Windows. Develop your own custom solutions to use in house or even sell! UltraStudio also includes DirectShow filters, a WDM Windows Driver and QuickTime API that lets UltraStudio models integrate seamlessly with an unbelievably wide range of applications and codecs. Develop your solutions with confidence because UltraStudio is a flexible, proven foundation that free you to work without limitations. "

can you playback to your device using windows media player or vlc?  or only through the Blackmagic interface?

https://get.videolan.org/vlc/2.2.6/win32/vlc-2.2.6-win32.exe

3 hours ago, viSci said:

Thanks for the links.  Took a peek but did not see any examples or API's of how to stream video to a directshow output device.

Whoops.  Sorry bout that.  When you mentioned make AVI files in LabVIEW that was my first thought.  But I made a bad assumption that it also supported playback via video outputs, but it doesn't look like it.  

I was relatively happy using a couple of third party activex controls to acquire and playback for a similar scenario (different hardware):

http://www.viscomsoft.com/products/videocap  ~175$ (single developer)

http://www.viscomsoft.com/products/movieplayer ~75$ (single developer)

I don't have any code available, but it was pretty easy to follow their example code for VB and convert it to LabVIEW.   

SVN

One thing to verify as well is that your clients power management settings for the NIC or wireless aren't automatically shutting down the adapters after long periods to save power.

6 hours ago, shoneill said:

Here are two small examples:

Nice examples in FPGA

WRT OOP LabVIEW vs Old School (OS) LabVIEW, I think both approaches are lacking in one way or another.  I think Actor/Messenger frameworks solve some of the problems of OS Labview but agree somewhat with Shaunr that they muddy the debugging waters significantly and strip some of the original benefits of WSYWIG OS LabVIEW away in the name of "pure" computer science principals.  Still waiting for the IDE to catch up with VR glasses so I can see dynamically launched VIs and message paths in a 3rd dimension during debugging.

If you look to our friends in the web and DB world similar struggles are happening.  For instance, relational databases by theory you should normalize to the 6th normal form but not many people do.  And in fact people got sick and tired of refactoring relational databases in general and completely abandoned them in many situations. 

3 hours ago, shoneill said:

Regarding callers having different terminals..... That's a red herring because such functions cannot be exchanged for another, OOP or not. 

Likely in LV 2017 it won't be a red herring anymore with "type enabled structures".  So in the future you may be able to have DBLs in FPGA without OOP and without breaking the code. Pure speculation on my part though.

just curious why you used a SEQ for a "semaphore" vs an actual semaphore.  BTW I really like your version of the Modbus library.

3 hours ago, CraigC said:

Why not Just put the Write/Read into a non Re-entrant VI (Action Engine) and have this called in your three threads?  Am I missing Something?  At the moment it looks like you are essentially doing what a non re-entrant sub-vi does for you..

What if you have more than one comm port / instrument?  Are you going to make an action engine for each com port/instrument?  

1 hour ago, ensegre said:

I don't know.

But for a similar case, in my ignorance and probably just crudely redoing what the lock is supposed to be for, I used semaphores named after the VISA resources. I acquire the semaphore immediately before every read or write, and release it then (forget the specific details of the readout):

To deal with multiple serial ports I have a FGV containing the list of serial ports used and their associated semaphore references.

ResourceSemaphoreContainer.vi

 

I do the same thing as ensegre.  I gave up on using VISA lock / unlock, because I keep forgetting the nuanced use cases like porter has shown (I'm getting old and my memory is going) so its easier for me to just use a semaphore and be done with it.

11 minutes ago, ShaunR said:

You can have your cake and eat it if you wrap them in a VI Macro 

Or better yet a Type Enabled Structure

6 minutes ago, Neil Pate said:

Thanks, I am now experimenting with using a variant to store quite all of my global system data, and this tree is a really neat way to show everything (for debug/dev purposes).

I would have had exactly the same bug, so I have updated my package with your fix.

Is the Variant Tree indicator available in the Dev environment?  Not sure I remember correctly, but I thought after looking into using it in a program I found the primitive only ran if it was a probe.