I felt that it would be good to have an option to switch to a previous case in a case structure with numerous cases when going through the cases for debugging or understanding a code. It often happens that I have to scroll through the list of cases to get to a case and then may be I'll have to check something in the top most case. Again if I have to check the previous case, I have to again scroll all the way down to the case, which becomes a little tedious. Instead, it would have been good if we had some kind of option to switch to the previous cases sequentially (in a right click menu of the case structure or some keyboard shortcut after selecting the case structure). Something similar to the "Previous Sequence" and "Next Sequence" options we have in TestStand.
I'm sorry if someone has already posted this in the idea exchange forum. I tried to search it but couldn't find any such posts.
Yup, Upgrading LabVIEW versions takes a day.
The "Process" today is:
Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......
"MyLabVIEW" would find all of those customizations and import them to the new version!
I find myself making a lot of VIPM packages for code re-use. As we re-use more code we increasingly want to protect the code so that we can more freely share such packages with e.g. sub-contractors/licensed users without sharing the block diagram. (and the first person to suggest we use VI password protection gets to wear the donkey ears for the rest of the year.)
When you remove the block diagram from a VI, you also remove the ability for that VI to recompile which means that it can only run on the same version of LabVIEW and on the same hardware as it was compiled on/for. This makes it a giant pita if you have code that is used (and works) equvally well on e.g. vxWORKS cRIO and "Windows". Currently VI's consist of 4 parts (Front panel, block diagram, code and data) and without the block diagram, the code section cannot be recompiled.
I wonder, if it would be possible to extend this to either allow the "code" section of the file to be essentially an "array" or at the very least let there be two "code" sections? -It would tremendously increase the usability of the "remove block diagram" feature if we didn't need to maintain a copy for each hardware platform.
I'm not sure how technically possible this would be, but since deployed code (at least to RT) typically gets compiled into (rt)exe's the extra and un-used code section(s) could be stripped during exe build, and the slight performance hit during development/debugging runs that might come from this along with larger VI size seems to me to be a decent trade-off.
So my suggestion is to investigate this and if possible allow some extra choices during the "strip block diagram" from VI process where you get to select an extra "target platform" or two.
A much less savy alternative would be to modify the existing tool to automatically pre-fix and output multiple "versions" of the same code distribution, one for each selected target platform. This would at least speed up the process of maintaining and creating all the variations.
So as I was thinking about easier ways to write set/get VI's for LV Classes and I realized "wouldn't be great if there was a way to set/get any property in a property node by name?". I've implemented this a couple of times on my own by creating a subVI that does set (or get) based on long name string input and string data value. This could also be a combination of enum property selection and variant data or multiple other possibilities but you get the idea.
There is already a Browse option in property nodes - what if we could take it one step further and have a "By Name" selection in a property node with data bundled in somehow (i.e. cluster or seperate line item)? This removes the need for creating large sets of code to set individual properties when high cohesion and loose coupling is kept in mind ;-)
I think everyoner knows this problem:
You maker a VI with a frontpannel and you have some elements on the Frontpannel, like editfield or Listbox etc...
Now in your VI you changes the proppertys of this elements programmaticly. To test your VI you execute it via run in your development enviroment.
After running your VI you get a "*" in your title bar (for changes you made programmaticly). After closing your VI, LV ask you, if you want to save. Now you didn't want to save canges, because you made them programmaticly.
So you can press No, but then ather changes you made will lost!
So an Option in LebView: "discard changes that was made on frontpannel programmaticly" would be nice!
LabView has supported SSL secure communications for the web server for some time now.
But, there is no support for using SSL to a data socket.
In these times, with the NSA and hackers snooping everywhere, it seems like a necessity.
There is a third party library "SSL Library" on the NI site. It has no documentation. It uses Microsoft .NET calls to do SSL, but it is not clear how to make it work.
We have been using a proxy written in perl to get SSL to a LV data socket. It is a kludge solution.
Why can't LabView handle this?
This is a rather non-technical request. When classes are created from Project Explorer, a color is assigned by default. If that's a color you're fine with, you hastily modify the icon and move on to more important matters.
While the color assignment works well enough to serve its mundane purpose, I've noticed several weaknesses:
My suggestion is this, and maybe there's a better way to do this:
In the class properties dialog, why not allow the user to simultaneously assign a color scheme to the icon and the class private data ("cube") icon, in one quick step?
This would adjust the hue of the "cube" icon and the VI Icon Template at the same time. It could also optionally modify the wire color accordingly.
Leave everything else on the UI as it is - this would be a new feature in addition to that pre-existing methodogy.
Thank you as always,
Note: For the sake of simplicity I chose the color picker dialog that LabVIEW uses everywhere else. Any of several other methods could be used, such as a pulldown menu with predefined color names and swatches. (Say, a dozen selections)
Related ideas I came across:
While some ideas like this suggest that we should be able to open block diagrams without opening the front panels, and others suggest that we let go of the front panel as the primary part of a vi, the front panels will probably be around for quite some while yet. But the block diagram is where we primarily work, and closing a vi requires clicks on two different windows. Using ctrl+w twice is not working since the second last window is not always the FP (if it's your very large project this may be annoying).
Let us have the possibility to close the entire vi including FP from the BD by ctrl+click the panel close 'x'. Similarly, remap ctrl+shift+w to close the entire vi.
In my experience, it is common to open files written by other peole, and realize that constants are displayed in hex or bin format only after spending time in debugging.
I think it would be nic to see directly on the block diagram the display format.
This could also apply to controls/indicators.
The error ring is a handy tool I've just learned about. It would be fantastic to be able to create an error ring for a project that can be type defined to easily distribute with applications. This way all custom error codes for a project may be easily stored with all the project files without having to worry about including a file from the user.lib. Other ring controls/constants/indicators can be type defined, why can't the error ring?
The LabVIEW menu has two entries with somewhat overlapping functionality that can lead to confusion
(1) "New..." let's us create many new things, from a blank VI to complicated design patterns and project templates.
(2) "Create Project ..." lets us create a new project using a wizard.
Since the results of menu (2) is invariably something "new" too, it seems odd to have things scattered across two different menu items. I think the "New..." dialog should simply add all the "create project" items under the "project" category. (e.g. "new project using a wizard" or similar.).
(Case in point: I recently attended a myRIO hands-on seminar and was looking for the myRIO template wizard in the "New...." dialog by accident. While there were some other myRIO related projects listed, I could not find what I needed until I looked in the "Create Project..." area. Very confusing!)
I use Unflatten from string (UFS) a lot. Most of the the flattened data, however, comes from outside LV and as such does not use an I32 to encode the length of strings and arrays. That leads to a lot of branching and bending of wires.
I would like to make the boolean input (Includes length?) polymorphic to accept numeric types to specify the number of elements in an array or the length of a string. I was too lazy to draw it, but I would also like it to promote the type input to an array if the count is wired so I only need a simple scalar constant to specify the type instead of the array constant (think Read from Binary File without the cluster of array business). Allowing a cluster of N numerics to specify ND arrays would be very welcome and permit compile time error checking. 1D arrays for dimension sizes could work as well, but the error checking would be runtime only.
I desperately want the boolean input to be overloaded since it is a straight shot from the output of the previous UFS.
Local variable for case structure
I do my best to use state machines and consumer-producer structures using queues that go into case structures for programming my applications. One of the problems I have is it is necessary to make a separate control for the various inputs that go the case structure. This situation is relatively friendly to making new cases (just edit the type def of the control and then got to the case structure and "add case for every value"). However, his takes two steps, is complicated, and is not intuitive - i.e. when I try to teach this to anyone else, it takes some time for them to appreciate how powerful it is.
Worse, however, is that it is very unfriendly when I want to remove cases and change the flow of the program, because I have to remove the same cases in a long list of both the control and the case structure.
I suggest a new way to do this - allow the case structure to "create a constant" in the wiring diagram that is linked to the case structure, so whenever the case structure is modified, any constants that were created from it are also updated. This would make creating state machines and consumer-producer programs much much simpler. Since the only cases that need to exist are those that are in the case structure, then it is a one-touch modification to add/subtract cases.
Please do this quickly, I am getting very tired of having to constantly open the "type def". It is way too much work and really slows down development!
The String to byte array instrument is locked into 8 bits only, which makes sense since it is taking a string and turning it into individual bytes.
An improvement would to have a right click feature on the instrument to change the size to bytes/words/dwords/qwords.
If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.
Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.
The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.
This new file type would be a LV Class Template similar to a VI template. It would copy all of the properties, methods, and inheritance and automatically prompt the user to rename them. The example below shows a simple lvclass template that could be used as part of a simple sequencer. This template could be used as a starting place to create the specific step classes called by the sequencer. Right now this process requires several time consuming manual actions, which would be replaced with the LV template functionality.
I don't know if this idea has appeared before, but for me it looks interesting enough to be presented even again.
Now the sequence structure takes a lot of place in the block diagram.
Why not utilise modified error wire to impose the flow instead? The modification would be that potential errors transmitted over this wire would be ignored, if a proper option on the error wire (or in VI or in the environment) will be selected; for example: impose flow only or ignore the errors.
I'm aware that the proposition of an option of automated ignoring the errors in error wire doesn't sound good. I agree that there is a good practice that error should be rather displayed and captured quickly than ignored and forgotten. And I'm aware that developers can explicitly break the error wire within the VI which effectively do the job: impose the flow with ignoring errors.
However, the reason of this proposal is to speed up the code development based on the native LV paradigm of the dataflow. It would be much quicker to build the application in quick and dirty style by not introducing the space consuming structures as the sequence structure is (BTW: I'd still recommend to leave the stacked sequence structure) and spending the time dedicated for development and solving real world problems for trying to fit and extend the structure and VIs within and around it.
For me ignoring the errors on the error wire option would be a natural option. Maybe a bit semantic should be involved here as well for better naming and description, but I think the idea is good enough to be presented.
Several times I have had customers that want to do multiple inspections in parallel in Vision Builder. Each task uses a different camera and is totally independent of the others. LabVIEW runs in parallel, why doesn't Vision Builder?
Wouldn't it be great if National Instruments could support AUTOSAR SWC-development in LabView. The AUTOSAR standard with its module-based approach fits perfectly for LabView. I am convinced that your company could do a great job in implementing an easy-to-use environment for this emerging standard. I have worked with the tools from Vector and in my opinion everything there is very messy and illogical.