Aristos Queue

Affects both 8.2 and 8.2.1.

There is an issue with generic probes of LVClasses. The problem arises only when a parent class uses another class as a data member and you probe a wire of a child class.

Assume 3 classes: Parent, Child and Other. Child inherits from Parent.

Parent's private data cluster contains an instance of Other.

Other's private data cluster contains a numeric.

Child's private data contains a numeric.

Set the value of Child's numeric to be 10, then probe a Child wire. The 10 will show up in Other's cluster. In this case you simply get misleading information in the probe, which is bad enough. But if Other uses a string instead of a numeric in its private data control, the 10 will be written where the address of the string is supposed to be in memory, leading to a crash (since 10 is not a valid memory address).

This issue is known and will be fixed in the next version of LabVIEW.

Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

Amazon.com has started a very cool site:

http://www.mturk.com/mturk/welcome

The basic idea is to use human intelligence to augment artificial intelligence. So a search query comes in "find the cheapest pizza joint along the path from my house to home that does carryout". There's no one database to check for this information -- google maps might find all the pizza places, but comparing prices and whether they do carryout requires visiting the pizza restaurant sites. But a human being behind the scenes could answer this question. So Amazon.com has established a brokering system so that you can post a question, for a price, and another person can answer it, and get paid for doing so.

The interesting use of this is in beating CAPTCHAs -- a spammer that faces one of those "type in the word you see in this image" that is supposed to block robots can automate the posting of a question to the Amazon.com site and then posting the human's answer back to the original website, thus giving the robot the ability to get past the CAPTCHA. It costs a bit of money, but for some activities (online polls, marketing buzz, etc) there would be financial gain for doing the post, so it may be viable.

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 02:33 AM)

there needs to be some kind of handshaking where the caller waits for confirmation that the VI is running before continuing.

... such as having both VIs obtain a reference to the same named notifier. The VI that needs to be running uses Send Notification to indicate that it is running. The VI that needs to wait until the other is running does a Wait For Notification and thus doesn't proceed until the notification is received. If it happens that the first VI gets up and running first, that's ok, it just means the message is there and waiting for the second VI so it doesn't have to wait.

QUOTE(mateo @ Jun 26 2007, 11:52 AM)

Dear friends,

I am using the IMAQ JPEG DECODE and IMAQ JPEG ENCODE but this 2nd VI waste a great amount of system memory. I think the cause is the Call Library Function Node called "IMAQ_JPG_JpegBuffer2Image" but I don´t know how to dispose the memory allocation.

Could anybody help me? Thanks in advance.

You might try placing the "Request Deallocation" primitive on the block diagram of the VI that is too big. Read the documentation before using this primitive. It explains the how and why this prim might help and the time/space tradeoffs you'll encounter.

QUOTE(yen @ Jul 9 2007, 12:43 PM)

Also, 8.2 and later now remove code like this when you build the application, so you can't use this to hold VIs in memory. I assume the same happens with the disable structures, but I'm not sure.

True. The diagram disable structures do not hold VIs in memory. If you need to hold subVIs in memory without invoking them, use the Static VI Reference node (found in the Programming>>Application Control palette).

Prior to the diagram disable and conditional disable structures in 8.2, you could just drop a case structure and wire a constant to the ? input. This wasn't a complete commenting out -- if you had a broken wire inside the case structure, your VI was still broken, unlike the new diagram/conditional disable structures. But it did guarantee that code would not execute. That trick still works in 8.2, but the new strutures, as I mentioned, do a more thorough commenting out.

QUOTE(lraynal @ Jul 2 2007, 07:26 AM)

Here is an other web site with lot's of Icons, I really like:

http://www.gbcdepot.com/icone/''>http://www.gbcdepot.com/icone/' target="_blank">http://www.gbcdepot.com/icone/

What are the licensing restrictions on icons on this page? Some of these icons include trademarks, so I can't imagine that these are all free-and-clear for use in other programs. I couldn't find any licensing information on the website anywhere.

QUOTE(MikaelH @ Jun 14 2007, 05:13 PM)

Limitations:

First: You can't set a dynamic dispatch method to be reentrant.

Second: You can't call a dynamic dispatch VI using the "Call By Reference Node"

In most situations, you can get around the Call By Ref limitation by creating a static VI that just calls the dynamic subVI, and then using Call By Ref to invoke the static VI. Not as nice as being able to do the invocation directly, but it does work.

As for the lack of reentrancy on the dynamic dispatch VIs, let me just say that I think that's a serious limitation of the language and some NI software engineer ought to do something about that in a future LV version.

By the way, to Jan, Mikael, Tomi, and Jim,

I was knee-deep in work for a future LV version when the toolkit released, so I never got a chance to say this formally and publically: Congratulations and thank you. Your tool is a valuable addition to the OO resources of LabVIEW.

-- Stephen Mercer

-= LabVOOP Lead Engineer =-

QUOTE(Karissap @ Jul 3 2007, 05:37 PM)

When you expanded the node all the event types were the same (Value Change). LabVIEW is probably just only taking the control refs to the first Value Change and ignoring the rest. I agree that this seems a bit counter intuitive and should probably be documented that you can't select the same event twice somewhere if that is the case.

Please file a bug report against the documentation so this can be noted in a future LV version.

QUOTE(alukindo @ Jul 5 2007, 01:45 AM)

Hi NI Engineers:

Please register your request using the http://digital.ni.com/public.nsf/allkb/EDA7C01C684ACB6286256FF0000238D5' target="_blank">Product Suggestion Center.

QUOTE(ntward @ Jul 7 2007, 04:17 AM)

Hi all,

I'm new here, and new to LabVIEW. I've done a lot of reading recently, but I'm a bit stuck. Apologies if this has been asked before, I've tried searching but I'm not certain what I'm looking for!

I need to make a control which is also an indicator (in the sense that it reflects it's output state as well as an input). I know I can customise standard controls, but I can't figure out how to do this. Any tips, pointers, suggested help topics etc. greatly appreciated.

To explain more clearly: My control needs two states; on and off. When on, the control will open a valve (I've got all that sorted). A micro-switch measures the position of the valve. If the valve has failed to open (i.e. control output and input differ) then I want to indicate this by altering the background colour of the control.

Thanks for any help...

There isn't any "control and indicator" concept in LV. Data enters a VI at controls, and leaves a VI at an indicator. In your case, input says either "open" or "close", the VI executes to do the operation, returns the current state of the valve and then the current state is compared against the original input, and the results of that comparison are displayed in an indicator. This would be fine for calculating the value, but what you're describing is that you need the composite behavior not because of any calculation of value work but instead to provide a nice user interface. <joke>There goes UI, messing with the purity of dataflow again.</joke> There are two possible solutions.

The first is to physically stack the input control on top of the output indicator on the front panel. You might put the boolean indicator as a background behind the control. For some user interfaces, this works fine. To some degree, it is my preference, since if the control itself changes color/state to indicate an error, the user may think he/she can no longer use that control. But there are user interfaces where this is desirable, so the second option would be using a property node to set display properties of the control programmatically. You can right click on any control on the front panel and select Create>>Property. Drop the resulting property node on the block diagram and choose the property that you'd like to set.

QUOTE(LV Punk @ Jul 9 2007, 06:17 AM)

I did learn that you can't use Get VI.Icon on an XNode; the Get Palette Info cluster indicates that the Path Item Type is VI but the method doesn't work; the U8 array does contain the image though (with the same transperancy/color table issue I have with the other built-ins...)

Hm... you should probably file a bug report on this.

Service Locator also gets involved with online help. If you look up a primitive in the online help, there's a button to show that prim in the palettes. Service Locator brokers the transaction from the html back to LV. Similar for the "open examples" button in the online help.

I've posted an example to NI.com that does this:

http://community.ni.com/examples/scrolling-led-xcontrol

I'm pretty sure that OpenG has some better array sorting/searcing VIs that let you pass in a VI Server reference to do the comparison, so you just write a compare function that compares the desired element of the cluster and returns greater, equal or less. I saw something like that on Jim Kring's screen when he won the LV speed programming competition at NI Week a couple years ago.

QUOTE(zoogies @ Jun 25 2007, 01:11 PM)

I do this a lot: have some messy, ugly, or tangled wires running together, and going through each one, right clicking, and pressing "clean up." Is there a shortcut for this, or better yet, a "clean all wires" shortcut?

No. And you're not the only one who wishes for such a tool.

QUOTE(jzoller @ Jun 22 2007, 01:40 PM)

If the probe is for a refnum, the XControl will keep the refnum alive even after execution finishes (as long as the probe is open). This allows modification of the data and properties in anything with a reference from within a relatively simple probe.

The probe would have to be the VI that *opens* the refnum. A refnum goes invalid when the VI that opened the refnum goes idle even if you pass that refnum to some other VI by some means. The other VI can be using that refnum and the number will start returning errors for invalid refnum when the original VI goes idle.

With something like the queue or notifier refnums, you might be able to look up the item's name and open a new reference to the same item. But for file refnums and similar, there's only one refnum and when it goes stale, there's no other way to get the reference.

QUOTE(Jim Kring @ Jun 14 2007, 08:59 PM)

I've heard that the reason A-->B-->A recursion isn't allowed is simply to avoid infinite recursions (protect us from ourselves, which is really annoying).

If we were protecting you from infinite recursion at runtime, you'd be correct that we were just protecting you from yourselves and being over-parental. No, the problem was infinite allocation at compile time. Just the act of dropping a node would create infinite allocations. The definition of reentrancy -- every node has its own instance to execute. If every node has one, then it's like staring into a mirror just to initialize the VIs.

QUOTE(crelf @ Jun 11 2007, 06:43 AM)

Thanks Aristos - do you, or anyone else you can find at NI, have anything to add about the "required" vs "recommended" terminal debate?

I don't.

QUOTE(Tomi Maila @ Jun 11 2007, 06:18 AM)

beyond the limits of native by-value LabVIEW OOP

*grin* *rolling of eyes*

Some users are never satisfied.

In any case, good work, gentlemen.

QUOTE(Jeff Plotzke @ Jun 10 2007, 05:24 PM)

That's interesting... So, does this mean that a built EXE actually contains some intermediate language (in the LLB) that's interpreted by the runtime engine or does LV actually generate the machine code while it builds?

No. I'm not sure why Rolf thinks the assembly code isn't in there somewhere. The assembly code for all the VIs is definitely in the EXE. The initial code is going to start the EXE, and then start executing "clumps" of assembly as they become available to the thread scheduler (the top-level VI schedules its initial clumps to run... as each clump's inputs become available, they join the list of clumps that can get executed). LV doesn't have a call stack for subroutines -- just the scheduler picking up a clump, executing it, then scheduling the next batch of clumps. Anyway, the long and short of it, there is assembly code in there for the VIs. I don't know why you're not seeing it.

This is probably the sort of information that you're not supposed to know -- because you're not supposed to be reverse engineering the assembly according to the license agreement -- but I figured I'd tell you because I don't want some rumor to start up that LV is somehow an intermediate interpreted language like JAVA. That sort of nonsense would just contribute to perceptions -- right or wrong -- of LV as not a real language and too slow for real work. LabVIEW is a compiled language.

QUOTE(Michael_Aivaliotis @ Jun 9 2007, 08:17 PM)

Does this work in an executable?

Yes.

LabVIEW classes know how to translate old versions of themselves into the current data format. Typedefs do not have this expertise. So if you flatten an instance of a LV class, then edit the class (add a field, reorder the fields, delete a field), and then read the old version, the same changes that you made to the class (add a field, reorder fields, delete a field) will be applied to the read data in order to make it match the new version (any added field is added with the default value).

QUOTE(tcplomp @ Jun 9 2007, 12:41 PM)

How long would it take before:

1. Aristos says LVOOP
   

A bit over 4 hours...

QUOTE(torekp @ Jun 6 2007, 06:50 AM)

I'm getting error 1401 when trying to read datalogs that I created in 8.20.

"Error 1401 occurred at Read Datalog in SG.lvlib:toplevel_read_datalog.vi

Possible reason(s):

LabVIEW: Attempted to read flattened data of a LabVIEW class. The version of the class currently in memory is older than the version of the data. You must find a newer version of the class to load this data."

What the ...?

That would be the version of the class file itself, not the version of LabVIEW. Be careful not to confuse these two version numbers.

LV8.2 has annoying behavior that frequently (but not always, which while still wrong would at least be less annoying) when you build a class into a built app, the version of the class in the built app has its version bumped and is no longer the same as the version used in the dev system. So one place that you might encounter the error you posted is when trying to use a built DLL in the development system. Your dev system has class version 1.0.0.0, and the class in the built DLL is version 1.0.0.1. When data tries to pass from the DLL to the dev system, the dev system doesn't know how to handle the data -- the data is from a version of the class that the dev system doesn't know about. (Data can pass from the dev system to the DLL because the 1.0.0.1 version has instructions for how to load and mutate old version of the data -- in this case, no mutation is necessary because the data types are actually identical, but the dev system has no way of knowing that fact when it tries to unflatten 1.0.0.1 data).

The use of classes in built apps has been hammered inside NI over the last couple months and there'll be significant improvements in the next full version of LV released. For now, there are a number of posts on DevZone and here that may help you figure out a workaround now.

You should probably move this post over to the GOOP forum and have a separate thread. Various folks on that forum may be able to suggest a workaround for you. It's a definite tangent from this thread on 8.2 vs 8.2.1.

QUOTE(Gavin Burnell @ Jun 5 2007, 07:06 AM)

Does the while loop actually do the allocation on every iteration ? - I thought I'd read somewhere that it allocates in chunks of increasing size and then deallocates anything left over when the loop finishes. Did I totally dream that ?

Amortized growing vs allocating on every iteration... I don't actually know which one the while loop does... I'd assume its the smarter of the two. But the details weren't really relevant to my point -- it doesn't have oracular abilities, so there's reallocation at some point regularly during the execution of a while loop. Even the smarter of the two algorithms is still less efficient than the For Loop and would account for the recollection of user eaolson.

QUOTE

Yes.

QUOTE

At first I thought you just wanted the functionality of the "Cluster to Array" primitive. But you're actually talking about being able to index the cluster, not necessarily convert it to an array. An interesting idea.