Strict typedef problem

[Mikk]

It seems that in LV7.0, accessing a strict type definition control
basically suspends all running VIs, even independent concurrently running VIs.

I have included a demo VI in the attached VI library.

The VI periodically updates the starting display index for an array on the
front panel. The purpose is to simply show that the VI is running and this
is how I originally ran into the problem.

The VI also has two enum controls. One of them is attached
to a strict type def (also in the vi lib). If I click on the simple enum
control, the VI keeps running as expected while I am making the selection
(array display keeps updating).

If I click on the strict typedef control, the display updates stop (in all running VIs)
and when I release the mouse button, I actually get an error for the
property node that accesses the array control, which is in no way connected
to the enum.

Could anybody explain this behavior?

[LV_Pro]

I am not seeing the behavior that you are describing in 7.1.1. Everything runs at full speed, regardless of which of the controls I change. Possibly this is a 7.0 bug, I don't currently have that installed on an available machine. Sorry that I can't be of more help


P.M.

[chrisger]

hi mikk,

i ran into this problem too a year ago. it's indeed a bug in LV 7.0. with LV 7.1 all works fine.

best regards
chris

[tst]

LV has one thread dedicated for user interface operations. When you use the property nodes, you force LV to go through that thread. My guess is that using the strict type def also forces this, so when you click the enum, all code running in the UI thread (the property node and therefore the rest of the loop) waits for you to free up the thread.
If you use a local and change the values of the array instead of index values you will see it works fine.
I'm not sure why LV returns the error about the type def. Maybe that is a bug.

[Mikk]

Re: suggestion that this is a UI thread problem.

I am aware of the tread model and I don't see how this could be a thread issue
since the non-typedef enum works fine. The typedef enum halts
all simultaneous VIs, even those set to run in a different thread and even
when set to highest priority levels, which is why it is so annoying
for me (crashed a mesurement).

[Mark H]

I don't have the answer - but I noticed a couple of things...

i) No error occurs if the type def enum is accessed by its up/down index buttons.

ii) No error occurs if you don't write to the array index propert node (reading the property node alone doesn't cause any error).

Not much help I know - but interesting!

[Mark H]

...I can also confirm there is no problem when running the example in the LV 7.1 version.

[HollywoodGunner]

I am experiencing a similar problem in labVIEW 7.1.

In somewhat real-time, I am acquiring data and displaying it to some graphs. I am using a series of graph cursor pairs to "window" the displayed data on the graphs in order to do some near real-time data processing. The data acquisition hardware is a couple of Acqiris digitizer cards, and the labVIEW code is written using "call library" nodes, which call the standard underlying "C" data aquisition code supplied by Acqiris. The call library is configured to run in the User interface execution subsystem. ( I also placed this data acquisition subvi into a seperate execution subsystem, but the problem persisted).

I retrieve the "X" values of the cursors using either property nodes (or control reference methods), and use those values to index into the data to perform the data processing. This works fine as long as I am not actually running the data acquisition. Once I start collecting data, the retrieved cursor X values no longer update if I move them. In fact, I placed this part of the functionality (retrieve graph cursor values)into a sepeerate loop, and the entire loop just "suspends" as long as I am taking data. Once I stop acquiring data, this seperate loop picks up where it left off, and you can see the values update as you move the cursors.

I am suspecting that this problem is related to the data acquisition vi being run in the USER ITNERFACE execution subsystem, but it is the only choice, other than choosing "reentrant"

[chrisger]

hi there

i found my code i wrote a year ago...

when pressing a enum strict typedef (just pressing, not changing) a MCLixtbox returns Error 1082 when writing to it, but not when reading it. see code attached (this MUST be bug in LV 7.0!)

best regards
chris

[Mikk]

I'll just upgrade LV to 7.1
Hopefully that will solve the problem.

Re LabVIEW freezing during acquisition that uses external DLLs, that is
not terribly surprising. You can achieve the same effect in a much more
simple way (at least under LV7.0 on XP). Run, for example, the same
VI that I originally included, or any other VI that keeps updating something
on the screen. Now grab any LabVIEW window by its title bar and keep dragging
it around the screen rapidly (just wiggle the mouse like mad while the mouse
button is pressed). You'll notice that *all* LabVIEW activity stops until
you stop wiggling the window around.

This smells more like a Windows scheduling issue. Apparently even a 3 GHz
processor cannot handle window dragging without bringing the whole machine to
a crawl.