SerialPort viOpen error

[tech2077]

I was trying to run the posted code in order to test out the serial port on our cRIO. The code faulted with a null pointer error due to the serial resource not being initialized and returning the error "VI_ERROR_RSRC_NFOUND in function viOpen"

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.SerialPort;
import edu.wpi.first.wpilibj.visa.VisaException;

public class RobotTemplate extends IterativeRobot {
    
    public SerialPort serial;
    
    public void robotInit() {
    }
    public void autonomousInit() {
    }
    public void autonomousPeriodic() {
    }
    
    public void teleopInit() {
        try {
            serial = new SerialPort(115200);
        } catch (VisaException ex) {
            System.out.println("Error to initialize serial port at 115200 baud " + ex.getMessage());
        }
    }
    
    public void teleopPeriodic() {
        try {
            serial.print("test");
            System.out.println(serial.read(1));
        } catch (VisaException ex) {
            System.out.println("Error");
        }
    }
}

[jross]

Did you reimage the cRIO with the v52 image? Are you using version 589 of the java plugins?

Which line is the exception reported?

[Kevin O'Connor]

This does occur with v52 and the error is from the viOpen in serialPort.java

I am looking into this now as it appears to be a regression from v47.

[slibert]

This does occur with v52 and the error is from the viOpen in serialPort.java

I am looking into this now as it appears to be a regression from v47.

I'm working with a few teams who are using the nav6 IMU, and they are running into this problem too.

It's sporadic.

SerialPort settings we use are 57600, 8, N, 1

The nav6 sends a stream of 30-40 bytes packets at about 20-50Hz rate, so a stream of bytes is arriving when the serial port is opened.

[cRIO] edu.wpi.first.wpilibj.visa.VisaException: VI_ERROR_RSRC_NFOUND in function viOpen
[cRIO] at edu.wpi.first.wpilibj.visa.Visa.assertCleanStatus( Visa.java:151)
[cRIO] at edu.wpi.first.wpilibj.visa.Visa.viOpen(Visa.java:6 3)

Here's a note on the error:

"...there doesn't seem to be any consistency with when the error occurs. Occasionally it would happen after a few times of sending new code to the robot and sometimes it would happen after I had just powered on the robot. I wasn't able to find anything that seemed to be a specific trigger. I was typically able to fix it by leaving the robot powered off for a period of time and then powering it back on."

[Side Note: If possible, if the Java SerialPort class is being modified, can the setReadBufferSize() method please be made public?]

[Kevin O'Connor]

I did not experience intermittent behavior in my testing but am not entirely surprised based on my belief about the failure mode. I added what I believe to be a fix to the visa.java file and the build has been promoted to Stable. With the change my setup went from consistently failing to consistently succeeding. The stable release including this fix can be installed by setting the Netbeans plugin update location to: http://first.wpi.edu/FRC/java/netbea...le/updates.xml and checking for updates. Stable updates will be promoted to Release updates periodically but are made available as interim updates for teams.

Please let me know if you still see the issue after updating to the Stable build (build 598 or higher).

[tech2077]

I still get the same error with the newest update.

[Kevin O'Connor]

Make sure Console Out is disabled using the hardware switches on the 8-slot or the virtual switches on the imaging tool for the 4-slot. EDIT: And also that you do not have Black Jag CAN plugin loaded.

Is there any further information that may help me reproduce the problem? I just downloaded the plugins from the WPI Stable link posted above and ran the code you provided at least a dozen times on a 4-slot with no error on open, including at least two tests where I blasted random characters at it from the terminal while the port was being opened. As a side note, I did notice that you are using the print method. This method is marked as deprecated and doesn't really work quite right from what I can tell. I would recommend using write(string.getBytes, string.getLength()) instead. When I was running your test code I got a whole bunch of other characters printed out to the terminal using the print method.

I will test again on an 8-slot tomorrow to see if I can reproduce the error there using the plugin instead of the local build I tested this morning.

[AllenGregoryIV]

I just verified that we are still getting the error running tech2077's code (He is a student on my team). We are running on a four slot cRIO that I imaged two days ago with no CAN plugin and the console out disabled. I updated my plugins tonight and they are build 598. We don't have anything plugged into the serial port. I created a new iterative robot template and pasted Tech2007's code directly. He has reproduced this error on two different cRIO's I've only personally run it on one of them tonight. We'll try on an 8 slot tomorrow. I'll also reimage the cRIO's again to make sure all the switches were off like they should have been.

[cRIO] Error to initialize serial port at 115200 baud VI_ERROR_RSRC_NFOUND in function viOpen
[cRIO] java.lang.NullPointerException
[cRIO] at edu.spectrum.serialport.SerialPortRobot.teleopPeri odic(SerialPortRobot.java:28)
[cRIO] at edu.wpi.first.wpilibj.IterativeRobot.startCompetit ion(IterativeRobot.java:165)
[cRIO] at edu.wpi.first.wpilibj.RobotBase.startApp(RobotBase .java:235)
[cRIO] in virtual method #10 of javax.microedition.midlet.MIDlet(bci=17)
[cRIO] at javax.microedition.midlet.MIDletTunnelImpl.callSta rtApp(64)
[cRIO] at com.sun.squawk.imp.MIDletMainWrapper.main(110)
[cRIO] in virtual method #95 of com.sun.squawk.Klass(bci=25)
[cRIO] at com.sun.squawk.Isolate.run(1506)
[cRIO] at java.lang.Thread.run(231)
[cRIO] in virtual method #47 of com.sun.squawk.VMThread(bci=42)
[cRIO] in static method #3 of com.sun.squawk.VM(bci=6)
[cRIO] WARNING: Robots don't quit!
[cRIO] ---> The startCompetition() method (or methods called by it) should have handled the exception above.
[cRIO] E-Stopped!
[cRIO] task 0xc8e6c8 (worker.0) deleted: errno=0 (0) status=0 (0)

Thanks for the help Kevin, we really want to get to the bottom of this.

[Kevin O'Connor]

I've still been unable to replicate this so far since the code change, but I did pass this on to some of the NI developers to see if they have any thoughts on what might be going on.

[jross]

I was able to duplicate the problem with the 589 plugins but not 598 on a 4-slot.