Interval execution irregularity

A while ago I did some coding for stepper motors - last but not lease because I could not find a reason why @fobus ' code as posted should not work. Now - a few days ago - I reclaimed the main stepper motor from a throw away OKI OL800 laser printer for a project and put it to test.

To observe 'long' term behavior, I run it now since several days 24/7 placed next to my pc and I can hear the hum by the resonating table top.

BUT: Once in a while, about every 6 hours - it could also be 3 hours - it 'coughs up' *badly, as if the interval is not behaving right - for about a quarter to a second - is if stepped with improper sequence or too fast. After the hick-up, things just continue as nothing has happened.

The code is very simple - in a nutshell the essentials:

var st = 0; // step
var sts = [0b1001,0b0101,0b0110,0b1010]; // steps (pin outputs)
var stPs = [C6,C7,C8,C9]; // pins
var stp = function() { digitalWrite(stPs, sts[st = ++st % 4]); }; // stepping
var stI = setInterval(stp,3); // every 3ms next step

@Gordon, could you see any interrupt set timing issues that would lead to such behavior?

A bit more information:

The complete code is published in the above mentioned post, with adaption to the 2-phase 4-wire stepper and use of a L298N drive (vs. a 5-wire stepper and simple ULN2003APG driver).

The forward and backwards steps are replaced by below ones with stepping modulo adjusted to 4 (vs 8).

var stFW = [0b1001,0b0101,0b0110,0b1010];
var stBW = [0b1010,0b0110,0b0101,0b1001];

Since this stepper is much larger, the maximum speed I can run is r(3); (vs r(1);).

Have you tried one of the nightlies? I actually fixed some timing issues just yesterday.

I'm not sure I'd they'd cause a hiccup every 3 hours though. If it happens again with the new build, is there a way to get a more accurate time period (to a minute or so)? It might help me to figure out exactly which bit of the timing has a problem.

nightlies?

No, I try not to do so except (clear) indication... or new function I 'depend' on.

Just saw the release of 1v73. Will pull it and get it running again.

The reason I asked is: long time ago, I did some simulations (of dog fights)... and all of a sudden, in a fraction of a seconds a plane was flying a very different altitude in same direction (3 dimensional). The change in location/altitude was physically impossible. It turned out that some formulas had critical 'input parameter transitions' in intermediate results - division by very small numbers and multiplication by very large numbers - which challenged the accuracy of a physical computing machine (Numerical Methods/Problems). Resolve the formula in different ways for different input value ranges resolved the issue. --- (Cyclic) calculation of the the timer values could be something with similar issues... (btw, just happened this very moment again - 05:25 to the second - about 9hrs after the last time... so I keep it running for another 6..9 hours with the same release 1v72 and no change, if you think you could get something out of it.)

(05:25:00)=0 / (06:32:50)+0:07:50 / (07:49:35)+2:24:35

Yes, it'd be handy if you could keep it running then...

Basically there are a few counters, and a lot of calculations are done in the SysTick IRQ. Those need to be fast, so they all use integers.

If it happens to roll over at intervals of say, 32768 - then it gives be a clear idea of where the error might be occurring.

While I was still editing the previous post, it happened again: after 7 minutes and 50 seconds... but not ever since - almost 2 hrs... How many nested rollovers are there that could play into one another? - Don't get tied up to much tracking these things... there will come a time that I have to look into the firmware... more for educational purposes than for tracking down issues ;-)

Well, I was actually trying to write some kind of description - but it's actually horribly complex, with many, many variables and registers, lots of shifting and multiplications :(

All the fun starts here though.