The "method" you have in your last post doesn't come anywhere near to what you say you want to do.
It creates a simulated sinewave and writes it to a text file. Waits 1/10th of a second, reads it back from that text file, does a lot of manipulation to that data to convert it to a dynamic waveform type. Then compares it to another simulated sinewave to say if they are equal or not.
"My doubt is if all the received signal are saved in the excel sheet first..". I don't know why you would doubt that this would happen. If you receive a signal and write it to the text file, then why don't you believe it would be written to a text file? By the way, the Read from Spreadsheet File and Write to Spreadsheet File functions have nothing to do with Excel. They read or write data to a text file that happens to be formatted in a way (delimiters between data in a row, end of line characters between rows) that is a text file version of a spreadsheet. Excel has the ability to import from or export to a text file, but that file is NOT an Excel file.
You have major portions of your code missing and questions to be answered.
Where are you actually outputing a signal to the printed circuit board?
Where are you actually receiving a signal from the printed circuit board?
Are you receiving one signal or 40 signals?
What type of DAQ board are you using to do this?
Okay, let's say once you have the first portion of your code set up to do that, you can write the data to a text file.
Now in another part of your code, you basically repeat the procedure but instead of writing to a text file, you read the data from your "good board" text file and compare the two.
How do you compare the signals and determine whether the newly read signal is good or bad? Right now, you are doing a comparison for equality. Do you think the "good" signal and the newly test signal will ever be equal? Even if you just repeat the test on the good board, do you think those signals will be equal? NO. It is impossible for the signals to ever be equal, even the slightest variation in the signal is going to make them unequal. You are never going to measure identical real world signals identically. You need to come up with some comparison algorithm with criteria that determines whether another good signal actually matches your saved good signal, and a bad signal does not match the good signal taking into account the variations you inevitably get when measuring real world signals.
Those are big questions you need to answer. Assuming you work all that out, on paper in a design specification document, only then can you start worrying about the LabVIEW program and its architecture. Ultimately, a state machine architecture will be your likely choice as you have multiple states to work with. Initialize, test board, save data to file, read data from file, compare data, possibly more states such as wait, close program, multiple states within the test board process as it is probably a multiple step process.
