VI doesn't run properly on Normal Mode, but does in Highlight Mode

[Liepo]

Hi,

First I will explain my VI.

I programmed this VI to acquire Images from 2 cameras and Data from a spectrometer simultaneously every 5 minutes.

That Images and Datas are separated per day at different pastes using the number of times the Datas are acquired.

The problem is the following:

When I run the VI in normal mode sometimes it doesnt work at all (without an error message). But other times it can work for about 20 acquisitions and then it stops without an error. When I highlight the VI after that happens I have the following image in " error.jpeg ".

When I run it in Highlight mode it usually works, but I haven't tested for long periods.

I believe the bug has something to do withing timing or race conditions, but I don't know how to fix it.

Thanks in advance for your Help,

Oscar

[Liepo]

OH, I forgot to mention that the program doesn't just stops, it freezes !

Tks

[Bob_Schor]

Is error.jpg just supposed to be a picture of the Block Diagram of your main VI?

It is pretty difficult to figure out what you are trying to do, with all those wires running all over the place, no sub-VIs, no labels to hint at what is being done.  You seem to be writing at least three files (two PNGs and a Measurement?).  Note that you have a single timed loop (why?) that contains both the Grab and the Writes.

First question to ask is "Who is the Boss?".  Who controls the Clock and sets the timing for the loop?  If you are taking Videos, it is not uncommon to set the camera to a particular Frame Rate and let the camera be the clock (it should wait until it has an image to give you, making it "run" 30 times/sec if you have set it to 30 fps).

The single VI that you attached does not show us all of the code -- there are missing sub-VIs or functions that generate data being written to the Measurement File.  What is this?  How is it "clocked"?

Going back to my previous question about who controls the timing, it may be important that each camera and the DAQ device "fire" at exactly the same time, in which case having them inside a timing loop may make sense, particularly if you understand that on a Windows PC, timed loops are not particularly accurate or precise (certainly not as good as the hardware inside the camera).

As far as the timing problems, you are trying to do too many time-critical things in a single loop.  You would probably benefit from a Producer/Consumer Design, with the cameras and DAQ device in a Producer Loop, putting data onto a Queue that then goes to the Consumer loop for writing to the three files.

Bob Schor

[natasftw]

Is that a timed loop... inside of a while loop... inside of a case structure?

Please tell me no.

Beyond that, if the problem doesn't exist in highlight, you're either looking at a timing issue (something you could check by adding delays) or more likely a race condition.

Can we begin to troubleshoot that picture?  No.  Can you get parts of the application to work on their own?  Does the problem exist when you have everything together?

[mikeporter]

If you want multiple cameras to acquire images simultaneously, you will need to trigger them external -- there is no other way.

You also need to take some time to go through the LabVIEW tutorials. The basic cause of your problem is a race condition, not surprising when you look at the disarray in the code. You could waste a lot of time fixing bad code, or start over correctly. The tutorials will teach you what "correctly" is.

Mike...

[Liepo]

Alright, so I went with the advice of separating acquisition in Producer and Consumer loops and the result is VI attached (you can see it in the images too). I tried to make it more easy for you to understand too..

aand the good news is: IT WORKS JUST FINE !

The images and datas are being acquired and saved normally for long periods of testing. But I still have a few problems to solve.

- I'm using Wait Until Next for timing and it doesnt meet my requirements (the number of images acquired by each camera is not necessarily the same). I wanted to know if there is a better method for synchronizing the Producer loops at 1 acquisition every 5 minutes.

- The function I created for automatically create Incremental New Pastes after a certain number of acquisitions (which is connected to the stop in each Consumer/Producer loop) sttoped working. How come?

- Is there a way to control the number of iterations in all Consumer/Producer loops with only one control in the Front Panel ?

That's all I need to solve for now. I appreciate very much the help.

Thanks !

[Liepo]

The images are attached below 😄

[Liepo]

Waiting for a reply (:

[mikeporter]

I would create the producer loops (which are acquiring the images) to be event driven and only get a new image when a UDE (User Defined Event) fires. To make it easy, make the producer VI reentrant so you can launch as many clones of it as you need when the application starts. When the clones are launched you would pass to them a value that would tell them which camera to access.

I would next create a new process -- called Metronome.vi, or something equally appropriate -- that does nothing but fire the acquisition event every 5 minutes.

To return the acquired images to the consumer, use an event or queue (UDEs are better and easier). The returned data should include the image and identify the camera it came from.

To control the number of images all you have to do is design the metronome VI to only generate a finite number of events. I would make the metronome event driven and create two events: one for setting the number of acquisitions to perform (this event would also start the acquisitions), and one for setting the acquisition interval.

Your GUI (which is also event driven -- seeing a pattern here?) would simply fire the appropriate UDEs when a button is pressed.

Mike...

PS: for more information check out the link in my signature.