Browse by label or search in the Vision Idea Exchange to see if your idea has previously been submitted. If your idea exists, be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: Please post technical vision support questions to the Machine Vision forum, not the Vision Idea Exchange.
Watch as the community gives your idea kudos and adds their input.
As Vision R&D considers the idea, they will change the idea status. Note: Vision R&D is committed to reviewing every idea posted in the Vision Idea Exchange. However, the implementation of any Vision Idea Exchange submission cannot be guaranteed.
Give kudos to other ideas that you would like to see implemented!
VBAI is a nice tool for some vision program, but the interface language is english. I know many engineers in China cann't understand it cause of English interface. but I can translate all of the interface words into chinese. If you wanna expland market in China, maybe i can help you to translate it.
Speed and sensitivity critical. 48kHz line rate with excellent sensitivity from blue through NIR. Blue is needed for online fluorescent applications, white light is for most applications, and NIR for inspections that need to avoid the influence of graphics.
Option to exclude “default” columns for data logging step
The current data logging step includes many colums of default data which very often gets deleted when sharing data with others. It's great having the data by default but is undesired in many roll out installations.
Using the image operators ADD or MAX or AVERAGE, even if both the images in the VI are calibrated, the output image is no longer calibrated.
To get around this, I have to separately copy the calibration to the output image. This is not possible from Vision Assistant (within VBAI) so I have to instead use a Run Labview VI step to re-calibrate the image. The same is also true for these VIs in Labview VDM, so I am posting this on both forums.
Need the ability to operate using local inspection variables quickly without the slow process of checking the value over the network each time; but the varaibles would be updated as needed from / to the remote location. Dan R
In the VBAI Dev environment, we currently have the ability to enable/disable overlays using the "setup overlay" button. This request is to provide access to access the overlay enables programmatically. The use case is for when operators are required to show/hide specific overlays. When many overlays are involved, the overhead for programming these using the state diagrams becomes overwhelming. Below is an example for only 6 overlays. You can see how 30+ overlay groups would be a nightmare. There is also a overhead performance hit.
One power of the custom VI in Vision Builder is to be able to distribute code but sometimes the custom VI is just to execute special LabVIEW code for capability that isn't native in Vision Builder. In the later case, it would be very helpful to enable the .VBAI inspection to include the custom VI ( .vi or .llb ) so that the code travels automatically when saving, copying, and sharing the .VBAI file. There is already a check box to set the path to be "relative" but it would be ideal to have an option to In Line the custom VI directly into the .VBAI inspection so there is no chance to lose / break the code when sharing the .VBAI file.
Instead of a only check box for "relative path" include a second check box which says "embed into .VBAI inspection". This would not be available in Start Up, Select Produt, or Clean Up parts of the state diagrams, only available in the Inspection State since that is the only state that loads from the .VBAI file. Checking this box would copy the code into the .VBAI container and the sytem would know that's where to extract the code from.
The "embed" check box would be grayed out unless you first check the "use relative path".
Caution would be needed if copying a Custom VI step from the Inspection state diagram to the startup, select, or clean up states.
Optionally, an "open" option would also be great when you open a Custom VI step that someone else saved. This way when editing the .VBAI inspection, someone could open the .vi or .llb which was embedded into the .VBAI file.
Perhaps speed would be a concern if trying to run directly out of the .VBAI container?
This would help reduce complexity and overhead of VBAI state diagrams. Often states are created empty with the only purpose is to use transitions to skip or bypass other states. When a state is disabled, VBAI would skip the steps in the state and immediately evaluate the transitions. Any transitions which rely on results from a disabled state would be "results unavailable".
Long names may get cut off in Measurement window, allow for a separate window, like the View Measurements dialog box, to fully display names and values with resizeable fields, instead of just relying on tool tips
When merge overlay is performed on image with multiple overlay groups, it merges selected group (correct) and clears all others (wrong!).
It seems that it should affect only what has been said to it (selected group), and do not touch what belongs to somebody else. If you need to kill all other overlays, use clear overlay after it. Or new version needs a switch to not kill other groups - for compatibility.
The title says it all, but let me expand a little...
Since LabVIEW 8, trying to create a VI from a selection containing a reference to an Image Control fails. It does absolutely nothing, nada, nitchevo, nichts, rien...
There are at least TWO CARs about it: 54165 and 35835.
Yet, years after years, nothing is done about it.
A workaround for creating VI is to remove the connections to any of the image control references in the original selection, and once in the created subVI, drop a custom control that you will have strategically dropped in your Favorites Control Palette:
Then you need to add it to the connector pane, reconnect in the original calling VI...
Not the easiest but manageable.
Now, what about managing events using a Register Event node handling several controls, including a couple of Image controls? Usually, when not using images, I bundle references to the controls and do the Event Registration in a subVI (there are typically a lot of wires and large nodes involved, therefore this would take an undue amount of real estate in a main VI).
The problem is, any cluster containing a Image Control Reference can apparently not be created as a control in a "Create subVI" or even a "Create Control" operation:
Once again, it is possible to do all this manually, but if you have a bunch of Image Control references and other references to bundle, this is becoming rapidly tedious.