That's a good idea actually; I'll go do that, as soon as I can find the bug reporting page;
Edit:
Ok so Check this out; I signed up for collabnet, then decided to go ahead and pull the entire wpilib source tree. I started poking around tracing the SerialPort calls through their JNI wrappers and into the underlying C++ VISA calls, and found this:
The error I posted above maps to the VISA error, VI_ERROR_TMO (in visa.h)
Code:
#define VI_ERROR_TMO (_VI_ERROR+0x3FFF0015L) /* BFFF0015, -1073807339 */
Doing a little poking around on the internet I found this (
https://github.com/hgrecco/pyvisa/issues/157) Unrelated to FRC
Quote:
|
Have you correctly set the read_termination character ? Visa looks for this character(s) at the end of the instrument answers. If it does not find it a timeout will occur as it will go on waiting for it.
|
So I went back and looked at the java class and it IS calling disableTermination() in the constructor. Tracing that down through the C++ it eventually calls viSetAttribute() with a bunch of params that look right (I'm not familiar with VISA yet)
I wonder if maybe the disableTermination method isn't working properly for some reason. I'm still going to write up a bug, but I think I'll also go create a branch of this source and start doing a little bit of creative debugging myself with a spare roboRio during the week. I'll update this post if I find anything (or the bug gets acknowledged and fixed)
WPILIB says that termination is only implemented for receive, but the github bug i linked mentioned that the WRITE might still be expecting a \n or \r. I'll investigate that too.