Strategies for continuous measurement: (a) or (b)

[win2suse]

Hallo all,
I program a pic chip as an A/D converter and communicate with LabVIEW thru RS232. The signal of interest is fast and continuously changing. Everyting goes smoothly expect that the sampling rate is not satisfactory. The algorithm of the present code in the chip is:

In one iteration LabVIEW sends a commence command to the chip, after confirmation of the command, A/D conversion starts and the final results are sent back to LabVIEW. This process is repeated until the stop button in LabVIEW is pressed.

I'd like to re-burn that chip with a new algorithm:

LabVIEW sends only once a commence command to the chip, after confirmation of the command, the chip goes to iteration of A/D conversion and sending data to pc.

But there are still some uncertainties about this new strategy:
1. Would it be faster than the former one?
2. Do I need a terminating character added to each A/D conversion result to inform LabVIEW?
3. Could I use a while loop in which the A/D conversion results are read thru VISA Read, then feed to Build Array and finally saved to a file? Are there any example for such cases?

Thanks a bunch in advance,

win2

[PhillipBrooks]

1. Would it be faster than the former one?
I believe this would be "faster". Faster means that your effective sampling rate will not be limited by the PICs processing of commands for each data point.

2. Do I need a terminating character added to each A/D conversion result to inform LabVIEW?

You can configure your VISA session to use your choice of termination character, or you could use a fixed message size and just read that size from VISA.

3. Could I use a while loop in which the A/D conversion results are read thru VISA Read, then feed to Build Array and finally saved to a file? Are there any example for such cases?

The is a fine case for the Producer/Consumer design pattern. You create two while loops and a queue. You place your VISA reads in the producer loop, then enqueue the received data. You use dequeue and a file write function with a wait next multiple in the consumer loop. There are lots of examples of producer consumer loops in the forums and developer zone.

[win2suse]

Thanks for your prompt reply.

How to define the wait until next multiple? The attachment is a rough outline of my new labview, could you give me any advice on it?

thanks again

[PhillipBrooks]

I've made some changes, see the attached.

The main thing was that you had the consumer loop inputs passing THROUGH your producer loop. In this case, the consumer loop won't run until the producer loop exits. I placed your consumer loop in parallel with the producer loop, and also tied some of the error in and error outs together; if you can't create a file or the VISA reference is invalid, the queue won't be created and the loops will error through.

It's runnable, but might not be complete for your needs. It should get you going in the end...

Message Edited by Phillip Brooks on 05-03-2007 01:16 PM

[win2suse]

Thank you very much.
Could you save it as a LabVIEW 8 file?

win2

[PhillipBrooks]

Here ya' go

[win2suse]

Just now I run it, one error came to pass:
Error-1073807253 occurred at VISA Read in pc_1.vi
VISA:(Hex 0xBFFF006B) A framing error occurred during transfer.

The other issue is that the save file dialoge window pops up all the time.

When I changed the outcome of the while condition to continue, it seemed to work smoothly, but the file is empty. I ran it step wise, and found that the code first came to the read loop/consumer then went to write/producer loop, and finally stuck to write/producer loop.

On that note, I'd like to know to:
should I need a Wait until function to guide the code to first run producter then consumer?

should I set the queue size as the same as VISA Read buffer size?

Thanks a lot.

win2

Message Edited by win2suse on 05-03-2007 01:41 PM

[win2suse]

I still can not find the reason. The execution order is not correct, seems like a chaos.

BTW, the code in the chip works normally when it works with HyperTerminal.

[PhillipBrooks]

Your original logic in the producer loop (pc1.vi) used an OR of the front panel control and error cluster to determine when to exit. Change the example I gave you to "continue if true" for the producer (top loop) only. The consumer loop (bottom) in my example uses the error from Dequeue Element to know when to exit the loop. When the producer loop (top) exits, it deletes the queue, and the bottom loop error and exit.

Set the producer loop to "continue if true" and  the consumer loop to "stop if true".

I normally use a latched STOP button on my front panel and OR this with the Status T/F from the error cluster to determine when to exit, so my loops will exit if Stop or Error = TRUE. Just a style thing...

[win2suse]

You are right. Actually I have tried four kinds of combination:
stop stop -> error
continue continue -> without error with empty file
stop continue -> error
continue stop -> without error with empty file
but without success.

However just now when I restarted LabVIEW, and tried my hand with your suggestion, it works ?!

Anyways thank you for the valuable tips.

win2