11-26-2023 01:30 PM
I want to receive data from another device to MyRio wirelessly using Xbee
So I want deep description of how I can connect Xbee to MyRio.
I am new to this. Your help will be appreciated.
11-26-2023 01:44 PM - edited 11-26-2023 01:46 PM
11-26-2023 02:44 PM
I just posted a link to another Forum post here where I say "You (probably) cannot do that". I suspect the explanation (not meant to be authoritative, but rather based on my knowledge and personal experience with myRIO) is also true in your case.
Here is a little more explanation, since you are "new to this", which I assume means you are, among other things, new to LabVIEW. Your LabVIEW experience is probably based on (what I'll call) "regular" LabVIEW running on a PC, where you develop programs/code using a Front Panel that serves as both a User Interface (with buttons, dials, sliders, text boxes, charts and graphs, and more) and a Block Diagram, where the "code" really goes, with Loops, Cases, arithmetic, array handling, file i/o, logical decisions, and sub-routinesVIs.
Because "regular" LabVIEW runs on Windows, it has access to a fair amount of memory for data (GBytes), can handle multiple "threads" at a time, has good I/O capabilities (including File I/O and TCP/IP, and can accept peripherals that "plug in" via USB to handle data acquisition and control (DAQmx and other drivers). But there are times when being able to do "many things all at once" gets in the way of doing things a precisely-timed intervals. For this latter need, you need a "Real-Time Operating System" that does fewer things, but is much more precise in its timing.
LabVIEW has such a Real-Time Module, and the myRIO uses that as its Operating System. In a LabVIEW RT Project, there are (at least) two Processing Units -- the Host, which is a Windows PC running LabVIEW, and a TCP/IP-connected Target, which can be a myRIO, running the LabVIEW Real-Time OS.
What does the Real-Time OS "give up"? The User Interface. Every VI that runs on the Target still has a Front Panel and a Block Diagram, but while the program is running (on the Target), there is no way for the User to directly manipulate the Controls or to see the Indicators -- they are reduced to the "inputs" and "outputs" of a subroutine.
So how do you structure a LabVIEW RT program that uses the myRIO? You open a LabVIEW RT Project, which has a section for the Host (called "My Computer") and a section for the RT-Target (the myRIO). When developing the code, you don't need the myRIO, but when you want to run the code you wrote for the myRIO, you need to connect it to your PC via TCP/IP (either wireless or via an A/B USB cable) and "deploy" it to the myRIO. [I was going to write something about the experience of running the myRIO code "in development mode" to test it, but it's been long enough ago (almost a year) that I don't quite trust my memory ...]. When you build a Real-Time Executable (.rtexe) and deploy it to a LabVIEW Real-Time Target, you usually set it up so that when the Target starts, it automatically starts running (only) the Executable that you downloaded, so you don't need to push the "Run" button (which doesn't, in fact, exist), except in the LabVIEW Project "test environment" when you are developing.
Bob Schor
11-27-2023 01:38 AM - edited 11-27-2023 01:38 AM
I would not go as far as Bob, saying it can’t be done but it is likely more trouble than you can handle. I did not know about XBee, nor that it is something different than ZigBee. But you will need a transceiver from Digi, the owners of the XBee brand and technology, and connect that to the myRIO. Common interfaces they support are UART and SPI. So far it sounds easy, but now you needs Linux compatible device driver to integrate this into the myRIO in a way that is easily usable in LabVIEW. i’m sure it’s doable but this is not going to be trivial and you have most likely to compile your own driver from sources, which might or might not be easily available. Ideally the driver would integrate the device into the TCP/IP stack but I’m not sure that is avsilable. In the worst case you have to program the device from within LabVIEW through AT commands (UART) or through SPI (which both would be very tedious).