viSci

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.

Just curious what tools people have found useful for Designing State Diagrams.

Remember the NI State Diagram Toolkit? I wonder if that will ever make a comeback.

I found this free online tool which is pretty neat:

http://www.gliffy.com/

You need to condition your while loop to stop when your elapsed time triggers. This would give you 50ms of data. I think you may have other problems using single point DAQ at these data rate. Do you have a driver that support HW timed DAQ?

Can you show us the code?

I have worked with 'experimental' peristaltic pumps using every kind of motor drive (PWM, H-Bridge, Stepper, Servo) and never had a problem as long as you remember to

make sure that your analog and digital grounds stay as separate as possible.

If you need more isolation then send the PWM through an optocoupler which will break the ground connection entirely.

Just in case anyone did not know the obvious...

Yes, a Set Control Value Method does indeed trigger a 'Data Change' Event.

Perhaps I am finally starting to understand the xcontrol basics

Does anyone know a way to detect when a Set Control Value Method has been executed on an Xcontrol?

I have tried the Display State Change and Data Change Events but they do not seem to trigger on this.

Thanks

If you have the DSC toolkit then you can Get Shared Variable List.vi and just give it the process name (either local or remote).

Without DSC you need to do it using variable engine properties:

http://decibel.ni.com/content/docs/DOC-9523

Has anyone else noticed a significant increase in variant attribute performance in LV2009SP1 from LV8.6.1?

In the past I had been using VA's for Current Value Table Implementations but reverted to using simple

numeric arrays in LV8.6 since the array based implementation seemed to be faster. Now in LV2009SP1

the opposite is true by a wide margin (40%).

I think the new PSP is very efficient. Read the white paper on the subject, it gives you pretty accurate performance characterizations.

Well, other than NSV binding, there does not appear to be a direct RT based OPC solution. It is interesting to note the Wind River does offer a VxWorks OPC driver

so any RT target such as cRIO should be able to theoretically work. Another possibility might be to see if the OPC data is available as ModBus over TCPIP, Profibus

or even Ethernet/IP for such devices as AB PLC's.

Here is some information on the subject...

http://forums.ni.com/ni/board/message?board.id=170&message.id=446048&requireLogin=False

Here is some info on the CJC in a 9211

http://digital.ni.com/public.nsf/allkb/E6DFDA7F1AA16C1C86257599006D4A0A

I believe if you are using the scan engine then the autozero and CJC are done for you automatically.