Z Axis Not Fully Retracting Before Moving

Actually, the serial stream never stops. Movement stops, though, so proportional control variables that adapt to the present movement might change, maybe?

Back in the dark ages when C++ was the new kid on the block the common opinion was it should be avoided for real-time code due to all the constructing/destructing going on. At the time the 2560 would have been a high powered big memory system.

FWIW Linus Torvalds has (like most topics) a very strong negative opinion on the subject.

I wonder if having G codes for displaying the heap would put them where they wouldnā€™t show this problem, since presumably all pending commands would have finished before the B12/B13 were processed and the fragmenting space released? Any chance using an ICSP debugger would help sort it out? Last time I used an ICE was in the Z80 days, not up on the current stuff.

@mooselake Good thinking but there is very little constructing\deconstructing going on in this code. Almost all objects are created at startup and used throughout. See my earlier related post in this topic (though that post is more about dynamic memory use).

I do have a debugger, but canā€™t simulate what is being experienced as I am one of those without hardware yet. I have the arduino and can run the code but without encoder feedback, things get stopped up quickly. Anybody have any spare motors\encoders they want to loan me?

Not to mince words or cause a stir, but to be clear, just because it is firmware does not make it ā€œreal-timeā€ code. Real-time is a term applied to code that is most often characterized by being deterministic (or very nearly so)ā€¦ that is, the time required to execute a task will meet itā€™s deadline each and every time. Real-time code has very little variability in execution timing. Very often real-time is achieved through the use of a real-time OS that is specialized for switching task contexts using priority scheduling. The Maslow firmware does not utilize tasks nor scheduling, but is rather AFAICR (ā€œAs Fast As I Can Runā€) code. One very useful thing about an RTOS is the protected access of shared resources (e.g. motors, memory, queues) such that they are accessed atomically, that is, a task owns the resource until it is completely through with it. Resource access is protected by using the semaphore and mutex constructs, that ensure multiple tasks cannot preempt each other until the shared resource is released by one task or the other.

Consider two timer ISRs that each fire a task, very closely one after another, that both want to access the same motor. Task 1 begins its movement of the motor to position X. The command to do so, may appear to be one pseudo-line-of-code: ā€œMove motor 1 to Position X.ā€ Beneath the covers of the high-level language though, that one line might be 50 lines of assembler code. The execution of the statement begins, but can only get through say 25 of its assembler lines of execution, before it is interrupted by Task 2 that wants to execute ā€œMove motor 1 to Position Yā€. What about the 25 lines of as of yet unexecuted code and the state of all of the registers when Task 2 begins? Chaos and unpredictable behavior ensue. This is why I advocate for anything that either task-switches or is interrupt-driven and uses shared resources, to be coded using an RTOS that can protect those resources and guarantee the atomic execution of the high-level code statements.

But I digress without adding any more value, so Iā€™ll stop here. :slight_smile:

I think Iā€™ve tracked down the issue.

Huge thanks to @blurfl for finding the tool to inspect the heap. After taking a look at it, it was pretty clear that fragmentation wasnā€™t the issue. It looked exactly like we would expect it to (yay!)

The only other thing that I could think of that could hold onto and build error over the course of a run was the integral term of the PID controller, and that seems to have been the issue. The integrator term was winding up and saturating making the machine move in a jerky way.

Iā€™ve reduced the value of _Ki and now it seems to be happy. The drawback is that when the machine first powers up it takes a second or two longer to compensate for the weight of the sled.

Bonus points to @seware for calling that it wasnā€™t a heap issue!

Iā€™m going to add an option to change the PID tuning values from the Advanced Settings in Ground Control so that anyone who wants to can easily play with them, and maybe weā€™ll find a better set

1 Like

_Ki was going to be my second guess. (actually I just thought it referred to a fraternity)

Nice work bar. You have a knack for troubleshooting.

And to everyone else who is regularly contributing. Some very cool people here.

1 Like

I noticed the right motor (the end where my laptop is) would buzz anytime the z was tweaked, for example when zeroing the bit. Does this eliminate that?

Thanks @seware! I get to listen to everyoneā€™s suggestions and then I look smart :grin:

@mooselake That hum is normal, itā€™s just the sound of the PWM signal which control the motor. The left motor sounds different from the right motor because they are controlled using different PWM sources due to the fact that the pin which controls the left motor is also used by the timer which is used to trigger the PID loops to recompute. Weā€™ll probably make them both sound the same eventually just for everyoneā€™s sanity, but they should function the same

1 Like

Sweet. Thank you so much.

I was close in my guess that:

But honestly, I am well over my head here so that is nothing more than dumb luck.

1 Like

Still a pretty spot on guess! :+1: :+1: :100:

I couldnā€™t tell if the left end buzzed; it was over 10 feet away and I had the laptop on the end of a lumber pile. To be more specific, I was only moving the Z (tweaking the bit position a, well, bit at time to zero it), not X/Y, and a bit surprised that there was any activity on the other axes every time the Z moved.

It looked like the sled didnā€™t move.

Is there any way you could implement an autotune feature in the future? Every sled will be different. BTW, Iā€™m an ignorant PIDder (hopefully not PIDdler), but do know an expert on another forum

The results of the change to Ki are night and day. Everything runs and sounds so much smoother now. When performing a drilling step, the XY positioning remains extremely constant and the motors donā€™t sound like they are struggling.

6 Likes