04-03-2014 11:16 AM
I'm working on an SD6
https://decibel.ni.com/content/docs/DOC-18528
I can get the sensors example working without a problem but the Teleop example keeps on error-ing out on me and I'm not sure why.
Error 116 occurred at 1SD6.1 Motor Drivers.lvlib:Set motor velocities.vi Robot Main.vi
Possible reason(s):
LabVIEW: Unflatten or byte stram read operation failed due to corrupt, unexpected, or truncated data.
I'm running the vanilla example with no changes.
Solved! Go to Solution.
04-04-2014 03:47 PM
Hi JasonTraud,
Do you have all the software requirements as listed in that example? Also did you download the drivers on that page?
Another suggestion would be to comment on that example, so that you might get the developer's input.
Here is Knowledgebase Article about the error.
04-17-2014 04:38 PM
I've found the solution. There were two issues.
1. There was something funny with the serial card. It seemed intermittant and the COM ports kept dropping out after use. The solution was to format and reinstall the software on the cRIO.
On a side note, the 116 error was intentially being thrown in one of the motor driver VIs as a flag that there was something wrong with the serial COM to the motor controllers.
2. Even with the serial card now working properly, I kept on getting an unknown error when running the Teleop example. The issue with Teleop is that the FPGA is being initialized in paralell with the VISA com. This was causing the example to fail. I moved the FPGA init in series with the VISA init and it solved that issue.
04-18-2014 06:14 PM
Jason, I am not exactly sure what you mean by the FPGA being in parallel with the VISA. Are you referring to in the actual code? In robot main, the commands to FPGA start is in parallel with initialize motor controller, is that what you are referring to? Sorry, I am pretty inexperienced with Labview and am not yet familiar with all the ins and outs of the system. Thanks for any support.
04-18-2014 06:24 PM
Yes, that would be correct. Follow the error out chain. In Robt Main of the Teleop example they are in paralell but in the sensors example they are in series. I'm still very new myself but it seems that initialization of the FPGA needs to take priority.
04-18-2014 06:38 PM
Thanks for the quick reply. So you only changed the error out wire?
04-18-2014 08:34 PM
So we varified by connecting directly to the Motor Controller board that it is operational. We were able to turn the motors using the Roborun+ application from RobotQ.
So we then proceeded to connect everything else back up the way it was back to the cRIO. When we opened up the NI MAX software we expaned Remote Systems and then Devices and Interfaces. Under Serial & Parallel we right clicked on "COM1 (ASRL1::INSTR)" and clicked "Open VISA Test Panel." Under here we noticed an error that has been attached to this forum post as capture.png.
Also, I think we hooked up the OpencRIO and Initilize Motor Velocities the way you said to "In Series" from your post. We have included a screenshot of that as well with this post named Capture1.png.
Again we appreciate any help very much!
-Chris & Paul
04-18-2014 08:42 PM
Probe your error lines. At what point does the error origininate.
What motor controller are you using? Are you using an SD6? Can you probe the error lines to see exactly where it originates? Does the sensor example work? Are you starting the VIs in the right order?
04-19-2014 05:23 PM - edited 04-19-2014 05:24 PM
Yes we are using the SD6 robot. The error originates in the set motor velocities vi. Robot main will run until we start host main, and then it stops and gives us that same error 116. Here is a picture of that vi, even before we run it is taking in a constant of 116. Is that supposed to be there? Thanks again for any help.
04-19-2014 06:28 PM
That VISA Write and Read looks completely wrong.
You use a VISA write to send a command. Then you immediately do a Bytes at Port which is probably going to be zero since you didn't give the device a chance to return a response. Then you do a VISA read of zero bytes which means you get an empty string. When you search the string, it finds nothing which will give a -1, that will give an error message of based on the logic going into the case structure.
Bytes at Port is the wrong thing to use about 99% of the time.