Aristos Queue

I second what Jeffery said - it's not a question of being able to explain the error after it happens, it's a question of knowing exactly what errors might be generated so I can make intelligent choices of how to handle them at run time in my deployed applications. Seems there should be a better way than just trying as many potential run-time scenarios as one can think of and then writing the code to handle the errors generated - what about those scenarios you didn't anticipate? Now I've potentially got a customer calling and asking why his system just generated some error that shut down his test when if I had explicit knowledge that error could be generated I might have been able to handle it much more elegantly.

QUOTE (jdunham @ May 20 2009, 11:53 PM)

With a measly 6000 error codes. We've used a good portion of them, and undoubtedly they would conflict with other users' codes if were were ever to share code. I don't suppose we could have a few more of the 4 billion codes available? Whom do we have to waterboard to make this happen?

As of this morning, the range 500000 to 599999 is now reserved for users.

In LabVIEW 8.6 I am unable to horizontally shrink the project explorer window below a certain point (~ 360 pixels). This used to be possible in previous LabVIEW version (ex LV 8.2). Is there a way to re-enable this (maybe an ini key)?

QUOTE (Black Pearl @ May 20 2009, 08:38 PM)

This is a historical flaw, I don't remember why that happend. They had no central repositiory for the error these times, maybe. But yes, every user is reporting you a GPIB error and never ever a file error.

The common NI Error Code Database came into being in LV 6.1. Prior to that, every group had its own error codes, and of course, every group started counting at 1... except for one group ( I forget which) that actually used error code zero as an error. Ug. Nowadays we have reserved error code ranges for different products, and we offset the errors coming from the operating system into their own region. There's even two ranges reserved for our customers. :-)

We had a bug appear in the development version of LabVIEW this week. It was the kind that makes developers ask questions like, "How did that happen and if we don't fix it can we call it a feature?"

Let me stress that this isn't a bug in any shipping version of LabVIEW.

The bug: Mass Compile only runs to completion if you keep moving the mouse. If you stop moving the mouse, mass compile hangs. The faster you move the mouse, the faster mass compile runs.

I and a couple others spent three days hunting this bug down, but along the way, there were many comments about the introduction of the new "LabVIEW Fit" -- a new product for building arm endurance in LabVIEW users. Imagine all these buff programmers (well, buff in one arm, anyway) showing up at NI Week, where we hand out t-shirts that said "I compiled vi.lib!" on the front. For the less athletic, NI offers new hardware: a mouse that moves back and forth for you. For only $100, you could buy the new NI Metronome Mouse so you can practice piano while you wait for your mass compile to complete.

Other suggestions included

-- the manual progress bar, where users had to click on each pixel themselves to advance the progress bar, one pixel at a time, thus solving the problem of inaccurate progress bars

-- "click the gopher" web ads -- if you click the gopher, you win a million dollars in Viagra and home mortgages!

Alas, we did finally find what the issue was -- XControls were waiting for UI events that would never come during a mass compile -- so these fantastic features will never be. But I thought our users would like to know that we never stop thinking about ways to improve your lives.

:-)

So XControls are for visualisation OUTSIDE of the class?

QUOTE (shoneill @ May 19 2009, 05:19 AM)

Has this been fined as a bug? I see it as a major problem as it makes LVOOP and XControls almost mutually exclusive whereas they shoiuld really be a perfect match.

An even bigger known issue: Do not create a circular link from your XControl to your class. In other words, write your class completely and then write your XControl using the class... do not put the XControl or any property/invoke node for the XControl into member VIs of the class. The circular load leads -- sometimes, most commonly in a built app -- to VIs that are permanently broken and no matter what you do the run arrow will not become fixed.

QUOTE (kchc @ May 14 2009, 12:31 PM)

1) How do I know what vi object class should be used for what sort of node?

QUOTE

Use the Create New Object primitive which is not found anywhere in the palettes and is not addable through any ini token magic. You have to find an unpassword protected block diagram somewhere that has that primitive on it and copy it. I think OpenG has some scripting tools that expose this prim.

The answer will be different depending upon the architecture of your XControl. I think you'll need to post a screenshot of your block diagram for your Facade.vi and your caller VI for anyone to be able to help.

Use the private scripting method "Read Link Info" and scan the returned list for the item in question. The link info is all of the dependencies this VI has including subVIs, typedefs, classes, xcontrols, libraries, etc.

QUOTE (Black Pearl @ May 8 2009, 11:18 AM)

One way to avoid that issue would be to have a required error in/out terminal on the for loops (with shift register behaviour) and an optional terminal 'allowed to execute 0 times'. But that would make such a basic concept a bit too feature-rich for standard users.

I posted earlier that you should just wire the N terminal out of the loop to know how many times it executed. This was corrected by someone else who said that only applies as long as the conditional stop terminal is not wired. I am stunned that no one pointed out this deficiency before now. We had this big public brainstorming over on ni.com to come up with all the use cases and issues with adding a conditional stop to the For Loop and no one mentioned "there's no longer an easy way to find out how many times it executed." That's an amazing blind spot on the part of all of us.

But this works:

http://lavag.org/old_files/monthly_05_2009/post-5877-1241809248.png' target="_blank">

If you are a Premium Member you can just delete the post.

_

QUOTE (PaulG. @ May 7 2009, 01:13 PM)

When a loop runs ONCE why is the iteration count 0? How can something run once yet still run 0 times?

QUOTE (Gary Rubin @ May 7 2009, 12:09 PM)

Because most people want double type for the numeric. But it is really nice on the BD constant to drop it and then, if you need floating point, to type in a value using a decimal point and the constant will automatically change to double type. If it dropped as double by default, if you typed 3, we wouldn't be able to assume that meant you wanted an integer.

We'd probably do the same thing on the FP except that most people never type into the thing that drops onto the FP... they just leave the value as zero (and you wouldn't want it coercing to a new type everytime you typed a value into it while you were debugging!).

RED ALERT. This is a LV crash waiting to happen. This is a very very very dangrerous piece of code: QUOTE

Let me explain what you have done: You have taken a control reference of one control and used the Type Cast to unconditionally change the type of the wire without changing the value of the wire. You are now calling operations on a cluster refnum that are only defined for a boolean refnum. The Value property itself may work at the moment, but you are one change in LV's source code away from crashing entirely if someone in R&D writes any code that assumes "if the type is this then I can do this" where "this" is an operation not defined for clusters.

I don't care how cool you think this is. It is fundamentally unsafe code. Normally if LV crashes that means there's a bug that LV R&D should be fixing. Hard casting refnums is one of only two ways that I know of that users can write code that can crash LV itself that is not a bug (the other being calls into a badly written DLL). You *can* get lucky on individual functions and not crash, but even then you cannot be sure that you are getting back meaningful results. Unfortunately, sometimes it doesn't crash and sometimes the results are meaningful, which can only encourage you to do this sort of thing more.

If you want to cast refnums, you should use the To More Specific and To More Generic primitives. If those prims give you broken wires for a given cast then that is a cast YOU ARE NOT MEANT TO BE ABLE TO DO. The Type Cast allows this hard unrestricted casting because there are cases where you are only using the refnums as lookup table numbers or something like that. It is not meant for changing types and then actually invoking methods.

Why the thumb up? 0! is factorial 0 not !0 (logic complement)

You can also use the Semaphore palette to protect the calls to your DLL. Wrapping the DLL call in a subVI is usually the easier solution, but if you're calling different functions within the DLL then sometimes using the Semaphores is simpler.

It sounds like you are doing something along the lines of a decorator pattern.

That's a flaw in our documentation scheme. All four of the "Available with..." fields in the help apply ONLY to methods and properties of VI refnums, but those four fields get printed for help for all of our properties and methods. Ignore them.

All VIs In Memory correctly returns all the VIs in that application instance including standard VIs, control VIs, poly VIs, global VIs, and custom probe VIs. I don't konw what it does with the pseudo VIs (such as the clipboard VI or the proxy VIs that are created when one app instance makes a remote call to another app instance). Those aren't really VIs as customers know them, but they have attributes that make them look like VIs to many of LV's underlying subroutines, and they do appear in the VI Hierarchy Window, so maybe they're in the list too, but I can easily see them not being there.

[LATER EDIT] I talked with our tech writers. This bug in our documentation process has already been reported and will be fixed in the next version of LabVIEW.

So does invoking a property or method cause Labview to copy the data in an object? Or is it all pointer arithmatic.

Ummm. Maybe it had something to do with this statement from Ernest.

QUOTE (ShaunR @ May 3 2009, 03:37 AM)

I disagree. IF it worked as it says on the tin (or labview help in this case), this is exactly the scenario where you would use it. Says nothing in the help that it won't work on classes (and they ARE vi's so it should, as in I would see that as a bug too). A slight performance hit using it is better than using up so much memory that you start using the swap file which would be even worse.

QUOTE

And although you might be correct in your diagnosis, I would like to hear confirmation of that from Ernest. And even if you are correct in that there is a large data allocation somewhere that is being copied too often, you have no evidence that it has anything to do with LV classes other than that it happens to be occurring while running one of the member VIs. Problems with large waveforms, strings or arrays can appear in many places. I get multiple bug reports each week assigned to my team that something is wrong with LV classes simply because there's a member VI somewhere in the VI hierarchy without anyone doing any analysis of where the problem is truly coming from.

QUOTE (ShaunR @ May 2 2009, 09:50 AM)

The Request Deallocation function might be of use here

A) Known issue: in LV8.2, 8.5 and 8.6, the Request Dealloc prim does not affect allocations of LV class objects. So any objects allocated in the dataspace of VIs -- not just member VIs, but any VIs -- will not be deallocated by the prim. That does not mean they are leaked. We simply leave the allocations in place. This bug will be fixed in the next release of LV. (It is not listed on the official Known Issues page because it was discovered relatively recently. This prim is very rarely used, as demonstrated by the fact that it took 3 versions of LV before anyone noticed it wasn't having any effect.)

B) Using this primitive often creates more problems than it solves performance-wise. I have a strong suspicion that it would not be desirable to use this even if it did affect LV class instances. Besides, Ernest already found some manual mechanism that he tried... I'm curious what that mechanism is. I think we need to know that before we can recommend solutions to the problem he is seeing. If he really does want the entire VI to leave memory, for example, the Request Dealloc prim is not the solution.

Step 1. Use Edit >> Select All on the front panel to select all the controls/indicators/free labels/etc.

Step 2. There's a ring on the front panel just to the right of the Run Arrow that is the font ring. Click it and select a larger font size. All the selected objects will get larger.

ALTERNATIVE:

Drop all your controls/indicators from the System palette. The controls in that palette are tied to the operating system settings. I assume that the default font on a touch screen is fairly large, so when you load those VIs on a touch screen, the text will be larger. Note that system controls also change color based on your OS settings.

Hello, Ernest. I am the lead architect for the OO features.

I do not understand your questions, in particular these two lines:QUOTE

I have been quite surprised to see that, every time I called a method of the said class, the corresponding vi remains in memory.

In the first, if a VI calls a subVI, the subVI typically stays in memory. Why do you think there would be any difference in behavior if the subVI is a member of a class? Could you be more explicit about the unexpected behavior you are observing and why it is unexpected?

In the second, LV doesn't have a "delete" or "freemem" command, so I am not sure to what you are referring. Could you describe this manual method that you're using?