viSci

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)

Windows CE or Windows Mobile as it is named nowadays really is not a realtime OS at all. It is rather designed to bring the Windows desktop experience to small and resource restricted devices than to do anything in realtime. And the LabVIEW module to create applications for PDA devices certainly doesn't make many attempts to squezze extra performance out of the whole thing. In my experience LabVIEW PDA is best used to create simple GUIs for control and/or supervision of RT applications or such elsewhere, such as on a cRIO target or similar.

Rolf Kalbermatter

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)

I don't think value property (as relating to updating the front panel) works with RT. Even if it works, it will be slow. In general I try to avoid property nodes when working with RT.

I usually just keep updating the indicators even if there is no client connection; when there is one, everything updates normally.

Are you using any exotic indicators (IMAQ image display)?

Neville.

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

Thanks to everyone who has tried to help. Here is the version of a batch file that finally worked:

cd c:\Program Files\Ecg Stairstep

regsvr32.exe """c:\program files\ecg stairstep\anigif.ocx"""

"c:\program files\ecg stairstep\vrmixr\setup.exe"

Lessons learned:

The cd command does not have any effect when this batch file is called from

the installer. The following snippet does not work even though anigif.ocx is located at c:\Program Files\Ecg Stairstep -

cd c:\Program Files\Ecg Stairstep

regsvr32.exe anigif.ocx

The complete absolute path always needs to be provided. The use of triple quotes is required to create a literal path string that contains quotes.

The last line will not work without quotes since there are spaces in the pathname.

Maybe Vista Powershell will finally extricate us from DOS hell.