SULLutions

Info-LabVIEWers:

The August 8 Digest is out. It has postings from July 20, July 19, July 29, and July 27 in that order. Progress but things aren't quite normal yet.

Paul

Gary and others,

Scott is putting Info-LabVIEW back together and you should have now received an e-mail rescinding your unsubscription. Day-to-day operations should be back to normal in a few days. The archives will take a while.

Paul

In case you are a lurker who also subscribes to Info-LabVIEW, Scott is having severe troubles with the server. You can see that on his site http://sthmac.magnet...efu/index.html. I'll try to keep you updated on mine: http://www.sullution...l#DigestStatus.

Paul

This has been reported as a bug, CAR # 154260.

The work around is to fill in the description--but you should have done that to start with.

QUOTE (Cat @ Mar 19 2009, 08:27 AM)

...I don't know much about object-oriented programming in general...I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP.

Cat,

Looks like things have wandered far from your original question. I can't answer the part about how the NI course is taught, but I have (long ago) had a formal course in Object Oriented Programming in C++ and I also own Conway and Watts "A Software Engineering Approach to LabVIEW". I found the book to be much more helpful in easing me into the OOP world. It doesn't get you all the way there, but it does show you why you should explore OOP and teaches you how small modifications to your current coding practices can give you many of the advantages of OOP.

QUOTE (crossrulz @ Mar 18 2009, 03:31 PM)

SULLutions,

Can you repost a newer version of your abort vi? I'd just like to see how you handled it.

Sorry, I thought I had posted an update long ago. Guess I should check my site more often. Here is a LV7 version that is a little better than the original LV5 and this is what it looks like:

And I learned the right way to post a BB link today.

Yesterday I was exploring an unfamiliar VI and turned on the context sensitive help to try to learn more about it. I was puzzled when I hovered over what appeared to be Boolean buttons on a Tab control and the help window indicated "No description available" (not surprising), but on an I32! Reordering the controls didn't help. With some experimentation, I discovered that controls with no description on a Tab that also has no description show as I32s in the help window. The Tab also shows as a generic I32, rather than a Tab. If the Tab has a description, even a single space character, then it and undocumented controls on it show as Tab controls. Any control with even a single space character in its description is identified properly.

The NI forum requested a posted example and I supplied the following detailed description of an experiment instead:

I see it in 7.0 on the Mac and 8.6 on Windows and Mac. In 7.0, the I32 indication doesn't show but the Tab's label will show and you can see its help window has precedence over the control's if only the Tab has a description and that neither is active if neither has a description.

I don't readily see how to post an example, but just start a new blank VI, drop a Tab on it, and drop a Boolean (or any other control) on that. Place a different control type (an Enum, for instance) directly on the front panel. Turn on context sensitive help.

When the mouse is on the panel but outside all controls, the help window maintains its last display. If you move over the control that is directly on the panel, its label and "No description available" will appear. If you move anywhere on the panel, over the Tab, or over the control on the Tab, the help display does not change. Add even a blank to the description of the Tab and the help window will change to show the Tab's label when over it. Add anything to the description of the control on the Tab and it will become visible to the help window. Delete either of the descriptions and that control becomes invisible to the help window again.

Note that the (Enum) directly on the panel is always visible to the help window whether or not it has a description.

Looks like a bug to Yair and me. Any comments?

QUOTE (Gary Rubin @ Jun 19 2007, 03:57 PM)

... Also, it doesn't seem to work on structures in 7.1.1. I see the context help for the structure, but it doesn't include my description like it does for other objects...

When I add a description to a structure, I overwrite the structure label. I either mention the existence of the description there or color the label distinctively and indicate the meaning of that coloring elsewhere on the diagram. That way I at least know which of my own structures have been commented. An automatic flag would be much better, but for now...

QUOTE (Mark Yedinak @ Mar 18 2009, 01:24 PM)

... when we catch the abort we can inject an abort state into the running state machine and exit gracefully...

Mainly for lurkers,

The abort, being an abort, is likely queued "at the opposite end" so it takes precedence over regularly scheduled tasks. The simple insertion responds neatly between the regular cases of the queued state machine. Anywhere that has access to the queue can Preview Queue Element to truncate its own lengthly operations. If there are prolonged periods within subVIs that don't already need the queue, the LV2 global is probably a better solution.

Cat,

No one deprecates LV2 (or intelligent) globals. A zillion years ago, I came up with my Running Global <http://www.sullutions.com/LabVIEW/GUIasSubVI%20Folder/Running.zip>, mainly for stopping parallel loops. Lately (since LV7.0), I've used it with event structures. The Value Change event of the abort button "stopping" this VI and a sprinkling of read-only copies (or even stoppable ones where the code detects that the test should be aborted) at suitable places throughout the code would be an easy retrofit to any code and may assuage your feelings.

On the other hand, one little global does not merit sack cloth and ashes, even during Lent.

Someone posted to Info-LabVIEW that he had a similar problem with the IMAQ toolkit and asked for detailed instructions for fixing the problem, so I'm posting them here as well:

Eric,

You wrote:

I temporarily put on an

unlicensed copy of IMAQ 3.8(needs to be registered) on a machine to debug

and now when I run my 7.1 app w/IMAQ 3.1(no reg needed) I get the

"unlicensed copy of IMAQ" error - how do I remove that?

I'd suggest trying what worked for me. If it doesn't work, it's easily undone.

First, run the license manager utility (Start>>All Programs>>National Instruments>>NI License Manager). Expand any collapsed entries in the folder structure in the left pane until you find an item whose status square is half red and half white (in your case the IMAQ 3.8 toolkit). According to the license manager help (under the index item "environment") and the "Status" item in the right pane, such a box indicates an evaluation license that has expired. (If it were a fully featured license that expired, the box would be completely red but the same procedure would apply.)

Next open the ..\Program FIles\National Instruments\Shared\License Manager\Licenses folder in Windows Explorer. You'll find a number of files with a .lic extension and cryptic names that refer to the package and version to which they apply. (LabVIEW_PDSM_PKG_080200.lic is for the LabVIEW Professional Development System with MathScript version 8.20, which was causing my problem. I can't tell what the code would be for the IMAQ toolkit since mine is also an earlier version but I'd guess it would start with LV_IMAQ or something similar.) Add an additional extension of .bak to the .lic file you think is causing the problem so it now is called, e.g., LV_IMAQ_030800.lic.bak and click Yes in the warning box about the file becoming unusable. (With this scheme, it will be obvious what you were trying to do and it will be easy to reverse if you chose the wrong file.)

Return to the NI License Manager window and choose Options>>Refresh (or hit the F5 key). The license you've disabled will have disappeared from the list. If it's the wrong license, just erase the .bak extension, hit F5, and it should reappear. Try another likely candidate until you find the right one.

Finally, try your previously failing program to verify that you've fixed the problem. If you haven't, erase the .bak extension and call NI for help.

I just got a call back from Justin Fuller at NI. The problem was an expired evaluation license for 8.2 Professional Development System with MathScript. According to Justin, an expired 8.2 license can interfere with licenses for earlier versions. This is not always the case: I have the same expired license on my other Win XP machine, where LabVIEW 7.0 still runs fine. Simply adding a .bak extension to the expired .lic file hides it from the license manager and allows LV7 to function properly. :thumbup:

This morning LabVIEW 7.0 will not run on my (Boot Camp) Win XP machine because the license has "expired", but the license manager utility lists the license as never expiring! (See attached screen shot.) It ran fine last week. It runs fine on another XP machine with the same licensing. :headbang: Anyone got any idea what's wrong and how to fix it?

Are there so many people going you've overloaded Evite? :headbang:

Norm,

Like Michael, I couldn't get your VI to fail in 7.1.1. Worse than that, I couldn't get a simplified version of my VI that apparently suffers the same problem to fail in 7.1.1 or 7.0 (where the full VI does fail) :headbang: .

It turns out that it is a Register for Events node that fails (in 7.0 and 8.0). I don't have 8.2 installed here, so I don't know if the performance has changed now. You're welcome to try the attached to see if it is what you saw change between versions.

Download File:post-1180-1157570599.llb

LabVIEWers,

In updating some code for a client I came across a property node whose output error glyphs were red:

Any idea what this means or how it happened? A new property node for this control has the normal black glyphs.

Michael,

Your solution is probably the best one for dragging the content from the control to the indicator :thumbup: but, in his original post, Simon said:

... I want the VI to clear the reference if I drop anywhere other than in the indicator...

...by dynamically registering the <This VI>.Mouse Up event, allocating it to a not-a-ref constant while the mouse is over the indicator.

, while too sketchy to be definitive, certainly has the potential to do so.

As a general programming point, tying the empty string constant to the frame of the while loop in your example does not ensure that the indicator is updated before the loop starts. In this particular case, operator response times are too long for the wiring to make any difference, but I have been bitten by this configuration when the machine response was too fast (commonly with my Running Global.vi utility). Your wiring only requires that the constant be read before the loop starts. (You can verify this by dragging the local variable upward and exposing the direct wiring from the constant to the frame of the loop.) To ensure that the indicator is updated before the loop starts, enclose the constant and the local variable in a single frame sequence. (The constant need not be in the sequence as long as the wire to the loop comes through the sequence, but I think putting both there is more explicit.)

Paul,

... The more usefull (in my opinion) is the recursive VIs that look for Diagram object (such as the one seen on the above image you mentioned), and I think its accessible through relink all vi by name example or clean all wire (which are part of the palette as well) .

Happy digging.

PJM

3713[/snapback]

This is PJM's personal palette. Perhaps with a little coaxing, we can get him to submit an openg package with these goodies...

Thanks, Michael. I'll give him a nudge, but I'm not sure how much weight I carry.

I believe the closest thing OpenG has to scripting is the ogmnu_appcontrol_plus package.

Only three functions instead of the zillions PJM tempts us with?

PJM,

This was indeed what did stop me initially, but once I recognize (like you did) that a diagram is very similar to a giant cluster, I went on writing my own recursive VI to get different type of objects on the diagrams (such as Functions, SubVi, Diagram, Wire, Decoration, All Objects ).

In the thumbnail attached to this post, there is an apparent OpenG Scripting palette. I can't find it on this or the OpenG site. Is it available?

I believe this this what you are looking for.

Thanks, PJM, that is exactly what I needed. :thumbup:

So, guys, does a hierarchical list of class specifier constants exist yet? I couldn't find it on the site.

Specifically, I'm currently looking for the highest levels at which I can elicit the Label.Text property.

A merge VI from the LabHSM package created with LV 7.0 on a PC reproducibly crashes Mac or Linux systems running 7.1 or 7.1.1 during the merge process. (It works fine under all versions on PCs and under 7.0 on Macs.)

By whittling the VI down, I found that the culprit was an error case structure. Removing and replacing the case structure, whether on a Mac or a PC, cured the problem. Apparently, the exact sequence in forming the case structure introduced a subtle error.

NI is investigating, but has no result so far.

If you see this problem, suspect case structures.

A merge VI from the LabHSM package created with LV 7.0 on a PC reproducibly crashes Mac or Linux systems running 7.1 or 7.1.1 during the merge process. (It works fine under all versions on PCs and under 7.0 on Macs.)

By whittling the VI down, I found that the culprit was an error case structure. Removing and replacing the case structure, whether on a Mac or a PC, cured the problem. Apparently, the exact sequence in forming the case structure introduced a subtle error.

NI is investigating, but has no result so far.

If you see this problem, suspect case structures.