Firmware bug fix

On my latest printer that uses an h-bot/corexy style drive, I was running into an intermittent layer shifting problem where for all the world it didn't look like just a lack of motor torque in that I would sometimes have both motors skip steps at exactly the same time. I began to suspect some sort of step rate timing issue because the problem was worse at high speeds, even though during test moves the motors had plenty of extra torque available. I ran across a thread in the Makergear forum where someone put a scope on the step pins and actually measured instances of the step pulses just stopping for 32msec in the middle of high speed motions. (See: http://forum.makergear.com/viewtopic.php?f=10&t=2568&sid=3ed91164115d82570e0247305e210af8) Turns out that Marlin (and many other firmwares) exhibit this glitch if the step interrupts can't keep up. The OP was noticing problems mostly on 45 deg. diagonal XY moves which is where both the X and Y axes need to move at high speeds, which maximally taxes the stepper interrupter timing. With an h-bot/corexy, any fast single axis move will similarly tax the ISR timing.

The fix Makergear settled on was a single line of code inserted just before the closing "}" of ISR() funciton in stepper.cpp :

if (TCNT1 >= OCR1A) TCNT1 = 175; //simple test recommended by jsc, tested by MG|Josh,
//to eliminate the mid-step-signal-set glitch;8/3/2015

which isn't a completely clean solution, but it does eliminate the whopping 32msec delay in the step pulses. I've implemented this change, and so far so good.

The interesting thing is that it sounds like this bug has been around forever, and it could explain a lot of layer shifting people encounter at higher speeds that maybe they've just been attributing to lack of motor torque. I haven't found any mention of this in the RepRap firmware sub-forums - has anyone else run across it? It sounds like this is a fix everyone should be implementing.

Is there a known pulse rate that triggers the problem?

It's nice that this bug has been fixed. But as someone on the thread you referred to said, "Of course, this whole situation is pretty marginal, and if it turns out this is what is causing the problem, it's just because you're running at the ragged edge of what is feasible on the hardware".

Some people delight in trying to get the maximum performance possible out of end-of-life hardware with very limited performance. Anyone else wanting good results at high speeds should use a modern 32-bit controller board and firmware designed for it.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
It's nice that this bug has been fixed. But as someone on the thread you referred to said, "Of course, this whole situation is pretty marginal, and if it turns out this is what is causing the problem, it's just because you're running at the ragged edge of what is feasible on the hardware".

Some people delight in trying to get the maximum performance possible out of end-of-life hardware with very limited performance. Anyone else wanting good results at high speeds should use a modern 32-bit controller board and firmware designed for it.

Exactly. I can see my days of using $50 Printrboard clones are nearly over. On a broader scope, though, this is the sort of bug that can rear its ugly head, albeit rarely, even if you aren't pushing speed limits. Real-time code is just hard to get right.

Yes, real time software is hard to write in such a way as to be 100% reliable, without race conditions and Heisenbugs. I have been writing it for 40 years. The more you have to resort to trickery to work around the limitations of the hardware you are working with rather than focus on writing reliable firmware, the harder it is to get right.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I haven't looked at any of the firmwares in detail, but I assume the stepper signals are driven off a timer based interrupt? That should be a lot easier to reason about than an external asynchronous event system as the frequency and instruction budget should be well defined. But yes, I agree that hard real time is difficult to do right, and pushing close to the limits of the hardware raises the difficulty exponentially. It's been a lot of years since I did anything close to that space, but it was some of the most fun I had.

Edited 1 time(s). Last edit at 07/02/2016 05:22PM by JamesK.

The stepper signals are, in fact, running off a timer-based interrupt, but just paging thru the length of code that is the Marlin ISR is mind-boggling. On top of that are the timing ambiguities introduced by the asynchronous serial communications. I suspect printing from an SD card is way more reliable for that reason alone.