bbean

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

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

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.

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.

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

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.

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

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

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.

Or better yet a Type Enabled Structure

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.

I know the title of your post is "CRIO-style architecture for Raspberry Pi" and briefly looking over the architecture I think it looks fine. But have you or anyone tried this architecture on the Rpi: Front Panel Publisher What are the limitations of the Rpi LabVIEW runtime? When I get some time I'd like to investigate more.

Sorry, I'm a little tied up right now with work stuff. maybe we could chat offline regarding what you want in detail, so I don't accidentally go off on a tangent when/if I do actually work on it. I think what was stopping me in my tracks before was figuring out how to determine the "name" to put on the output control based on an upstream connection (input wire)

lordexod. I tried your new Relabelizer popup plugin and its a nice solution. Seems to have a small bug that the terminals may not get wired up properly depending on where you right click to execute the script. See: Relabilizer Plugin Bug I still like my solution better because it looks better on diagram. Yours is more elegant because of its simplicity though.

Bean, Thanks for the response. I clicked your link and then went down the black hole of MS again trying to find a reseller for the license. Doing a google search resulted in this possible link to purchase: Microsoft MSDN Platforms License & Software Assurance 1 Is that a similar license to what you are using? I may be hijacking the thread at this point.

To be a little more helpful, I googled speed up gifs and found this: Ezgif speed up site and sped up the above gif by 200% and inserted it into the attached VI. Then inserted the original gif saved from the site at 100% (for some reason the original gif wouldn't drag/drop into the VI, but ones run through the website would). Anyway it seems the speed up works on my machine/vi. staythirsty.vi

Stay thirsty my friends