Stepper does not move small steps with 16bit value input

[particlerain]

Hi,

thanks for the amazing library.

With accelstepper or other standart stepper libraries i can receiive 16 bit DMX values by using two channels and i can control the stepper with normal and fine steps modes. But can't get it done with FastAccelStepper library. The stepper moves only to the val1 values. Looks like your library does not accept the 16 bit values of val2.

eg. float val1 = (map(DMXSerial.read(board_dmx_adress + 0),0,255,0,65535)); // Ch1 Normal float val2 = DMXSerial.read(board_dmx_adress + 1); // Ch2 Fine (256 steps only)

long target = (val1 + val2); stepper->moveTo(target);

Any idea how to solve that issue? Thanks.

[gin66]

what are the values or value ranges of val1 and val2 ? Perhaps a log with prints of val1, val2 and target help to dig deeper

[particlerain]

For example val1 is 1: That makes 256 (range 0 to 65535) val2 is 125 ( (range 0 to 255)

Stepper moves to 256 , not to 381 which is val1 + val2.

If val1 is 2, it moves to 512 but not to 637.

I did a test with aother code by usng step++ with a delay of 50ms. That works fine. DMX protocol communicates with 250K baudrate tosend values . Might that be a problem for your library?

[particlerain]

what are the values or value ranges of val1 and val2 ? Perhaps a log with prints of val1, val2 and target help to dig deeper

Cant print logs right now because DMX is using the serial port of UNO. Would need an atmega2560 with more than one serial port.

[particlerain]

I did a test without DMX Serial input, and printed val1, val2, target, and getcurrentposition. It indeed goes to the corect target. So the problem i guess is the 250K DMX baudrate communication. i guess that causes some timing problems. As i said before it works with accelstepper & standart stepper libraries fine. What should i edit in your source files to fix that issue. I need to use your library because i need fast stepper speed.

[gin66]

If it is about interrupt timing, then it will be difficult: With atmega2560 or atmega328p every step requires one interupt. If you go one stepper at max speed, There will be every 20us an interupt. FastAccelStepper blocks up to ~13us in an interrupt (worst case). If serial driver blocks for >7us, it may get problematic.

With 250kBaud at 8N1, DMX will give you another 25000 Interrupts/s, so every 40us. So worst case will come out quite reliable.

what is surprising, that the deviation is so big. Can it be, that buffer overruns occur ?

[gin66]

if you need high speed, perhaps esp32 is a better choice

[particlerain]

Dont think its a buffer overrun. Becauee without the serial 250k value input your lib runs just fine if i set a fixed target.

Esp32 would be a great alternative, but it just sucks with higher baudrates rx than 115k because of many internal wifi bt interrupts. Even if you turn off wifi.

Would go with stm32 , but i cant rewrite all the libraries ...

[particlerain]

if you need high speed, perhaps esp32 is a better choice

I now tried the esp32 with your library. And yes it accepts the 16 bit values vla dmx and performs the steps. But unfortunately all of the dmx libraries for esp32 have timing issues. The stepper therefor makes some glitches every 10-20seconds.

[gin66]

Happy to hear, that esp32 works much better.

For the quirks: I don’t think, I can help you further. But in case the dmx reader is in one task and another task is using those numbers for controlling FastAccelStepper, then - if I would be in your position - I would check for interprocess communication issues between those two tasks.

[particlerain]

I would check for interprocess communication issues between those two tasks.

Yes i thought about the same thing. Thanks for your time. I will try to find a way and if not, stick to artnet.