LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using VISA references within clusters

Solved!
Go to solution

Hello,

 

I'm setting up a test bench that must control multiple VISA connected instruments.  They all show up and connect in NI MAX so I know I can talk to them, and have done so in simpler programs.  The new trick I'm trying to do is to put all the instruments I'm using into a large cluster, and unbundle them from the cluster as I need them.  The program is based on the example State Machine program that comes with LabVIEW so what I'm trying to do is cluster all my instruments into one wire and have an "InitInstruments" state that unbundles the VISA references from the cluster, and sends VISA write commands to each instruments to put them all in the initial state.  I have another state called "CloseInstruments" that does the same sort of thing, but puts them in the safe shutdown state then closes the VISA resources.

 

I'm also trying to be clever and have created a typedef file of the cluster that contains all the instruments.  This is part of my LabVIEW project I've created for this program.

 

The problem is that I get an error saying the VISA reference is invalid when getting the VISA "wire" from the cluster BUT, if I put an actual VISA control to the same instrument, all is fine.

 

I'm not clear on why a control by itself works fine and putting the same control into a cluster and unbundling it to access it does not work.

 

Thanks,

-John C.

0 Kudos
Message 1 of 10
(293 Views)
Solution
Accepted by JohnCookInfineon

I see that many of your tunnels are set to Use Default if Unwired, and that not all of the cases are wired through.  (The hollow box indicates this.)

 

Right click those tunnels and uncheck "Use Default if Unwired".  Then go and wire through all of the cases until your VI is no longer broken.

 

My guess is that one of those cases is running where your setup cluster is not wired through and as a result, it is getting replaced with an empty VISA reference.

Message 2 of 10
(270 Views)

Without being able to look at your actual code I am guessing Ravensfan is right and your cluster is not being carried through one of your cases.

 

I bundle all my VISA resources into a cluster like you are trying to do all the time.

 

So when done right it does work.

 

I am still on the fence if it's "better" or not. Really depends on the project and the number of instruments.

-------------------------------------------------------------------
Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
Message 3 of 10
(245 Views)

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

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 10
(233 Views)

Thanks much for all the input guys, its appreciated.

 

I think for what I'm doing.... characterizing integrated circuits on a lab bench... I should just keep it simple.  This is my first time using a big state machine technique and with it I'm able to incorporate all my VISA resources, my SQLite DB, keep all my code pretty neat and easy to follow and my peer seems to think this is a good way to go too.

 

Going down the path of multi-tasking is probably much more complicated than I will need.

 

I think the original suggestion to wire through all the tunnels is the correct fix, I'm new with those too so I wasn't sure.

0 Kudos
Message 5 of 10
(219 Views)

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

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 10
(216 Views)

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


 

 

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.


Honestly I have found %99 of my automated test applications spend %99 of their time waiting for a measurement interval.

-------------------------------------------------------------------
Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
0 Kudos
Message 7 of 10
(206 Views)

Thanks so much for the prompt, accurate replies.  I am new with tunnels and state machines and did not realize that I have to wire the tunnel through the VI to make the values move across.  Works great now.  Thanks.

 

-John C.

0 Kudos
Message 8 of 10
(194 Views)

Helpful tip for this situation:  you can right-click a case structure output tunnel and choose the "Linked Input Tunnel..." menu option, and then identify which input tunnel should be linked to it. 

 

When you do this, future cases you add will automatically make that wiring connection for you.   There's also a menu option to auto-wire existing cases that haven't yet connected a wire to the output tunnel.

 

 

-Kevin P

0 Kudos
Message 9 of 10
(192 Views)

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

0 Kudos
Message 10 of 10
(188 Views)