From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Using VISA references within clusters
Solved!
@RTSLVU wrote:
I am still on the fence if it's "better" or not. Really depends on the project and the number of instruments.
It's easy when you get started with an application and for many typical test applications sufficient, but that says it all. As your test application grows and gets more and more complex, the typical "one entity to rule them all" (your top level VI having all the resources in this BFC) from this design soon gets in your way in many ways.
As you get deeper into things you will eventually find that an architecture where the different devices or subsystems are independent entities that you control with messages, may seem to be a lot more work initially, but tend to be more flexible and also much more performant as each entity runs on its own to do the things it needs to do, without being serialized with all the other calls to control the umptien other devices from your main control.
The high end solution to this is the Actor Framework. It takes care of some of the overhead associated with the creation of infrastructure for such a distributed operating model but has its challenges in terms of complexity and getting to a level where you can actually start to work with it. But once you know it well, you are likely to never do anything else even for relative simple applications that don't really need the distributed flexibility this framework provides.
A compromise is a DOY type process control architecture that creates processes for the individual resources you want to control. A process is basically a dynamically loaded VI that runs in the background and is controlled through queues and/or user messages through an API that hides the complexity. However dynamic loading of VIs in that way has its challenges. It seems initially very easy to do in LabVIEW but there are corner cases where things don't always work as expected and the building of an executable application can make things also more complicated. This is one thing that is already well solved in the Actor Framework for you and by some of the brightest LabVIEW programmers around. Doing it yourself is definitely possible, but you will need several iterations to get it to work reliable in all cases.
In the short term, anything but the BFC (big f*cking ccluster) will take more time to develop, but in the long term this BFC architecture will turn into a nightmare as your application grows and is extended more and more. Also the almost unavoidable sequentialization of all calls to the various instruments and other resources can be a huge liability for complex applications, making everything unnecessarily slow as most instrument communication is usually spending most of the time waiting for responses from the instrument, and with your single state machine architecture using this BFC, everything else in the other states has to wait even if this state is spending 99% of its time waiting for the response of the device.
My answer was not to claim that your solution is wrong. It works reasonably well for smaller applications with only a few instruments at most. I still do it in this way for small test applications. It was really more in response to RTSLVU's remark that I quoted.
Making sure all your tunnels are properly wired is one of the many complications of this design though! 😁
@rolfk wrote:
@RTSLVU wrote:
I am still on the fence if it's "better" or not. Really depends on the project and the number of instruments.
It's easy when you get started with an application and for many typical test applications sufficient, but that says it all. As your test application grows and gets more and more complex, the typical "one entity to rule them all" (your top level VI having all the resources in this BFC) from this design soon gets in your way in many ways.
As you get deeper into things you will eventually find that an architecture where the different devices or subsystems are independent entities that you control with messages, may seem to be a lot more work initially, but tend to be more flexible and also much more performant as each entity runs on its own to do the things it needs to do, without being serialized with all the other calls to control the umptien other devices from your main control.
The high end solution to this is the Actor Framework. It takes care of some of the overhead associated with the creation of infrastructure for such a distributed operating model but has its challenges in terms of complexity and getting to a level where you can actually start to work with it. But once you know it well, you are likely to never do anything else even for relative simple applications that don't really need the distributed flexibility this framework provides.
A compromise is a DOY type process control architecture that creates processes for the individual resources you want to control. A process is basically a dynamically loaded VI that runs in the background and is controlled through queues and/or user messages through an API that hides the complexity. However dynamic loading of VIs in that way has its challenges. It seems initially very easy to do in LabVIEW but there are corner cases where things don't always work as expected and the building of an executable application can make things also more complicated. This is one thing that is already well solved in the Actor Framework for you and by some of the brightest LabVIEW programmers around. Doing it yourself is definitely possible, but you will need several iterations to get it to work reliable in all cases.
In the short term, anything but the BFC (big f*cking ccluster) will take more time to develop, but in the long term this BFC architecture will turn into a nightmare as your application grows and is extended more and more. Also the almost unavoidable sequentialization of all calls to the various instruments and other resources can be a huge liability for complex applications, making everything unnecessarily slow as most instrument communication is usually spending most of the time waiting for responses from the instrument, and with your single state machine architecture using this BFC, everything else in the other states has to wait even if this state is spending 99% of its time waiting for the response of the device.
Another simple way to accomplish similar things is to just plop separate control loop subVI's on the block diagram instead of launching them dynamically (which can be confusing to new users). You still communicate with queues/user events/etc as normal. Granted, you do wind up with very coupled design, but it's not a bad way to get one's feet wet with multiple asynchronous processes before jumping into the Actor Framework. IIRC the MGI QMH platform does it this way, but I haven't actually used it before. It might be dynamically launched.
I did it this way for a while before I could get my head around AF, which can be a real PITA to debug when you're first starting out.
