LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Errors from PC to myRIO RT with USB Xbox One Controller

Hello all,

 

I am currently created a myRIO PC, RT, and FPGA project where I use an external Xbox One controller to communicate to the PC vi, then have this written to the RT through STM TCP/IP. I would like the joystick position to be communicated from the PC to the RT, then have this RT value written to the FPGA to control onboard myRIO LED's.

 

However, my current iteration generates Error 74 on the RT after passing through the "Unflatten From String" vi.

2001J_0-1598980211915.png

 

On the PC side, I obtain Error 62:

Possible reason(s):

LabVIEW: Serial port overrun error.
=========================
LabVIEW: The system caused the network connection to be aborted.

 

This occurs at "Write Message TCP".

2001J_1-1598980501037.png

 

I have attached code for my project. The PC vi is called "PC.vi", the RT is called "RT ControllerMain.vi", and the FPGA Target (which never obtains new data since the RT Host doesn't) is called "FPGA_ControllerLED.vi".

 

Does anybody here know what may be the issue with my code?

 

- Best regards, Justin Burzachiello

0 Kudos
Message 1 of 8
(1,165 Views)

On opening your Project, there is no PC.vi, and no Global_PhysicalConstants.vi.

 

Missing the main VI, it seems a waste of time to look at the rest of the code.  Please create a complete Folder with all of the Files in the Project included and attach a compressed version of this "complete" Folder.

 

If you are having Error 62 on the PC, it sounds like a problem involving the XBox Controller.  Can you write a small VI that does nothing but get (and display) a graph of the signals from the Controller?  I'd imagine you could use the Joystick Vis that are included with LabVIEW.  [Hmm -- I've written such routines for a real Joystick, last looked at the code 4-5 years ago, but I've got an XBox Controller somewhere and could see if my old code works on it ...].

 

I use Network Streams for communication between the Host (PC) and RT Target (myRIO).  Works very well.  Wouldn't dream of doing this any other way.  Recommend you investigate this method.

 

Please attach a complete Project with no VIs (particularly PC.vi) missing.

 

Bob Schor

0 Kudos
Message 2 of 8
(1,125 Views)

If you are having Error 62 on the PC, it sounds like a problem involving the XBox Controller.  Can you write a small VI that does nothing but get (and display) a graph of the signals from the Controller?  I'd imagine you could use the Joystick Vis that are included with LabVIEW. 


NI has a free add-on listed for xbox one controllers, that i've used before, that you can use for this test if your not sure of your code (never had a problem with it) http://sine.ni.com/nips/cds/view/p/lang/en/nid/213222

 

0 Kudos
Message 3 of 8
(1,102 Views)

I should have said that yesterday, after I wrote my message, I used the Joystick VIs that come with LabVIEW to (a) identify my Controller, (b) get it to tell me how many Axes (5, I think it said), Buttons (10), and POV (1) it had, and then I wrote a little program that polled these resources 10 times a second, showing me that the Axes values ranged from -32768 to 32767, 10 Booleans (1 .. 10) lit up as I pushed the 10 buttons on the Controller, and the POV showed (hmm, I don't remember if it was numbers 0 .. 7 or somethng else).  In other words, using the built-in LabVIEW Joystick VIs, I could access the Controller.  [It was, in fact, not an "official Xbox One" controller, but a Logitech Controller for Xbox].

 

Bob Schor

0 Kudos
Message 4 of 8
(1,099 Views)

Hello Bob Schor,

 

Apologies for the mistake about the missing PC.vi and the GlobalPhysicsConstants. I had those files in a different folder for some reason when I was making the zipfile.

 

Now I have actually fixed the issue since posting. I was able to do this by rewriting the program while implementing your suggestion to use Network Streams. I found that I had assigned a TCP data type for an Enum as a U16 numeric, which created errors.

 

If you are curious, for the controller, I have been using a downloadable library from MakerHub (the group that made this Xbox One Controller library). This is the same one that pjroland1121 graciously mentioned. As for my initial code, the RT coordinate y-axis values are obtained correctly, and they are correctly converted into numbers 0,1,2,3, or 4 depending on their values. But I had an issue with data communication, as described in the paragraph above.

 

Now, I do have a followup question. You may recall from an earlier post by me that I have been learning TCP through the STM library. I did manage to learn that method of STM TCP communication to the extent that I can get it to work. However, I do not yet know the intricacies that differentiate it from other data communication methods.

 

May I ask why one would use Network Streams over STM TCP? I saw on documentation (link) that Network Streams do not require one to Flatten or Unflatten strings to transfer data, but they still work well across LabVIEW. Would one use this communication method over others because it is easier to implement? Are there other communication methods that you would recommend me studying? I'm still learning about it, but I am curious as to when would use each communication method.

 

 

- Best regards, 2001J

0 Kudos
Message 5 of 8
(1,092 Views)

Hello pjroland1121,

 

Thank you for the link to this library. It is actually the one that I have already been using, but it is still nice to receive a heads up about it. Also, I agree that its ability to poll the controller and check for connection is useful.

 

- Best regards, 2001J

0 Kudos
Message 6 of 8
(1,089 Views)

I use Network Streams because I'm "lazy" and don't want to "fuss with the details" of massaging my data so that it "fits" some TCP/IP or Messaging protocol -- I just want to "stream" data across the Network with a minimum of fuss.

 

I'm currently using 4 Network Streams for a LabVIEW Real-Time Project.  The Host and the RT Target are both running Message Handlers, with Messages defined (similar to the Queued Message Handler) as an Enum (which I call the "State", or sometimes the "Message") and a Variant that I call the "Data" (and is often not used).  The Host sends Messages to itself (like the QMH), and can also send (via Network Streams) Messages to the Target.  The Target, also, can send "self-Messages" and "Host Messages".  Through this system of "Self" and "Other" Messages, it is easy to keep the Host and Target synchronized with each other, and also for them to send Program Parameters (# A/D channels, sampling Rate, scale factors, etc.) in the Data part of the Message.  Since the Network Stream is one-way, it takes two Streams for bi-directional Messaging.

 

I use additional Streams for transferring Data collected by the RT Target to the Host.  A routine I wrote 6-7 years ago was able to stream 24 channels of Analog data sampled at 1 kHz from a PXI target to the PC Host, where it was streamed to disk, with every 50th point plotted on a graph (we were tracking eye and head movements in response to a sound-localization task, and the sound targets moved relatively slowly, so a 20 Hz display update was quite adequate).

 

When I started this earlier Project, the method for handling dealing with the data was, shall we say, "primative".  All of the data that were acquired by the RT Target were stored locally in its Memory (somewhat limiting how much data we could acquire).  At the end of the experiment, the User would wait a minute or so while all of the data were transferred via FTP from the Target to the Host, and written to disk.

 

"But how", you ask, "can you see what you are doing while you're acquiring the data?  What if the recording conditions are bad?"  Good question.  Would you believe that the "solution" was to put A/D converters inside the PC, and using a "T" BNC connection, send 16 Analog signals to both the PXI and the PC?  The PC, of course, did not have an accurate clock, but if you only wanted to "view" the data, you could sample at 20-50 Hz and make a nice plot.  I called this technique "WYSINWNG", What You See Is Not What You Get, and decided I needed to throw out the old code and (re)design the entire system ...

 

So using Network Streams, there is a single Data Stream, coming from the RT Target with its accurate clock and all the time and resources needed to acquire samples and control the stimuli, and a PC optimized for writing to disk, multi-tasking, User Interaction, etc, with Network Streams letting both Target and Host "handle" a single copy of the data.  Our students were much happier with this system!

 

Bob Schor

0 Kudos
Message 7 of 8
(1,082 Views)

Thank you for your explanation. At the moment, I am just trying to learn methods to transfer data, but not necessarily the intricate differences between protocols, so it is nice to know that Network Streams are relatively accurate but very simple to implement.

 

And for your work in the past, that old system transferring and handing the data does sound a bit awkward. May I ask if you are, or were, a professor somewhere? I'm curious because you mentioned your "students."

 

- Best regards, 2001J

0 Kudos
Message 8 of 8
(1,061 Views)