Are you limited to just a few V5 Controller buttons commands?

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

Another Newbie question. Is there a limit to the number of controller buttons that can be programmed? Is there a limit to the computing power of the “Brain” to process “When” commands? Or, is there a trick to allow the brain to see more “When” commands by adding a sleep command for say 0.1 seconds?

Our first several ”When” some controller button “pressed” commands work great. Then, as we added some more button commands, these new ones do not work. We deleted a “Forever” loop out of our “When – Start” command in hopes that that would free up what we perceive as some cpu power. That seemed to help a little bit, but not enough.

Any help on this would be greatly appreciated.

Thanks in advance,
David

#2

You should post your code so people can see if that’s the problem.

#3

It would be helpful to post the code that is troublesome. Usually a button stops working properly because of a coding error, though it is possible to starve tasks.

#4

There is not a good way to paste the code as text from Modkit. Attached is a Word document that has some screen shots that shows the programming.

The 4 lower button commands on the right side work if they are the first command that you hit. After the first activation, you are lucky if you can get any of the 4 to work again.

Thanks!!
Driver Control Dec 30.docx (1.49 MB)

#5

Post the .vex file, we will look into it after the new year. There should not be any limits.

1 Like
#6

The .vex file is attached.
Driver Control Dec 30.vex (18 KB)

#7

Hey DavidC!
jpearman has replied to a conversation which you followed: Are you limited to just a few V5 Controller buttons commands?

Jpearman,

No, I think we can program and use all of the controller buttons. We have not seen any faulty buttons, but we have not programmed buttons R2 or L2.

I went back and relooked at the controller issue within the “Driver Control Dec 30.vex” program to see if I could make a repeatable error.

For starters, I charged up both the controller and the main Brain battery.

I was able to make a repeatable error. When I first start the program, I can use the 4 arrow buttons, Axis 1, 2 & 4, R1 and L1. They all work great and there are no issues. The error starts after the first uses of Axis 2, and that is when all 4 arrow buttons stop working. Logically, that doesn’t make sense to me.

We also had another programming mystery with our “Mecanum Drive 16Nov18.vex” program (see attached). In this program, we had a issue with the LeftRear motor spinning very slowly, or maybe not at all. I now think these two issues are related. Originally when we were working on the drive train issue, we thought we had a bad LeftRear motor. Twice, we replace the motor with a new motor out of the plastic wrapping. We replaced the wiring a couple of times. We changed motor ports on the brain at least 3 time. We then replaced all of the hardware holding the motor, wheel and axle. Then we added a little lithium grease to the black plastic axle holder. Nothing improve the performance of the LeftRear motor. The robot just moved around like it had a broken motor. Even after that, I remember it was very strange that everything worked well when the boys were calibrating the robot with very simple drive commands like all 4 motors rotate forward for 2000 degrees of motor rotation (28.1 degrees of motor rotation equals 1 inch of robot travel, and 7.35 degrees of motor rotations equals 1 degree of robot rotation). That seemed to work just fine. We figured the LeftRear motor worked for short programs, but not our longer Mecanum Drive program. We then stripped out the double if-then statements and all of a sudden, the LeftRear motor started working perfectly.

Next, we started to add buttons to the Driver Control program, and we started to have problems getting the Controller buttons to work. We thought the CPU was not processing the information fast enough, Or, it could be a limit on how long a program could be before it became too long, and the Brain could not keep up. Our next step was to simplified the START Control by removing a Forever loop that ran our Mecanum wheel script. The Drive Control Dec 30.vex is the result of all of these changes.

Thanks,
DavidC
Team #43899A
Mecanum Drive 16Nov18.vex (7 KB)

#8

Problems in the Dec 30 program are primarily related to controlling the Tower motors from different control loops. The Axis2 control will have set velocity to 0 (or close to 0) and that event will be triggered often. The buttons that then try and use startRotateTo on the same motors will then either use that very low velocity or be overridden when the next Axis2 changed event fires.
An additional problem is the use of controller.Screen.print in both events. This is a blocking call and will be slowing down both event handlers. Modkit, unlike VEX C++ or C++ Pro, is really a single threaded program, if controller1.Screen.print blocks it will have an impact on other events firing.

1 Like
#9

Jpearman,

Nice catch on the set velocity command!! I added a set velocity to 30% for both tower motors, and to all 4 arrow button commands. Now, everything is working as intended. Yeah!!

A blocking call, is that something that slow the responsiveness between the Controller and the Brain, or does it block all commands for the instance it is running? Example, if another operation is ongoing, like the robot is driving forward, and the boys decide to raise the tower in the middle of the movement with Axis-2 (lots of Controller print command), would the blocking just delay a stop driving command from the Controller, or could it even block the stop command entirely with the robot continuing to move forward?

Thanks again on the velocity command!
DavidC

#10

Generally speaking, a blocking call will block execution of subsequent program statements until it has finished. We can only send a new line of text to the controller every 50mS due to the relatively low bandwidth channel we have between brain and controller. If a call is made to controller.screen.print before 50mS has elapsed from the previous call, we call task::sleep on that thread until the 50mS requirement has been met. When using VEX C++ (or Pro) this works well as we recommend that all controller printing is done from the same task (task and thread being the same thing in VCS C++). The task will sleep but other tasks will continue to run. Modkit is a little different, it really runs as a single task in VCS despite implementing its own scheduler within that single task. If task::sleep has been called because of the call to controller.screen.print, the entire Modkit program will be sleeping. New events will still be queued but there may be a delay before they are acted upon. The changed event for a controller axis will fire often, so if controller.screen.print is called from that event handler it may slow the whole program. This is something I need to look into and see if we can improve for Modkit, however, as that will require a change to the sdk it may not get released for some time as we are dependent on the VCS team releasing a new version to be able to update the sdk.
One workaround may be to put Controller.Screen.print( Tower.rotation, degrees ) in its own STARTED event with a forever loop and 100mS delay inside. Then remove the other controller.Screen.print statements from the button events. Now output will happen from a single location and the 50mS internal task delay should never kick in.

2 Likes
Wiki
#11

Jpearman,

That was a great explanation of what a blocking call is, and how to work with it. Prior to your explanation, we would probably have assumed that it was a quark of the V5 system, and learned to live with it.

The boys are coming over tomorrow and I will let them decide what they want to do it. I am hoping they go with your separate STARTED event & sleep command.

Thanks again!!
David

#12

Jpearman,

The boys did go with your suggestion, except the text to the Controller appeared and disappear so fast that it was very faint. The boys increased the Sleep time to 0.5 sec.

Thanks again,
David

#13