ZOOM

[Dennis_Knutson]

You don't have a schematic, you have a block diagram. A zoom function has been endlessly discussed in the Idea Exchange. If you want this, that is the correct place to post your suggestion. Remember the style rule to keep the block diagram about the same size as a single screen. Remember that you also have a magnifier built into Windows. Personally, I have never missed a zoom feature.

[JÞB]

---

@johncf wrote:

thanks for the reply, no i want both.  i need to be able to see the whole schematic to see/understand the overall logic and there are times for instance when i want to connect somethign in the far top left corner with something in the far bottom right corner.  for this i'd like to be able to zoom out and make the connections...  i like to compare this to using CAD you need to be able to see the whole thing (and sometimes make adjustments) to really understand what is going on.  especially the logic flow of a schematic...

---

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.

[Blokk]

LV needs zoom!!!  When you are creating a schematic for the first time, its far easier to lay everything out til its working first THEN optimize by putting into sub VI's etc...  Why can't NI do this?  Every other piece of S/W out there can...

No, it is not easier. When I start to create a new application, I start with a proper pattern (producer/consumer, etc.). This pattern always fits into one screen. After this I can add subVIs as needed. What you explain above looks to me a non-optimal programming style. I try to imagine some of my larger applications to be written following what you say. It would be a disaster. Impossible to debug, and wasting time (working twice).

[johncf]

What you explain above looks to me a non-optimal programming style....   I try to imagine some of my larger applications to be written following what you say. It would be a disaster. Impossible to debug, and wasting time (working twice).

Correct, it may not be an "Optimized programming style" because i'm starting a layout of the logic which may have multiple approaches and seeing what may or may not work best.  its a bit of trial and error.  AND i'm not a programmer, i'm a controls engineer so once i define the logic then a "programmer" can optimize the bejesus out of it if so desired....  its funny some folks seem more concerned about style vs having open functionality...  thanks god the CAD and FEA software developers are have not taken that same approach...  and Blokk, nothing i have written has been a "disaster" nor has it been impossible to debug...

[crossrulz]

---

@johncf wrote:

What you explain above looks to me a non-optimal programming style....   I try to imagine some of my larger applications to be written following what you say. It would be a disaster. Impossible to debug, and wasting time (working twice).

Correct, it may not be an "Optimized programming style" because i'm starting a layout of the logic which may have multiple approaches and seeing what may or may not work best.  its a bit of trial and error.  AND i'm not a programmer, i'm a controls engineer so once i define the logic then a "programmer" can optimize the bejesus out of it if so desired....  its funny some folks seem more concerned about style vs having open functionality...  thanks god the CAD and FEA software developers are have not taken that same approach...  and Blokk, nothing i have written has been a "disaster" nor has it been impossible to debug...

---

Considering about all I do anymore is controls software, I can say with a lot of experience that a modular design from the beginning makes this entire process A LOT easier and faster.

But what do I know?  If I mess something up a jet engine explodes...

[Blokk]

---

@johncf wrote:

What you explain above looks to me a non-optimal programming style....   I try to imagine some of my larger applications to be written following what you say. It would be a disaster. Impossible to debug, and wasting time (working twice).

Correct, it may not be an "Optimized programming style" because i'm starting a layout of the logic which may have multiple approaches and seeing what may or may not work best.  its a bit of trial and error.  AND i'm not a programmer, i'm a controls engineer so once i define the logic then a "programmer" can optimize the bejesus out of it if so desired....  its funny some folks seem more concerned about style vs having open functionality...  thanks god the CAD and FEA software developers are have not taken that same approach...  and Blokk, nothing i have written has been a "disaster" nor has it been impossible to debug...

---

I am not a programmer either, I am a physicist. Never studied programming in school.

I learned LabVIEW first around 2009 lead by a NI trainer online, Core 1-2 courses. After that I just learned by myself and using this forum. End of last year I managed to pass the CLD exam, it was a useful goal to force myself to improve my programming style. As I see you do not understand that programming style is crucial. You lose so much time during development if you do not follow good programming practices. Except some small applications, "code and fix" approach is just not good. And I am not talking about optimalization. The development time difference is just huge between a good approach and a bed one! And do not forget scaleability, and how much time you burn if you need to add extre functions/hardware to your application which is not properly designed.

One thing more: it is funny to compare LabVIEW to a CAD or FEA software. LV is a full featured programming language. A CAD or FEA is not a programming language. It is like comparing an apple to a sausage...

[johncf]

ok i'm not going to go back and forth on style etc because others here seem to know what works best for me...  all i know is that for MY work style i would like to have the capability to see (and make edits too) the entire block diagram if i choose too.  especially for the case of working on a laptop with 15" screen set to a resolution i can see...  AND i work with 7 other people who also use LV (and they are S/W programmer types) and they all say they wished LV had zoom.  not to mention that the NI sales rep for us said the same thing and said he gets asked that queston a lot....  so lets see, of the users i have personally met 100% of them wish it had zoom in/out capability...  i guess we are all non-optiminal users of the software... 

in resposne to the apples to sausages reply i got, i was trying to make the comparison that both are visual representations of something and sometimes it is desired to see the whole picture vs a small fraction of it...  given that both are visual, zoom in/out is what allows that regardless of programming style...

[Yamaeda]

---

@mikeporter wrote:

LabVIEW doesn't have a zoom. LabVIEW doesn't need a zoom. If you think you need a zoom, you need to rethink how you write applications. If you write programs with proper modularzation a zoom function is unnecessary.

Mike...

---

---

It sure needs a zoom if you use a laptop with 4k resolution ...

/Y

[Blokk]

All of my collegues create LabVIEW spagetti codes usually (research fellows, MSc students, PhD students). Full of race conditions, flat sequence structures, overuse of local variables, and block diagram size of several screens. It happens often that I have to fix hidden bugs, etc...

So 100% of the people I know tend to create spagetti code/oversized block diagrams, but I would never say this is the proper way to program in LabVIEW 😄

I think this is a natural laziness of most people. To improve LV programming level you do need to put effort into it.

Anyway, we could argue a lot about these things, but it will not change the fact: a properly designed LV code should fit into one screen more or the less (usually my codes are about ~1.5 screen sized in horizontal direction), from the beginning of the project until the finish.

[johncf]

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...