I'm required to send the AC signal from the arduino to labview wirelessly.. I'm only able to display readings wirelessly from the arduino to labview but not the signal.
If it doesn't work, I was thinking of plotting the value from the arduino to labview by reconstructing the graph.
I don't know what you're saying here. Do you need to send the AC waveform to LabView so that it can be plotted? Right now, you're just sending a single sample at a time. You won't be able to send samples fast enough that way to be able to plot the AC current waveform.
You will need to collect a bunch of samples rather quickly, and store them in an array. Then, when the data is requested by LabView, you will need to send the whole group of samples at once. I'm not familiar with LabView (last used it over 20 years ago, and didn't use it much even back then) so I'm not sure how you would format and process the data. I just know that you won't get there sending one sample at a time.
Right now, you are taking a sample once every 2 ms or so (it's actually a longer time between samples because there is overhead of looping around, and overhead of checking for an incoming command. So now, since the timing is becoming more important, we're back to Robin2's suggestion of getting rid of the delay and using millis() to determine your timing: look at the BlinkWithoutDelay example for ideas. That sketch turns the LED on and off, you will want to replace that whole section dealing with ledState and the digitalWrite() with a call to read and store another sample. The advantage to doing it that way is that the loop overhead and incoming data overhead will have less impact in the timing.
With a 2 ms sample time, you will only get about 8 samples in a 60 Hz period, and about about 10 samples in a 50 Hz period. That may be enough to be able to determine the frequency of the signal, and a very rough wave shape, but it will probably not give you enough points to be able to see a nice waveform. You may need to sample faster than that, so you may need to substitute micros() for millis() in the BlinkWithoutDelay example so that you can get better timing.
Rather than look for an incoming command on every loop (sample) I would probably collect and store a series of samples (enough for a few cycles of the waveform, say 50 or 100 milliseconds worth) and then check for a command to send them. I think checking for incoming data on every sample will take too long and it will mess up your sample timing. Only checking at the end of a group of samples would mean there could be 100 milliseconds or so delay before responding to a data request, but I doubt that LabView will notice that delay
Good luck, this is not a trivial project, but it can be done.