Topics created by leone

@dc42 here the files, yes the report is the same with M400 in between.
config.g
test_microstep.g

@dc42 about 200-250Hz is good for what I'm doing now. If higher is possible, it is even better for future uses.

@Argo

Beta2+1 https://www.dropbox.com/scl/fo/kaxbpbsyq2lxbae4tmzpk/AAPVUAh6CO_FMO-cG9ttX6U?rlkey=f0aesppc8d2p7bzwwi2s1jayo&dl=0.
(newest) Beta2+4 https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0.

You may want to try beta2+4's homing behaviour, For me something broke, On +1 it was fine.
Most of the step timing errors have been fixed in beta2

@leone thanks again. Looks like the maximum allowed acknowledge delay should be about 900 to allow for maximum length messages. However, I'm still a little surprised that you had the maximum delay exceeded 10 times in succession.

@Triet said in [FW 3.5.2] High jerk good for circular path not for corners:

I downloaded Duet2CombinedFirmware.bin from
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.6.0-beta.4
and installed it as usual, but I saw no files being extracted as it usually happens

Beta versions of the firmware are not packaged together as a single zip file as the main releases are.

@dc42 great news!
The modulation parameter goes from -27 to 39.

maxMod.PNG minMod.PNG

@dc42 understood, thanks for the detailed response. Moves this long are not really a use case when 3d printing i guess. Certainly not important for us right now as the behaviour was only noticed on accident.

Thanks again!
Cheers

@dc42 thanks!

@leone From the 3.5.1 source....

gb.MustSee('A'); const uint8_t mode = gb.GetUIValue(); ... ... ... (void)mode; // TODO implement mode

So the various A options are not currently implemented.

See: https://github.com/Duet3D/RepRapFirmware/blob/3.5-dev/src/Accelerometers/Accelerometers.cpp#L391