Getting my photon count to display in realtime?

[RavensFan]

How are you running this VI?

It looks like it is intended to run through once and end.  I hope you are not using the Run Continuous button.!!

You could simplify the code tremendously by using the Format into String function with multiple inputs instead of using all those number to string functions and repeated use of the concatenate string function.  Each use of Format into String woud likely eliminate at least a dozen other function nodes.  Also use Unbundle by Name for better readability.

Message Edited by Ravens Fan on 09-29-2008 08:08 PM

[smercurio_fc]

Well, since you have none of the error clusters wired, it's impossible to tell if the problem is just communication with your instrument or whether it's something with the code. I suspect it's the former.

Also,

• You really need to learn to make subVIs.  
• Learn to make clean wiring. Your VI is a wiring mess. Prodigious use of the wire cleanup tool is recommended. 
• You have unnecessary code duplication. For example, the "A Periods X" and the "B Periods X" arrays come from the same array replacement. There is no point in replacing the array element twice. Replace once, and branch a wire. 
• Your method of replacing the 1D array makes no sense, and it has nothing to do with LabVIEW. You have an initial array that you've created that of a certain size. Yet inside your loop you are using Build Array to create a larger array, and instead of replacing a single element with a new element you're replacing it with a larger array by feeding out the output of the Build Array. This makes no sense. There is no point in replacing anything related to an A/B operation or log (A/B). These two operations should be done in-place based on the new array which is generated from your new data.

[Khume]

I am running it only once, the aim is the read x number of photon counts and then end. I had this part working perfectly, but really wanted the data to appear on screanas the data cytakes around 30 min to collect so I wanted to get an idea of how it was looking as it was collected. Now when I run the program once it starts collecting the data and displaying it and then it is as if the buffers get full and can't be cleared in time or something as the display gets slow and then just stops and the program/PC seems to freeze. I don't get any LabView error messages. Thanks for your suggestions.

[smercurio_fc]

Well, since you don't have any of the error clusters wired, you're not going to get error messages.

As for your "buffering" problem:  as I indicated in my previous response, the way you're doing the array replacement simply makes no sense. Instead of replacing elements you're replacing array elements and increasing the size of the array with each iteration. This was not the intention of what I had initially described. There is no reason for you to have a Build Array function inside the loop. 

[Khume]

Ok, this is the first VI I have ever built and I am the only one at work who has ever used labview (I used it at my old work, but we had a whizz who actually built all of the VI's,I just ran it), so I don't really have a clue about error clusters or probing or anything else for that matter and the books are not all that helpful. I have put the huild array function outside of the loop, tunneling out with shift registers, is that right?

Now the program runs, and the graphs move along with each photon count, but I only get NaN as the data. I can't see why this is as the NaN is not exiting the loop anywhere, and the rest of the code is as it was before.

I have also encountered a "Labview out of memory" message which I'm not all too sure about. I have tried running my original simple non-realtime working VI and now that too seems to freeze the PC.

Has anyone ever encountered this?

Thanks

[smercurio_fc]

There's no reason for you to have Build Array anywhere, based on my understanding of what you're trying to do. Upload your latest code and I'll take a look at it.

[Khume]

Arrgh, now the program seems to run without problem, in that the graph acts like it is building up however many points I put in there, without getting hung up or having any memory/timing issues. My problem is that I am still just getting tables full of NaN, not the data collected by my photon counter. I'm thinking I must just have something wired incorrectly?

[smercurio_fc]

All right. Attached is a refactored version of your VI. I made the following changes:

• Used VISA used instead of old GPIB functions. 
• Created a simple Wait subVI so it could be wired in-line with the code.
• Used Unbundle By Name rather than Unbundle. This creates self-documenting code.
• Used Format Into String to greatly reduce all the string formatting. Note that %.; is used to specify the decimal character to use. This replaces the string replacement that you were doing.
• Cleaned up your for-loop. Specifically:
  
  • Added additional shift register for "B" data.
  • Got rid of duplicate Replace Array functions. Remember: replace once, branch many times!
  • Got rid of incorrect Replace Array functions used for A/B and log(A/B). You already have the A and B arrays in the loop, so simply operate on them directly in each loop iteration.
• Wired error cluster all the way through.

Take a look at the code and compare to yours. I think you will find this version easier to follow. Note: I don't have LabVIEW 7, but I have 7.1 so I backsaved. Hopefully you will be able to open it.

[Khume]

Hi, wow thanks for all that. I follow your code perfectly, and it does look much nicer and is easier to follow. There are still a couple of problems though which I don't quite understand. Now if I rin your code, it does not seem to look for the trigger at all and just whizzes through the number of periods, taking no notice of the instrument (I have selected it in the code VISA selection on the front panel) and again returning NaN as the values. It's strange as starting labview does initialize the instrument in the right way but then seem to take no notice of collecting the data it reads, instead just bringing up the save file prompt almost instantaneously after pressing the run button.

The error message which I get saythere is an error with the "visa wait on event in wait for RQS.VI..." -"You must be enabled for events of a specified type in order to receive them"

Error code 1073807313

Hex code BFFF0027

[smercurio_fc]

Because of data dependency (or lack thereof in this case), the File Dialog function can execute right away since all of its inputs are satisfied as soon as you run the VI. That's how LabVIEW works. If you do not want this then you need to establish data depency. Previously you were using sequence frames. I used error in/error out wires. Since the File Dialog function has no error cluster input then you need to use an alternate method, such as the method I used with the Tick Count function. In that case the sequence frame that encloses the Tick Count function is dependent on the value of the error cluster, which is not set until the VI that it comes from has finished executing. Thus, you could do the same thing with the File Dialog function to have it so the prompt doesn't come up until the end.

As for the RQS: Sorry, I forgot about that. Yes, you have to enable the service request event. This is quite simple. If you open the Example Finder (Help->Find Examples) and search for "visa" and then open the "SRQ Event Handling" example you will see how this is done. I don't know your instrument so I was only going by the code, and it seemed that you were waiting for RQS after sending the "fa" command. Also, your code showed that once you got the RQS you immediately went into the for-loop starting with a GPIB Read. I don't know where the delays were supposed to be since in your code you did not have any data dependency so there was no way to tell when the delays should occur. At least with the "Wait" VI you can explicitly control when the delay should occur. 

Attached is an updated version. Note: I'm not forcing VISA down your throat. If you want to use the older GPIB function, go to it. It's quite easy to change the code.