Sorry I feel like this is simple, but I’m missing something.
I have an actor on my real time system, and I want almost the same actor on my host PC. I’d like to be able to make edits to one (or a common parent) and the other one to reflect it. I feel like I need them to inherit from a common parent, but when I I tried using an existing actor and giving it two children in separate projects it locked not only the parent (expected) but the children too. I realise we use interfaces to stop this happening with messaging, but you can’t use call parent method with interfaces. I don’t have any experience using abstract classes, so not sure if that’s what I need here.
Can anyone advise?
Solved! Go to Solution.
I can't tell exactly from the description, but I think your projects are locking because they're cross-linked, nothing to do with inheritance, per se.
What you're describing is essentially making the parent into a shared library, and making multiple projects (the children) use that shared library. If they point to the same files on-disk, then LabVIEW will lock everything when one project claims the parent.
When I do this, I give each child project their own full copy of the shared parent library (instead of pointing everything to the same disk files). For simple projects, it's ok to just copy/paste the shared parent library into the project. For bigger or complicated projects, I like using SVN externals to keep it in sync everywhere.
I usually keep the PC and the RT code in separate LabVIEW projects and only open the one I'm editing.
Okay I think that makes sense. So are you saying I would just have two copies of the parent, each child would inherit from a copy, and if I wanted to make changes to the parent I would edit one version and then copy it again? Seems fair enough, I can see why you'd only want to do this for simple projects
If you have a child in one project open, and another project open with a child of the same parent, it is expected that the parent will be locked (as you said) since it is in two application instances at once. However, the children should not be locked. If they are, then it means you have a circular dependency, like for example if the parent is depending on its children. Children have to know about their parents, but parents should not know about their children. You need to find what is causing this dependency, first. If the dependency is caused by a send message, then you might be able to resolve it by using interfaces to make abstract messages. I'm not sure what you mean by "you can’t use call parent method with interfaces" - why is that causing a problem for you, why do you think you need to call parent method with interfaces? Are you familiar with how to use interface messages?
There are cases where I think it's fine to have copies of a parent that you are inheriting from - eg: if it's part of a built library/package that you re-use in various places, like using GPM. But in this case I would not recommend it at all. You will likely make changes to that parent and you don't want to constantly have to copy/replace to the other copy of it. It would be a huge pain.
Yeah my comment about call parent method with interfaces isn't relevant as that's not what interfaces are for. I really just meant I'm happy with how interfaces work for messaging, and how for sending messages over the network you use an interface class to define the messages, and that class gets locked, which is alright. I wanted the same setup, but with call parent methods possible so that the parent can be locked but not the children, and both children can call their parent actor core etc
(it made sense in my head) I see this is how things should work with the parent class, I'm just seemingly introducing some kind of dependency that means it doesn't work.
I think i hadn't set up my investigation well (i used a fully made actor, which presumably pulled in some other dependencies), so did it with a more basic three actor system and it seems to be fine (only parent locks), so I guess this is fine after all!
Although it's possible that these are more complicated droids than you're looking for, PPLs have helped me in this situation.
When you use a PPL, you build a copy for each target system (Windows PC, cRIO) and then you link your children to that Packed Project Library (PPL).
This allows you to have a single source (always on PC, in my case, always Windows) and build it for multiple targets.
Note that once you start having dependency trees of PPLs, you need to consider your build 'strategy', for want of a better term.
However, for a single library, you might manage to make it work with only the built-in Build Specifications and a Ctrl+Drag'd copy between targets (in the same project).
This gives you an icon like this when you change it in one target (3 green arrows, update):
Making changes in one target whilst the other is open displays something like this:
In this configuration, it is possible to create two build specifications for the same code on your hard drive:
However, as I mentioned before, if you want to build an entire collection of PPLs, I'd recommend something more automated.
I can expand if you'd like on what I do, but I don't want to post an essay that you don't care about 😉