Moderator, ROBOTC Tech Support, V5 Beta Moderator

Last active [hidden]

  1. yesterday
    Wed Jan 23 05:13:36 2019

    @MTO967 So @jpearman does that mean it is not currently possible to send a parameter directly to a thread?


  2. Wed Jan 23 05:12:50 2019

    @technik3k That's unfortunate. Protection system needs to react faster than any damage can occur, otherwise it just offers false sense of security.

    I was not involved with the hardware design, but my understanding is that it's primarily designed to provide similar protection to the old PTC in the 393 motors.
    The firmware has knowledge of current and voltage, we limit current to a predetermined maximum which is lower than the theoretical stall current of the motor. A motor that is operating normally can be stalled for a couple of minutes before temperature rises and we start to reduce current. I've not heard of any issues when operated like this and my own testing hasn't shown any problems in doing this other than having to wait for quite some time before the motor cools and it can be run at full power again.

    If vex support can intercept these failed parts when they are returned, we can do more investigation (perhaps it's been done already, I haven't specifically asked hardware guys about that) and figure out what happened.

  3. Wed Jan 23 05:01:32 2019

    @R47 Threads are standard c++ I believe

    no, the threading is not standard C++

    we plan an update in the future that will allow passing a single (void *) argument as a parameter, the primary use is to allow a C++ class instance to be passed in and therefore allow access to C++ instance methods, but the date is still TBD and I suspect we will delay until after worlds.

  4. Wed Jan 23 04:57:41 2019
    jpearman posted in Creating Keywords.

    I've been waiting for someone to create a robotc wrapper. I actually wrote a robotc class several months ago, you could emulate almost exactly a robot program, for example,

    #include "v5.h"
    #include "robotc.h"
    using namespace robotc;
    task testTask() {
        int count = 0;
        while(1) {
          displayBigStringAt( 10, 90, "Task %d", count++ );
          wait1Msec( 500 );
          clearTimer( T1 );
    int main() {
        writeDebugStreamLine("Hello from v5");
        startTask( testTask );
        while(1) {
          motor[0] = vexRT[ Ch3 ];
          motor[1] = vexRT[ Ch2 ];
          wait1Msec( 20 );
          int t = time1[ T1 ];
          displayBigStringAt( 10, 50, "Time %6d %6d", nPgmTime(), t );      
          displayBigStringAt( 10, 10, "Sensor %6d", (int)sensorValue[0] );      
        return 0;

    would work.

    bad news is I have no plans on releasing it, we don't want to confuse things and prefer everyone to use the new V5 APIs.

    In terms of adding keywords, that's not possible. The tokenizer and VCS language extensions are an integral part of VCS, we generate all the necessary information from the C++ class headers as VCS is built.

  5. Wed Jan 23 02:02:18 2019

    @technik3k Do you know where exactly the temperature is being measured. Is it motor casing, external sensor, or an integrated H-Bridge sensor?

    The sensor is not ideally located, it's on the pcb, not on the motor casing.
    H-Bridge has its own internal over temperature detection IIRC.

    @technik3k Could it be that it is good at reading steady / slow temperature changes, but would not be able to detect fast increases due to shock loads, until it is too late?

    quite possibly.

    @technik3k Also, when firmware makes decision to shutdown, does it look at only temperature, or the current and voltage readings are taken into consideration as well?

    motor firmware current reduction is only based on temperature. We initially go to 1/2 current, then 1/4, then 1/8 and finally disable completely.

  6. 2 days ago
    Mon Jan 21 23:31:22 2019

    @Anomaly I wonder why the firmware doesn't keep them from moving once they get to level 3.

    level 4 is 70 degC, that's been determined to be safe, level 3 is 65 degC.
    It sounds like something is failing in the motor and causing both overheating and eventual motor failure.

  7. Mon Jan 21 22:36:53 2019

    post the code you are using.

  8. 3 days ago
    Mon Jan 21 01:54:51 2019

    @kevinrandell Do you think the other labs might also link to the incorrect files?

    probably, it's not that the file is wrong as such. The problem is that device names must start with capital and controller should be Controller1. So when VCS tries to generate the robot-config.h header it fails somehow. The logic of the code is correct, I just had to delete all devices, add them back in and then rename correctly in the code.

  9. Mon Jan 21 01:04:33 2019

    no idea where that code came from, it's completely broken must have been made with a beta VCS. Try this

  10. Mon Jan 21 00:55:25 2019
    jpearman posted in V5 Antenna disconnect.

    @PlacerRobotics @jpearman - have you seen any radio issues caused by brain hardware faults and/or sluggish behavior in V5 brains?

    not that I remember.

    @PlacerRobotics I noticed their brain was very sluggish when moving back/forth the screen.

    did this happen even after brain power cycle ? do you mean slow to start a program ? or just going into devices screen or something ?

View more