crelf

This is a very annoying behavior of LV8:

I've had the same problem with VIs called from TestStand - anyone from NI care to comment? Perhaps provide a CAR?

I don't really think their use is really valuable for multiple instances (you can save any normal cutomized control for that), but for when you want to build functionality into a control - sort of like the difference between a standard VI Global (just holds data) and a Functional VI Global (holds data and performs some work on them).

As you mentioned, dq was not the first to use queues for GOOP. And, the author has stated publically that it is a combination of ideas mentioned first elsewhere.

Sure - there's nothing new in dqGOOP, but it's a particularly eloquent implementation of it - and also a IMHO great place for those unfamiliar with OO to start understanding the concept.

If you have Automatic Wire Routing enabled...

C'mon Pete - I know that you've got a plethora of more keyboard shortcuts Have you ever thought of putting them all into a new thread?

...when building the cvi install, use the embedded laview runime libray(very small dll)...

Now if only the LabVIEW Runtime Engine was small... :laugh:

It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread.

Come to think of it - that means that you could write to a global and then read from it again before it's updated. I know that globals inherently lead to race conditions, but the statement above means that even if you force dataflow so a global is written on your BD and then later read, there is no gaurantee that the write happened before the read...

You would also have to disable any copying abilities from that code.

That's right - locking a VI in Run Mode stops the user from selecting anything on the diagram, so they wouldn't be able to copy anything out of it.

Do gloabl reads have to execute in the UI thread?

Yes they do (from "VI Execution Speed" on NI's website):

How Multithreading Affects User Interface Actions

When you write to a local or global variable, LabVIEW does not switch to the user interface thread immediately. LabVIEW instead writes the value to the transfer buffer. The user interface updates at the next scheduled update time. It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread. Functional global variables can be more efficient than ordinary global variables because they do not use transfer buffers. Functional global variables exist only within the execution thread and do not use transfer buffers, unless you display their values on an open front panel.

...or what about a password protected VI, where you can choose, if the BD is viewable (but not editable) or not? (I think, that would be the easiest way to implement that ...)

:2cents: Now that's a good idea - and you're right, it shouldn't be too difficult to implement, as all you're really talking about is making the "Change to Edit Mode" functionality password protected at the VI level - the users could still open the VI, run it, see the BD, even open subVIs, but they wouldn't be able to edit the diagram...

After 500 posts you can customize your "slogan" underneath your avatar.

Sweet! Now everyone's going to be watching your slogan Jim - choose carefully...

I found this quote on the Ardence website concerning calling DLLs:

http://www.ardence.com/uploadedFiles/Embed...cts/ETS_FAQ.pdf

Very very interesting - thanks for doing the research!

Yes, I've seen and used the queue data store technique. Mark Balla has put in some effort refactoring OpenGOOP to use the queue data store. I'm not sure when this will be released, but it will happen.

Personally, I'm a big fan of GOOP using queues (I'd implemented my own version prior to the dqGOOP release, but the dq version is a lot cleaned than mine) - it's easy, fast and covers a lot of what I need to do (I'm certainly not a GOOP 'power' user). I'd sure welcome an openG version (is there any legal issues here? Can OpenG release an open under LGPL that's very similar to the dq version?)

Does anyone have any ideas of what's under the LabVIEW OO engine (soon to be realeased)? Is it going to be queue based, or something else entirely?

I've found a 'workaround', however definitely not memory-efficient. You basically need to do something in the inner loop which will cause LV to re-create the array in memory.

Also, changing anything on the BD between subsequent runs causes the VI to recompile, meaning that the memory space is reallocated. These two methods sort-of demonstrate the different behaviour between runs, but they unfortunately don't fix the bug - that's NI's job :laugh:

I've recently started a new project in LabView 8 and I'm trying to read large binary files.

LabVIEW does indeed have issue with opening large files - what you need it the "Large File" package from OpenG - download and install the Commander and you'll be able to get access to all of the packages...

are there any special requirements to participate?

Probably: head over to the Beta Program Website and register - then they'll contact you if you've been selected...

I don't know, too, but I guess there is a reason, why you have do download and install megabytes of data to get the .NET framework running on your PC ... and I disbelieve that you will get it running without the registry.

OK, you could maybe use some .NET controls, but what sould that be good for?

.NET and ActiveX are far more than just controls - my question is: if we can do Win32 DLL calls, can we do cusom ActiveX DLL calls under RT? I'm thinking that the answer is most probably going to be "no"...

Can you post a range of example images alng with a description of the region you're interested in?

hmm.. guess .NET and ActiveX will not work on RT... too bad...

I don't know - it's just a DLL...

is it also possible to directly access the serial port from a DLL without using VISA or Serial?

I've had great sucess with Port Controller in the past, but never tried it on an RT system...

I could have gladly gone the rest of my LabVIEW career without ever even having to contemplate either of those ....

Just imagine it - a LAVA user group meeting, with everyone in thongs...

.

.

...then again, you probably shouldn't

hmmm ... I use LV 7.1 / 8.0 on my laptop allmost every day (I have RT + PDA Module installed). Ok, it's not super fast, but it's ok ...

My personal laptop is a 3GHz P4 with 1Gb of RAM - unfortunately my wife uses that one for checking her mail, whereas my work-provided one is a 1.3Ghz M with 512Mb of RAM - there's a HUUUUUUUUGGGGGGEEEEEE difference between them

I have filed a CAR (3VJDFQF2)...

Wow! A real-life-honest-to-goodness CAR - I never thought I'd see the day! Looks like the ol' NI LabVIEW Champions programme is really starting to pay off - thanks Darren!

I've got a nasty one.

Yep - it's a particularly evil bug when not only is the result wrong, its behaviour changes between runs

It's a good thing that I only use Build Array in a loop.

I feel dirty...

OK, you can buy a ultra fast SCSI HDD for your workstation, but who wants a jet engine under his desktop?

...or laptop

http://www.cafepress.com/lavausergroup

Sweet - thanks!