LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ZOOM

I am not sure why we even have this discussion, because we have discussed all this long ago in this idea, so let's keep it all in one place.


@johncf wrote:

just because i choose to expand beyond 1 screen for my block diagrams DOES NOT mean its spaghetti code...  in fact quite the opposite as by having space between the icons allows me to better see what is connected to what without having to dig into a sub VI...  in fact after i have something figured out and working,  i do typically condense what i can into a sub VI...  but getting it to work first is my priority, not keeping it to 1 screen...


Zoom out is problematic, because many wires are single-pixel wide, so they would distort or disappear by a quick, inexpensive zoom. LabVIEW is pixelmapped and we already use the smallest quantum for crucial representation of dataflow. Sure we could do antialising and e.g. have a half-pixel wide wire at full pixel with, but at half the intensity for example. This is a relatively expensive operation, especially for the cases you are describing where the diagram covers many thousands of pixels in all directions.

 

Your "delayed subVI creation" scenario is actually backwards. SubVIs encapsulate specific operations and isolate them from the calling VI. The correct way would be to start with the subVI nearly empty, Call it once with typical data from toplevel VI so all controls have typical data. Now you can keep editing and running the subVI in its own sandbox without having to worry about the calling VI at all. Troubleshooting code in the context of a gigantic diagram is significantly more difficult. (Of course this method requires that you don't rely on local variables for computations. Local variables should be reserved for UI specific stuff). I often just place a small sequence frame on the toplevel diagram and wire all needed inputs to the left border. If needed, I create diagram constants for all outputs inside the sequence. Now I just create a subVI from the sequence frame and have a subVI with everything already connected and already placed in the calling VI. In the subVI, I delete the sequence and compose the code as needed.

 

Testing a small code segment in a gigatic VI is like testing a headlight switch only while the car is driving down the freeway. You need to isolate the tasks.

 

 

Message 41 of 63
(2,593 Views)

I always hate to see these "Where's the Zoom?!?" threads resurface because every time I fear that the NI LabVIEW Devs will break down and fold to the requests of all the unenlightened noobs who will eventually 1) give up on LabVIEW because they were never serious about it, or 2) develop their skills to the point where they realize zoom is essentially useless in a programming language.  

 

You don't need to zoom the block diagram any more than you would need to zoom the text in Visual Studio or Eclipse.  True, some new monitor resolutions make me grab reading glasses. But I need them for both LabVIEW AND Python/C++ coding.  I prefer to grab those glasses and have all the fine resolution and extra screen real-estate any day of the week rather than waste time zooming and panning around.  Note that I LOVE zooming and panning around in Blender3D, SolidWorks and any other application that actually benefits from those editing features.

 

Noobs:  Spend some time learning how to use an advanced programming tool like LabVIEW before you come on here and demand that the developers make fundamental, time-consuming and expensive changes to the core of a language you barely understand.  The professional LabVIEW users want the devs to spend their time working on features that will actually enhance our productivity, not frivolous eye-candy.

 

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
Message 42 of 63
(2,557 Views)

@johncf wrote:

...  i do typically condense what i can into a sub VI...  but getting it to work first is my priority, not keeping it to 1 screen...


 

That is actually part of the problem.  If we were talking C programming, this is your argument:

 

#include <stdio.h>
 
int main()
{
  // ENTIRE PROGRAM GOES HERE
  return 0;
}

I don't think anyone in any porgramming language would argue that this is a good plan. That includes LabVIEW.

Message 43 of 63
(2,538 Views)

LabVIEW Communications has zoom, something like 30% to 300% (not sure about exact numbers).

 

I thought zoom would be really awesome but in practice you just kind of stay at the normal 100% most of the time.  Mechanically, it just gets more difficult to program when you are zoomed out and the task of getting a full view of the code is solved pretty well by the navigation window.

 

I haven't used it a whole lot though so maybe it would grow on me.

Matt J | National Instruments | CLA
Message 44 of 63
(2,471 Views)

@JÞB wrote:

This is why I want LabVIEW 2051 (Not a typo 2051)

In LV 2051 I expect that my several BD's will be able to holographically project onto any direction while I manipulate the 3D representations of the app code by simple hand gestures to move through the graphical function representations.  

None of that tech is really priced well enough for the average developer today.Heart


And I thought channels were going to be confusing enough.  

 

I think I found your ideal environment here Jeff. People may bring up small concerns about unimportant things such as practicality, they just don't understand.

 

https://www.youtube.com/watch?v=7SFeCgoep1c

Matt J | National Instruments | CLA
0 Kudos
Message 45 of 63
(2,456 Views)

@Jacobson-ni wrote:

@JÞB wrote:

This is why I want LabVIEW 2051 (Not a typo 2051)

In LV 2051 I expect that my several BD's will be able to holographically project onto any direction while I manipulate the 3D representations of the app code by simple hand gestures to move through the graphical function representations.  

None of that tech is really priced well enough for the average developer today.Heart


And I thought channels were going to be confusing enough.  

 

I think I found your ideal environment here Jeff. People may bring up small concerns about unimportant things such as practicality, they just don't understand.

 

https://www.youtube.com/watch?v=7SFeCgoep1c


I was thinking more of a Tony Stark type of thing.


"Should be" isn't "Is" -Jay
0 Kudos
Message 46 of 63
(2,238 Views)

NIquist wrote:

Noobs:  Spend some time learning how to use an advanced programming tool like LabVIEW before you come on here and demand that the developers make fundamental, time-consuming and expensive changes to the core of a language you barely understand.  The professional LabVIEW users want the devs to spend their time working on features that will actually enhance our productivity, not frivolous eye-candy.

 

I'm just trying to say that i'd like to be able to easily see my entire block diagram; so for example i can trace the command and feedback signals of a 20,000 lb actuator through my control loops and verify that everything is hooked up correctly before i command it to produce 20000 lb and break some very expensive equipment.....  (yes yes yes i will do other testing to verity things before opertating this, but a visual check is just as important....)

0 Kudos
Message 47 of 63
(2,225 Views)

I can always see my entire block diagram of the MAIN VI, which should fit into one screen, so no zoom is needed. I use subVIs with descriptive icons and also with proper documentation, so when the help is turned on, I just have to move the mouse cursor over a subVI, and I get a description what it does, what kind of input and output terminals it has.

 

Beside, I usually work with a 2 monitor configuration. I can see my entire MAIN.vi BD on one monitor, and I can just quickly check the BD of any subVI on the other monitor in case when the help description is not enough. But in principle this just gives a little more comfort, even a 1 monitor system should be enough to see an entire MAIN BD (ok, you probably need to scroll through some state machine state cases...)

 

So I am still very convinced we do NOT need zoom for a properly programmed LabVIEW project...

Message 48 of 63
(2,220 Views)

johnfc wrote:

I'm just trying to say that i'd like to be able to easily see my entire block diagram; so for example i can trace the command and feedback signals of a 20,000 lb actuator through my control loops and verify that everything is hooked up correctly before i command it to produce 20000 lb and break some very expensive equipment.....  (yes yes yes i will do other testing to verity things before opertating this, but a visual check is just as important....)

 

I'm sorry but that's my point.  You're making assumptions about LabVIEW that are not true.  You're not looking at a schematic that represents physical entities, you're looking at a block diagram that represents software abstractions.  If you simply would have created your code in a modular, encapsulated way in the first place you could have easily tested all its functionality independently and safely.  A properly designed state machine that performs a sequence of states can be shut down at any particular state quickly in case of unexpected behavior.  It's like pushing a bowling ball down a staircase where you have some control over it at every step.  Running a long block diagram straight through is like pushing that same bowling ball off a cliff.  You have no control to stop it if you realize too late that some poor soul has walked into its path.  Smiley SurprisedSmiley Sad

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
Message 49 of 63
(2,201 Views)

NIquist wrote:

You don't need to zoom the block diagram any more than you would need to zoom the text in Visual Studio or Eclipse.  True, some new monitor resolutions make me grab reading glasses. But I need them for both LabVIEW AND Python/C++ coding.  I prefer to grab those glasses and have all the fine resolution and extra screen real-estate any day of the week rather than waste time zooming and panning around.  Note that I LOVE zooming and panning around in Blender3D, SolidWorks and any other application that actually benefits from those editing features. 


Your analogy fall flat when you realize you can zoom C++ and that it's not fixed at 8 pixel fonts, which is basically the case for LV (since the blocks can't be resized). Zooming out is not so much of an issue. Although it can improve overview the pure size of things makes is impractical (and close to impossible) to work and wire zoomed out. Zooming in to easier connect things on the other hand ... It has nothing to do with being a nooblet and all to do with having a good IDE.

Implying that only noobs would benefit from a zoom function, when you happily use it in other programs, is hypocritical and elitist.

I guess the argument can be used the other way around, only n00bs use zoom in Blender. 😛

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 50 of 63
(2,155 Views)