write multiple signals into excel continuously from VISA

[kiandr]

Dears:

I know that it is a common topic in the forum, how to write into excel. But, the reason that I am posting this is to find the proper approach for my problem.

I have an VI file which collects data from serial port. Writing one signal to excel has been successfully accomplished. But at the time, I want to add more signals into excel columns. Result is that my computer goes "blue". I mean, after 1 minutes Windows crashes and gives me a blue screen error.

I am sure that the problem is somewhere in the excel writing part. Cause without that loop, the VI goes on successfully. Could you please take a look at the sketch and tell me what do I do wrong here?

I will keep looking for excel examples, but most of them are collecting data from DAQ, is there any specific technique to write into spread sheet from VISA or the same thing applies in both methods.

Thank you.

KD.

[RavensFan]

What does the blue screen error say?

You're not actually writing signals into Excel.  You are writing your data to a text file which is in a "spreadsheet-like" format.  Comma separated values, and lines delimited by line feeds.

Your file writing loop is writing extremely fast.  You don't have any wait statements in that loop to throttle the execution speed.  Because you are passing data by way of local variables, you could be duplicated data into your file, or possibly missing data.  You should use a producer/consumer architecture using queues to pass the data from your VISA communication loops to your file writing loops.

You are only reading 9 bytes at a time (or 5).  You have your termination character enabled.  What happens if the device is sending more data?  Or if it is sending data and the termination character shows up in the middle?  What does the data look like?  You could be accumulating data in your serial port buffer and the PC is crashing when the serial port overflows if you aren't reading the data as fast as it is coming in, or reading it all when necessary.

Also, your code doesn't quite look the same as what Mark presented in your other thread.  Are you sure you are parsing your data properly?

[nyc_(is_out_of_here)]

basically rehash of another lengthy thread on same topic http://forums.ni.com/t5/LabVIEW/Visa-find-byte/m-p/2314610

[kiandr]

1- Do you guys believe that the issue roots in serial communication?

2- Does that mean that the writing structure is OK?

3- RavensFan, could you post me some sort of example about that structure the producer/consumer architecture?

4- Data from the Arduino serial communnication, does not contain termination character, it there are 9 bytes at row. 

The serial port at Nonin, that we discussed with mark,sends a 25 frame of 5-byte packet three times per second.

However, the the serial port at the second loop sends 9 bytes at a time, with no termination character. Actually that reads form a microcontroller, I can adjust that to send add termination character if it is nessasery. 

I wonder then, why the VI crashes as soon as the writing process begins?

cheers

KD. 

[RavensFan]

---

@kiandr wrote:

1- Do you guys believe that the issue roots in serial communication?

2- Does that mean that the writing structure is OK?

3- RavensFan, could you post me some sort of example about that structure the producer/consumer architecture?

4- Data from the Arduino serial communnication, does not contain termination character, it there are 9 bytes at row. 

The serial port at Nonin, that we discussed with mark,sends a 25 frame of 5-byte packet three times per second.

However, the the serial port at the second loop sends 9 bytes at a time, with no termination character. Actually that reads form a microcontroller, I can adjust that to send add termination character if it is nessasery. 

I wonder then, why the VI crashes as soon as the writing process begins?

cheers

KD. 

---

1.  Possibly.  I associate blue screens with low level driver issues.  I've seen it when resources are abused (DAQ tasks created repeatedly and never cleaned up, doesn't seem to be your case) or buffer overflows with serial ports (might apply in your case.)

2.  Nothing looked obviously wrong with the File Writing portion.  But the loop executing as fast as it can might be choking off processor resources that other execution threads might need.  (Search forums for "greedy loop".)

3.  Go to menu File,  New....,  producer/consumer design pattern (Data).  Or search the forums for "producer/consumer".

4.  If your communication does not contain a termination character, then why did you set termination character to True on your Serial port configuration.  If the raw data coming in contains the termination character as one of its bytes, then the serial read will end early leaving other bytes in the serial port.  Then reading the next 9 bytes will grab the remaining bytes from the previous packet and only some of the bytes from the next packet.  Beyond that, your code does not match Mark's.  (Why are your replacing only the first 5 bytes of your array in the innermost while loop?)

[kiandr]

Thank you for the reply. 

I gree, I will turn off that termination.The reason it is still on, is that because I started that VI days ago, based on some tutorials. Since I was working with micro controller and adjusting the characters from the source, never bothered to tune the VI for unnecessary configuration.

As of mark's code, The reason is that the sketch meets the desirable requirement rather writing feature, thus I focused on ouput feaures, as soon as I got the VI working properly on serial communication. Howver, I will go back now to that sketch and fix that first, hopefully that solve the crash problem. 

As for reading 5 bytes, if that is neccesary, I could do that as well. However, the reason is that, the byte#3 represts PPG which needs to be ploted as soon as the value becomes availabe. To my understanding, reading 75 bytes takes longer time rather 5 bytes. The application is about studying changes of blood volume in respond to physical activity, which requires the presentation of PPG visually during the experiment period. 

Thanks

KD