LogMAN

I'm not quite sure if this is what you are looking for but here is an example that works for me:

Excel Formula.vi

A union is always sized to its largest member, not the sum of its members. In your case, 4 bytes. You currently provide 8 bytes of memory. Try reducing the size of the union to 4 bytes.

+1 for Unbundle. It it simple, requires less code and you understand immediately that these elements belong to the current class. They are also easier to maintain in case you ever feel the need to change the name or type of an element and work well with In-Place Element Structures in Unbundle-Bundle-Scenarios.

A few month later, this is what Bing Image Creator produces for the same input:

Can confirm, wires everywhere...

13 hours ago, Mahbod Morshedi said:

I have heard that converting everything to a class is the best approach

Not like this

13 hours ago, Mahbod Morshedi said:

, but I am unable to find any suitable resources or examples for it. Most of the available information pertains to simple and uncomplicated data types.

Because that is the goal; break down your complex and complicated data types into simple and uncomplicated ones.

For configuration data you could maintain the path to the storage location and load the data as needed.

9 hours ago, mwebster said:

Not sure why ROLLBACK TO X didn't close the transaction, but that was the root cause.

This is explained in the SQLITE help pages: https://www.sqlite.org/lang_savepoint.html#savepoints

Quote

The ROLLBACK TO command reverts the state of the database back to what it was just after the corresponding SAVEPOINT. Note that unlike that plain ROLLBACK command (without the TO keyword) the ROLLBACK TO command does not cancel the transaction. Instead of cancelling the transaction, the ROLLBACK TO command restarts the transaction again at the beginning. All intervening SAVEPOINTs are canceled, however.

Sounds like an uncommitted transaction. Make sure you have committed all transactions before closing the file. Uncommitted transactions are lost.

This appears to be a known issue in LabVIEW 2021 SP1.

Quote

LabVIEW 2021 SP1 causes an increase in the memory usage of some applications unnecessarily over time. 

 

Workaround:

You can disable the performance optimization which caused the memory leak by adding "MemoryManger.UseMasterPointerPool = FALSE" to the LabVIEW INI file. LabVIEW 2021 SP1 f1 patch fixes the issue by disabling the performance optimization by default.

https://www.ni.com/de-de/support/documentation/bugs/22/labview-2021-sp1-known-issues.html

For future reference: https://download.ni.com/#support/daq/pc/ni-daq/daqmx/

It appears they moved their old ftp server to that site.

4 hours ago, bsvingen said:

Please note that moving forward from LabVIEW 2022 Q3 you can only purchase LabVIEW Application Builder via LabVIEW Professional Development System.

Okay, wow! This is just awful.

4 hours ago, bsvingen said:

Are there any other way to get around this, other third party builders, or anything?

Community edition is equivalent to professional... just saying...

This might be an issue with environment variables. Your application runs with whatever environment variables exist at the time it was launched and cuda is only added to PATH during its installation.

Quote

By default, where searches the current directory and the paths that are specified in the PATH environment variable.

-- where | Microsoft Learn

It should work if you specify the path explicitly (or somehow reload environment variables).

3 hours ago, hooovahh said:

Why does everyone have problems downloading this except me?

Your download works fine but only for signed-in users. Also, the error message could be misleading:

I use InnoSetup and offline installers.

The steps are documented here: https://www.ni.com/docs/en-US/bundle/package-manager/page/automate-installer.html

Here is the kind of response it produces for LabVIEW:

Quote

Me: Can you write code in LabVIEW?

Quote

AI: Yes, I can write code in LabVIEW. LabVIEW (short for Laboratory Virtual Instrument Engineering Workbench) is a graphical programming platform that allows users to create programs using block diagrams and icons rather than traditional text-based programming languages like C++ or Python. The block diagrams and icons used in LabVIEW represent data flow, rather than traditional control flow, which allows users to create programs that are intuitive and easy to understand. Do you have any specific tasks or projects you would like help with in LabVIEW?

Quote

Me: Give me an example written in LabVIEW.

Quote

AI: Certainly! Here is a simple example of a LabVIEW program that reads a temperature value from a thermocouple and displays the value on a front panel control:

# Open the serial port to read from the thermocouple
Open Serial Port VI

# Read the temperature value from the serial port
Read from Serial Port VI

# Display the temperature value on a front panel control
Numeric Control

This is just a simple example, but LabVIEW is a very powerful programming platform that can be used for a wide range of applications, including data acquisition, instrument control, and test and measurement. If you have any specific tasks or projects you would like help with, I would be happy to assist you.

Quote

Me: Create a VI for this example.

Quote

AI: Certainly! Here is a LabVIEW VI that reads a temperature value from a thermocouple and displays the value on a front panel control:

[LabVIEW VI]

To create this VI, you would follow these steps:

1. Open LabVIEW and create a new VI by selecting "File > New VI".
2. Add the following VIs to the block diagram:

• "Open Serial Port" from the Serial I/O palette
• "Read from Serial Port" from the Serial I/O palette

3. Wire the VIs together as follows:

• Connect the output of the "Open Serial Port" VI to the input of the "Read from Serial Port" VI.

4. Add a numeric control to the front panel by dragging and dropping it from the Controls palette.
5. Wire the output of the "Read from Serial Port" VI to the numeric control by dragging and dropping a wire from the output terminal of the VI to the input terminal of the control.
6. Save the VI by selecting "File > Save" and giving it a name.

I hope this helps! Let me know if you have any questions or if you need further assistance.

The responses are impressive but it doesn't look like we are getting replaced any time soon... 

The reason your cant change the unit label at runtime is because unit labels change the data type of the wire (notice the "S" in brackets at the end).

That said, what you want can be achieved with the display format.

1. Enable unit label and specify the unit "S"
2. Change the display format to SI notation and the number of digits to 3

Now it will automatically add the prefix according to your value. For example, 10000 S will turn into 10 kS.

While community-scoped VIs are only accessible from VIs in the same library and friends, they are still exported.

To see the complete list of exported members, use Get Exported File List.vi or open the library from the Getting Started Window.

Attempting to execute community-scoped VIs results in a runtime error. Here is an example using Open VI Reference.

The same error should appear in TestStand (otherwise it's a bug).

LabVIEW simply hides community-scoped members in Project Explorer for convenience. Looks like TestStand does not do that.

3 hours ago, bna08 said:

Initially, I created an array of LabVIEW clusters which I wanted to pass to the .NET via an Invoke node, but passing array of clusters or clusters from LabVIEW to .NET is not possible if I am not mistaken.

LabVIEW clusters can actually be passed by value, given that the values are structs.

For classes, you need to construct the class before you pass it to the method.

It sounds as if you want to pass a .NET Array type by ref to your method. This should be possible by constructing an array in LabVIEW, for example, by using the To .NET Object function, and passing the instance by reference to your method (assuming that your method signature is by ref).

If you want to avoid generics, you can also initialize your own array as illustrated below.

On 12/1/2022 at 4:25 PM, ShaunR said:

The single execution while loop to force clumping was an eye opener.

1 hour ago, kej said:

A long time ago I decided never to use property nodes for private data access. I will do a little research to see if I should reconsider that...

Instead, within member VIs I always use bundle/unbundle, outside the class I use getter/setter methods. I'm happy to make custom getter/setters if I need to access some arbitrary set of the private data.

Yes, this makes sense for class members. They should always access the private data cluster directly. Property nodes are only good for callers (and maybe when accessing parent class data).

In the past I also avoided property nodes. Mostly because of stability and performance issues (~2011-2015). Nowadays they appear to be stable and are just easier to read (also, I'm lazy and property nodes don't need icons 😏).

1 hour ago, kej said:

When appropriate, my favorite idiom within the class is to use the Unbundle/Bundle Elements border node of the In Place Element Structure. I write a lot of RT code where I need to preallocate memory and use in-place.

This is probably the best way to do it. Read-only and write-only access, however, should still be done with standalone bundle/unbundle. It makes it easier to understand what is going on, avoids unnecessary wires, and has the same memory footprint.

By the way, Darren Nattinger recently held a presentation at GDevConNA 2022 that might be interesting to you. He provides some insights into features of LabVIEW that aren't as stable as one would hope...

Cross-post: Remove Block Diagram after Build with VIPM - VI Package Manager (VIPM) - VIPM Community

Please always include links when posting in multiple forums.

5 hours ago, kej said:

Specifically, I've had the App Builder fail to compile or build .exe's that come up broken in the runtime when I have class private data saved in a block-diagram constant or an FPC--and when that data is in a previous structural form reliant on the class mutation history. I never intend to invoke the class mutation history, in fact I'm not sure I knew it existed until I ran into the problem. But it's easy to do accidentally and afaik there's no way to tell without building tooling outside the IDE, so this falls into the silent-but-deadly category of not having visibility into automated mutations.

Class constants and controls have black background when they contain non-default values:

5 hours ago, kej said:

Even if I'm going to explicitly initialize all class private data, the class itself has to be instantiated using a BD constant or a FPC, right?

Class constants (and controls) always have the default value of their private data control unless you explicitly create a non-standard constant like in the example above.

5 hours ago, kej said:

But I'm not sure that this approach actually does anything. When I plunk the class control on the front panel presumably it gets the current default value of the private data control, but what happens then? Is it ever updated automatically?

It is updated every time the private data control is changed. This is why VIs containing the class are broken until the changes to the private data control are applied.

5 hours ago, kej said:

Experience leads me to believe that if I never explicitly save a default value for the class control in this VI, any changes I make to the class private data structure will propagate to that control and the class mutation history won't be invoked.

That is correct.

5 hours ago, kej said:

But maybe that's not true, I have only anecdotal evidence, so asking here. If it is true then the invoke node above is redundant. But even if the invoke node above isn't redundant, maybe it initializes the private data to the previous private data structure version still dependent on the mutation history.

It does not. The default control does not actually contain a copy of the private data control, but a value to indicate that it returns the class default value. Even if you make this value its default value, it is still just a value that indicates that it returns the class default value.

Only when the background turns black, you have to worry.

5 hours ago, kej said:

Unfortunately, even if I figure out how to handle bypassing the mutation history at object creation, it turns out that the problem with the App Builder can be invoked by any saved default value on a class control anywhere in the code, even if that control is always on the conpane and required to be connected.

By any chance, do you write values to class controls?

This can result in undesired situations when combined with 'Make Current Values Default':

That is very unlikely. It would turn classes into interfaces, which is a major breaking change.

Not sure about speed, but these VIs use features that aren't available in earlier versions.

However, if backwards compatibility isn't an issue, this is probably the most native way to go about it.

As for speed, perhaps caching is an option?