LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (1)

Get contents of all XML Node Types:

As a beginner at XML parsing, it would be great if LabVIEW had a VI (like Get Node Text Content) but for every node type (it would get the contents, whatever they may be).

All node types stated here:

http://www.w3schools.com/dom/dom_nodetype.asp

are possible and may require a different set of property/invoke nodes (some have children, some don't, some have values, some don't... and so on).

Inputs: Node handle

Outputs: Raw node contents (whatever XML is contained within the tags of the Node handle), Value (where applicable), Name (where applicable)

Write general string to XML node type:

It would also be great if there was a VI (or set of VI's) that could take an input (as a string) convert it to the w3 conformant XML. It's important to use the w3 definition, rather than LabVIEW XML for external compatibility.

Inputs: Node handle, Node Type

Outputs: XML string of Node Type

View All (1)

Timed structures require a priority for scheduling. Default priority level is 100 for each structure.

If that priority is not changed (one dedicated priority level per structure) it could lead to unexpected behavior like hangs.

Therefore i propose a new test for the VI Analyzer which tests for unique (static) priority levels in timed structures. If there are priority levels shared among several structures, the test shall fail.

The test shall also work within a whole project, so it shall not only check this within single VIs.

Norbert

The waveform chart has an awesome low level buffer built-in. I wish I had a simple drag/drop buffer function/subVI that was as effiecient.

The attached zip contains some buffer comparisons that I was messing with when I thought how nice it would be to have an efficient XY Chart:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/XY-chart/idi-p/2045138

It got me thinking about how nice it would be to have a buffer as good as the one inside the waveform chart.

With minor modifications to the attached comparisons, you can easily see how the chart is SO MUCH more efficient as a buffer than any I made or found. You can take out the graphs, and the chart will finish updating its buffer AND drawing its new plots before the others can even finish updating their buffers!

View All (4)

Make current values default - Excluding Large Data

Subject:

Improve "Saving Default values" option, adding the possibility to EXCLUDE data of certain kind of control or

exceeding a certain size.

The typical case of use

You use LV for developing data analysis software, or for data reduction. You want to save the values of parameters which give you a certain result, but not the result itself in the case its too huge.

In my case "result" = a number of Intensity Graph controls each one of 2048x2048.

Why that?

To reduce VI size, saving time and improve VI startup after small changes. This encourages the use of LV as "scripting" (or "sketching", as I like to say) language.

Print. Panel To Printer with Wait

If the Index Input Terminals of an expanded Index Array primitive are not wired, the first index defaults to 0 and subsequent indexes increment sequentially. Similarly, if the first index if wired to some value and the remaining are unwired, those remaining also increment sequentially beginning from the first wired index. This makes it easy to extract a sequence of N sequential elements from an array. However, an In Place Element structure configured for Array Index/Replace Elements requires all its index inputs to be wired. This forces the wiring of 0,1,2,3,4,5 constants when one wishes to replace the first 6 elements of an array for example.

Steve

The default timeout of a queue write primitive is set to -1 right now, which means that it waits forever to insert an element. I am sure there are intstances where this is the right behavior, but for virtually all the cases that I have come across, I don't ever want that primitive to hold up operation of my code. Whether running in RT or on a Windows machine, simply mimicking the behavior of the RT FIFO primitives would seem to be much better. If for some reason your queue has filled up (and you have set a size limit), you can wind up with a hung application and no real way to fix it. Right now, I have to remind myself to go in and set the timeout to 0, which works but can be tedious.

So, I vote to change the default timeout to 0 ms. Not sure if it makes sense on the queue read or not, but for sure on the write side. Thoughts?

View All (2)

Override basic methods.

View All (1)

multiple inheritance

I want to suggest implementing multiple inheritance.

I find that I regularly want to use building blocks in my applications.

An example from my project: I need a serial device class and an analog device class. I have a power supply class and a flow controller class. Now if I have a "serial flow controller" or a "analog flow controller" I could have a Flow Controller base class and use serial or analog children. Or I could say I have a Serial base class and Power Supply and Flow Controller children. Either way I end up duplicating one set of code, specifically any configuration type settings via data accessors.

I believe multiple inheritance would fix this.

View All (1)

I would like to see something such as a "Synchronous property update block" as an easy way to prevent race conditions when updating front panel objects.

Let's say I have two inherently asynchronous threads that both want to modify a front panel object, by first reading its value (or a property), changing it somehow, then writing the new value (or property) back. There is a risk of a race condition if the first thread is interrupted after reading (but before updating) the value – and this seems to occur with tables, graphs, etc. – particularly when the data size gets large.

What I propose is a structure with symmetric input/output groups, like an in-place structure. But in this case, the input/output terminals would be one or more local variable selectors or, even better, property node selectors that could be either hard-linked or wired with a reference. During execution of this block, all other threads are blocked from either (a) writing properties or values to any of the linked/referenced FP objects, or (b), entering into any other synchronous update blocks that are linked to any of the same FP objects.

Sure, there are other ways to get around this, but…

- Semaphores and other synchronization functions seem a bit cumbersome for such a simple (and frequent) task, and are unnecessarily prone to deadlock

- Using a functional global would duplicate the data in memory, I’d rather just keep it in the FP object.

- Other possible fixes (e.g., manually synchronizing the code, forcing synchronous updates for the indicators, deferring panel update, or using local variables instead of property nodes) all seem to sacrifice of performance and/or functionality. I’m not positive the latter options would actually prevent the race – they might just lower the probability.

On the other hand, a synchronous update block could:

- Automatically prevent deadlocks – LabVIEW could just lock controls and indicators in a consistent order to prevent a circular wait condition. And of course, we would know better than to nest a mutex wait, I/O, or anything else foolish inside these blocks... right?

- Operate independently from other synchronization instruments and thus not unnecessarily stall other threads or the front panel (i.e., other threads can still READ locked controls during the synchronous update, or modify and update other controls)

- Promote better coding and data flow by distinguishing between FP update tasks and other processing / IO / etc...

Finally, if these block structures further supported iteration (that is, like a for loop that buffers all the property node writes until the loop is complete), you could get a way to temporarily defer front panel updates for individual objects – e.g., for tasks such as coloring table cells or populating a graph legend. See the "’Defer Panel Updates’ within sequence frame so configured” idea – or the “Make Defer Updates an Object Property as well as a Panel Property.”

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Defer-Panel-Updates-quot-within-sequence-frame-so/idi-p/1288952

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Defer-Updates-an-Object-Property-as-well-as-a-Panel/idi-p/1292100

View All (3)

subpanel -> "Is Vi loaded?"

IMAQ Linear Sums

Quick Compile

Sometimes a quick and easy program is desired by a coworker or to do a test. It would be nice to create or open a vi, modify as needed, and create an exe from the VI itself, and distribute it. Open, edit, compile, send.

Quick compile

Ability to open a VI and select compile to exe without creating a project.
Use a predefined setup script or a wizard.
Ability to decompile from the exe to get the source vi's, if option is desired.

The EXE is the source also. No lost code.

End user would have a link to download the runtime if not already installed.

Selective Chart Scale Legends

I'd like to have a way to give the FPGA on my PCIe card direct access to a block of the host PC's RAM. At the moment, the FPGA is limited to its internal RAM and whatever might be on the PCIe card. With my PCIe-7841, I have about 1MB available to the FPGA. If I need more, I have to use DMA FIFO transfers - the FPGA can use one FIFO to ask the host for some data and the host can send it to the FPGA in another FIFO. This is a lot of overhead compared with simply using a memory method node to access the FPGA RAM.

So how about a method to allocate a block of memory in the host's RAM that the FPGA can access directly over the PCIe bus with minimal involvement by the host. For simplicity, it will probably need to be limited to a contiguous block so that there are no gaps in the addresses - the FPGA would only need to know the start address and the number of bytes in the block. Ideally safeguards should be established to ensure the FPGA doesn't access memory outside the allocated block, but leaving that to the LabVIEW programmer would be fine.

The PXI-6682 is able to read time from other sources (GPS, IRIG B among others). This time can be accessed from software, but currently there is no way to synchronize the PC's system clock to the master time source. This seems like it would be relatively simple to do - indeed most competing products that read time sources are able to do it out of the box.

So my suggestion is to improve the drivers for the PXI-6682 so that it can keep the system clock synchronized when a master time source is being received.

LabVIEW Idea Exchange

"Wait Until Next ms Multiple" accept DBL

Get contents of all XML Node Types / Write general string to XML Node Type