Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.
I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.
Examples: Release Semaphore, Close reference, Release Notifier
Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.
Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):
I am currently trying to do something which is apparently impossible.
I want to create some code which returns a string which represents the selector of an event structure in which the code is executing. Obviously, scripting is required for this. While I can do this if the VI I am using for the task is used in only one event structure case (traverse for items) it doesn't work with a cloned VI. The sub-VI reference found returns the VI definition of the non-cloned instance. As such there is no way to actually find a specific clone.
The key here is that I want to have access to the "Diagram" of the event structure where the code is executing. If I would be able to drop a scripting type constant "This Diagram" which returns a reference to the Diagram similarly to what "This VI" does (but not the top-level Block Diagram, the actual diagram in which the node resides i.e. Diagram within Event structures, While loops, Sequence structures etc.), I would have all I need. I could then parse the rest in a sub-VI and return the required string without jumping through lots of loops to get there (or not, as I am currently experiencing).
Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).
This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.
Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.
Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes,example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a threaddiscussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:
This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closedis a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.
I recommend the implementation of architectural warnings in the error log for detection of architectural mistakes. It would be nice if this could be toggled from the error log (like warnings) or had a viewer of some sort.
So far, I only have one architectural error that I’d like to catch, but I’m sure there are many others as well. Feel free to add suggestions for more architectural errors you'd like to catch.
Below I’m demonstrating the problems with bi-directional library dependence when using ppls. In this case the warning should state that: “Bi-directional dependence detected between Lib3 and Lib4”.
Initial state: Lib4 initial state and Lib3 initial state So we have bi-directional dependence which can only be seen through usage of multiple projects.
Lib3 built to Packed3 and replaces Lib3: Lib 3 replaced with Packed3 Everything seems fine and the replace operation worked.
Now look at the project used to build Packed3: Lib3 code locked Lib3 depends on Lib4 but Lib4 has had a replace operation so it depends on Packed3 --> Packed3 will always be in memory --> it is no longer possible to rebuild Packed3. Reverse replace not possible, so manual reverse is required to fix the code again.
(In LV2017) "Browse Relationshiips\Unopened SubVIs" shows a list of icons with truncated VI names - about 12 characters per VI. When looking through a list of similar icons, one has to hover over each icon to see the full VI name. This is impractical when hunting through tens or hundreds of SubVIs. If unopened SubVIs could appear as an alphabetically-sorted list of VI names, it would be very helpful.
When creating a LabVIEW installer, in the Source File Settings dialog, I might change the attributes of several files in the same way. For example, I might make many files read-only and/or hidden. Currently, I have to click on each file and change its attributes. I would like to be able to choose multiple files (either by highlight, control-click, etc.) and change their attributes at the same time to the same setting.
A common problem for usesrs is attaching additional input devices (eg. touch panels, keyboards, ...), to LV-based systems (including embedded controllers), but yet LV seems to miss an generic API/binding for that.
In Linux world (and BSD, too) we have standard APIs for that. On kernel side, there is evdev, which has lots of drivers for quite any kind of input devices you could buy (and easy to extent for new, even selfmade devices). In userland, there's an small wrapper library - libevdev - which encapsulates the platform/kernel specific stuff and is easily portable to other OS'es (eg. there's already a BSD port, Win32 and MacOS ports shouldn't be a big deal either).
This library could be directly called from a VI. This VI could also exist in several specific (and potentially highly optimized) versions, to Labview users have a generic API handling input devices (such as standard USB HID class) in LV.
You just have to place your mouse over what feels an approximately 1 pixel wide area on the left side of your loop and press the right mouse-button without moving the mouse. If there was no input or case terminal around a context menu opens that gives you access to the function you need.
Point anywhere else and the contect menu doesn't contain what you need.
The context menu entry could also show if the mouse hovers over any other parts of the loop as well to make the area easier to point at.
The current version of the Ethernet/IP tool kit 781656-35 only functions as an adapter. I need it to also function as a scanner. Specifically to take control of the point I/O module 1734-AENT module of the Allen Bradley RSlogix 5000 PLC. I need the Labview to replace the PLC RS l5000 logix software. I still want to use the Point IO modules.
When passing a control reference to a sub vi , it would be nice to be able to map ALL properties to the taget control in one hit rather than individually setting each property in turn from the reference.
The "All Recent Files" list on the opening LabVIEW (2015) window is convenient but the order is inconvenient. All .lvproj files are at the top and .vi files at the bottom. Once we open 7 projects the most recent VIs are pushed down out of sight. Since it is a "Recent" files list, it should be sorted chronologically so that if a VI was opened last it is at the top of the list.
This is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.
The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.
In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.
Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.
Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.
Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.
We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.
Finally, we have Destroy Promise. It does exactly what it says on the tin.
I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway ).
It is axiom that "a * b = b * a" if "a" and "b" are scalars.
Scalar addition is commutative too.
It is axiom that "a + b = b + a" if "a" and "b" are scalars.
If the diagram cleanup recognized such a thing, then it could switch leads on a multiply icon to undo a crossed wire, without changing anything in the function. I tried it, and to my poor ability to tell, it seems to not be undoing the wire-crossings that it could clean up. There are plenty of things that do commutate, and if re-arranging inputs was enabled for them, then cleaner diagrams could be made.