bbean

I confess I haven't dug too deep into this but based on the support note here, I'm not to optimistic: Thermistor Measurements Using the NI-9219 there is a 10K upper limit for resistance measurement (we have 10k thermistors...so the resistance will exceed this at lower temperatures) The NI-9219 has an unregulated voltage source that excites anywhere from 220µA to 420µA across the thermistor depending on its resistance 10k thermistor measurements seem like a pretty common item, not sure why NI doesn't have an off the shelf module/approach for this with cRIO/cDAQ Support note Snip--> " In cRIO and cDAQ, measuring thermistors can be accomplished by setting the NI-9219 to 2-wire 10 kΩ resistance mode. This will return a resistance measurement that can be scaled to temperature using the thermistor's scaling coefficients. DAQmx doesn't support thermistor measurements on all channels. On NI-9219 DAQmx supports channels _cjtemp0:3, but not channels ai0:3. If using this configuration, keep in mind the following limitations: The 2-wire resistance measurement configuration is easier to assemble than the half-bridge configuration, but it does not take into account measurement accuracy. The NI-9219 has a 10 kΩ limit for making 2-wire resistance measurements, which is too narrow for many thermistors. This is the first limitation. The NI-9219 has an unregulated voltage source that excites anywhere from 220µA to 420µA across the thermistor depending on its resistance (the excitation values for resistance mode can be found in NI-9219 Operating Instructions and Specifications). This could potentially affect the accuracy of some thermistors, because the current may cause self-heating errors. Refer to the thermistor datasheet to determine if self-heating will be an issue. "

The thermistors we are using are very small and based on the experience of others on the project, current > 100uA causes self heating of the thermistor and sensor error. Ideally we run @ 10 uA source current

Has anyone used cRIO to measure a bunch of thermistors? We have to add thermistor measurements to an existing cRIO chassis and I'm surprised to find out NI doesn't offer an out of the box solution for this. From what I've seen they say you can use the NI-9219 for thermistors up to 10k but the current would be way to high and would cause self heating.

I think the U16 length is overflowing. Not sure what to do about it though.

Sounds like a firewall issue. One side may be blocking the connection attempt. Not sure about linux, but a recent windows update made the firewalls a little more strict and caused similar problems for me.

Ok if you said PXI I was going to say check the RAM type. I had a evil crash that appeared randomly on machines and after a long process with NI's help found that it was the RAM. NI sells "certified" RAM for the their PXI's and I will always buy that in the future even though its a complete ripoff. Back to your issue. Have you tried the Desktop Execution Trace Toolkit to check for reference/memory leaks yet? I wouldn't be scared about going under the hood of the db toolkit, but I wouldn't go there quite yet.

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?

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!

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?

same here

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

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.