Jump to content

Worst LabVIEW design feature


GregSands

  

117 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

:frusty: What design feature in LabVIEW most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about?

In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth.

OK, your turn.

Link to comment

I'm not a fan of the Image type for the vision stuff either. I keep getting caught out even though I know how it works.

A lot of vision stuff I do requires acquiring and image then creating various masks and applying them (often one after the other or in various combinations). The UI though, normally requires showing of original images and the results of the various stages of mask applications therefore you end up copying everywhere so as not to overwrite the originals or the intermediate results of a mask. It gets very messy wacko.gif

But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

  • Like 1
Link to comment

But my pet hate is that you cannot wire a VISA refnum to an event case like you can with DAQmx. But more generally, the "probe window" introduced with LV2009.

Oh I so agree with the new probe window. I think a number of the "windowed" IDE addon's are like that, only half thought out in usability terms. The heirarchy view is next to useless in any real way.

Dannyt

Edited by dannyt
Link to comment

In my part of the world everyone's winding down for their summer holidays! So I thought I'd start a pair of topics to sing the praises (and raise the sins) of LabVIEW. In this topic:

:frusty: What design feature in LabVIEW most annoys you? The one that you constantly bang your head against, and wish that it had been developed differently, but it's probably too late to do anything about?

In the code I write, it would have to be the separate Image datatype. Why could it not just be an array? Sure, there are benefits to having a separate type - some very fast image processing code, and handling of image borders. But it is so restrictive if what I want to do is not already coded as an IMAQ routine, for example, taking the square root as part of computing the standard deviation of an image region, or wanting to use 3D images. Either I ignore all the really useful image routines, or I use twice the memory and keep swapping back and forth.

OK, your turn.

1) "annoyed" past tense. Remember the Just in Time Advise thingy that peoples started calling "Spoolie"?

2) "Shared Variables" lets take the danger of globals and allow the devlopment of race conditions across platforms? While we are at we can tell the world they are the answer to everything, and lets lock down all of the functionality so users have to wait half a year to get a fix (maybe) and for bonus points let's make our DSC product dependent on them... Wait... We can move all support for the low level stuff to another continent and implement a 24 hour e-mail delay in replies like "BridgeVIEW? I don't know BridgeVIEW, but it was supposed to be like DSC." Yes the quagmiere of treading between "Yes I recomend using LV for this project." and "No, I am not going to take NI's advise to use SV's." can leave a mark on you.

Ben

Link to comment

The tree control has always been difficult to work with, but since there has been some community support it has become easier to work with.

Maybe the fact that the run time engine balloons with every version. Making a 100MB install for a "Hello World" program doesn't seem very useful, but then again Hello World isn't all that useful anyway. Really it would be great if some basic LabVIEW runtime engine was included in Windows, but that'll likely never happen.

Version dependent issues really suck. You can save up but now down very easily. It would be nice to be able to open a LabVIEW 7.1 VI in 8.2 and when I save let it have the option to save in 8.2 or 7.1 compatibility. (obviously wouldn't work if you use a feature that wasn't in 7.1). Again I don't expect this to ever happen. Other version dependencies issues are anoying too. Say I have LabVIEW 8.0 installed, what versions of MAX work with it? What versions of DAQmx work with it? Traditional DAQ? FPGA? NI-RIO? NI-CAN? Switch? Now what hardware work with what software? Are there some DAQ cards that only support DAQmx? Where is the tables and charts showing these dependencies?

Link to comment

Insufficient customization options over the development environment.

There are lots of actions I'd like to assign keyboard shortcuts to but can't. I'd like to be able to create custom toolbars move them around where I want. Menus (especially right click menus) are overpopulated and I wish there was a way to make them "smart" where they show items that are used frequently and offer a way to quickly expand to see all the options.

QSM

:lol:

Oh I so agree with the new probe window. I think a number of the "windowed" IDE addon's are like that, only half thought out in usability terms. The heirarchy view is next to useless in any real way.

I actually like the new window better than the old style. When I have a lot of probes going I find it very useful to be able to refer to a single list of probe values that describes the application's state at any one time. That said, the UI definitely needs usability improvements. Resizing the window in particular is implemented all wrong.

Link to comment

But more generally, the "probe window" introduced with LV2009.

It really wouldn't be so bad if I could open the probe in a new window AND close the parent window ... and if we're going to get timestamp tracking in the parent window, why not find a way to show that in the floating window too??

Link to comment

QSM? That's not a LabVIEW feature. Also, there are many many different ways to do QSMs with many different advantages and disadvantages. If poorly developed, then yes, they are a pain. But nothing protects against bad code.

Probe Window: Big yes. Terribly painful. Off the top of my head here are the biggest pain points:

  • It's a floating window, so it's forced to stay on top of other windows. Why?!? Don't force this behavior on me! Why is it shocking that I'd want to view other windows on top of the probe window?
  • Since it's floating and I can't put it behind other windows, I regularly minimize it. However, probing a new value does NOT restore it! Wrong wrong wrong.
  • Generic probes don't resize to fit the large amount of space they now have. This means that numeric and string probes only show a small fraction of the content, with no means of seeing it all (other than creating a new probe type).
  • The dialog remembers its last size, but gets confused if it was last maximized. It tries to set its new size to be the size of your monitor, but it is not in a maximized state. Wrong wrong wrong. This forces you to manually restore it to a normal size. I HATE this. Especially when it's so common that you want to maximize the probe window to get the most out of it.

Shared Variables: Definitely agree. Now that you can dynamically read and write to them, why can't you programmatically create Shared Variables on the fly without the DSC module?

Link to comment

There are lots of actions I'd like to assign keyboard shortcuts to but can't. I'd like to be able to create custom toolbars move them around where I want. Menus (especially right click menus) are overpopulated and I wish there was a way to make them "smart" where they show items that are used frequently and offer a way to quickly expand to see all the options.

XControls are your friend sir.

About the probe dialog, what I don't like is the fact that the new dialog gets focus after creating a probe. It's a major step back in quick debugging (and that for a prototyping language):

  1. A VI with unforseen outcome
  2. Drop a probe
  3. hit ctrl-r (run)
  4. nothing happens
  5. ....:wacko:
  6. Oh yes, the probe dialog has focus
  7. Switch back to VI
  8. hit ctrl-r
  9. find bug

Ideally that would be a 3 stepper.

Auto tool (you're welcome asbo).

Don't reject the auto-tool! You are like Apple (who needs more than one mouse button?)

Ton

Link to comment

You are like Apple (who needs more than one mouse button?)

Ton

What do you even mean by this? Who needs more than one mouse button? ...Me, my mouse is a 17 button with scroll wheel that also has a middle click (so I guess 18 buttons) To be fair I only use 5 of the buttons, but I don't see how not liking the auto tool means I like one mouse button. If anything it means I like using more than one mouse button for Shift + Right click.

  • Like 1
Link to comment

I'm not an auto-tool fan either. It wires when I want to select and you have to select breakpoints and colour chooser anyway.... drives me mad. I'm a Tab and space-bar freak.

Put a mark in the Auto-tool select for me as well. I have tried it in various releases and although getting better, it eventually guesses wrong bringing my work to a stand-still. Shift-right-click shut-it-off and I am done experimenting until the next release of LV.

Ben

Link to comment

I don't understand the auto-tool hate.

1.) It is an option, you can turn it off.

2.) Its function is based on what pixel you are hovering over. Memorize the pixel context, turn down your mouse sensitivity and quit complaining.

3.) Yes, it doesn't switch to the paintbrush tool, but if you bind the tools palette to Ctrl+T (who tiles windows anyway?) then you're in business.

Seriously, auto-tool gets the job done if you know how to use it. Your inability to use a tool doesn't invalidate its usefulness.

  • Like 1
Link to comment

I don't understand the auto-tool hate.

1.) It is an option, you can turn it off.

2.) Its function is based on what pixel you are hovering over. Memorize the pixel context, turn down your mouse sensitivity and quit complaining.

3.) Yes, it doesn't switch to the paintbrush tool, but if you bind the tools palette to Ctrl+T (who tiles windows anyway?) then you're in business.

Seriously, auto-tool gets the job done if you know how to use it. Your inability to use a tool doesn't invalidate its usefulness.

It is not hate but frustration. In my case I have to work on everything from LV 5 through 2010. Which means sometimes the auto tool is there and other times it is not or is a differnt flavor. If I get in the habit of using auto-tool then show-up at customers sight and start acting baffled when the auto-tool is not working on a LV 5 mahcine, i will look like .... not a LV expert.

THe tabs and space work on all versions and I don't even have to think about how many clicks from ths to that any more and besides, I can do the tool selection while the mouse is in transit so I have to right toll ready BEFORE I get there and not after.

Ben

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.