viSci

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

I would like to pass along this method of creating transparent bitmap overlays. The example uses IMAQ but the core vi will process any 2D bitmap images. Let me know what you think... Mike Sachs Intelligent Systems

I have sucessfully used network buffered shared variables for transfering complex and high speed data from a cRIO or cVision system to a PC. One of the really nice things is that you can setup arbitrary shared variable data types and you can specify client and/or server buffering. I believe shared variables are the future in distributed system design. Also LV8.5 has a totally rewritten network protocol for shared variables that has greatly improved performance over previous versions of LabVIEW, which, by the way, had very respectable performance. Forgot to mention that you can specify the buffer size when creating the shared variables in your project and in operation they function very much like a queue. You can also poll the error out of a shared variable to determine if there is any data in the buffer to read or if there was an overflow condition. Mike Sachs Intelligent Systems

QUOTE(Neville D @ Nov 5 2007, 04:21 PM) Yes I am using an exotic IMAQ image display and those seem to be the most problematic. In regards to value property nodes, there is an NI app note that specifically suggests doing this. http://digital.ni.com/public.nsf/allkb/FC5...6256C8C0054689B

I understand that an RT application is headless (i.e. does not have a front panel) for that reason it makes sense to check when a client connection is made and then enable writing to any front panel indicators. What is mysterious to me is that if you do update a some indicator values before any remote connection is made, then that indicator may 'stall'. In other words subsequent updates, even if forced via property value nodes or local variables does not visually update on the remote panel. Could anyone offer a theory to explain this? I have observed this in LV 8.2.1 Thanks, Mike Sachs Intelligent Systems