SuperS_5

The property node can be set to "ignore errors." This stops this propagating the error down to the other properties. (Incoming errors still cause the node to skip execution though.) In this mode, the first error is outputted, while execution continues.

P.S. - moreover, you can't call a property node of the same class from within a member access vi of the same class that has a property node.

I believe we have done this in LV2010. The same code works in LV2011, but I don't think I have tried creating this scenario in LV2011. (Property node>property node of the same class.)

I assume that you are using LV2010. (From your profile) We just recently upgraded to LV2011, and it a lot more stable. We had a lot of problems where LV would become very flaky when editing classes. (particularly if you tried to click faster then LV could finish loading screens, or had a lot of windows open. I never tried too hard to isolate the problems) Of course, there may be limitations, but if it is possible, I recommend upgrading.

I used to play a lot of PC games, before getting into programming. This background taught my one hand to hover over the keyboard, quickly hitting multiple shortcuts without looking. The 100+Keys on the keyboard come in handy. (I can also use the mouse with either hand.)

Trackpads, and single displays drive me crazy though.

Hi,

The message is related to the fact that your references are not defined types, just generic controls. On my system they are just warnings not errors. Maybe the error window gets a little confused sometimes.

I have to agree with Daklu. I only start to use any kind of flow-charts/Pseudocode for very large programs. I usually define these when the program must be split up so that multiple developers can work simultaneously. On one project, I used the state chart module fairly effectively for a single developer.

I you use the "separate compiled code from source" option, clearing the object cache may help. It is in some where in "my documents/LabVIEW data/". If the VI uses any ctl files, I would check them first. I have found that corruptions in type-defs to occur way too often. We now use 2010 SP1, while being a little more stable, we still see this kind of crash often.

Good luck

Every time I have seen this problem, the computer did not have enough RAM, and the swap file was heavily used. Upgrading the system RAM solved the problem. If you cannot upgrade the system RAM, and have windows 7, then ReadyBoost can be used to augment the system RAM. I currently have 8GB of RAM. (I was running out at 6GB)

Hi everyone!

A few of us at Enable have just passed our CLD's. Cheers and high fives all around.

*Hint Hint: Look at my signature.*

I removed my "hosts" file work around, and can still get LAVAG. :-) looks good.

The message seams to suggest that you are low on system memory. How much RAM/page file do you have? How much free RAM do you have then you get (and just before you get) the error? (If you have plenty of available RAM when the error occurs, then I completely agree with Yair, above.

There are several white papers and various forum threads on the use of parallelized for loops. I believe it is not very useful to nest parallelized for loop. Not wiring the P terminal, will yield a number of threads equal to the logical processors. I think the way you have nested these for loops will cause twice the thread count, and not be more efficient then a single parallelized for loop, nested with another regular for loop.

If you can reproduce the issue, you could submit it to NI on their forums.

You can get the classic windows theme, which is settable globally for your whole system. It is included with Windows 7. Several WinXP themes are also available, again settable globally. It is also possible to "disable visual themes" for LV. (or any application) This is accessible via the application properties pop-up from the context right click. As for LabVIEW only, WinXP theme, you would have to make customized buttons.

As mentioned, a daemon always polling for updates is the most robust method. This allows for the updater app to make significant changes, without user interaction. The main app can update the updater whenever necessary. (Would eventually be very infrequent) Either by the updater sending an "update me" message, or the main app polling.

A simplistic approach is to use batch files. Your app will poll for updates. When found, create a batch file that completes the copy, and restarts your app. In the most sloppy method, running the batch file (without waiting for the return) and immediately exiting can work. This is also the fastest to create, but harder to maintain over time.

Hi,

I am still learning about LVOOP, but here is the little I do know.

A static dispatch VI is mostly a regular VI that is owned by the class.

A dynamic dispatch VI is sort of "similar" to a polymorphic VI. For each of these VIs, a replacement can be made for each child class. (A class can be a child of a class, of a class, ... etc) If the child class is used instead of the parent class, the "replacement" VI would be used instead of the original dynamic dispatch VI.

These replacements are defined by the same connector pane, and VI name. (The owning class name will be different)

The connector pane specifies if the VI is a dynamic or static dispatch VI. Right click on the class input/output connectors on the connector pane > "This connection is", and you may choose [required, recommended, optional, dynamic dispatch(required)]. If the dynamic dispatch option is chosen, the VI is a dynamic dispatch VI. If any of the other 3 are chosen, then it is a static dispatch VI. (Both input/output connectors for the class have to agree)

An accessor VI is a template for accessing the data from the class wire. This VIs are used as "gate-keepers" to the data. Making them dynamic dispatch allows for different behavior depending on the input class.

The dynamic dispatch VIs have a noticeable overhead during execution, and loading. It is always better to use a static dispatch VI unless your really need the dynamic dispatch.

PS. Darn....Paul replied first.....lol

Setting the boolean to true allows it to work....cool. I also tried changing the string to contain actual content, and using an uninitialized array. Both didn't work.

I originally thought that this was related to the cluster, but an array of strings, or variants also crash LabVIEW.

Definitely reproducible. It does not crash if only the cluster is inputted, only for the array. Adding a label to the array did not help either. (I had seen that be a problem before.) I originally thought it might be a corrupt cluster, but recreating it from scratch did not help.

I have LV2010sp1 -32bit on 64win7

Hi,

I have been looking at your VI. I would completely remove the "plant.vi" simulator. That is where your DAQ calls could go. (That's the simple approach) The LabVIEW example finder will help you with the DAQ calls. You need to output your pid value. and get the level. I wouldn't personally use this single loop approach because it is not scalable, and would not be responsive enough if the output valves have to be driven more slowly. There are a lot of examples in LabVIEW, and on Google to get you started there.

Using simulated DAQ I could reproduce. (LV2010 sp1) Stoping->Closing the DAQmx event without using the unregister event primitive did however seam to work. (Again I am on simulated devices) I could also re-register the task.

If you want to manually pick where each of the measurement areas are, cursors may be a good start. It would be easier once you have the cursor positions, to calculate the periods. Trying to pick those measurement points automatically would be a whole lot harder. The signal processing toolkit may help there....and a whole lot of work. Manually, your main challenge would be to make a UI that is fairly intuitive.

Now we just need the android/mobile windows versions.

I have had problems with various firewalls when doing this. The debugging tool is very sensitive to low capacity, medium-high latency networks. It will work, but I have had it crash/timeout often when not on my LAN.

It is good that the installer worked, I am guessing that it updated some libraries that were flaky.

Have you tried building a separate test app. "Hello world" - Do nothing sort of App. Easy and quite to create and build, would tell you if your app, or LabVIEW is triggering the crashes.

NI also does offer support for their products. You could try their forums as well. (If you do, then post the link here.)

Hello,

If I had custom drivers for an instrument/device, how can I "import" them to Labview so that I can use it to communicate with the device and acquire data?

Thank you in advance

It depends on the driver. For DLLs you can use the "Call Library Function Node." You have to know the function calls, the node will try to guess only the function names. Each function prototype must be entered. .Net stuff can also be used as well to communicate to the driver.

Hi,

I found a broken link, at least on Firefox 4. The premium membership on the drop-down user menu (Top left of page) is giving a 404, not found. The "Membership" link in the navigation bar works though. (below the LAVA logo)

There is a timeout input on the "DAQmx Read.VI." I believe that it will return an error if it times out, so yo u will have to handle that too.