SD6 Teleop issues

[RavensFan]

4096 bytes is a lot.  It sounds like a full buffer.

But that error message is a framing error, which implies something wrong with your serial settings (baud rate, parity, number of data or stop bits.)

[eephysicspaul]

Thank you for the helpful post. Yes, the ASRL1 is the only com port that has been showing up. When I physically remove the 9870 from the system, nothing in NI Max changes (it still shows up the same way whether it is connected or not). I am not sure I have the correct type of cable to try and connect the NI 9870 directly to my computer, but I will look around and see. We did already interface with the motor controllers directly through Roboteq, so the motor controller board works. I just checked the power to the NI 9870 and I am getting 12V. I am convinced that the NI 9870 is not working for some reason.

[RavensFan]

If you got their software to work, then you know the cable is correct.

Now try getting LabVIEW code to work on the PC rather than the cRIO.  Once you do that, then you can worry about transferring code to the cRIO.

Start simple.  Send a command, wait, then read what comes back.  Get rid of all the other code where you are searching for something for something and or generating homemade errors such as #116.  Start with the basics and build up from there.

[eephysicspaul]

We got their software to work by directly connecting the motor controller to the computer we are using, and taking the NI 9870 out of the loop. I believe our 9870 is not operational. We are currently communicating with a representave from NI about how to verify whether or not the 9870 works.

Ravensfan, I am not sure if you are familar with the SD6 system, but here is a little more info about it that may help you or anyone else give more advice. There is a motor controller board on the robot that is connected to the NI 9870, that connects to the crio and then connects with our system. The crio also has two other modules connected to it, an NI 9201 and NI 9403. We are able to take readings and send outputs through both of them using labview and the same programs that are giving us these problems. Which, to me, is another indicator that specifically there is a problem with the NI 9870. We have checked to make sure we have the correct  software to interface with the 9870, and I have attached a picture of the software installed. As Jason said, we are never getting a reading of ASRL2-5, which means we arent interfacing with the NI 9870. We chouldnt see those outputs on NI Max according to a rep from NI, but I would think that we would see them in the VISA read VI. Would we not?

[nooks]

Oh by the way Jason an applications engineer from NI informed us that we will not see ASRL2 - ASRL5 in NI MAX if we are using the FPGA interface for the cRIO. Only when you choose to use the Scan Interface and all drivers and software are installed on the cRIO will you see ASRL2 - ASRL5 in NI MAX.

Just thought I would comment on that incase in the future some other group has troubles with this.

[eephysicspaul]

Okay, so after quite a few more hours troubleshooting, I was able to find the source of the problem. The IP address on the cRIO needed to be  reset by physically switching the IP Reset control. The process is outlined in the following webpage.

http://digital.ni.com/public.nsf/allkb/2367ADE10FDD98C4862576EB005C255D?OpenDocument

The simple VISA read program I used now shows the correct output listing of all the VISA ports I should be connected to, as the attached VI shows. Unfortunately, the Teleop Example is still not functioning correctly, as I am now getting errors with the UDP read and an error -314101, destroy stream endpoint. The error seems to go back and forth between and error 56 in UDP read, and the error 314101, but at least we have gotten past the VISA problems that have been troubling our group for so long. I will post an updated more detailed explaination of the problem in the morning. Thanks for all your help so far guys.

[eephysicspaul]

Okay, so we were finally able to get the robot to work. There seems to be a problem with the connection dropping out though. Jason, have you had any problems with this? We are thinking of switching from a UDP to a TCP connection in the program. I wasnt sure if I should start a new thread on it, but would it be as simple as switching the UDP read/write commands with their TCP counterparts in the program? Ravensfan, I will go back to modify that VI with a delay as well, as it may help the program run more efficiently. 

[JasonTraud]

I'm experiencing the same issue but so far I've been blaming the router. However, I do feel that the code should be more resillient to this kind of issue by catching the error and attempt to re-establish the stream.

[eephysicspaul]

Hey Jason, how is your code coming along? We switched ours to TCP, and were getting a much clearer, smoother video stream from our camera, but are now having troubles with the network stream between the Host Main and Robot Main VI, specifically we are getting Error -314220, the network stream endpoint has been destroyed. I guess I am not sure exactly how data flows through VIs and to the robot, but is there a reason you need both Host Main and Robot Main? Can you not move the contents of Robot Main into the Host Main and get rid of the network streams, and just use local variables? I am working on that now, but is there some reason it should or shouldnt work?

[JasonTraud]

From my understanding, the error can be attributed to getting a bad packet which happens on any network. From the looks of it the VI errors out when this occurs instead of taking the bad packet hit and looking for the next one.

For the two VIs, this is necessary if you want to be able to drive the robot from some type of user input (keyboard, joystick, etc). Otherwise the sensors example is what you can focus on instead.