viSci

For small videos you can convert to GIF and use a cheap activex control like AniGIF http://www.jcomsoft.com/anigif.htm

Could you also show us the code for the ICubeSDK_SetCallback function? I am excited about using this same idea to create a LV user event from a NSV value change callback registered within a CVI dll

Yes, I had thought about using the FileVersionInfo.vi but it appears that this information does exist in the cRIO (VxWorks) file system. Actually, I wonder why NI does not build this into all exe's with a native property node to read it out. Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers Could you tell me what property nodes you are referring to?

I would like to settle on a consistent version management method that will give me basic version numbering on the software components in my system. I have 3 types of HMI (windows) and 2 flavors of cRIO code. I would like to have one global software version embedded in each exe so that it can be locally and remotely verified. The problem I have is how to reconcile all the different version numbers that exist such as the SVN revision, the LV build revision, LV VI revisions and now an additional project based version vi that I am starting to include for all builds. I was hoping to hear from others who have navigated these waters before and might have some tips to offer.

Although not what I was looking for initially, one thing I discovered that is pretty cool is that you can feed DSC NSV value change events (they propagate up to LV as User Events) to a Event Callback node (normally used for activex events) and you can then wire in a static node for any callback vi that will automagically execute when a NSV changes value. The holy grail would be to generate User Events from NSV changes without the DSC. Now that I know it can be done in CVI it should be possible to create this in LV. I am not trying to get out of paying for the DSC (we already have a license) it is just that I believe, as LAVA citizens, we have the unalienable right to be able to access the entire shared variable API with just LV.

You could use the new LabVIEW C code generator http://zone.ni.com/devzone/cda/tut/p/id/11784 Or you could build your vi's into dll's and call from CVI

For some reason this mechanism is forbidden in LV but seems to be supported in CVI. It appears that you can do an async read on a NSV and specify a callback function which gets invoked when the NSV value changes. Does anyone know if it is possible to wrap this functionality up in a dll that would allow me to specify a NSV by URL and a callback vi to execute.

AWESOME!!! Thanks a Million.

I have some legacy code that used the Callee's Property to discover the names of subvi's within a vi that is within a running exe. The code uses a static reference to the vi and attempts to extract all the callee names. Of course this no longer works in LV 2010 but was wondering what kind of workarounds people have discovered. I can understand protecting an exe from the outside but it seems there should be someway to enable this functionality in your own created code.

You might take a look at a pipelining architecture... http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/fpga_pipelining/

I posted about something similar here... http://forums.ni.com/t5/LabVIEW/Add-XControl-Properties-in-LV2010-is-not-working-correctly/m-p/1244688#M525523

Here are some links that I found useful. http://zone.ni.com/devzone/cda/tut/p/id/9861 http://www.controlguru.com/2007/011107.html

FYI - Here is a Question and Answer to Jason Reding at NI concerning the use of RT-FIFO enabled NSV's: 6. Are there any caveats in creating programmatic access or alias binding to cRIO hosted NSV's with RT-FIFO enabled? The automatic deployment of RT-FIFOs to decouple your read/write access from the jitter occurred when accessing the network stack is only a feature of the static variable node. When using the programmatic API, you will be communicating with the variable in the same manner as if the variable had been deployed without the RT-FIFO option enabled. If this is functionality you need, we recommend you use the programmatic RT-FIFO API directly to decouple your deterministic loop from your network communication loop. This loop would look something like the following: In terms of binding, my understanding is that the binding just serves as another level of indirection to the original point deployed in the SVE. In essence, the SVE of the bound point becomes a client of the SVE of the original point. However, the configurations applied to the deployed points in the two SVE's are still unique. In other words, just because the original point was configured with the RT-FIFO option enabled doesn't mean clients accessing the bound point will access the bound point through an RT-FIFO. For this to occur, the configuration for the bound point would also need to enable the option for the RT-FIFO. The same goes for the network buffer configuration options. Accessing bound points using the programmatic interface has no additional caveats over accessing a non-bound point through the programmatic API.

Dude - where were you yesterday when I spent all day mangling c# code to produce a .net assembly that would set timeadjustment priviledges. Nice library though...thanks for sharing.

Just in case anybody missed this one...

It appears that all of the strange conflicts I was seeing were being caused by some 'innocuous' initialization code that contained a call to the RT Set Time and Date vi. Apparently, this is a no-no when your RT code if first starting up and can cause problems with the static NSV init code that the LV2010 compiler generates which runs in the background as your RT code begins execution. So I guess my title should be changed to LV2010+Static NSV+Dyn NSV+RT Set Time and Date=Watchout!

Yes it has been reported.

Just a word of warning based on my recent experience... If your RT code has lots of static NSV nodes and you are also programmatically opening NSV references then you need to make sure that the behind-the-scenes init code that comes with each static NSV node has completed before attempting to use the NSV API. If you do not then you may corrupt the SVE and will have to reboot to recover. Currently I just do a dumb wait (30s in my case), it would be nice if there was a way to find out programmatically when it was safe to start executing your RT code.

Hi Christian, Thanks for the suggestion. I took a look at the SNTP client vi's and they look pretty simple (as the name implies). I think I can get a SNTP server going with this as a starting point. I hope that in a future release, NI will consider adding a 1588 windows client to the NI-SYNC driver.

The problem is that I do not have any master time servers on my network other than a GPS based IEEE1588 master clock node which is not supported by windows network time clients.

I am trying to create a vi to servo the windows system time to match my cRIO clock which is disciplined by GPS. I was hoping to find a IEEE1588 stack for windows that would do this for me but in the meantime... It appears that the way to do this is by using a windows dll function called SetSystemTimeAdjustment which can speed up or slow down the windows tick time, with this in hand, you can implement a PID servo loop to gradually sync the clock to an external reference. I was wondering if anybody has gone down this path before and might have a few tips.

Also worth mentioning is that in LV2010 we now have 'Network Streams' which function like lossless network queues between any processes.

LVRT even on an older cRIO should provide plenty of cpu bandwidth for simple constructs such as a state machine or timed loops etc. The things that can really eat up cpu is the scan engine and the use of network shared variables. BTW, the distributed system manager will give you a readout of cpu% and memory usage so you can easily run some preliminary tests.

I think you are unnecessarily taxing your diagram real estate You need to first come up with a performance spec - how fast do you need to sample your tire temp's (include the transducer response time also) Chances are this sampling rate will be glacially slow compared to the performance of the FPGA. I would go with the mux'd version, it will probably give you sub us synchronization.

Very interesting, thanks Paul for putting together so much good information. You have given me some new ideas! I have developed a system that is similar except I use NSV with variant payloads to message my cRIO processes. I also rely on Citadel and DSC SV events. I agree that it would be nice if they became a native part of LV. I thought someone (maybe you) told me that DSC runs a service that polls the NSV's for change and then somehow generates the user events.