I've used that X-CTU software before with a radio modem set I purchased years ago. It was part of the initial tryout for one of my first LabVIEW projects. My office was upstairs and through a windows from our R&D lab. I wanted to talk to a motor controller serially, but it was too far to run RS-232, and really no convenient way to run a wire. So used the radio modem as my link. It was actually set for RS-485 on the motor end and RS-232 on my PC end. It worked well. I could issue a command on my PC, pop my head up and see if the motor was turning when I looked through the window.
So now you really don't have a LabVIEW/Zigbee problem any more. It sounds like that is solved. Now your issue is creating your own communication protocol to transmit waveform data.
How many samples of data are in each of the 3 waveforms? How often do you need to transmit?
I would look at the TCP/IP examples in LabVIEW for how to transmit the data. Not because you are going to be using TCP/IP, but because it has some principles on how to transmit binary data reliably.
I would send a few preample bytes with each package of data to tell how many bytes to expect to receive in a package. Two bytes should be enough. I really don't think you want to send more than 4096 bytes at a time (all dependent on how big your serial buffers might be). Maybe one byte to tell what waveform you are sending. Maybe one more byte to tell which part of the waveform you are sending (1 for the first part, 2 for the next part, 3 ....) in the event a waveform is so long that you needs to be spread acrosss multiple packages. Then you can send the waveform data in a binary format. It might be 2 bytes or 4 bytes for each piece of data depending on the datatype. You may want to include a byte to tell whether or how many more packets of waveform data follow. In the end, you may want to use one or two checksum bytes calculated from all the previous data to determine if the data was received intact.
When you want to receive the data. Use a VISA read to read 2 bytes. These two will tell you how many more bytes to read in the next VISA read command. Then read that much more. The next byte tells the waveform, the next would be the sequential number to know that it is the next one to append to the previous packet of the same waveform. Then the raw binary data that you can typecast back to numeric data. Then the checksum bytes you can use to verify the data came through correctly.
The only other thing left to do is have a means of the PC to tell the microcontroller when to send the next packet of data, or when to send the next waveform. You may want to create some command bytes for this for the different possible commands.
One other thing you may want to do for future exandability is to add an address byte to the commands and the responses so that if you expand beyond a pair of zigbees, each device will know whether the command is intended for it or some other device. Add it to your protocol now if you think you may ever need it later.
Actually, a good reference might be for you to look at the modbus protocol http://www.modbus.org/tech.php. Pretty much all of the features you will need will already be incorporated there. In addition, LabVIEW already has a modbus library you can download and use. It is geared around a register/address scheme for most of the "public" command codes. But they also have "private" command codes that you can use for whatever purpose you may need. The modifications to the modbus library would be minimal for your application. And the benefit is that if you ever need to communicate with other devices that are using a modbus protocol, you can piggyback the communications on the same backbone.
