didierj

Acutally I'm stuck with a similar problem, having to deal with excel in quite a heavy manner. I help myself by having open firefox with msdn (to find what the methods/attributes might be), delphi (to find out what datatypes/values the attributes are), an uncounted number of excel-sheets (due to all the tests till it works) and of course LV. (same as you) Didier

You have forgotten the most obvious "LabVIEW 2 Globals", for every one who prefers the actual status.

I've also seen that variant data isn't kept after closing the vi. It already gave me quite some work to redo twice. I didn't check, but it came to me right now: Would it work if you flatten-to-string your ole-variant and read it with the second app? What does the flattened variant contain (whole data, only a pointer, ...)? Didier

With the omnipresent OO / UML /... it seems quite logical, but you will confuse any new LV-user. As an "overall" subject name I like "LV-2-globals", To describe the internas I find your approach best.

Wouldn't this mean that your son is using your home-LV at the same time as your office-LV... t...t...t... I would name this expanding the "gray-zone" of your licence areement (if both installations have the same serial-no). :laugh: Didier

Do you get a personal quote for a mid-range electricity connection (throughout Europe 16kV) from your local supplier along with the video card purchase? At least, if you install this into your computer, you'll have to upgrade your case & power-supply to a server-system. Normal mid-tower supply (350 to 500 Watts) won't love your new graphic card. On the other way: might be a nice experience playing doom with such a screen & resolution.

I think both have their advantages. For myself I'm used to the shift register, I seldom use the feedback node. As Neville mentioned, the advantage of feedback node is, that you don't have to route wire through the whole diagram. It's disadvantage might appear, when you need the data after the loop finished. With the feedback node you have to branch your wire and therefore most probably producing (somewhere in the deep background of LV) a copy of your data, and therefore lost of time. Didier

Set the timeout to a higher value. So your VISA-read will wait a longer time. To set the timeout go in the palette to Instrument I/O -> VISA -> VISA Advanced. There select VISA Set Timeout. Didier

I suggest that you take a second computer and either port your LV6.1 & DAQ6.9.3 to this computer or install your LV8 on the second machine. Installing LV8 will for sure upgrade your drivers. Your LV6.1 will still be able to run the traditional DAQ-vi's, but what is running in the background... At least your MAX (and if important: VISA, GPIB,...) won't be the same. Didier

Open the chart in the control-editor and you'll see the problem. The plot area is not the same size as your x-scale. How this could happen, I can only guess: Considering your experience you might have found a bug. Usually, resizing the plot-area, also resizes the axes (except if you are in the control-editor). Edit: Is it somehow related to the font-modification? Or try the behaviour on a different computer (in case your installation is somehow broken), I never have seen this issue. Didier

Not a workaround, but a possible solution for NI (hopefully someone there is reading): handle enum-/ring-length same as text controls & constants. This means, add a checkable entry "size to text" to the rmb-menu. By having it checked, the enum (and therefore the whole array where the enum resides) resizes when a different enum-element is selected to it's text-size, otherwise it doesn't. I often use this feature when applying text-array-constants: 1. put the array on block diagram 2. check the option 3. type in the longest array element 4. uncheck the option 5. type in the other elements. ...But also here is quite some room for varying opinion, since checking the "size to text" option in a text-array, resizes the array to the size of the element you clicked on, I would prefer a resize to the largest. ...at least it would be contiguous throughout LV. Didier

I would say +/- 0.0.0.5 So, if NI releases update 8.0.1 then you get it.

Using DLL in LV I have also seen odd behaviour, especially when the DLL doesn't reside in the search path of the computer. Usually this would mean - either directory where the app resides - or windows/system32 (if in win-environment) Alternatively add your directory to the system-"path" variable. This should give you a workaround. Didier

Depending on which purpose you want to show/hide elements in the cluster I see 2 possibilities: 1. If you just need show/hide for cosmetic purposes, get the control refs from your cluster and show/hide the elements. The order of the elements you get with "all controls"-property is the order you placed them into the cluster. 2. If you use the cluster to read/write configfiles (with e.g. openG) then you'll have to build as many clusters as you have possibilities and show/hide only one of them. In the background you'll have to deal which cluster you pass to the inifile. In LV6 I used some ActiveX-tab control to change between configs Didier.

Just checked "draw text in rect" and "PCT Pad String" (since the error you showed is referencing this vi). In my LV-installation both vi's have their corresponding block diagram. Following rolfk, I think somehow your block diagram got removed during your last build. You will have to either reinstall or repair your LV-installation. Didier

1. With "Release ..." or "Destroy ..." I mean e.g. "Release Queue", "Destroy Class" (if you use any sort of goop-objects, e.g. ini-files,...). 2. Memory management is done internally by LV. Usually you don't have to bother about it. I'm not absolutely sure, but thought it was so, LV doesn't give the allocated memory back to the operating system right by the way, but keeps it for future use. Up to LV6.1 there was an option that was called "free memory as soon as possible". In LV7 this option has gone. 3. To have no memory leaks, make sure you close/destroy all references. they can be: queue refs, file refs, goop objects, refs to dynamically called vi's,... Also make sure, when you display anything (esp. large arrays), that this vi get closed. As long as the vi is visible or loaded, the memory it uses won't be released. A vi is kept loaded when there is a vi-server ref still hanging around somewhere in your LV-envionment, even when you close the vi.

Make sure you close all the references before you end your app with "Close File", "Close Reference", "Release ...", "Destroy ...", or similar.

how bad. hmmm... Last time I went to LTR I was interested in some volumes, but got outraced by problems in my factory. Now LTR is down and I can't get them anymore, or is there still any resource?

As an update to this topic I'm wondering why LTR is down. This seems to be since several days (not too long, since I was there one or two months ago). Does anyone know more?

We make them ourselves. Go to Keller Druck -> English -> Products -> Miscellaneous -> Converters. Under "Addresses" you'll find the address for our sales reps (unfortunately no online shop). Didier

Does your dll reside at the same place as your vi? If not try to copy it into the same directory. If I remember correctly dll's should reside somewhere in the system-search path: In win environments this would mean: <app>-directory, <windows\system32>, <LV> directory.

Is it possible that several items in the tree have the same tag? If (while setting up the tree) you set uniquely tags, you shouldn't encounter any problems. Otherwise send an example (in form of a vi-file) of what you are trying to do.

What a strange example... On my computer, when I start this vi, it never stops and raises the cpu load to 100%. In the meantime I read the whole Info-LV-digest, and now while I write this post the vi is still running and my cpu tells 100% load. Most strange is although the cpu load is at 100%, I don't seem to have any limitation in speed for the other apps. ... I think I'll have to kill this LV-session... ...Update: after 25(!!!) Minutes I finally also got your error. :thumbdown:

...ok, I use the USB-Serial converter we sell ourselves (together with our pressure transmitters). They have galvanic isolation.

In the NI knowledge base you find a lot about this error. As you state that you are using eval version, did you installed VISA? You get it either from the NI site or on a CD called "Device Driver Reference CD". If you installed NI-DAQ (With VISA, Measurement Explorer,...) you might need to run the Measurement Explorer at least once, so the ports get registered correctly by VISA. On earlier versions this was required, I don't remember exactly up to which version.