V2 behavior

RAyWB

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?

RAyWB

seems watchdog is triggered by eeprom handling .

RAyWB

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)

Repetier

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.

RAyWB

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

Repetier

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.

RAyWB

ok, thanks I´ll try that

RAyWB

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?

Repetier

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.

RAyWB

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?

Repetier

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.

RAyWB

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?

Repetier

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.

RAyWB

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.