Bottom-Feeding Chain Accuracy

@blurfl, could you try this branch? https://github.com/reecej/Firmware/tree/Revert-Chain-Angle

This reverts the chain angle calculations for the top-feeding configuration only, which was the only aspect of the top-feeding kinematics that was changed, outside of variable names. Since the bottom-feeding configuration didn’t exist at that point, there wasn’t anything to revert to. Plus, the bottom-feeding configuration could serve as a control to compare with the top-feeding.

Let me know what you think!

1 Like

@blurfl Did you revert the direction of the green lines?

Is exactly what I cut and could mirror.

1 Like

I was using the right and left arrows to move side to side. The arrows send G00 Xnn.n or G00 X-nn.n and use 1000mm for the speed. Making macros to send G01 ±Xnn.n Fss let me play around with speed.

1 Like

I’ve run your branch using the top-feed configuration and plotted it directly against the current master that it derives from. The lines are so close as to be almost indistinguishable, the variance from ‘true’ the same as in my earlier diagrams. I think you can eliminate the chain anvle calculation change as a factor. :+1:

3 Likes

Thanks for the testing!

So, what’s next? I’ve been browsing through the changes to try to determine what may be the issue.

I am under the impression that v1.04 has not been tested specifically. I believe we know that v1.03 is good, and v1.06 is bad. Would it be possible to try the v1.04 release and see what happens? Then based on that, if you’re willing, I can try reverting individual PRs to help identify what’s going on.

1 Like

I’m not sure… Back in the other thread, I had only tested the v1.03 version of motor.cpp against the file because I was bottom-rigged. Today, since I’m presently top-rigged, I ran the full Firmware-1.03 with the test file, plotting on top of the lines I ran yesterday (v1.06 and your ‘revert-chain-angle’). Today’s plot was as exactly the same as the results yesterday. Today’s line was hard to see, orange right on top of blue on top of red! Still the same slight distortions, but no change between v1.03 and v1.06.
I’m looking at stepping back to v1.02, but that would require a full recalibration because v1.02 didn’t have chain-slack compensation. Before I do that, are there any other tests you would like to see with the present setup?

Very strange. It looks like @clintloggins had success moving back to v1.03. I wouldn’t think it would make a difference, but is your GC v1.06 or v1.03?

1 Like

I used GC v1.03 with firmware v1.03, GC v1.06 with firmware v1.06… think GC v1.06 with firmware v1.03 is worth a try?

It’s worth a try. This is really strange though. Do you think we have had this issue since v1.03 or earlier?

The deformation I’m seeing could be a chain-slack-calculation thing. V1.02 didn’t have that. I’ll have to recalibrate when crossing between v1.03 and v1.02 in either direction, so we’d be comparing calibration routines as much as anything, and we’ve assumed that v1.03 was an improvement.
What best to try, in what order? Lube the chain? Add/remove weight?
I wonder whether the chain-slack-calibration wants a third pair of cuts, in the upper region…

It’s definitely worth testing I feel. It’s strange how some people see issues with v1.03, and some don’t. Do you think a wipe of the EEPROM would help when going between firmware versions? And/or a fresh .ini file?

When going back to v1.02, you could try the test pattern without running the calibration routine too.

Based on the patterns you’ve been seeing, it strikes me that the right motor has the proper chain length, whereas the left motor doesn’t.

I would consider this, if possible:

  1. Try going back to v1.02, without running the calibration routine, and trying again
  2. Then try wiping the EEPROM and renaming the groundcontrol.ini file, then using a fresh calibration routine, then running the test pattern again

If that still doesn’t work, then we’ll have to dig deeper.

I’ll do those. Should I use GCv1.02 when running firmware-v1.02?

I would say yes, to avoid possible version compatibility issues. Plus the GC v1.03 calibration routine would not work with Firmware v1.02 either.

1 Like

On running Gc-v1.02/Firmware-v1.02 I got the (expected) message:

error: EEPROM read fail. Using default settings.

The v1.02-pre-re-calibration cuts at X-15.0Y-18.0 and X-15.0Y-10.0 were as closely aligned to the previous runs as all the previous runs were with each other.

The v1.02-pre-re-calibration cuts at X18.0Y-18.0 and X18.0Y-10.0 were very different from the previous cuts. Where the previous cuts bowed ~2mm bellying toward the edge of the sheet, these bowed a similar amount in the oppposite direction, bellying toward the center. Also, the cut starting point did not line up with the previous cuts even though the ‘Home’ position did align.

This prompted me to measure the distortion of the patterns in a different way. Measuring from ‘Home’, the first cut should start at X26.83. The cuts in the middle of the sheet with ‘Home’ at X-15.0 yesterday and today are all correct. The cuts at X18.0 yesterday and the v1.03 ones today all start too far from ‘Home’ at X27.21. The v1.02-pre-re-calibration cut at X18.0Y-10.0 starts at X26.5, and the one at X18.0Y-18.0 starts at X26.34.
I’ve run out of time for tonight, I’ll wipe then EEPROM and re-calibrate under v1.02 tomorrow and continue.

1 Like

This is great testing!! Thank you for the detailed information!

That’s very interesting about the bowed cuts. It looks like with the patterns cut with the home at X18.0, we may be seeing the effect of chain sag? Does the cut start at the bottom or top of the workspace? Especially if it is the bottom, then it sounds like we are seeing chain sag where the X18.0Y-18.0 experiences the most chain sag, and then X18.0Y-10.0 experiences a bit less, making it closer to the accurate position.

To confirm, it sounds like the X-15.0 homed cuts showed the same distortion above Y0.0?

Yes, that’s right.

The cut starts at the ‘southeast’ corner, Ron’s up to the northwest then back down.

Perfect, that’s what I thought.

So we are seeing the effects of chain sag, but it seems like we’re still seeing that distortion too. Looking forward to seeing your clean configuration results. Thank you for all your help!

Something to keep an eye on here could be the settings pushing issue we were seeing on Friday.

Great work tracking this one so far!

This was a reminder of the many improvements to GC and calibration since v1.02! Ouch!

After the v1.02 cal:

  • the X-15.0 Y-18.0 cut upward leans left by 2mm, mostly above Y0. The downward cut has a 1mm belly over all, and the top of the figure was 7mm short of the same part on the earlier cuts.
  • the X-15.0 Y-10.0 cut was 13mm short at the top, the upward cut leans 6mm left above Y0, and the downward cut leans 6mm left over all.
  • the X18.0 Y-10.0 cut was 7mm short at the top. It starts at X26.69 (the file calls for 26.83), the upward cut bellies right 2.5mm (most markedly below Y0). The downward cut bellies rightward 2mm over the length.
  • The X18.0 Y-18.0 cut is 5mm short at the top. It starts at X26.56, the upward cut bellies rightward 3mm (most markedly below Y0), the downward portion bellies 2mm rightward.
1 Like

Great testing, thank you @blurfl!

Based on my understanding of your results, it sounds like the pattern at X-15.0 Y-18.0 was similar between v1.02 and v1.03, and close to similar at X-15.0 Y-10.0?

The rightward belly of the X18.0 cuts sounds like the expected chain sag. It is interesting though that all of the cuts sound like they exhibit similar distortion about Y0.0, especially being too short.

Is it possible we’re having trouble parsing the Gcode? I would think if this issue went back to v1.02 it would have been noticed.

1 Like