LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. 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!
  2. 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.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Custom Structures

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

To further expand generic programming, we should be able to specify custom patterns as a custom structure. For example, if you very often write "retry once" code you could write retry2x.

 

CropperCapture[47].Png

I think if you expand this concept you can accomplish other requests on this board like case structures that respond to error wires with warnings on them. If you expand it farther you could have "express" structures that have a configuration interface.

CLED (2016)
9 Comments
Knight of NI Knight of NI
Knight of NI

I don't see how this code is readable and debugable, which is a problem.

 

LabVIEW already has the option to place a piece of code in the palettes and then drop that actual piece of code (see here, for instance). Does that provide what you want, at least in the sense of not requiring you to rewrite the same piece of code?


___________________
Try to take over the world!
Active Participant

Ooops, I tried to edit the last post but it created a new one. See comment below

CLED (2016)
Active Participant

I think it's as debugable as a subVI. You'd double click on the structure and it would take you to the VI in the lower half of the image. I'm not sure I made that clear. There are two advantages of this idea over the palette drop.

 

  • The top level VI (the top half of my image) would have less clutter because more of the code would be in the subVI (below)
  • If you later decided that you want all your "retry" loops to have a 250 ms period between retries or if you decide that it should only wait on the second iteration, you wouldn't have to go to every loop and change the code, you'd just change the subVI and the change would propagate everywhere. This lowers code maintenance and aids abstraction.

 

CLED (2016)
Knight of NI

Sorry, but I still don't understand what you're asking for.

Active Participant

Essentially, case structures with built in logic defined by a subVI. In my example, Retry2x.vi is the subVI. The code at the top half of  the image is calling the structure with built in logic by wrapping the subvi structure around the file open code.

 

Maybe subVI is the wrong term to use here. It might need its own term like substructure. 

CLED (2016)
Member

One issue is that there is nothing in the subVI/subdiagram/substructure to represent the enclosed code. If the diagram must contain one and only one structure, then you can define that the referencer's code is inserted into that structure. I think you will very quickly come up with cases where you need multiple structures (either nested or not) and then you need a way to say where that code is inserted. There is also the issue of specifying tunnels. In your example you have one normal tunnel and one that looks like a sequence local. The custom structure would need to be able to define arbitrary visuals for an arbitrary set of terminals. This quickly becomes a very complicated set of configuration and would make this quite complex to create.

 

For the specific case of "retry" it seems like there are probably not that many operations that you commonly want to retry so making a subVI for each operation would probably be reasonable. I have a hard time seeing how we would generalize this to a wide set of use cases without making it very complicated.

Active Participant

Why not encapsulate the whole retry action inside a SubVI?



Michael Aivaliotis
VI Shots LLC
Active Participant

Because you might want to retry all sorts of things. TCP connections, database queries, etc. It's a very common way to handle errors. Currently, you'd have to create a subVI for each. If you change your mind on the implementation, maybe you want to enqueue a flag so you know a retry was needed, you have to apply that change throughout. 

CLED (2016)
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

DNatt, NI