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


We are discontinuing the use of the sbRIO product line because of this issue.


Yea, OK it sucks that the class is locked, but I'm not sure that is the root problem.  I wonder if this is a problem with VI Server or projects in general?  The issue I'm having is communications between a PC project and an RT project.  In other development platforms this would likely be two separate projects and each project would have a copy of the same class.  The communications interface would be TCP/IP and a driver would have to be written to take the data and stuff it into the appropriate location.  If the class changed, both sides would have to upload the revised class.  This is basically the solution that is suggested, close the project, update the class, and reload the project.  


In my mind, I want isolation, I don't want the PC code to create a dependency to the files on the RT side.  I want the PC code to have it's own copy of the code, when data is exchanged it should be loaded into the active side class.  I'm not sure what has to be done to make this happen, but without it, I can not truely write modular code, because I'm referencing to many dependent files on the other side of the interface.

Proven Zealot

King_Cluster: If that's what you want, then you should be able to do it. Create two classes with exactly the same name at two different locations on disk. Add them both to your project, each in a different target. LV does allow multiple files of the same name in the same project so long as they are on different targets. As long as they have the same private data cluster and the same class version number, they will serialize back and forth just fine.


This issue is affecting me as well. I just spent a week developing some LVOOP classes, only to find out I had to scrap it all because I couldn't get them working on multiple targets without making multiple copies of the project or the classes. This is clunky and opens room for lots of mistakes and debugging headaches. No thank you. I'll put in the extra work up front to make sure I don't have to deal with headaches in the future, which, ironically enough, is one of the reasons I use classes to begin with.


Another reason I use LVOOP is because it makes code reuse much simpler. Well, not in this case. I'm now concerned that many of the classes I've already written will need to be rewritten without LVOOP if I ever need them on multiple targets, which happens rather frequently in my line of work. Come to think of it, I've been developing a pretty large application for a couple years that I was hoping to use on both PXI and cRIO targets, but now I realize that I won't be able to do this easily.


This is a really frustrating issue, and it's even more frustrating to find out it's been known for several years. Why does there have to be a business case and a return on investment for everything? What ever happened to doing something because it's the right thing to do for your customers?

Proven Zealot

> What ever happened to doing something because it's the right thing to do for your customers?


We do as many right things as we can, and there are many right things that demand our attention. The business cases are how we decide among those right things.


For what it is worth, I am sorry I had to make LV work this way. There is work being done on this issue, but not as fast as I wish it could happen. There's a lot to untangle.


My apologies; that final paragraph wasn't meant to be directed at you or NI in particular. I was using "your" in more of a general and figurative sense.


I understand that you had to make a tough decision, and I know that I'm not aware of all of the decisions you folks have to make internally and how your priorities are laid out. I'm also sure you're all trying to do the best you can, and I'm very appreciative of the way NI typically handles customer issues. I guess I was just venting some frustration.

Proven Zealot

No need (in my opinion) to apologize. It was correct to complain to us. There are times when that bothers me, but in this case, this decision falls squarely on my shoulders. I still think it was the right call to make at the time... I just didn't expect it would still be lingering all these years later. I had no idea how deep that dependency chain would run.


Venting frustration is fine when there really is something to be legtitimately frustrated about -- it keeps the fire lit so that eventually this gets resolved! 🙂


Don't give up on Classes yet!!!  I think there is a lot of good things that come out of them.  What we came up with for a work around is to create a development platform directory that contains a subdirectory structure similar to the following:




C:\DEV\ Application_Layer




In the Data Link Layer there are directories associated with functions, such as IEEE_488.2.  Typically these files are stored in a library of common files.


In the Session Layer we have parallel threads that can be reused from project to project, which may or may not point directly to data link files.  These files are stroed in libraries or classes depending on there function.  We are in the habbit of using classes, when there is data we want to share with other project, so we will wrap the class in a Functional Global Variable action engine.  If we don't have to share data, we typically use a library, because it's just a little bit easier to setup.  One could argue that with classes, you don't need libraries, I think that is a valid arguement for a different thread.

NOTE care must be taken so that there are not project specific functions within this layer.


Then the Application Layer has the project specific files that are custom from project to project..  Again which may or may not point to the Session layer files and files are stored as libaries or classes. 


In this platform concept, the application files point directly to the "reused" files from the session layer.    Are solution seems to be working, but has added a new dilemma.  It is possible that while developing, an application layer program we can introduce a bug into the session layer, that could affect other applications the next time they compile.  We went down the road of packet libraries, which sounded exactly like what we wanted to do (locking down session layer files so that the application layer doesn't accidently modify these files) But that became very difficult to develop.  We found ourselves developing both the session layer and the application layer at the same time, and then having to modify the packect library files, which became a pain in the neck.  Additional, replacing existing files with packet library files became really frustrating.  I think once the session is developed and really ironed out, it MAY be the way to go, but for now, we are avoiding packet libraries.  And it is the programmer's responsibility to know whether files are in the session layer and whether or not it is acceptable to modify these files.


Another issue we are working through is version control.  If you modify applcation 1 and save it, then you modify application 2 and save it, session layer files will ripple though, that's the whole point.  But if you ever need to go back to an exact revision of appplication 1, how do you do it?  We are trying mercurial to rev the entire DEV directory on each application release.  But it turns out that we need nested subrepositories and haven't figured that out just yet...




I have also run into this issue and have all the same complaints as the others.  I appreciate Aristos Queue's honest and interesting explanation of the issue and the decision behind it. 


1) I urge action on this and look forward to using the fixed version someday.

2) LabVIEW adoption is optional, and NI being responsive to serious issues of this type will help me to continue using it. There is a perception among many engineers that labview is a toy, and although I am always fighting this perception, this kind of issue contributes to it.


This is still a problem in 2020. Why?