›

V2 behavior

RAyWBRAyWB
in Repetier-Firmware
Hi,
tried to setup the V2 for test  on a corexy on due/radds.(used dual x axis template from github sample systems)
did not really succeed as watchdog triggers (without visible reasons).

another thing is that io_input_inverted_pullup don´t work correct (missing ! in io_input.h line 95)

had to divide x and y steps by 2  compared to v1.0.3

but major problem is watchdog... any idea?

Comments

  • RAyWBRAyWB
    seems watchdog is triggered by eeprom handling .
  • RAyWBRAyWB
    edited August 2018
    do you have a corexy running on V2?
    printing infill on 45° ( 1 motor should stop, 1 moving) has clearly visible and hearable jitter on the motor which should not move. does also happen on a single 45° move  clearly visible.
    measured with oszilloscope on stepper driver of the motor which should not move shows on signal "dir"   squarewave,
    on signal "step" some pulses
    this results in moving some steps forwards and some steps back so at least position is  fix +-lets say 4 steps

    flashing back to 1.0.3 prints without jitter(same printer , same gcode file)
  • RepetierRepetier
    io_input_inverted_pullup is in deed wrong. Will add it for next update.

    I have no corexy system so no tests myself.

    My guess for the jitter are rounding errors. The positions are computed for short intervals by interpolating start/end. There will always be a tiny variance to the left or right of the ideal move and converting this floating point to steps might cause the jitter. What is your xy resolution? I think the higher the more probable it might get.

    What is if your move is slightly off the 45° e.g.
    G1 X0 Y0
    G1 X100 Y101
    does it still jitter or more keep the direction?

    Will also do some tests with cartesian. But there it would be 0 and 90° so one axis is 0 and multiplying with 0 gives no rounding errors for that axis, so that is why I do not see it I guess.
  • RAyWBRAyWB
    also with slightly off the 45° same result.
    as i have htd3 belt my steps /mm are only 101.5xxx

    but my question: why do we not have that jitter on v1.0.3  ?

    i just switched firmware , same machine,same resolution,same gcode.

    BTW watchdog seems solved for the moment, may be eeprom was corrupted
  • RepetierRepetier
    V2 uses a completely new motion engine that has nothing in common with V1. That is one of the 2 biggest changes (modular system is the second). So different behaviour will come from this. I have to think about the why. It is done in MotionLevel2 where you have
    FOR_ALL_AXES(i) {
    if (actM1->axisUsed & axisBits[i]) {
    pos[i] = actM1->start[i] + sFactor * actM1->unitDir[i];
    } else {
    pos[i] = actM1->start[i];
    }
    }

    that gives the next planned target position in global coordinates. Then

    fast8_t nextMotorIdx = 1 - lastMotorIdx;
    int32_t* np = lastMotorPos[nextMotorIdx];
    int32_t* lp = lastMotorPos[lastMotorIdx];
    PrinterType::transform(pos, np);

    Gets last integer position and updates next integer position. Looking into it I see in PrinterTypeCoreXYZ.cpp

    void PrinterType::transform(float pos[NUM_AXES], int32_t motor[NUM_AXES]) {
    float px = lroundf(pos[X_AXIS] * Motion1::resolution[X_AXIS]);
    float py = lroundf(pos[Y_AXIS] * Motion1::resolution[Y_AXIS]);
    float pz = lroundf(pos[Z_AXIS] * Motion1::resolution[Z_AXIS]);
    motor[X_AXIS] = COREXYZ_X_X * px + COREXYZ_X_Y * py + COREXYZ_X_Z * pz;
    motor[Y_AXIS] = COREXYZ_Y_X * px + COREXYZ_Y_Y * py + COREXYZ_Y_Z * pz;
    motor[Z_AXIS] = COREXYZ_Z_X * px + COREXYZ_Z_Y * py + COREXYZ_Z_Z * pz;
    for (fast8_t i = E_AXIS; i < NUM_AXES; i++) {
    motor[i] = lroundf(pos[i] * Motion1::resolution[i]);
    }
    }

    could be the problem. First rounding to steps and then interpolate might be the wrong order. Can you replace it with

    void PrinterType::transform(float pos[NUM_AXES], int32_t motor[NUM_AXES]) {
    motor[X_AXIS] = lroundl((COREXYZ_X_X * pos[X_AXIS] + COREXYZ_X_Y * pos[Y_AXIS] + COREXYZ_X_Z * pos[Z_AXIS]) * Motion1::resolution[X_AXIS]);
    motor[Y_AXIS] = lroundl((COREXYZ_Y_X * pos[X_AXIS] + COREXYZ_Y_Y * pos[Y_AXIS] + COREXYZ_Y_Z * pos[Z_AXIS]) * Motion1::resolution[Y_AXIS]);
    motor[Z_AXIS] = lroundl((COREXYZ_Z_X * pos[X_AXIS] + COREXYZ_Z_Y * pos[Y_AXIS] + COREXYZ_Z_Z * pos[Z_AXIS]) * Motion1::resolution[Z_AXIS]);
    for (fast8_t i = E_AXIS; i < NUM_AXES; i++) {
    motor[i] = lroundl(pos[i] * Motion1::resolution[i]);
    }
    }

    this postpones integer conversion to last time. I think this is the more correct approach.
  • RAyWBRAyWB
    ok, thanks I´ll try that
  • RAyWBRAyWB
    Great JOB !
    that solves the issue now i can see the smooth operation :-)

    just another question, in github you wrote :
    No more delays for slower drivers wasting CPU time

    i still have to set STEPPER_HIGH_DELAY  to 1 for my drv8825
    misunderstanding from my side?

    and last but not least:

    how can i get the boardfan?

  • RepetierRepetier
    That variable is not used at all. Just a relict of old code that I need to throw away. We now have a fixed stepper interrupt and at the beginning it disables steppers and later tests for enabling steppers. That way I do not need any delays any more. It's all controlled with these variables:

    #define STEPPER_FREQUENCY 250000 // Maximum stepper frequency.
    #define PREPARE_FREQUENCY 2000 // Update frequency for new blocks. Must be higher then PREPARE_FREQUENCY.
    #define BLOCK_FREQUENCY 1000 // Number of blocks with constant stepper rate per second.

    But it is better described here:
    https://docfirmwarev2.repetier.com/config/motors

    You are now free to have any number of fans. Just connect a PWM output of the fan with a control logic. Example

    IO_OUTPUT(IOCoolerFan1, HEATER_3_PIN)
    IO_PWM_SOFTWARE(CoolerFan, IOCoolerFan1, 0)
    COOLER_MANAGER_SENSOR(ExtruderCooler, TempBoard, CoolerFan, 30, 50, 40, 255)

    This creates a software PWM and enables it at 30° with 40of255 and increases it to 100% at 50°C. With the modular concept you can also use hardware PWM with one of the supported pins. Temperature can be any module reporting temperature. You can make one for board temperature just like for extruders.

    Will describe the new modules like COOLER_MANAGER_SENSOR soon in the doc.
  • RAyWBRAyWB
    OK, thanks .
    So my misunderstanding is propably based on the comments behind the numbers, especially PREPARE_FREQUENCY
    how can it be higher than itself ?
    is there a possibility to couple  a fan to f.e. enable of steppers? may be always on at 30% and flip to 100% when steppers enabled?
  • RepetierRepetier
    Block frequency is what you want so 1000 blocks per second with constant speeds so speed changes every ms. If you have a move < 1ms this can lead to buffers running empty for the level 3 move planner, so you need to be faster to catch up for line ends not requiring 1ms or being shorter. With double speed the buffers seem to never go empty.

    There is no cooler for any stepper on also it will be very easy to write one. Will write one tomorrow. Printer has a flag for all steppers disabled that I can use for this. Apart from this it is more a copy of an existing just with fixed pwm frequencies.
  • RAyWBRAyWB
    Thanks, will take some time for me to get familiar with the new structure , but i can already see the huge potential.
    Will continue testing , may be set up a machine for that.
    Already saw some mismatches on the corexy but may be it´s easier to collect my findings and send you an email in german language as it´s easier for me to explain .
    Think I´ll additional set up my cartesian for tests.
    Do you have an idea when laser tool follows?

  • RepetierRepetier
    Yes, personal mails might be easier. I really can need any help in testing it as it is all new stuff and you have different hardware then me so different test.

    I think I will not distinguish the modes any more. I think laser will just become another tool type that can be activated. I'm also thinking about adjusting PWM with speed now that I update speed in discreete intervals. We also have hardware PWM for 9 pins on due. I can write a sample implementation at the weekend for you to test. My laser is on 8 bit system that does not compile with V2 at the moment.
  • RAyWBRAyWB
    that would be great as i´ll switch over to due on my cartesian (where my laser is installed) this weekend.
    If i can run any test´s let me know.

Sign In or Register to comment.