QSM Trouble

[NECO2012]

To all that have helped me before, I appreciate it.  I'm asking for a bit more help now.  Both of these links are related to this post; however, they all ask different things.

http://forums.ni.com/t5/LabVIEW/Producer-Consumer-Trouble-Multiple-Loops-Queues/m-p/2038432

http://forums.ni.com/t5/LabVIEW/What-is-the-best-way-to-switch-between-multiple-image-buffers/td-p/1...

I have a lot of the program down.  Still don't have the main function of the program working.  For others, it will be very hard to test because you need the third party hardware which sort of puts me in a bind.  Here's my problem: The program freezes on me every time I try and grab an image.  A link to the zip file is posted at the very bottom.  The problem is mainly in the DAQ Loop.  Once it finally "grabs" an image, the whole program freezes and needs to be restarted. 

I'm assuming lots of memory is being leaked somewhere.  However, even after going to the Performance and Memory, there did not seem to be a problem.  I don't have access to the image of that at the moment because it's on another computer.  Also in the zip file are DAQ test and DAQ Loop test.  With these (pretty much the same loops) I was able to get things working granted the Daq test program is much more basic than UI loop.  With this, I'm assuming it is some sort of memory allocation issue.  I think the PROC loop would have the main memory leak.  I have not figured a way to limit the number of arrays being copied. 

If anyone has any insight to the best method, it'd be much appreciated.  Also if anyone has any suggestion on any part of the block diagram, that would also be appreciated.  I am new to this Producer/Consumer architecture.  My main insight was from the website everyone links when talking about QSM as well as many forum posts.

One last thing I'm asking people to look at is the stop button.  When I stop, everything is supposed to quit out.  However, it always gives me an error about the obtain queue status vi.  I'm assuming no reference is seen because the queue is released.  However, it should have exited the while loop before going back to this point anyway.

Thanks,

Rob

[smercurio_fc]

Please do not post your code on another site. Attach the code directly to your message. Most of the folks here work in corporate environments, and some sites get blocked by firewalls. Also, some folks are dubious of downloading code from other sites (though in this case dropbox is pretty safe).

Thanks...

[NECO2012]

Nevermind.  It used to be larger but now works.

[smercurio_fc]

It's only 700KB. That's definitely not too large to post. Perhaps the issue is with your browser?

Attached is the code for others to reference...

[NECO2012]

Actually I sent out wrong version.  I will upload updated version soon.  This older version doesn't start the process correctly.

[Bogdan-B]

Hi NECO2012,

If the problem is with the grabber, your best bet might be to talk to Matrox or the supplier for that hardware.  NI does not support that hardawre directly, however if you do encounter issues that you can trace to LabVIEW, feel free to post again.

Bogdan Buricea

[NECO2012]

So I've figured out the issue but do not exactly know why it occurs. The Matrox Grabber needs certain inputs in order to grab.  The problem is how I deliver those inputs.  Please look at images Option1 and Option2 (taken from Vi UI_LOOP and another Vi I made just now to compare).  The Triangle is a Vi that contains a list of parameters enclosed in a typedef.  When I feed those parameters via UI_LOOP (Option 2), the program freezes on me. When the only thing fed is the reference and the VI houses all of the parameter defaults which allows no user change (Option 1), the Vi works.  Can anyone explain this occurrence? VI Overhead or something perhaps?

[Ben]

---

@NECO2012 wrote:

So I've figured out the issue but do not exactly know why it occurs. The Matrox Grabber needs certain inputs in order to grab.  The problem is how I deliver those inputs.  Please look at images Option1 and Option2 (taken from Vi UI_LOOP and another Vi I made just now to compare).  The Triangle is a Vi that contains a list of parameters enclosed in a typedef.  When I feed those parameters via UI_LOOP (Option 2), the program freezes on me. When the only thing fed is the reference and the VI houses all of the parameter defaults which allows no user change (Option 1), the Vi works.  Can anyone explain this occurrence? VI Overhead or something perhaps?

---

Probe both and compare what is in the cluster.

There may be something different in the no-work version that is causing the hang.

Ben

[NECO2012]

I tried that. I might just contact the third party and see if they have any insight.  I mean I have that part working now with this other option so I guess it's not that big of an issue.

[NECO2012]

I also figured out the stop button question.  I moved the release queue out of the while loops.  That was the source of the problem.