[FTC]: Possible issues with lost messages to DC Controller.

[PhilBot]

Hi

I think anyone who's done FTC for a year or so knows that the occasional message from the NXT to/from the DC Motor controllers gets corrupted.

This has caused all sorts of Autonomous problems in the past (some of which have been corrected with the current code).

However, I think I've discovered a new wrinkle.

The code that's generated by the LabVIEW For LEGO Mindstorms (LVLM) software for the new templates is clever in that it doesn't send mechanisim commands continously (as with prior code), instead it detects when buttons are pushed or released and generates code that is called when either of these events occur.

So if you are using two buttons to raise or lower a mechanism (like a scissor lift) the code sends a motor move command when you press the button, and a motor stop command when you release it (and nothing the rest of the time). This is very efficient as it cuts down on I2C communications with the Motor Controller.

However, there is a problem. If the comms glitches when you are sending a start or stop command, the action is lost, so the controller continues as if you didn't press or release the button. So in my case, if you are tapping the button to raise the lift in tiny increments (eg for testing), every now and then the stop command gets lost and the lift keeps moving. OWE!!!

This is especially bad if you don't notice at the end of a motion and the motor keeps on running against the stops. (Blue Smoke time).

So far it's only happened a few times, but it's enough for me to consider going back to the old style of issuing motor commands each time around the loop. That way a missed command gets resent 20ms later.

Anyone else seen this behavior on a mechanism (not drive train)?

Phil.

[JohnFogarty]

We've noticed the same thing in RobotC strangely enough while testing our elevator system.
I had to stop using certain methods I had constructed last season because of it.

also from what I'm understanding you are using a multi-case boolean switch?
and your button values change a pre-defined variable. allowing you to push 2 buttons to start the movement and push them again to stop it. If not.....then this may be a possible solution. I used muti-case boolean switches to allow multiple button press's to mean different things.

If this is a real problem... though I've only used LabVIEW on my FRC team.

There was a piece of code added to RobotC that allows the program to tell if the comm link is active. So I simply put all of my running code inside of a If statement which is running only when the comm is connected. otherwise it brings the robot to a halt. this really helps with the problems discovered last year with NXT brick lockups, from micro-electric power transfers.