Time = 0, stop working

[Daniii438]

When setting a time of 0, the ramp library seems to stay at the previous value, instead of the new one. is that expected behaviour?

[siteswapjuggler]

Not really maybe it should react like the go() method. That's why the go method is implementeded in the first place. I'll make another commit to correct this in the dev branch

[siteswapjuggler]

It should be corrected in the dev branch, I'll test this tommorow before merging it to the master branch.

[Daniii438]

I'll test it and report back

[Daniii438]

it works now. however another issue is happening now, which has the same effect.

if i want to go from value 5000 to 0 within 10ms it will go negative and not stop.

the output values are:

• 4990
• -499
• -5988
• -11477
• -16966
• -22954
• -28443
• 31604
• 26115
• 20626
• 15137
• 9648
• 4159
• -1330
• -6819
• -12308
• -17797 and so on

[Daniii438]

This is the TestCode

include

rampInt Ramp; int xvalue = 0; int lastValue; void setup() { Serial.begin(115200); xvalue = 0; Ramp.go(5000, 500, LINEAR, ONCEFORWARD); delay(500); Ramp.update(); Ramp.go(xvalue, 10, LINEAR, ONCEFORWARD); }

void loop() { if(Ramp.value() != lastValue){ Serial.print("* "); Serial.println(Ramp.value()); } lastValue = Ramp.value(); Ramp.update(); }

[siteswapjuggler]

Sorry couldn't help much without a microcontroller to test it in real condition. The delay might be the problem as it's as long as the ramp duration, update will come after the ramp timeout.

And for the second ramp it could be a grain problem as your duration is equal to the default grain (fyi update does calculate only if the grain time is passed, it prevent for overcalculating on small microcontroller).

It's still not the good behaviour so I'll investigate by tomorrow, with my mind concentrating on it.

Thanks for your report.

[Daniii438]

the point of the first delay is it to get the ramp to 5000 to test how it behaves when going "backwards" aka from 5000 to 0 in 10ms.

[siteswapjuggler]

Ramp.go(5000); will do it immediately no need for the delay here...

[siteswapjuggler]

Btw what microcontroller are you using ?

[Daniii438]

Arduino UNO for testing, nothing except USB attached to it

[Daniii438]

Could the problem be, that the position overshoots it's Target, goes negative and then bad things happen?

[Daniii438]

btw using "constrain(val,A,B);" does nothing, because its not applied to val itself using "val = constrain(val,A,B);" would work, BUT it breaks the whole thing. I have tried it and it stopped working.

i have tried some more and as soon as i set the time value between 0-11 it breaks the code again. aka value() doesnt get set properly,so it seems to be an issue with the grain.

i started there and set the grain to a lower value (aka 0) and now everything seems to work. what didnt work before works now.

[Daniii438]

include

rampInt Ramp; int lastValue;

void setup() { Serial.begin(115200); Ramp.setGrain(0); Ramp.go(25); Ramp.update(); Ramp.go(0, 5, LINEAR, ONCEFORWARD); }

void loop() { if (Ramp.value() == 9) Ramp.go(50, 2, LINEAR, ONCEFORWARD); //9 happens to be a value that is reached when going from 25 to 0 if (Ramp.value() == 29) Ramp.go(4, 1, LINEAR, ONCEFORWARD); //29 happens to be a value that is reached when going from 9 to 50

if (Ramp.value() != lastValue) { Serial.println(Ramp.value()); }

lastValue = Ramp.value(); Ramp.update(); }

this will also break the library. Output of the serial monitor is:

25 20 15 9 29 4 -46 4 -46 and so on..

[Daniii438]

i have succesfully narrowed down the issue, it only happens when "pos" is over "dur", i dont know how that can happen, but for me it happens sometimes. i have fixed it by adding:

if (mode != NONE) { "if(pos > dur) pos = dur;" <--this float k = (float)pos/(float)dur;

to the library, k can be above 1 and below 0 and thats the issue, its not fixed by just clamping k between 0 and 1 but to set pos = dur in this case, it seems fixed for now. need to further test it.

maybe you know what the issue could be, and in which case pos > dur could happen. maybe you can explain it as well, it would be interesting to know why.

[Daniii438]

The issue is not happening that often anymore but still present. I'll test more tomorrow. Maybe you can take a look and check why it happens in the first place and when it would happen. I can't seem to figure it out. With the fix I'm just fixing the result not the issue itself.

[siteswapjuggler]

I appreciate your enthousiasm but sometimes too many post is just too much. I narrowed it also yesterday evening and told you I'll have a look this morning.

I suspect a problem with the pos and duration comparison (which should not happen because it mean to be limited) or a type overflow.

[Daniii438]

Sorry

[siteswapjuggler]

Problem solved dev branch update to 0.5.0 prerelease for you to test. New exemple based on your test code in the exemple directory.