Search the Community

OpenG’s Trim Whitespace fails on a string of all whitespace, if set to trim the front only. It returns the last whitespace character.

Here is the output: No better luck with long messages: here is the result: notice the "Standard" added to the text. Windows LV 2021 SP1 64 bit

My colleagues and I use the Fit VI to Largest Decoration function in OpenG all the time, and it (usually) works like a charm. I've got a fairly small Project, a simple State Machine that takes readings from a Vernier SensorDAQ device and plots it on a graph. I'm using a Queued State Machine pattern, so I begin by creating the State Machine Queue and enqueuing the Initialize State. The first thing I do inside Initialize is Fit VI to Largest Decoration, and it throws Error 1, pointing to the final FP.PanelBounds Property node that it is setting to resize the Window. I also watched this function run with Highlight Execution turned on, and sure enough, the Error line was OK until it got to that final Write to the Property node. My initial suspicion was the SensorDAQ function, even though it hadn't been called. So I took it out, but the error persisted. I also tried making the Fit VI to Largest Decoration the first VI to be run -- same error. Ohh, an idea. The VI in question was written by a colleague, who is not big on LabVIEW style. This morning, I rewrote the entire program, keeping only the Front Panel which has, among other things, a Graph on it. This problem is so weird that it almost has to be something "unconventional" -- I'm going to leave this post here, in case anyone has other insights, but I'm then going to replace the Front Panel and will report back, especially if it fixes the problem. Bob Schor

[Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.

Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it. The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further). The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed. The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event. To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement. evnt.vi

Hey everyone, I am working on a backup function for a test executive. The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children). I like this functionality because it makes backup and reload brainless. It just works.... until now... I've got a test class for my current tester that's grown rather large. Everything works fine, until the tester loads some waveform data into either of the waveform arrays. Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted. As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class. This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error. Does anyone have any knowledge or experience with this? Cheers, Tim

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example. I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.) DVRtest.zip

There are some OpenG VIs, like the Variant Configuration File IO VIs, that use the legacy form of recursion (VI Server Call By Reference to self), which is (I believe) much less efficient than using the native recursion feature introduced in LabVIEW 2009. I would recommend changing all VIs that use legacy recursion to use native recursion, provided that a performance improvement would be gained. Here's a screenshot, showing what I mean:

Name: Help! Discovered a big bug of labview's ChirpZ Transform function(Not Sure) Submitter: bodopoq Submitted: 04 Dec 2014 Category: *Uncertified* LabVIEW Version: 2012 License Type: BSD (Most common) When using ChirpZ transform of LabVIEW(The example itself provides),I found a strange thing.When the frequency is very big and the range is small together with a not small number of ChirpZ transform,Error happened(very bad spectrum and wrong frequency ChirpZ's result is)! Nothing is wrong with the examples(I've scripted other VIs to verify this),and this error didn't happend using MATLAB. So I believe that is a bug of LabVIEW!!!(Not Sure yet of course). I Need Help! Talent Masters, Come out! Click here to download this file

One of my minions is working thought the online Core3 course and showed me some code that made no sense to me. I am wondering it this is a bug or some little known feature. In the code, he was told to wire a variant to the 'variant to data' function and wire in a path constant so the output would be a path. This was later wired to a function needing a path input. So far so good. But later in the same code (in a different case) he was instructed to do the same thing but this time there was no input to the 'variant to data' function to tell it what to cast the variant data to. But for some reason, the output was still a path and he could still wire it to another function that needed a path as input. Here is a screen grab of the magical code: So, what is going on here? Bug?

The Automotive Diagnostic Command Set (ADCS) in version 1.2.0 when used will prevent the installer to generate a preview, set properties of any application executable, and building the installer, due to a bad linked VI. The installer dialog will just show '<Error generating preview>' in the application details section. I got this issue on a new installation of LabVIEW 2013 and this behaviour has since been reproduced by an NI technician. A bug report has been filled in: CAR 429636 There is currently no way to build the installer including the application. It is not possible to add the offending VI to the library, as the library is locked & password protected. My solution was to build an installer for just the additional installers (runtimes, etc..) and to manually copy the application files to the target system. Here is a copy of the issue details from the initial thread that is also linked below. Please reffer to the thread to get more detailed information about the circumstances that causes the issue (and to see some actual pictures): ----- The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem. Add an INI key to the LabVIEW.ini NI_Appbuilder_logging=TRUE The build log is created next to the *.lvproj file and directly shows the problem. Here is the important line of the build log: The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'. ----- Notice: I was able to start the build, because the installer has already been configured in LabVIEW 2011 SP1 & ADCS 1.1.0. Here is the related topic: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

Hi, I found this bug in LV 2011 SP1 and it was reproduced in LV 2012 by an NI application engineer who filed CAR #385212 for it. Basically, if an installer build specification has values under a key that you've created in the "Registry" section and that you delete the key without having deleted all the values before the build will fail. The solution is either to recreate all the same keys and values and delete each value before deleting the keys or edit the lvproj file with a text editor to remove all the lines corresponding to the values and keys your want to get ride of. The error I was getting when the build was failing was : *** Error: An internal tool or library returned an error. (Error code -21) Error adding registry key: Name: name_of_value ************** *** Error Details: Error in MDF API function: _MDFBuildDevPart_AddRegKey nmdkAddRegKey returned error code 26051 *** End Error Report

The following VI is part of the OpenG LabVIEW Zip Library: ZLIB Specific Path to Common Path__ogtk.vi If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac. Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

So another Mac issue. Whenever I try to use the ZLIB Store File.vi, I get an (always helpful, generic File IO) error. See the screenshot. Can someone (Rolf?) help me with a workaround? I need to stick with the OpenG Zip library because of the low-level VI's it provides, which are very powerful.

We found this bug when updating from 2010 to 2012 last week. Certain types of clusters will not update over datasocket or network-published shared variable. You will only get their default data. Here are the conditions that will cause the problem: The cluster contains an array of clusters The array of clusters is not the last item in the cluster The array of clusters is empty All three conditions must be fulfilled in order for the bug to appear. An AE was able to reproduce it and it has CAR #385089.

This thread was manually moved from OpenG to LAVA.

I have posted on the NI forum (here) but didn't get any response sine 5 days. I have came across a nasty bug that caused Labview 2010 SP1 (Running Win 7 Ultimate x64 bit) to crash without any warning. To replicate the bug do the following: Add a numeric control and another indicator to the front panel Switch to block diagram and add a feed back node Connect the initializer terminal of the feed back node to the output of the control Now do ANY of the following to cause the bug: Press the run button (which is broken due to not connecting the input of the feed back node) it will turn to a normal run without displaying the error Do an extra action and undo it, the run button will turn from list error normal So far the Vi can be saved normally. Now connect the output of the feed back node to the indicator and try any of the followings: Save the VI Close the VI Create a new project and select to add the VI to the project This will cause Labview to crash without any notice! When you are at step 4, the bug is there but harmless. Once you combine it with step 5 (connect to indicator), the bug is active and cause crashing. I have attached a snapshot of how the Front panel/block diagram look like before saving (since it can't be saved). Notice how the run button is enabled although the input of the feedback node is not connected. I have tried to replicate the error on Labview 2009 but couldn't.

There's a VI in the lvdata package called Get Default Data from TD (that accepts a type descriptor input), but there's no equivalent (wrapper) for variant data input. I suggest that a Get Default Data from Variant VI be added to the library, for symmetry (and the fact that it would be useful -- I've needed such a function recently). Get Default Data from Variant.vi

I've been playing around with the variant configuration palette this week, and I think I found a bug in the Write Key (Variant) VI. The VI will insert escape characters into the section and key name strings to conform with INI file syntax. I've noticed, though, that if I use a file path as the name of a section that holds a cluster, it inserts multiple escape characters at each point, instead of just one. The image below explains it (hopefully). It looks like this bug only shows up when two conditions are met: 1. The section name contains escaped characters, like ‘\’. My section names are file paths to .lvclass files. 2. The variant key contains a cluster or an array of unknown type, causing the VI to be called reentrantly. Since the VI has to be called reentrantly, I haven't thought of a workaround yet. (Well, I guess I could restructure my file to stop putting paths into the section name, but I'd rather not have to.) I can think of two approaches to fix it, though. One is to add logic that counts the recursion in the VI and ensures that only the first instance executes the Encode subVI. Another is to encapsulate the multiply executing logic into a reentrant subVI, leaving out things like the Encode subVI so they're only called once from the main Write Key (Variant) VI.

I found a nasty bug where a control that has units associated with it somehow appears to get corrupted. When a corrupted control and a normal control are fed into the equals function, it returns false. It's not limited to controls either, a corrupted and normal constant will return as not being equal. Example vis are attached. labview bug with units example original.vi labview bug with units simple example.vi

This thread was manually moved from OpenG to LAVA.

Hello, Am I crazy ? I can't get this to work right. Why isn't my 0 column sorted? Please help answer what I hope is a dumb question. Thanks Dan

Format Variant Into String__ogtk.vi doesn't handle timestamps, you get an "Unexpected Datatype" error, as the TDEnum reports it as a Waveform. I have put in place a fix that seems to work without issue, but I can't be sure that it doesn't falsely detect timestamps when processing other types of data. Is this something that can be integrated into the release? Up to this point I just have to remember to copy my version over the OpenG version. It would be nice to not forget and break my code every time I move to a new machine! -jed

ShaunR's LAVA CR Trim Whitespace VI (Fast Trim) is nominated to be integrated into the OpenG Strings package as it is 3x faster the standard Trim Whitespace. The author has confirmed this is ok. You can track this new feature here: ID: 3292424