Closed lromor closed 7 years ago
wow. Nice solution
Now the code should be simpler, shorter and faster. Thanks. (Next time, if you want, don't tell me the solution =P)
p.s. could you add to .gitignore simple-lexer_test?
Looks much nicer. There are still a couple of smallish comments left, but I think we're mostly ready to merge.
I now added all *_test in .gitignore
So I tried this patch on my machine, but it starts hanging when it does a G28
and reaches the endstop. I have not dug into details yet why this is happening.
(this happens on the z-axis with home-pos = max in case that is relevant). Can you have a look ?
BTW, I changed little things so that it passes my test with various compilers and valgrind. Attached a patch relative to your change (and I had to name it .txt instead of .patch as github then complains that it can't deal with that file type. D'oh).
it seems the subtract thing is making problems, from what I saw with the debugger there's a no wait loop, causing him do underflow.. or something like that, I will work on it this evening
So, for X and Y works right?
I don't know, the Z axis is the first that was homed when it got stuck :)
Ok, now should be fixed :)
Alright, seems to work. Pushed as submit https://github.com/hzeller/beagleg/commit/03950be17eec2490909d67048824e2cf50d7ed55
(with only minor changes to make it compile with various compilers and with uninitalized memory fixed as found by make valgrind-test
).
Thanks!
Thanks, that looks pretty good already. I have some concerns regarding unnecessary computation in the critical phases when we enqueue things in the history list, so made some suggestions there.
Essentially: if we always record in the history what at the end of that the positions should look like, we can make the whole
UpdateAbsolutePosition()
implementation a lot cheaper, and we only ever would need to call it when we callGetMotorLoops()
(which should be called GetMotorPosition()), not at enqueue time.