viSci

I would like to programmatically bind front panel controls to Network Shared Variables. For some reason I keep getting this mysterious error Error 1522 occurred at Property Node (arg 2) in NSV Binding Test.vi Possible reason(s): LabVIEW: (Hex 0x5F2) The BindingPath property can only be written when the control is already bound to a PSP URL. Property Name: Data Binding:Path I find that I can set some binding properties such as the binding mode, but cannot seems to be able to set the binding path. I can however set the binding path manually in the controls properties. This seems like very basic functionality that should work right out of the box, any ideas?

Yes, I could add an input to my NSV wrapper vi but it seems messy to have to add that information to each use on my diagrams (which will be very plentiful). I guess my question could be distilled down to: How can a subvi discern the identity of a cloned parent vi instance without having to open up a reference to that parent vi. Opening and closing a vi reference every time I need to access a NSV seems very wasteful. For example if the call chain indicates the subpanel instance number then it could be done.

Greetings All, I have a vi that has n subpanels that each contain a instance of a reentrant vi. Each instance is given an identity by preloading a front panel control or the vi description with a unique identifier. Each instance will need to call a vi that provides Network Shared Variable R/W access. Since this vi is used across all subpanel instances, the vi must know which of n NSV processes is associated with the calling vi instance. So far the only way I have been able to do this is by using the call chain vi and then reading the top level vi description or 'identifier control' that contains the correct NSV process name. Just curious to know if anyone might have thought of a better way to do this.

If you use the fixed point acquisition then calibration is included in the measurements.

Whoops! Forgot to make a few more changes, make sure you have the latest upload.

In case anyone besides myself is still using the Excel GOOP toolkit by Martin Vernhout from Philips Research, you will find that it no longer works in LV 8.6. Apparently LV 8.6 rejects depricated activex properties that were working just fine in LV 8.5. I am attaching the fixed version. Also, LV 8.6 no longer installs the old _goopsup.llb files so you will need to install them yourself.

Pretty cool... I wonder if it has the resolution to capture a camera image, it might be kind of scary to have your face liquified.

I have been investigating the new RT Scan Engine and would like to compare notes. I have been testing the Forced I/O vi's and have found them to be very slow (~500ms/call) Anyone else tried this yet? Also, am curious to know what the plans are to extend the I/O Variable API so that we can programmatically create and/or rename Variables and modify scaling properties. It seems that the dll's under the hood have the hooks to do these things but the function prototypes are not published or wrapped yet.

Ok, the problem with 'scan from string' is that it cannot be used when trying to transfer an enum into a subvi. The only way to do that is with a variant. So how about adding some goodies to the scan function to scan a variant and we could have it do all sorts of cool lvdata parsing including obtaining the enum string.

I should have explained my application... I would like to create a generic CVT (Current Value Table) for cRIO applications. Instead of strings, I would like to use typedef'd enums as the tag key on my diagram. The generic interface for a CVT read or write would have a variant input for the enum key and a DBL,STR, or BOOL as the data input. I need to convert the enum to a string and use it as the key of a variant attribute which is used to strore all the CVT data. I thought it would be nice if the enum could be automatically converted to a string at the vi interface (I am sure NI could do it more efficiently than I can). I am currently preprocessing the enum typedef to extract all the strings and then use the enum cast to a I32 to index out the string. Overall, on the cRIO, it turns out that working with variant attributes is quite costly in performance so I may have to rethink the whole approach.

I was wondering why LabVIEW does not automatically convert enum's to strings on subvi inputs. The information is available on the wire so why not just offer this as a convenience instead of having to send it in as a variant and doing the conversion manually inside the subvi. I think it would promote the idea of using typedef'd enum's as diagram tags instead of having to use strings which cannot be 're-applied' when the typedef changes.

Here is a multichannel boxcar filter with individual filter orders. Originally wrote it as a LVOOP class (my first!) but then tried to deploy to my cRIO and felt really dumb since LVOOP does not run on LVRT!!??

Anybody know if the new RT I/O variables will have an API associated with them to allow programmatic access by name?

Greetings, Does anyone know if it is possible to run the PTP protocol on a cRIO? I currently plan on using the cRIO trigger input to receive a GPS 1s sync output. The newer cRIO's have a .ini switch to enable RTC correction. Thanks,

Can't you use Network Shared Variables for this application?

I was wondering why this architecture is not based on Shared Variables. It seems (with the DSC) it is possible to programmatically create and read Network Shared variables of any type. More and more it seems that the DSC is being melded into LV itself, so why not just absorb it completely and not have to reinvent the wheel here. The CIE component makes alot of sense but again it would be better if NI would just build this functionality into LVRT/FPGA to be able to read cRIO I/O directly in LVRT. Also was wondering why the CVT does not use Variant attributes to store tags, it seems like it would be faster than indexing through an array.

If you revert to traditional DAQ you might be able to use what was called 'software triggering' http://zone.ni.com/devzone/cda/epd/p/id/165 BTW, nice video

If you monitor them one at a time (assuming different electrode placement) then a common EMG/ECG amplifier would work assuming you could adjust input filtering individually for each case.

Tomi Maila peeked my curiosity about the language Erlang. Here is a interesting interview on SE Radio about this newly rediscovered concurrent functional programming language. http://www.se-radio.net/podcast/2008-03/ep...rmstrong-erlang

QUOTE (rolfk @ Apr 15 2008, 12:24 AM) Well, you may be correct but here is a report that makes it seem like Windows CE has more capability than that. www.qnx.com/download/download/8124/QNX_Neutrino_v61_vs_VXAE_and_WinCE.pdf -

Greetings, I am interested in getting some performance benchmarks on LV running under Windows CE. I would think that, in theory, it should be possible to achieve real time performance in the league of LVRT which runs under the VXworks OS. I went looking in the LVPDA 8.5 help for details on the implementation of the timed loop but could not find anything except some mention that while loops execute with cooperative multitasking with a 50ms timeslice. I hope that is not the upper end of performance! Mike Sachs viScience

Here are a couple of links to get you started. http://www.ni.com/academic/bme_course.htm http://zone.ni.com/devzone/cda/tut/p/id/6349 http://zone.ni.com/devzone/cda/epd/p/id/5832 Also you might try to implement the standard Pan-Tomkins QRS detector which is described in the attached PDF written by Monnie Anderson from NI.Download File:post-162-1208116855.pdf Mike Sachs www.viScience.com

Have you tried Buffered Network Shared Variables? I have used them in applications were multiple clients communicate with a single server. Also you can look at the error out of the Shared Variable node to see if there are any messages pending. NI has put alot of enginnering into the performance of Network Shared Variables so they should be up to the task you have in mind. Mike Sachs Intelligent Systems

I had a working LV8.2.1 application using IEEE1394 low level vi's until I loaded an unlicensed copy of the IMAQ Acq. Software drivers v8.5. I have tried to back out and uninstall the v8.5 drivers and reinstall the 1394 drivers but all my vi's are now broken as shown in the attachment. I checked to see that the 1394 low level.llb vi's match the imaq1394.dll and they do match and are from the same installation. I called NI and they are still scratching their heads. Any thoughts....

Here is something that I think could be modified for your purpose. It was designed for lab stations that have corporate mandated inactivity lockout, causing you to have to login to the workstation again if you leave it unattended for a period of time. Mike Sachs iSG Technologies