This is a follow-up thread to a separate discuss (Velocity slow down and arced cut) where @blurfl noticed some distortion in cut patterns when using the new bottom-feeding chain configuration with triangular kinematics. We’re creating a separate thread to not confuse troubleshooting efforts from the other thread.
I suspect this is related to the new chain angle calculations used for the bottom-feeding situation, so it would be interesting to see if the problem only occurs when the chain angles are near horizontal, so to speak!
That would be very helpful! Although, it may not give enough data as I don’t think there are many squares to give good data from. But it would be a start!
The 27 square test pattern that @MeticulousMaynard has been using might be a good one to consider, although it would take substantially longer.
Here’s the file I’ve been using, it’s just the outline taken from the tripp2 file @clintloggins was using. The angled arm is ~66 degrees from horizontal bottom arm. I moved it to X-15.0 Y-15.0 INCHES as a starting point, which puts the top ~6" from the top of the workarea, the bottom ~11" up from the bottom.
That is a tedious test. I’ve never timed it, but I think it takes somewhere between 30-45 min. Do you need that much data? I the benchmark test you guys have been using definitely is faster.
I’ll generalize that top-feed and bottom feed performed essentially identically.
Here are screenshots,
taken in the horizontal center of the sheet, showing the bow to the left above Y0.0 whether moving up or down. Below Y0.0 both made straight lines in both directions.
and at the right edge of the sheet. Both had a distinct 2mm bow over the whole line when moving upward, and a line joining the endpoints leaned one degree to the left. Both created very straight lines when moving sownward, tough that line also leaned left one degree.
Another intrersting thing showed up as I tried to plot a horizontal check-line at Y19.0 INCHES using the left- and right-arrows. It ran starting from the left, sagging to the right until the last moment, then climbing to stop at Y19.0 When I ran it leftward, it sagged toward the left and climbing again at the last moment. The trace shows four transits. There must be a pooka in the upper middle of my workarea. Seriously, the arrows use the G0 gcode which though it uses the same routine as G1, it ignores the sys.feedrate limit and runs at 1000 instead. Perhaps this needs review?
motoroffsety = 463mm, motorspacingx = 2978.4, sled weight 24.5 pounds
I am wondering if the PID loop changes that were made a few versions ago are now
not sensitive to correct for the small errors when the motor should be moving a
small amount in a long horizontal cut
The horizontal cuts that are part of the pattern are all proper, as are the horizontal check lines I plotted at X0.0Y0.0 and X0.0Y12.0 and X24.0Y19.0… The checkmark at X0Y19.0 , ‘the lines that are hooking’, was the only horizontal anomaly.
PR#393 software does not report overspeed warning while running trapp2 outline file in any of the four locations.
The PR#393 software does in fact report overspeed warning while making the line at X0.0Y19.0. Changing the feedrate for the G0 gcode from 1000 to 900 in Gcode.cpp resolves the overspeed issue at X0.0Y19.0
Note that one instance of the overspeed warning still occasionally occurs elsewhere on the board when the sled first starts up on a horizontal traverse.
I ran the full calibration just before running these cuts.
The solution to this is that we need to include acceleration planning so that
the software doesn’t think that it’s possible to go from dead stop to full seed
instantly.
This is great testing, thank you @blurfl! I have a few questions.
First, This seems different from what we have seen before. It looked like previously you were getting accurate profiles with the top-feeder configuration, and distorted profiles with the bottom-feeder. Did something change, or am I missing something?
From these tests, it looks like the top and bottom feeding configurations performed nearly identically. The test you performed at Y=19 was very interesting, and similar to what we have seen with some other’s tests. Out of curiosity, did you try a similar horizontal test at Y=0 to confirm if distortion was present there or not?
Your sled weight seems very reasonable. Clearly there’s something going wrong here.
I must have created confusion in the other thread, those runs in my post were made in the bottom-feed configuration, but with different versions of motor.cpp (which made no difference).
I did see 5mm of left-leaning distortion toward the top of those runs, while the more recent runs in this thread had 2mm. In between that post and the one in this thread, I re-rigged from bottom- to top-feed and ran the calibration cutting step. After running the top-feed series I re-rigged to bottom-feed but only did the chain calibration before running the series again.
I fully agree, I don’t see even half a mm difference between top- and bottom-feed in a pattern at the same location. Bottom-feed works every bit as well as top-feed.
If we’re talking about the distorted horizontal lines at X0.0Y19.0, then yes, I also ran those at X0.0Y0.0 and X0.0Y12.0 and X24.0Y19.0 without distortion at any of those places. Reducing the hard-coded feed rate of the G0 code from 1000mm to 900mm removed the distortion at X0.0Y19.0
Great, thank you for the clarifications! I must have just got confused before, my apologies about that. This is obviously very localized and repeatable. I wouldn’t think it is a motor stall, as your sled isn’t that heavy. I did rearrange the kinematics formulas since v1.03 when the bottom-feeding capability was added, but everything appeared to be a mathematical equivalent. If you felt it was worth testing, I could make a modified master version of the code with the old kinematics to see if it did affect anything.
Otherwise, I’m at a bit of a loss. Is it possible PID tuning could be causing this?
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.
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.
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.
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.
