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: 

Classes should not be locked when added to multiple targets

Status: New

Let's say you have a class you are developing and want to reuse it in multiple targets, particularly if you work with RT targets. You want to do most of your troubleshooting and development on the PC (assuming that the class has nothing hardware-specific) and when it works well you plan to do some final testing in the actual RT target.

 

So, you create your test project, with the PC target (with the class and the tester VI). Now you add the RT target and reuse all the VIs and the class. BAM! LabVIEW locks the class and you can't make any more changes until you delete one of the targets of your project. You can't even create two projects (one for the PC another for the RT), because the class will be locked.

 

NI has an "explanation" here http://digital.ni.com/public.nsf/allkb/219A8BB7FD8EF0D9862571840053A5E9 but I find it lame, because a similar situation described in the article happens when modifying typedefs (some VIs get temporarily "broken" until you Apply Changes in the typedef editor).

 

Please do not lock classes or at least have a button/command to unlock one of them.

23 Comments
Member

I have to agree that this is the most annoying thing ever if you develop on RT as well. I thought that this would be fixed by 2020 but that is not the case. 

Member

In the last few years I have made the decision to not use labview for at least two projects because of this issue.  I am a labview "evangelist" who often has to counter the stereotype, held by many engineers, that the language is a toy or only an educational tool, and this is not helping. The language should not have arbitrary limitations on how language constructs can be used.  I shouldn't be prevented from using my software on multiple pieces of hardware in the same project without incurring a maintenance headache. 

Member

After more than a few years of developing in labview I keep getting the feeling that Rt development is just lagging behind in every aspect. No reentrant debugging on RT is furiating as well and the list just keeps growing.