viSci

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.

Hello All,

I was wondering if anyone has any of the missing LVx posts that include the vi's and basic examples of its use.

I am trying to put together a LVUG presentation on the general topic of messaging frameworks and would like to

include LVx as well as some of the other interesting methods such as active vi's, event bus, etc.

Thanks

NI has been experimenting with RT based infrastructures to allow remote managed RT test sequences. Veristand is a case in point.

You might want to check out the Multi Process Engine Reference Design from NI

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

or

Reference design for Real Time Test

http://zone.ni.com/devzone/cda/tut/p/id/9883

You could probably extend the 'command server' to include

transfer of task vi updates.

PID is based on Proportional control so it expects your output to work with a 0-100% range, in your case it would have to be PWM and you will need to setup a timer to

control the pulse width. Also remember to scale all of your inputs and outputs to % full scale.

Just found out from NI R&D that the problem is repeatable and is caused by attempting the customize the digital numeric on a slider control. The vi will run once but thereafter will be corrupted.

A CAR has been filed.

Just a little memo to all who responded (none actually) that I sent in my corrupted vi to an AE at NI and within 24 hours he got it to R&D where they were

able to repair the self inflicted damage. I would really like to know what kind of tools they are wielding. The big lesson learned is that the damage could have

been much worse and that was a big wake up call to get tortoiseSVN in place. Now I will do a daily revision of my source code and a backup of the SVN repository.

Thanks NI for your help and quick response.