I am happy to announce new RS485 LabVIEW VIs and an official NXTBeeNXT-G block. After a few months of work and lots of testing, I am happy to report I have closed out all remaining bugs. The files are available now on the Files page and a new RS485 block (rev B) will be posted later this week as well as new blocks that have support for Boolean and numeric input.
Special thanks to Dexter Industries for providing the NXTBees, everyone who beta tested the blocks, and Mr. John Hansen for all his help! Included in LabVIEW download are sample VIs and there sample NXT-G code posted in the download area.
Remember that slower data speeds (and the NXTBee all together) required John Hansen’s Enhanced Firmware. The Enhanced Firmware will still let you run NXT-G and LabVIEW code but adds support for these lower speeds. In addition, using RS485 allows you to connect to an NXT running any other firmware (Standard, RobotC, Lejos). Just make sure your speeds match! If you have any questions, email me or post below!
Milluzzi Labs 
Couldn’t the software emulate other speeds of communication? I.E., sending a bit twice to cut the data rate in half? There could be some sort of communications standard that conflicts with this, for all I know, but I thought it would be worth suggesting. I truly prefer the enhanced version anyway, so it won’t affect me if this doesn’t help.
While that idea seems good at first, there are a few details that get in the way. For example, when you send 1 byte, you are actually sending 9 bits, not 8. However you only have control over 8 bits. The last bit is a stop bit that is done by the firmware. So if you double the length, that bit does not get doubled. Also, the buffer is only 128 bytes long. If you divide that down, you begin to lose the ability to send useful data. If we were to divide the default baud rate by 8 (still way faster than 9600 baud), we could only send 2 bytes.