Jerk settings

RAyWB

Hi , found that there are changes from 0.92.9  to 1.03 in jerk Settings.

think that´s why i get the message  "XY jerk was too low, setting to".

first Point:

is there a reason why

 minimumSpeed = accel * sqrt(2.0f / (axisStepsPerMM[X_AXIS]*accel));

changed to

 float minimumSpeed = 1.41 * accel * sqrt(2.0f / (axisStepsPerMM[X_AXIS] * accel));

second Point:

i also do not understand why this is added :

  if(maxJerk < 2 * minimumSpeed) {// Enforce minimum start speed if target is faster and jerk too low
        maxJerk = 2 * minimumSpeed;
        Com::printFLN(PSTR("XY jerk was too low, setting to "), maxJerk);
    }

  as i´m fighting agaist ringing on my corexy i´m pretty lost on the attempt to reduce jerk while keeping high Speeds and accelerations .

Hope there is some time to explain a Little what´s Happening here.

Thanks

Repetier

Start speed is 50% of minimum speed. So that just enforces the mathematically required minimum speed for jerk.
Change for minimum speed, no idea now. Think that it was a correction for the error at first step. That step has biggest error for low speeds.

All that stuff is really a pain and completely removed in V2. I'm currently working on V2 again. Delta kinematics is now working locally and I will add dual x axis these days. Then all drive systems I plan to support for the start are implemented and I can focus on autoleveling and jam detect to have the important features all working. CoreXY should already work but if it is for your laser system it is not ready.

RAyWB

OK, thanks

I´ll just check out what happens in my System when changing that part back to the 0.92 stuff.

but may be  I just touch some physical Limits on my Printer ;-)

(kinematics can go up to 900 mm/s @ acceleration 12000 )

just checking whats "makeable" but think the high weight  of  idlers and bearings  causes that issue

as i´m using 9mm HTD3 belts.

(the GT2 stuff quit the Job after 1200m of Filament , thats the reason for Change to HTD3)

BTW,

is V2 already usable on corexy Printer and can i control it via repetier Server?

so I can give it a try to compare the movement

Repetier

That is pretty fast. I wonder that in these case the low jerk setting limits make a difference. Motors loose torque at high speeds are much strong at low speeds.

RAyWB

did some tests, low jerk Settings did not solve my Problem, Problem might be caused by defective linear sliders,

as some balls also quit their Job... (cheap chinese stuff) waiting for new precision rails/sliders now.

I´ll Keep you updated.

Is there something like a Setup guide for the V2 Firmware? (I´m using DUE/RADDS )

Repetier

It is work in progress, but I started a documentation that also should help to understand:

https://docfirmwarev2.repetier.com/

Next days there will be a bigger update with delta/dual x axis and many small fixes and additions.

RAyWB

Are you also planning to Support more Hardware ? STM Boards f.e. or Teensy ?

Thanks for the link, think thats enough for me at the moment

Repetier

At the moment I have no plans for this. I think it will take some time to make it production ready. But from the design it can support quite easily other Arduino supported hardware. It is mainly a new fastio and HAL for the target system. The remaining code should be compatible. But I#d wait for new hardware until HAL design is finished. I still plan to switch SPI handling to SPI library, maybe using a HAL proxy to make it easy to replace it.

RAyWB

Maybe switching to Wire library would also be great , would be more comfortable for users working with custom Event system

Repetier

Yes, maybe that would also be a help also I2C was so far not a problem. But SPI with different speeds/modes constantly make problems if you have more then one device.

RAyWB

OK, but some kind of error handling would be nice on I2C as Errors issue a Watchdog reset.

I have a working one for DUE, will send you a proposal if you are interested

Repetier

Not sure if wire would also never time out. For writing/reading eeprom a reset is best solution anyway I think. For temperatures etc it would be difficult to say. When it stops working errors will happen imagine temperature not updating any more. So maybe best solution on such failures would be to issue a fatal error to console and show it on display and disable everything.

What do you have working for due that you can send me? 

RAyWB

i added a kind of error handling on due´s i2c routines so it continues regular code if i2c is not responding.

similar to the handling in u8glib

Repetier

Yes, please send me what you changed so I can think about it. But the main problem would remain that something is not correct after this step and would need proper error handling instead of ignoring the error and not knowing the problem we get then.

RAyWB

From my experience I2C is quite sensitive on spikes coming from crosstalk or emc for example.

So just ignoring the error is mostly enough as usually in the next loop everything is ok again ;-)

Of coarse some explicit handling would be better but for debugging a simple message is enough.

will send the modifications on monday by email

Repetier

Ok, thank you.