viSci

Hi All,

I would like to capture video (30Hz, 24bit color, 640x480) in sync with some DAQmx channels.

The data needs to be streamed to disk and retrieved back to display in realtime with data.

My question is what hardware is recommended to support the video portion of the system.

I am planning on a cameralink interface that has hardware triggering but am not sure if I will need any special RAID hardware

for the streaming to disk. Also what is the most efficient format to use:

IMAQ->AVI->Disk

IMAQ->JPEG->Disk

IMAQ->(Some other GPU compression)->Disk

IMAQ->Array->TDMS

I am not really going to processes the video so would it be possible to use some 3rd party activex controls that are optimized for GPU video streaming?

Not sure how I stumbled on to this, but thought LAVA folks might find it interesting...

http://www.slideshar...ormal&rel=15910

Is this what you are doing? I thought that save changes?=F would disable a popup.

Tell us what you want to do with the DSC, maybe we can help.

IR thermocouples can have response times ~10ms, check out Omega.com

Could you add the mouse and key down events to the value change event case and then look at the event type.

I guess that will not really work, sorry.

Sounds alot like NI's own PSP (Publish Subscribe Protocol). The only problem is that NI does not fully give us the ability to create

subscriptions that can be used to create user events. We can of course use the DSC toolkit, but IMHO it should be built into the NSV API

and available also in RT since it affords such a powerful architecture.

You can also use the GXML libraries.

http://zone.ni.com/devzone/cda/epd/p/id/6330

But as jgcode mentioned, you should benchmark first because they can really hit your cpu pretty hard.

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.