francois-normandin
commented
7 years ago Hi Thomas,
List Dependencies was a private method before 1.1.15 and has only been made protected to allow more specific SMOs to list the dependencies created and started by their ancestor. It should not have changed the behavior. That being said, I see that it does filter shared dependencies that would have been started by another component in the system even if it was aggregated as defined in enumerateStaticDependencies. I believe we can correct that with an addition in the ListDependencies method as follows:
- Can you add a OR logic with the "isSharedResource.vi" as input to allow those dependencies to be listed and see if that solves your issue?
I use this mechanism a lot and have not seen this issue with 1.1.15 but I think I am using the "ListSharedResource" method instead of "ListDependencies" to find those references... thanks for reporting this issue.
thomasliebenau
Hello,
i have created a SMO for an ethernet IO-node. This SMO was used as shared resource in multiple SMOs representing pneumatic subsystems in my environment. I used enumerateStaticDependencies to define dependancies and this worked very well. I could start the different pneumatic SMOs in parallel using their test launcher. Finally i started composing my machine controller using the pneumatic SMOs. This also worked well.
Since release 1.1.15 i only can start 1 pneumatic SMO successfully. Even the machine controller composition can't launch the dependencies successfully.
The release 1.1.15 changed the output of smo.lvclass:ListDependencies.vi. The output now is filtered by a component shared key. The shared key is calculated from a SecretKey and GUID and changes every time an input changes. So I never get my component shared to other SMOs.
How do i have to implement my shared dependencies now?