LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

problems about reading complex VI

Hey friends,

I need to read some real complex VI about keithley 2400, SR7280 and many others. Those vi are not permitted to post, so I can only describe them roughly. One of them has about 8 structures nested with each other, and many lines, and about 50 child vi, some of these child vi also very complex. My problem is, how can I read and use those VI? Should I read them one by one?Or there are other ways to use those vi without comprehend them? Does anyone use ni instruments need to read or even write 8-structure-nested vi?

I know my question is a mess, and I'm a mess too. I really don't know how to solve it. Could someone give me suggestions, please?

thank you

0 Kudos
Message 1 of 7
(1,174 Views)

If it's any sort of well programmed it should have a good description on top level VI's and you shouldn't need to open them at all. If there's 8 structures Deep it sounds like that won't be the situation ...

Compare to e.g. LVs ini-file functions, you can open and study them, but you don't need to.

If a driver is implemented as an AE (Action Engine) you'll get one level extra with the wrapped functionality, but it should still be pretty obvious what's happening as you should have a Enum as command-input and a case structure.

So, what can you gather from your code information wise?

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 7
(1,169 Views)

Reading that VI (any VI really) isn't hard at all.

 

It's understanding it that could be difficult. Especially if you don't get to see it, like we do.

 

But seriously, what do you need to understand from this code? Do you need to fix a bug? Or reuse some drivers? Add to it? Or are you trying to figure out what the program does (so you can re-write it properly)?

 

If there is no logic at all, you're up for a lot of work. This could be very painful. I usually start replacing simple stupidities with clean code. If there really is no logic, there's usually a lot of this kind of code. So much that you can't see the structure through the mess. So, clean up the mess, until you see structure.

 

Meanwhile, work from the other side. Things that are structured (drivers maybe) can be organized, documented, and form a basis to clean the places where they are used.

 

It's hard for us to judge the situation. It could be your level of experience that needs work. That's no insult, we simply can't tell (and your actually asking for experience 😉).

 

8 structures of nested VIs could very good. I'm sure I have 8 levels of nested VIs, but without knowing the complexity of the application, that doesn't mean anything. 8 levels could be very clean for the complexity of the application. The number of (nested) VIs should be balanced. 0 (nested) VIs would probably be worse. I've seen a number of "one liners", 14 MB VIs that contain anything. 8 levels of nested VIs sound good compared to that.

0 Kudos
Message 3 of 7
(1,147 Views)

wiebe@CARYA wrote:

8 structures of nested VIs could very good. I'm sure I have 8 levels of nested VIs, but without knowing the complexity of the application, that doesn't mean anything. 8 levels could be very clean for the complexity of the application. The number of (nested) VIs should be balanced. 0 (nested) VIs would probably be worse. I've seen a number of "one liners", 14 MB VIs that contain anything. 8 levels of nested VIs sound good compared to that.


Everything in moderation, i guess, or "Lagom är bäst" as we say in Sweden. 🙂

Yes, 8 levels of VI's could be useful and well built, but i bet on it being overkill. Still better than a "one VIer".

I interpreted it as 8 levels of case and sequences (akin to the one VIer). 🙂

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 7
(1,131 Views)

@Yamaeda wrote:

wiebe@CARYA wrote:

8 structures of nested VIs could very good. I'm sure I have 8 levels of nested VIs, but without knowing the complexity of the application, that doesn't mean anything. 8 levels could be very clean for the complexity of the application. The number of (nested) VIs should be balanced. 0 (nested) VIs would probably be worse. I've seen a number of "one liners", 14 MB VIs that contain anything. 8 levels of nested VIs sound good compared to that.


Everything in moderation,


including moderation 😁?

0 Kudos
Message 5 of 7
(1,127 Views)

wiebe@CARYA wrote:

@Yamaeda wrote:

wiebe@CARYA wrote:

8 structures of nested VIs could very good. I'm sure I have 8 levels of nested VIs, but without knowing the complexity of the application, that doesn't mean anything. 8 levels could be very clean for the complexity of the application. The number of (nested) VIs should be balanced. 0 (nested) VIs would probably be worse. I've seen a number of "one liners", 14 MB VIs that contain anything. 8 levels of nested VIs sound good compared to that.


Everything in moderation,


including moderation 😁?


Sure, look at any forum or Twitch channel for example. 😉

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

Qestit Systems
Certified-LabVIEW-Developer
Message 6 of 7
(1,115 Views)

First of all there is not a "child vi" in LabVIEW. When your talking about a child it is related to classes where you can have parent and children. There is a definite relationship between them. I believe that what you are referring to are subVIs. 

 

As others have said based on your description this could be good code or poorly written code. If you could share a little bit more about what you are trying to do it would be helpful. Are you trying to use the code in a larger application? Then you really only need the top level VIs. Are you trying to fix a bug? The number of subVIs utilized might be beneficial as you can focus in on where the issue resides. Are you trying to add functionality? Perhaps you don't really need to know how everything else works - you just need to know where your new functionality needs to reside. Start from the top level and work your way to the appropriate location.

0 Kudos
Message 7 of 7
(1,106 Views)