Just want to throw this out before for people’s attention before it gets really bad if what I suspect is true… tagging @bar…
Firmware V1.27 incorporates changes to the kinematics routine to use chain elongation and sled weight and ignores chain sag compensation values. This requires recalibration… see this thread:
Worse, though, is that Ground Control v1.27 calibration routine still uses the old kinematics. Therefore, it is possible that someone may not even be able to calibrate the machine correctly because the results don’t resolve into a solution… see this thread:
I think v1.27 firmware should be pulled for the time being.
As of 15 minutes ago my system was running perfect under 1.27 firm and GC. But I had to re-enter some numbers after running the calibration and then it ran faster and smoother. My wife and I were able toi disassemlble cnc recalibrate and recarve the 10x6 in sign I posted earlier in 40 minutes with no errors.
I think you were able to succeed (get results) because you were already calibrated to start with. However, the machine is calibrated to one set of formulas and uses a different set of formulas in reality… That’s an issue that needs to be resolved.
I suspect (none of this do I know for certain) that @jess’s issue was that she was starting from scratch and the difference in cuts were too much for ground control to come up with a solution using formulas that the machine didn’t use to make the cuts. I might be wrong, but we’ll find out when she tries v1.26.
PR#479 Change operation associated with ChainTolerance was a small change, but touches Kinematics::triangularInverse() as well. @madgrizzle, would that need to be backed out as well - would it cause a need for re-calibration?
I don’t have a Maslow set up to do the needed testing .
So that’s a good question. Chain tolerance was introduced some time back because people’s chains weren’t exactly 6.35 mm per link… The kinematics in the firmware was updated to, in essence, change the effective circumference of the sprocket. However, the initial attempts to incorporate this into calibration, if I recall correctly, resulted in poorer performance than without. I have a really crappy memory in general, so I can’t recall all the details. Holey calibration was started to try to come up with a better way to do calibration to get good results with chain tolerance. I ultimately moved onto optical calibration but others continued the work.
My suspicion is that most people have chain tolerance set to 0, resulting in no effect. And for those that have set to something other than 0, I suspect the calibration process results in minimizing that effect (i.e., tries to cancel it out because its not incorporated into the calibration formulas)
So… was this fix in v1.26 or is it new in v1.27? I don’t see it referenced anywhere in the release logs. maybe I’m missing something.
PR#479 was about the only thing changed in v1.26. These changes have been merged since version 1.26 was released.
A summary of that list here:
Merged #480 1 Change originalChainLength to 1651 mm
Merged #481 Chain length calculation improvement: stretch compensation
Merged #486 Step further back to PlatformIO 3.5.3
Merged #489 Fix to EEPROM write issue
Merged #490 change firmware link
Merged #494 detach() should run once per state change
Merged #498 Move directWrite outside the loop
Merged #499 Avoid compiler warnings about aux3…aux9
Merged #501 Avoid PWM value 255 for TLE5206
Merged #507 rename RingBuffer to maslowRingBuffer
Merged #510 When (pinCheck >= 6) the board version matches the version strapping
Merged #512 Alarm if board version is unrecognized
Merged #513 recognize a soft reset command in the serial stream
Merged #514 Limit PWM frequency value
Merged #519 Adds directWrite(0) at end of B11
PR#480 looks like the only one that changes Kinematics.
.