The focus is on the communication rather than how you generate the data.
1) Dream up an equation Y = f(x) such as Y = sin(x) and store that in 1000 locations of the uC (as a table = array). This is a do while loop or a for next loop.
2) Transfer that to the PC software (labview) using a serial port transfer. Presumably this means RS232 serial port. At the PC end this may be using a virtual serial port obtained from a USB to serial converter. This is another do while or for next loop.
The data is read from memory (the table) and transmitted. You will need to implement some sort of protocol and handshakes presumably, to make sure no data is lost. This is because data can be transmitted more quickly than the receiver can process the data. As your next step is to send by a wireless link, I would form the data into packets, use handshakes to make sure there is no buffer overflow, and determine errors by parity on a character basis, and check sum on a packet basis. There is no need for a CRC style checksum, just add the value of all characters and send the lowest 8 bits of the result as a checksum. As there is no multiple access, a very basic packet can be used. The length can be fixed or variable, but should be sent in the packet.
http://bioharness.com/zephyr-labs/development-tools/hxm-bt/communications-packet-structure-overview/
When an error is detected the protocol requests the packet be sent again.
The handshake can be implemented using "Xon/Xoff" protocol where the control S and control Q characters are used to stop and start data. This means all the protocol data in packets is sent as hex pairs to represent the binary value of each 8 bit character, as binary values cannot be sent. This is because some of them are used as control characters, like STX, ETX, CtrlS and Ctrl+X and Ctrl+Q carriage return and line feed. You will need a list of ascii characters, which use only 7 of the 8 bits.
http://en.wikipedia.org/wiki/File:ASCII_Code_Chart-Quick_ref_card.jpg
The data part of a packet can be in hex equivalents of binary or plain text like decimal numbers "-01.414, +13.938" You might decide to send 32 numbers per packet, whatever makes a neat appearing one line display on the screen makes sense. Format the packets so it always looks the same length etc.
As you have a labview "receiver of data" the protocol you use should be one that is readily implemented in labview.
http://www.ni.com/white-paper/4049/en/
All the labview program does is receive characters, implement the protocol, decode the data and store it in the array that duplicates the array in the microcontroller. See figure 4 in this link, that is where you start from. It already does part of what you want.
http://www.ni.com/white-paper/4058/en/
You will probably need a terminal emulator to run on the PC that just displays received characters. This helps with the development work. One example is a free download called PUTTY. The terminal emulator mentioned is hyper-terminal, but that is no longer available in windows. TTY means teletypewriter, the most basic emulation. You will perhaps be using 1200 baud, 8 bits, odd or even parity or maybe no parity, 2 stop bits.
When running with the radio links note that they are probably "simplex", that is either transmitting or receiving, not at the same time. There will be a Tx/rx mode switch possibly. Implement your software so this is possible, i.e. it is either transmitting or receiving.
The data rate (serial baud rate) will be limited to whatever the radio link can carry.