How do I acquire data form 12 serial ports simultaneously?

[Skoorb]

I have 12 anemometers connected via RS232 that I need to poll and acquire/log data from simultaneously.

I'm having a hard time with the program structure in that if I put all 12 of the subvis in one while loop, a delay on one sensor causes a delay for the others as well.

I need to acquire the data, time stamp it, then write it all to a file for 10-60 minutes. Each channel updates at about 30 hz and the data is ASCII.

Any suggestions on program structure would be MOST appreciated!

Chuck

[unclebump]

What protocol does the device use?? Is there an opc server program that will talk to them? Then you could use the DSC module to read the data from the opc server.

[Skoorb]

I'm not sure what you mean by protocol and I'm not familiar with an OPC server for them. Currently, I send a poll command "MA!" then read 36 bytes from teh serial port, parse out the white space and append a time to the sample. I haven't figured out how to do all this efficiently or log the data to file while displaying it.

The anemometer's are RM Young 81000's http://www.youngusa.com/Rmyprod1.htm

[Wally48]

Check this link out the have some samples and a product that will do up to 64: http://www.viewpointusa.com/prod_multicom.asp

wally

[Skoorb]

I just found that by putting each sub vi in its own while loop I'm back to acquiring data at a fast pace.

Now I need to figure out how to collect the data from all the while loops and perform the file I/O.

I suppose I could do the file I/O after the while loops have been stopped but I'm concerned that the ever increasing amount of data in the shift registers would slow the program execution over time.

[unclebump]

Protocol is the command structure/syntax for talking to the instrument. It will specify commands and data format. Maybe the device came with a serial communications manual?? An opc server handles the communcation commands for you. It continually requests or writes data to a device and them makes the data available to an opc client program(DSC module). The opc server makes it so you don't have to do the communication stuff in labview code.

It sounds like a multiple producer/consumer pattern might work. Are you writing all data to a single file?? Writing all the data even if it hasn't changed?? Can you set the instrument so that it is in continuous broadcast mode?? That way you don't have to request data, just wait until bytes at port=36 or wait for a termination character.

[unclebump]

Try this example.

http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=B45EACE3EF5B56A4E034080020E74861

[Skoorb]

Ah, sorry I understand. I think something in my head was short circuiting. I have the comm protocol and I've written all the code for polling, retrieving, and parsing the data. I'm just having a hard time figuring out how to make 12 instances of the code work in the same VI and then collect all the data into one file.

The multiple producer consumer sounds promising. I'm going to go look for examples...

[Skoorb]

I tried setting the instrument to broadcast but had a hard time manipulating the data for display if I missed a frame marker (carriage return) So now I'm polling the device instead.

Yes, trying to write all data to a single file, even if it hasn't changed.

[Skoorb]

Quick update, I built a test vi using 5 instruments and 5 queues. I have the 5 queues feeding a sixth while loop where I'm de-queueing,  concatenating, and displaying the data. Seems to be working very well. I'm going to continue testing and add some file I/O but this looks promising!

Thank you for suggesting the producer consumer method!

Message Edited by Skoorb on 09-06-2006 02:37 PM