 |
|
||||||||||||
The provided model templates (fitting, optimization, etc. listed here) have the ancient icon style where the text is actually merged into the single layer of the icon.
Since in the typical scenario the text will be immediately changed to reflect the actual customized model name, it would be reasonable if these icons would have the current text editable in the icon editor instead. Currently, we need to erase the icon background before we can start typing or we get a mess.
For example, in the nonlinear fit model, the text "curve|fit|model" should be in the text tab, and not contained in the icon background (see image).
Suggestion: the model template icons should be blank and the current text should be pre-filled, but editable on the text tab of the icon editor.
Current Situation
The current commenting practice in the BD is to place free floating comment number labels and write the comment in a text field as in the example below.
Disadvantages
- comment number labels do to stick to the code block. if the code number block is moved the comment has to be moved as well.
- no link between number and comment text block
This unsophisticated way of commenting LabView code lead to the lack of comments in general. Usually a new programmer can understand what happens, but not why a function is implemented like this.
Proposal
LabView provides the Advanced Code Commenting Functions.
The comment block is more then just a text block. Basically it has a comment ID, the comment itself and a comment category.
By the context menu the following functions are provide:
- add comment
- delete comment
- move comment up
The particular comment line is moved up in the comment block. The ID is decremented - move comment down
Opposite from 3. - highlight function
The function to which the comment ID sticks is highlighted. - the comment category can be selected. (e.g.. Code Explanation, To Do, )
Adding Comments
Adding a comment in the comment block incorporates two steps (after selecting Add Comment from the context menu):
1. Sticking the automatically generated comment ID to a particular code block just by selecting the item the comment belongs to.
This could be any type of code: wires, SubVIs, the whole Case, a particular Case, Sequences....
2. Writing the comment
If the mouse pointer is set over a comment ID the comment is shown like a tool tip and disappears as soon as the mouse is moved away.
Advantages
- Comment moves with function block if function is moved on the BD
- Comment ID sticked on the BD item and ID on the comment block always match
- generally more comments in a LabView programm through more simple way of commenting code
The examples related with artificial vision, should be rewritten. ( Stacked Sequence Structure)
Jokelnice
on
The idea came in this discussion -----> http://forums.ni.com/t5/Machine-Vision/Machine-Vis
and of this other idea. ------> http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Rewr
The most examples related with artificial vision or machine vision, have excessive use of the "Stacked Sequence Structure". This is a contradiction, since in the courses, trainings and some discussions in the forums, they always recommend that work with this structure is minimal. The examples, would need to be rewritten.
Here's an example that is in the help.
Hello, this is my first post in this forum and I don't found ideas about this topic. I hope you like it.
Well, time ago I started to work with LabVIEW, It's powerful, but there are some kind of issues that I want to explain here. Now I'm get involved in a big project for a very big aerospace company, and I'm developing a complex application to acquire some data and process it. Well, this software is in development by some people and I have an idea for the work flow.
I explain it with an example:
If we have in every VI a little data base with some notes ordered by type or something we can read the code or we can start to work in a VI faster. Imagine that you have an event structure with several cases, and you put some notes like you can see in the following image:
Now, I'm able to revise quickly the code reading all the notes and start working only in the "TO DO" zone. But let's do a more complex design: Now I open my project explorer, and open the "Note manager" that could be like this.
Here it is the real advantage of this tool: All the design are done and now I want to improve the application. Lets go only to the notes that interest to me: "TO DO" notes. If I double click on an element LabVIEW opens for me the VI centered in the zone that is interesting for me. And some more: I can check the work I've done and I can add new notes only with a click.
The more complex the project is, the more useful is this system. So, what do you think?
This is a "repost" of an idea back from 2009 - I would like to see if it will get any traction now.
Original idea Here
I have been using the DETT pretty extensively for the last few weeks, and would love to see some simple usability improvements with a few additions for automation.
1. Better handlling of arrow up, arrow down and page up/down key strokes. It is very jerky when scrolling through pages of a long trace
2. Addition of a search function - especially for user defined strings. I use them as placeholders to indicate where I am in a sequence of events, and having an easy way to find them would be great.
3. Rolling save of logs. It is way to easy to run out of memory and lose a trace. Having a way to automatically stop and save a log and start a new one would be a great way to automate data collection. Here is a screenshot of how Wireshark does it:
Feel free to add more thoughts, these are just a few of my major ones.
Rob
Why is it that when you go to Select a VI from a packed library, all of the careful work that the developer put in to add folders, protected statuses, etc are completely discarded?
Surely it would be so much easier for people to find the RIGHT VI from a PPL if instead of seeing a flat list of VIs like this:
They were to see something much more like the what they get in a project view:
(In this particular example things are extreme as the lvlibp is a plugin interface so it has an awful lot of protected VIs, that the "user" of the PPL does not care about (and cannot even use directly).
Surely something can be done with this dialog that looks like it hasn't been touched since Windows 3.1!?
I hope this is the correct venue for ideas about the desktop execution trace toolkit. It is a LabVIEW-related tool.
In the course of investigating several LabVIEW crashes, one of NIs AEs suggested the DETT. This seemed like a really good idea because it runs as a separate application and therefore doesn't lose data on the crash. Better yet, the last thing in the trace would be likely to be related to the crash. So I started my eval period of the DETT. I am debugging a LV 8.6.1 program but since I have installed LV 2009, the 2009 version of DETT came up when I started tracing. It seemed to work, however.
Sadly, the DETT sucked. After about a minute of tracing, it got buffer overflow and popped up this dialog:
When I dismissed this, I got the usual popup about "Not enough memory to complete this operation." Following this, the DETT was basically frozen. I couldn't view the trace, specify filters, nothing. I had to restart the application. I tried a few hacks like disabling screen update while running, but nothing changed. The DETT app was using about 466 MB at the time, and adequate system memory was available.
Possibly this is a stripped-down eval version. If so, it is a mistake to make an eval version work so badly that one is pursuaded not to buy the full version, which is the way I feel now.
I have some suggestions about how to improve the tool. If these are implemented, I would recommend that we buy the full version.
- Stop barfing when the buffer overflows.
- A wraparound (circular) buffer should be an option. Often one is interested in the latest events, not the first ones.
- There should be a way to specify an event as a trigger to start and/or stop tracing, like in a logic analyzer. Triggers could be an event match, VI match, user event, etc.
- The tools for analyzing events in the buffer (when it doesn't overflow) are useless. A search on a VI that is obviously present fails to find any event for that VI. Searching should be able to be done based on something like the trigger mentioned above.
- The display filter is a good start but needs to be smarter. It should be possible to filter out specific patterns, not just whole classes of events.
- The export to text is broken. It loses the name of the VI that has a refnum leak.
- Refnum leak events are useless. They don't give even as much as a probe would show, like what the refnum is to, the type, etc.
- The tool should be able to show concurrent thread/VI activity side-by-side, not serially, so one can see what is happening in parallell operations.
Do this stuff and you will have a useful tool.
John Doyle
Have a LabVIEW Idea?- Browse by label or search in the LabVIEW 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
Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea. - Watch as the community gives your idea kudos and adds their input.
- As NI R&D considers the idea, they will change the idea status.
- Give kudos to other ideas that you would like to see in a future version of LabVIEW!
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||