Solution to SubVI freezing Main VI loop during execution

[DecentPhysics]

This isn't a problem with LabVIEW; it is a problem with my experience.

My main VI consists of a Picture control that gets updated when the next frame from the camera becomes available. I would like a SubVI to move a stepper stage so that the camera can image an entire substrate on the stepper stage. I currently have my SubVI in the loop of my Main VI, and it executes when a button is pushed.

My issue is that when the SubVI executes, the camera image in the main VI stops being updated. I'm pretty sure this is because the loop of the main VI gets hung while the SubVI finishes executing (because it is in the said loop). After every move, I need to have the picture updated to gather the image data at every location.

Is there a solution to this problem other than running two loops in parallel? I had initially done this, but I seemed to run into issues, especially performance-related ones.

For reference, I am using a ThorLabs scientific camera and Zaber stepper stages while using the provided SubVIs for both.

[altenbach]

---

@DecentPhysics wrote:

Is there a solution to this problem other than running two loops in parallel? I had initially done this, but I seemed to run into issues, especially performance-related ones.

.

---

What kind of "issues" exactly (sluggish UI? CPU core pegged at 100%? runs out of memory? etc.)?

There should not be any difference in performance unless you  e.g. use greedy loops everywhere.

[proland1121]

based on your description, and without seeing any code, I'm going to assume that your loop is inside the SubVI that you described.  Your main VI won't have any updates until the subVI has completed its entire process.

assuming that guess is correct..... Simplest method... Change your subVI to handle a single step (instead of the entire loop) and place the loop in your main VI.

[DecentPhysics]

---

@proland1121 wrote:

based on your description, and without seeing any code, I'm going to assume that your loop is inside the SubVI that you described.  Your main VI won't have any updates until the subVI has completed its entire process.

assuming that guess is correct..... Simplest method... Change your subVI to handle a single step (instead of the entire loop) and place the loop in your main VI.

---

This was my original guess at a solution, but I forgot to mention that I have two stepper stages (x and y-axes) and I could not reason a way to do the single steps in 2-dimensions.

For instance, this would work flawlessly if the x stage just steps from its initial position to the end (just looping one step). But here, after the x stage steps to the end, the y stage must step up once, then the x stage must step back to the initial position, then the y stage would step up once more, then repeat. But during this process, the main VI does not update.

I attached an image of this process for visual aid.

[DecentPhysics]

---

@altenbach wrote:

---

---

What kind of "issues" exactly (sluggish UI? CPU core pegged at 100%? runs out of memory? etc.)?

There should not be any difference in performance unless you  e.g. use greedy loops everywhere.

---

Yes, mainly performance issues. CPU and RAM usage was very high.

[altenbach]

---

@DecentPhysics wrote:
I attached an image of this process for visual aid. 

---

Such a trajectory is trivially simple to generate. None of this explain high resource usage. Maybe you could show us the entire VI.

[altenbach]

---

@altenbach wrote:
Such a trajectory is trivially simple to generate..

---

One possibility:

[proland1121]

I've not worked with Zaber devices before, but most linear motion hardware accepts both 'absolute' and 'relative' motion commands.  Using absolute commands, there is no harm in telling one axis to go the the position it is currently at.  This will allow you to have both your X and Y movement commands in the same subVI.

OR, you could use a "select" to decide which subVI to call (X or Y)

[zabercs]

Thanks for your question. I agree with all of the other suggestions in the thread. Additionally, the Zaber A Series library package includes a Raster Scan example program in the examples folder: https://www.zaber.com/w/Software/ASCII_Labview_Driver#Raster_Scan. It gives a space to include the code you want to occur at each point in the scan. 

Alternately, if the camera is supported, Micro-Manager is an alternate program that is able to do raster scans and post-processing to stitch the images:  https://www.zaber.com/articles/image-stitching.

Best,

Mike McDonald

mike@zaber.com