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) 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) 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: Looks like a bug to Yair and me. Any comments?

QUOTE (Gary Rubin @ Jun 19 2007, 03:57 PM) 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) 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: and your solution does not do that. :thumbdown: The approach he posted to Info-LabVIEW: , 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.)

Thanks for the hints of where to dig. I'm off.

Thanks, Michael. I'll give him a nudge, but I'm not sure how much weight I carry. Only three functions instead of the zillions PJM tempts us with?

PJM, 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?

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.