This list has been reported to NI as problems existing in LV 6.1. I am hoping to put all of these in a single place available to the info-labview community.
Meanwhile you can use this workaround (suggested by NI):
"The behavior can be avoided by using the Select a VI palette function to place it on a diagram as it loads a copy of the template."
Status: Verified in LV 6.1 Platforms: All
It turns out that this is a problem installing the DSC toolkit. The labview.ini file is modified to have an incorrect list of serial
ports. There is a spurious double quote at the beginning of the list. (or lack of a quote at the end). Editing the labview.ini file
will fix it.
Corrected Platforms: Mac
Greg Mckaskle replies immediately... This shouldn't show up in prior to LV6 since I'm pretty sure it is caused by sub-arrays. These are
an efficiency type added under the hood so that more items can be inplace. Bugs like this were found and fixed in the LV6 beta, but
obviously not all of them.If you need to work around this, you should drop a single element biuld array set to concatonate mode. Do
this upstream of the sort and that should fix the problem. I'd also suggest a comment explaining why this "useless" looking node was
placed in the wire.
Every time I try to query or set the VISA attribute 'wire mode' VISA returns an error ''0xBFFF001D', implying that the hardware doesn't support the attribute.
Dan Mondrik (aka Dr. VISA replys):
Yep, I'm lurking. Yep, it's a bug. It works fine on Windows 9x and on NT 4. It's only a problem on 2000 and XP. Unfortunately, that means you, and there's no workaround we could find. We will fix this in our next version, which is planned to be NI-VISA 3.0. I don't have a non-debug build right now but if you need it, let me know directly and I'll see what we can do for you.
Therefore, I pressed on "Add your comment" at the bottom of the page to signal it. The answer I received by email from NI was quite
disappointing: "It appears that you are correct; however, since the "DIFF L" and DIFF H" indicators are not used downstream in the VI,
it's somewhat of a moot point. The subtraction can easily be corrected by rewiring to obtain "DIFF L" from "2L" - "L". Again, since
"DIFF L" is never used, this doesn't really even matter."
Platforms: Win (All)
Corrected Platforms: Mac, Unix (not applicable, uses CIN)
Status: Not tested in LV 6.1
The problem is most noticeable when you exceed your limits. Set the proportional gain to a large value, and use a setpoint with a large error. The limits will be exceeded and the integral constant is adjusted to stay within the limits. Now, if you set the setpoint equal to the error, the output should be zero, but it isn't. It is still equal to whatever was used to compensate for the limit. This value is stored in a shift register in the integral routine. I ended up modifying it to always use zero, except to correct for exceeded limits.
NI response: "I spoke the the Research & Development Engineer that will be dealing with your request for a change to the PID toolkit
vi's. He was aware that for some applications this behavior was not expected nor wanted, and feels that he can change the behavior for
your. I do not have a time estimate at this time, but the corrective action request is CAR 29UG1MBQ"
Platforms: WinNT, Win98, Win2K, Mac
No example posted since PID toolkit is not public
Info from Bien Entendu <BienEntendu@mac.com>
it just happens when you uncheck "show menubar" there is a conflict with the STF Fax software. so you have three options: