Just in case you don’t github much. In the choose version drop down there is a tags tab. If you put 418 in the box, it should show you the 418 tags available.
That definitely pokes a big hole in the theory, unless there is some internal code that wants to check M105 (but obv isn’t sending itself gcode).
There is a 421 release as well but I did not tag it for some reason. I have it ready to flash on the other computer, it seems like halfway between 418 and 427 in terms of Marlin PR’s. My number are increasing but not necessarily one at a time. any edits I made I added a number no matter what board. So the 418, 421, 427 are the Last three Rambo firmware on that side.
This is definitely my priority at this time. The laser is dependent on this but I think that is also another issue on top…maybe not. Looking at some Marlin responses and other search results the top answers are “just go slower” or “32 bit is the best bet” but we know that is not the solution. Someone once told me why fix the hardware when you can fix it with software…Wise Sensei
1 Like
421 is fine. So it started between 421 (3/6/20) and 427 (7/18/20).
421 keeps rebooting on me though…and arcs still seem to work better on that version. So 421 might have a precursor to the issue
Okay can you think of any faster way to find the specific PR. My plan is just to roll 421 forward half way to 427 see if there is an issue. Keep rolling forward/backward half the PR’s until I find it?
Running a few more dates I will just edit this post with my findings
The issue starts between 5/3 and 5/6
Not a arduino ide vs platform io thing.
Okay, good news. It is one of these…and my name is not on that list. Even better, No one from here that I recognize!
In there we have three that are the most likely.
acosx, probably not but a planner edit.
explicit jerk, but I tried even with JunctionDeviation off and it seems to only have JD variables in it.
fix and combine JD, Big planner edit…but again should only be JD.
I will roll back and move ahead of acosx, before explicit.
edit.
Whaaaat? One of these little boogers.
edit.
not 17874
not 17865
not 17855 or 17840
DING DING DING winner 17846
Not sure if this is the actual problem, the current branch is much worse.
Tried to edit the current version, it was only half this PR for some reason, no change.
Tried to revert the current branch to not contain this change, no luck.
This is not the issue.
OMFG!!! I am not sure weather to be happy or pissed.
You know what the solution is…I tested turning everything off…I tested every dang revision for the last several months…
Turning Junction deviation back on…
Confirmed. I made the change to the current nightly and it works perfect.
4 Likes
Oh. Wow…
But…
Ok. So do we need to go back through the arc no arc tests to look for issues?
Also. Great work. Two gold stars:
2 Likes
Thanks for the great work! Does this fix imply there is a problem in Marlin’s jerk code that needs to be fixed?
No, I am fairly certain we did that with JD on. The only reason I turned it off with the 427 tag is Thinkyhead tweeted non-delta machines should be using classic jerk, and I saw it repeated several times while googling like a mad man yesterday.
I think so. The funny thing is Jerk did not work for years, the way it was supposed to, then just before they started or finished JD (maybe it was S curve), jerk finally got fixed. I am not sure if that fix means it works as intended but then caused this issue…and probably spurred on s curve and JD. Kinda of a complicated history with Jerk.
Now the kicker is JD doesn’t do anything. Several of us tested the crap out of it. I remember even Teaching Tech said he didn’t see a difference between any value in a video. So I suppose Thinkyhead was right JD is for delta’s (and maybe corexy). We do know now it frees up the planner/buffer/whatever. Luckily S-curve, fairly low accels, and adaptive step smoothing. Seem to do exactly what we are looking for anyway.
Do you have an issue open with Marlin? I am not sure it will be well received. But it would be responsible to kick it upstream.
1 Like
So following this thread and the laser thread - in the end is it the same issue?
Knowing this now is there a recommended firmware for the SKR PRO Dual for milling and plotting?
Or recommend configure change?
I have been think about how to approach that all morning. I am about to test the mini to see how it does (extruders=1) just to have more data. Really trying to narrow down the actual issue with an easy test. I am still not sure why the crown is not smooth (accel math bad, or too small of segments), and why straight laser paths are not either, no accels only power changes (which should not be accelerated). Dam that planner black box.
I believe so. I am about to go do some lasers test in a few minutes.
Let me do some testing and I will update the firmware accordingly. The currently build under the action tab should be good to go and what I am testing. I just updated it a few minutes ago.
2 Likes
@Flyfisher604, unless you’re interested in jumping in the trenches and testing things out, it is better to wait. But if you’d like to test and report back what you’ve found, then there is probably a zip that can help.
1 Like
Can you point me to where in GitHub to find the most recent relevant zip to test?
Github pre-configured firmware repository.
If you want bleeding edge, you can head to the “actions” tab and see all nightly marlin bugfix builds along with pull request builds testing new features or settings.
This should be set for the skrpro and rambo. Next up I plan on testing the mini.