VEXnet 2.0 issues - unofficial reply

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

There is a problem, but it’s not ROBOTC as I see the same effect in ConVEX (although less so). Somewhere (probably the cortex master firmware) button pushes are “bouncing” so that code of the following form.

        // Push changes state
        if( vexRT Btn8U ] == 1 && pressed == false )
            {
            pressed = true;
            toggle = 1 - toggle;
            pressed_count++;
            }
        else
            {
            if( vexRT Btn8U ] == 0 )
                pressed = false;
            }

        SensorValue dgtl1 ] = toggle;

can detect a double push when using VEXnet 2.0 when it did (does) not with VEXnet 1.0. I see a change back to not pushed and then pushed again with 30mS as if you pushed, released, and then pushed the button very quickly. De-bouncing switches is a common practice in embedded code, however, I don’t think this is a mechanical issue and de-bouncing in user code on the cortex should not be necessary.

For the VEX engineers, I don’t see the bounce in the USB data, that doesn’t mean it’s not there but it feels like a bug between reading the joystick status from the VEXnet 2.0 key and the SPI message to the user processor.

1 Like
#2

I’m going to try and make an intelligent reply here so don’t mind me…

task usercontrol()
{
        int last_7U_Value = 0;

	while(true)
	{

                 int curr_7U_Value = vexRT[Btn7U];


		if (vexRT[Btn7U] && TrayState == 0 && curr_7U_Value != last_7U_Value)
		{
		TrayState = 1;
		}
		else if (vexRT[Btn7U] && TrayState == 1 && curr_7U_Value != last_7U_Value)
		{
		TrayState = 0;
		}

                last_7U_Value = curr_7U_Value;
	}
}

Above is the current “toggle” piston code I have been using so that the pistons do not fire multiple times as the driver control loop loops. From what I understand, this is similar to the code you posted for detecting a button hold as a single press of the button. Would there be a solution to fix this problem in my code? Our last resort would be to use separate buttons.

As well, this problem seems to have appeared after updating our VexNET 2.0 firmware to the latest version that supports wireless debugging and downloading. Is it possible to downgrade the firmware of the 2.0 keys back to the vanilla firmware that came as shipped? We had no problems at all then…

#3

The problem only occurs for me when to robot is being wirelessly debugged. If you still have problems even after disconnecting from the computer, then try redownloading.

#4

I saw the problem when not debugging, but much less frequently.

1 Like
#5

There are ways to solve this type of issue, here is one.

#pragma config(Sensor, dgtl1,  ,               sensorDigitalOut)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

typedef enum {
    kButtonReleased = 0,
    kButtonPressed = 1,
    kButtonWait
    } buttonState;
    
void
doPneumatics()
{
    static buttonState state = kButtonReleased;
    static int  pneumaticsState = 0;
    static long releaseTime = 0;
    
    switch( state )
        {
        case    kButtonReleased:
            if( vexRT Btn8U ] == 1 ) {
                pneumaticsState = 1 - pneumaticsState;
                state = kButtonPressed;
                }
            break;

        case    kButtonPressed:
            if( vexRT Btn8U ] == 0 ) {
                state = kButtonWait;
                releaseTime = nPgmTime;
                }
            break;
        
        case    kButtonWait:
            if( nPgmTime - releaseTime > 50 ) {
                state = kButtonReleased;
                }
            else
            if( vexRT Btn8U ] == 1 ) {
                state = kButtonPressed;
                }
            break;
        }            

    SensorValue dgtl1 ] = pneumaticsState;      
}

task main()
{
    while(1)
        {
        doPneumatics();

        wait1Msec(10);
        }
}

This function waits for 50mS after a button is released before checking for another button press, if it sees the press before that time then it assumes it was a button bounce.

1 Like
#6

Shouldn’t this part of the code reset the solenoid? Otherwise it stays on forever. Reset to 0 or decrement?


            if( nPgmTime - releaseTime > 50 ) {
                state = kButtonReleased;
                pneumaticsState = 0;
                }
#7

We are also having a problem with pneumatics mis-firing after this latest version firmware update to the vexnet 2.0 keys. We have three output circuits and all three are now mis-firing. Erratic action when buttons pressed. We tried a new joystick and a different cortex. We even made a new program with only pneumatics and same behavior. When we connected direct with the usb cable from joystick to cortex everything works fine. Any solutions? Pneumatics are a big part of our robot. It did not do this before we updated. Any way to go back one version with the firmware?

Currently using
Easy C version 4.2.1.5
Vexnet Firmware 4.1.0
Vexnet 2.0 Firmware 1.36

#8

The code I posted was a “push to activate” then “push again to deactivate”, in other words, each time the button was pushed the state of the output would change. Code for a push to activate and release to deactivate would be different.

1 Like
#9

A workaround in EasyC is also possible, but a bit more tricky depending upon exactly which functions are used. Perhaps VEX is working on fixing the underlying problem and everything will be good in a few days, I have no idea.

It’s possible to downgrade the master firmware but I see no way to downgrade the VEXnet key firmware.

1 Like
#10

Any updates on this? I tried Vexnet 2.0 keys with the older firmware and same results. That points back to new Easy C version. However When I try the old black keys everything works fine. We want to use the 2.0 keys for connection stability, but if this can’t get fixed we will unfortunately have to revert back to old school. Any input from VEX or Intelitek on this to at least acknowledge there is a problem?

#11

I can tell you it’s not related to ROBOTC, EasyC, PROS or ConVEX.

For an official response you would need to post in the official Q&A forum.

Use the VEXnet 1.0 keys for the time being and don’t stress about this issue too much.

1 Like
#12

Thanks for the suggestion to post on the official Q&A Forum, I will do that. Yes we can use the black keys and yes we will do that if we have no alternatives, but that was not the intent of this thread. Most that are using the 2.0 keys are doing so because they do not drop you as much on the field. Since matches are not re-ran if you drop, you are left at a dis-advantage. Now we have 120 bucks of keys that are worthless to us for now. Releasing patches the week of worlds and not having them work is discouraging at best. I am sure a fix will come out, but before worlds?

#13

Hello All,
Yes, we’re aware of this bug people are seeing. This issue is related to the VEX Microcontroller and VEXnet Joystick Firmware – it is not caused by any of our technology partners (it’s not related to easyC or ROBOTC).

We have a version which we believe fixes the problem, it is going through final regression testing (to make sure we didn’t inadvertently break something else) and will hopefully be released today or tomorrow.

Sorry for any inconvenience this has caused. Expect a new version soon.
As always, if you have any concerns please contact our support department directly.
903.453.0802 or support@vex.com

#14

Hello all,

VEXnet Firmware Upgrade Utility v4.1.2 updates Cortex / Joystick Master Code to fix the digital output jitter. It is available at http://www.vexrobotics.com/wiki/Software_Downloads.

#15