How high can the control frequency be on the esp32 using this library?

I have a esp32 controlling 3 AC Servo motors of a delta robot with a maximum RPM of 3000 and an entire motion plan sent to the esp32 over UDP at a rate 1.12ms per message.
I am trying to execute motions on the esp32 using FastAccelStepper at two different control cycles - 0.02 (ie a point every 20ms) and 0.015( a point every 15ms) run at a max velocity of 1500 RPM. The motion plan for the two control cycles for the same positions is as follows -
CC = 0.02
total points :  47
POINT:
 positions: [0.26831230272552986, 0.26831230272552986, 0.0029724586491534327]
velocities: [-0.5669126948666714, -0.5669126948666714, 0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  26528437
Count :  0
POINT:
 positions: [0.24575334131226417, 0.24575334131226417, 0.004902549033968065]
velocities: [-1.1338253897333428, -1.1338253897333428, 0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  53056874
Count :  1
POINT:
 positions: [0.21191489919236567, 0.21191489919236567, 0.0068326394187826975]
velocities: [-1.133825389733343, -1.133825389733343, 0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  79585310
Count :  2
POINT:
 positions: [0.18935593777909998, 0.18935593777909998, 0.00876272980359733]
velocities: [-0.5669126948666715, -0.5669126948666715, 0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 106113747
Count :  3
POINT:
 positions: [0.1818362839746781, 0.1818362839746781, 0.010568969776197397]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 132642184
Count :  4
POINT:
 positions: [0.17382536889095124, 0.17382536889095124, 0.017967653621135504]
velocities: [-0.5851380270316452, -0.5851380270316452, 0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 160023468
Count :  5
POINT:
 positions: [0.14979262363977064, 0.14979262363977064, 0.02956024797841075]
velocities: [-1.1702760540632904, -1.1702760540632904, 0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 187404751
Count :  6
POINT:
 positions: [0.12575987838859004, 0.12575987838859004, 0.041152842335686]
velocities: [-0.5851380270316451, -0.5851380270316451, 0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 214786034
Count :  7
POINT:
 positions: [0.11774896330486317, 0.11774896330486317, 0.04855152618062408]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 242167318
Count :  8
POINT:
 positions: [0.11079022865783808, 0.11079022865783808, 0.05582936936414794]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.557723065386227]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 268265730
Count :  9
POINT:
 positions: [0.09928244116520318, 0.09928244116520318, 0.0776628989147195]
velocities: [-0.44093822540279076, -0.44093822540279076, 1.115446130772454]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 294364142
Count :  10
POINT:
 positions: [0.0877746536725683, 0.0877746536725683, 0.09949642846529107]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.5577230653862271]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 320462554
Count :  11
POINT:
 positions: [0.0808159190255432, 0.0808159190255432, 0.10677427164881492]
velocities: [1.1102230246251565e-16, 1.1102230246251565e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 346560966
Count :  12
POINT:
 positions: [0.0788156519159068, 0.0788156519159068, 0.11612888723980719]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.6323102643157151]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 376149654
Count :  13
POINT:
 positions: [0.07669522454435801, 0.07669522454435801, 0.14419273401278399]
velocities: [-0.07166344670845368, -0.07166344670845368, 1.2646205286314303]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 405738342
Count :  14
POINT:
 positions: [0.07457479717280922, 0.07457479717280922, 0.17225658078576078]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.6323102643157151]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 435327030
Count :  15
POINT:
 positions: [0.07257453006317283, 0.07257453006317283, 0.18161119637675305]
velocities: [-1.3877787807814457e-16, -1.3877787807814457e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 464915718
Count :  16
POINT:
 positions: [0.07257453006317283, 0.07257453006317283, 0.18161119637675305]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 1
  nsecs: 365237339
Count :  17
POINT:
 positions: [0.0795875587214206, 0.0795875587214206, 0.18862422503500081]
velocities: [0.5474822781182189, 0.5474822781182189, 0.5474822781182189]
accelerations: [21.37, 21.37, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 390856538
Count :  18
POINT:
 positions: [0.10062664469616427, 0.10062664469616427, 0.20581985228212318]
velocities: [1.0949645562364378, 1.0949645562364378, 0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 416475737
Count :  19
POINT:
 positions: [0.13218527365827978, 0.13218527365827978, 0.22348846342089834]
velocities: [1.0949645562364376, 1.0949645562364376, 0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 442094936
Count :  20
POINT:
 positions: [0.15322435963302344, 0.15322435963302344, 0.2406840906680207]
velocities: [0.5474822781182188, 0.5474822781182188, 0.5474822781182187]
accelerations: [-21.37, -21.37, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 467714135
Count :  21
POINT:
 positions: [0.16023738829127132, 0.16023738829127132, 0.2476971193262686]
velocities: [0.0, 0.0, -1.1102230246251565e-16]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 493333333
Count :  22
POINT:
 positions: [0.16023738829127132, 0.16023738829127132, 0.2476971193262686]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 593333333
Count :  23
POINT:
 positions: [0.15322435963302344, 0.15322435963302344, 0.2406840906680207]
velocities: [-0.5474822781182189, -0.5474822781182189, -0.5474822781182189]
accelerations: [-21.37, -21.37, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 618952532
Count :  24
POINT:
 positions: [0.13218527365827976, 0.13218527365827976, 0.22348846342089834]
velocities: [-1.0949645562364378, -1.0949645562364378, -0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 644571731
Count :  25
POINT:
 positions: [0.10062664469616427, 0.10062664469616427, 0.20581985228212318]
velocities: [-1.0949645562364376, -1.0949645562364376, -0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 670190930
Count :  26
POINT:
 positions: [0.0795875587214206, 0.0795875587214206, 0.18862422503500081]
velocities: [-0.5474822781182188, -0.5474822781182188, -0.5474822781182187]
accelerations: [21.37, 21.37, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 695810128
Count :  27
POINT:
 positions: [0.07257453006317272, 0.07257453006317272, 0.18161119637675294]
velocities: [0.0, 0.0, 1.1102230246251565e-16]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 721429327
Count :  28
POINT:
 positions: [0.07457479717280914, 0.07457479717280914, 0.17225658078576067]
velocities: [0.07166344670845488, 0.07166344670845488, -0.6323102643157147]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 751018015
Count :  29
POINT:
 positions: [0.07669522454435795, 0.07669522454435795, 0.14419273401278393]
velocities: [0.07166344670845488, 0.07166344670845488, -1.2646205286314294]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 780606703
Count :  30
POINT:
 positions: [0.07881565191590678, 0.07881565191590678, 0.11612888723980717]
velocities: [0.07166344670845488, 0.07166344670845488, -0.6323102643157149]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 810195392
Count :  31
POINT:
 positions: [0.0808159190255432, 0.0808159190255432, 0.10677427164881492]
velocities: [1.6653345369377348e-16, 1.6653345369377348e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 839784080
Count :  32
POINT:
 positions: [0.08777465367256829, 0.08777465367256829, 0.09949642846529107]
velocities: [0.44093822540279076, 0.44093822540279076, -0.557723065386227]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 865882492
Count :  33
POINT:
 positions: [0.09928244116520318, 0.09928244116520318, 0.0776628989147195]
velocities: [0.44093822540279076, 0.44093822540279076, -1.115446130772454]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 891980904
Count :  34
POINT:
 positions: [0.11079022865783807, 0.11079022865783807, 0.05582936936414794]
velocities: [0.44093822540279076, 0.44093822540279076, -0.5577230653862271]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 918079316
Count :  35
POINT:
 positions: [0.11774896330486316, 0.11774896330486316, 0.04855152618062408]
velocities: [-1.1102230246251565e-16, -1.1102230246251565e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 944177728
Count :  36
POINT:
 positions: [0.12575987838859004, 0.12575987838859004, 0.041152842335686]
velocities: [0.5851380270316452, 0.5851380270316452, -0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 971559011
Count :  37
POINT:
 positions: [0.14979262363977064, 0.14979262363977064, 0.029560247978410753]
velocities: [1.1702760540632904, 1.1702760540632904, -0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 998940295
Count :  38
POINT:
 positions: [0.17382536889095124, 0.17382536889095124, 0.017967653621135504]
velocities: [0.5851380270316451, 0.5851380270316451, -0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  26321578
Count :  39
POINT:
 positions: [0.1818362839746781, 0.1818362839746781, 0.010568969776197427]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  53702862
Count :  40
POINT:
 positions: [0.18935593777909998, 0.18935593777909998, 0.008762729803597356]
velocities: [0.5669126948666714, 0.5669126948666714, -0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  80231298
Count :  41
POINT:
 positions: [0.21191489919236567, 0.21191489919236567, 0.0068326394187827235]
velocities: [1.1338253897333428, 1.1338253897333428, -0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 106759735
Count :  42
POINT:
 positions: [0.24575334131226417, 0.24575334131226417, 0.004902549033968092]
velocities: [1.133825389733343, 1.133825389733343, -0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 133288172
Count :  43
POINT:
 positions: [0.26831230272552986, 0.26831230272552986, 0.002972458649153459]
velocities: [0.5669126948666715, 0.5669126948666715, -0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 159816609
Count :  44
POINT:
 positions: [0.27583195652995174, 0.27583195652995174, 0.0011662186765533911]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 186345046
Count :  45
POINT:
 positions: [0.27583195652995174, 0.27583195652995174, 0.0011662186765533911]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 2
  nsecs: 286345046
Count :  46

CC = 0.015
total points :  65
POINT:
 positions: [0.2719953984664712, 0.2719953984664712, 0.0024210042534921093]
velocities: [-0.4049376391904796, -0.4049376391904796, 0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  18948883
Count :  0
POINT:
 positions: [0.2604857242760295, 0.2604857242760295, 0.0037996402426454185]
velocities: [-0.8098752783809592, -0.8098752783809592, 0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  37897767
Count :  1
POINT:
 positions: [0.24130293395862673, 0.24130293395862673, 0.005178276231798727]
velocities: [-1.2148129175714388, -1.2148129175714388, 0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  56846650
Count :  2
POINT:
 positions: [0.2163653065460031, 0.2163653065460031, 0.006556912220952036]
velocities: [-1.2148129175714386, -1.2148129175714386, 0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  75795534
Count :  3
POINT:
 positions: [0.1971825162286003, 0.1971825162286003, 0.007935548210105345]
velocities: [-0.809875278380959, -0.809875278380959, 0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs:  94744417
Count :  4
POINT:
 positions: [0.18567284203815865, 0.18567284203815865, 0.009314184199258654]
velocities: [-0.40493763919047954, -0.40493763919047954, 0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 113693301
Count :  5
POINT:
 positions: [0.1818362839746781, 0.1818362839746781, 0.010568969776197397]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 132642184
Count :  6
POINT:
 positions: [0.1782758772707995, 0.1782758772707995, 0.01412937648007603]
velocities: [-0.3900920180210968, -0.3900920180210968, 0.3900920180210968]
accelerations: [-21.37, -21.37, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 150896373
Count :  7
POINT:
 positions: [0.16759465715916366, 0.16759465715916366, 0.021831851740227254]
velocities: [-0.7801840360421936, -0.7801840360421936, 0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 169150562
Count :  8
POINT:
 positions: [0.14979262363977064, 0.14979262363977064, 0.02956024797841075]
velocities: [-1.1702760540632904, -1.1702760540632904, 0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 187404751
Count :  9
POINT:
 positions: [0.13199059012037762, 0.13199059012037762, 0.037288644216594245]
velocities: [-0.7801840360421937, -0.7801840360421937, 0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 205658940
Count :  10
POINT:
 positions: [0.12130937000874177, 0.12130937000874177, 0.04499111947674547]
velocities: [-0.39009201802109683, -0.39009201802109683, 0.3900920180210968]
accelerations: [21.37, 21.37, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 223913129
Count :  11
POINT:
 positions: [0.11774896330486317, 0.11774896330486317, 0.04855152618062408]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 242167318
Count :  12
POINT:
 positions: [0.11309178615636505, 0.11309178615636505, 0.05320934581807935]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.44617845230898157]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 263046047
Count :  13
POINT:
 positions: [0.10388555616225714, 0.10388555616225714, 0.06718280473044515]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.8923569046179631]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 283924777
Count :  14
POINT:
 positions: [0.09467932616814924, 0.09467932616814924, 0.08814299309899384]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.8923569046179632]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 304803507
Count :  15
POINT:
 positions: [0.08547309617404132, 0.08547309617404132, 0.10211645201135966]
velocities: [-0.44093822540279076, -0.44093822540279076, 0.4461784523089817]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 325682236
Count :  16
POINT:
 positions: [0.0808159190255432, 0.0808159190255432, 0.10677427164881492]
velocities: [1.1102230246251565e-16, 1.1102230246251565e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 346560966
Count :  17
POINT:
 positions: [0.07952246103975638, 0.07952246103975638, 0.11093187857814482]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.42154017621047674]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 366286758
Count :  18
POINT:
 positions: [0.0781088427920572, 0.0781088427920572, 0.1234046993661345]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.8430803524209535]
accelerations: [0.0, 0.0, 21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 386012550
Count :  19
POINT:
 positions: [0.07669522454435801, 0.07669522454435801, 0.14419273401278399]
velocities: [-0.07166344670845368, -0.07166344670845368, 1.2646205286314303]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 405738342
Count :  20
POINT:
 positions: [0.07528160629665882, 0.07528160629665882, 0.16498076865943348]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.8430803524209536]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 425464134
Count :  21
POINT:
 positions: [0.07386798804895964, 0.07386798804895964, 0.17745358944742318]
velocities: [-0.07166344670845368, -0.07166344670845368, 0.4215401762104768]
accelerations: [0.0, 0.0, -21.37]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 445189926
Count :  22
POINT:
 positions: [0.07257453006317283, 0.07257453006317283, 0.18161119637675305]
velocities: [-1.3877787807814457e-16, -1.3877787807814457e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 0
  nsecs: 464915718
Count :  23
POINT:
 positions: [0.07257453006317283, 0.07257453006317283, 0.18161119637675305]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 1
  nsecs: 365237339
Count :  24
POINT:
 positions: [0.07615260590921756, 0.07615260590921756, 0.18518927222279777]
velocities: [0.391058770084442, 0.391058770084442, 0.391058770084442]
accelerations: [21.37, 21.37, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 383536767
Count :  25
POINT:
 positions: [0.08688683344735207, 0.08688683344735207, 0.19572350305996597]
velocities: [0.782117540168884, 0.782117540168884, 0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 401836195
Count :  26
POINT:
 positions: [0.10477721267757628, 0.10477721267757628, 0.20834393958766248]
velocities: [1.173176310253326, 1.173176310253326, 0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 420135623
Count :  27
POINT:
 positions: [0.12803470567686775, 0.12803470567686775, 0.22096437611535902]
velocities: [1.1731763102533264, 1.1731763102533264, 0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 438435050
Count :  28
POINT:
 positions: [0.14592508490709194, 0.14592508490709194, 0.23358481264305556]
velocities: [0.7821175401688842, 0.7821175401688842, 0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 456734478
Count :  29
POINT:
 positions: [0.15665931244522646, 0.15665931244522646, 0.24411904348022376]
velocities: [0.39105877008444245, 0.39105877008444245, 0.39105877008444223]
accelerations: [-21.37, -21.37, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 475033906
Count :  30
POINT:
 positions: [0.16023738829127132, 0.16023738829127132, 0.2476971193262686]
velocities: [0.0, 0.0, -1.1102230246251565e-16]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 493333333
Count :  31
POINT:
 positions: [0.16023738829127132, 0.16023738829127132, 0.2476971193262686]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 593333333
Count :  32
POINT:
 positions: [0.1566593124452265, 0.1566593124452265, 0.24411904348022376]
velocities: [-0.391058770084442, -0.391058770084442, -0.391058770084442]
accelerations: [-21.37, -21.37, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 611632761
Count :  33
POINT:
 positions: [0.14592508490709197, 0.14592508490709197, 0.23358481264305556]
velocities: [-0.782117540168884, -0.782117540168884, -0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 629932189
Count :  34
POINT:
 positions: [0.12803470567686775, 0.12803470567686775, 0.22096437611535905]
velocities: [-1.173176310253326, -1.173176310253326, -0.6896629080550688]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 648231616
Count :  35
POINT:
 positions: [0.1047772126775763, 0.1047772126775763, 0.2083439395876625]
velocities: [-1.1731763102533264, -1.1731763102533264, -0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 666531044
Count :  36
POINT:
 positions: [0.08688683344735208, 0.08688683344735208, 0.19572350305996597]
velocities: [-0.7821175401688842, -0.7821175401688842, -0.6896629080550688]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 684830472
Count :  37
POINT:
 positions: [0.07615260590921756, 0.07615260590921756, 0.18518927222279777]
velocities: [-0.39105877008444245, -0.39105877008444245, -0.39105877008444223]
accelerations: [21.37, 21.37, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 703129900
Count :  38
POINT:
 positions: [0.07257453006317272, 0.07257453006317272, 0.18161119637675294]
velocities: [0.0, 0.0, 1.1102230246251565e-16]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 721429327
Count :  39
POINT:
 positions: [0.07386798804895954, 0.07386798804895954, 0.17745358944742304]
velocities: [0.07166344670845488, 0.07166344670845488, -0.42154017621047646]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 741155119
Count :  40
POINT:
 positions: [0.07528160629665875, 0.07528160629665875, 0.16498076865943337]
velocities: [0.07166344670845488, 0.07166344670845488, -0.8430803524209529]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 760880911
Count :  41
POINT:
 positions: [0.07669522454435795, 0.07669522454435795, 0.14419273401278393]
velocities: [0.07166344670845488, 0.07166344670845488, -1.2646205286314294]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 780606703
Count :  42
POINT:
 positions: [0.07810884279205717, 0.07810884279205717, 0.12340469936613448]
velocities: [0.07166344670845488, 0.07166344670845488, -0.8430803524209529]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 800332495
Count :  43
POINT:
 positions: [0.07952246103975638, 0.07952246103975638, 0.11093187857814481]
velocities: [0.07166344670845488, 0.07166344670845488, -0.42154017621047646]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 820058288
Count :  44
POINT:
 positions: [0.0808159190255432, 0.0808159190255432, 0.10677427164881492]
velocities: [1.6653345369377348e-16, 1.6653345369377348e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 839784080
Count :  45
POINT:
 positions: [0.08547309617404132, 0.08547309617404132, 0.10211645201135966]
velocities: [0.44093822540279076, 0.44093822540279076, -0.44617845230898157]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 860662809
Count :  46
POINT:
 positions: [0.09467932616814922, 0.09467932616814922, 0.08814299309899386]
velocities: [0.44093822540279076, 0.44093822540279076, -0.8923569046179631]
accelerations: [0.0, 0.0, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 881541539
Count :  47
POINT:
 positions: [0.10388555616225713, 0.10388555616225713, 0.06718280473044516]
velocities: [0.44093822540279076, 0.44093822540279076, -0.8923569046179632]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 902420269
Count :  48
POINT:
 positions: [0.11309178615636505, 0.11309178615636505, 0.053209345818079345]
velocities: [0.44093822540279076, 0.44093822540279076, -0.4461784523089817]
accelerations: [0.0, 0.0, 21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 923298998
Count :  49
POINT:
 positions: [0.11774896330486316, 0.11774896330486316, 0.04855152618062408]
velocities: [-1.1102230246251565e-16, -1.1102230246251565e-16, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 944177728
Count :  50
POINT:
 positions: [0.12130937000874178, 0.12130937000874178, 0.04499111947674547]
velocities: [0.3900920180210968, 0.3900920180210968, -0.3900920180210968]
accelerations: [21.37, 21.37, -21.37]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 962431917
Count :  51
POINT:
 positions: [0.13199059012037762, 0.13199059012037762, 0.03728864421659425]
velocities: [0.7801840360421936, 0.7801840360421936, -0.42337658803633726]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 980686106
Count :  52
POINT:
 positions: [0.14979262363977064, 0.14979262363977064, 0.029560247978410753]
velocities: [1.1702760540632904, 1.1702760540632904, -0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 1
  nsecs: 998940295
Count :  53
POINT:
 positions: [0.16759465715916366, 0.16759465715916366, 0.021831851740227257]
velocities: [0.7801840360421937, 0.7801840360421937, -0.42337658803633726]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  17194484
Count :  54
POINT:
 positions: [0.1782758772707995, 0.1782758772707995, 0.014129376480076034]
velocities: [0.39009201802109683, 0.39009201802109683, -0.3900920180210968]
accelerations: [-21.37, -21.37, 21.37]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  35448673
Count :  55
POINT:
 positions: [0.1818362839746781, 0.1818362839746781, 0.010568969776197427]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  53702862
Count :  56
POINT:
 positions: [0.18567284203815865, 0.18567284203815865, 0.00931418419925868]
velocities: [0.4049376391904796, 0.4049376391904796, -0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  72651745
Count :  57
POINT:
 positions: [0.19718251622860034, 0.19718251622860034, 0.007935548210105371]
velocities: [0.8098752783809592, 0.8098752783809592, -0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs:  91600628
Count :  58
POINT:
 positions: [0.2163653065460031, 0.2163653065460031, 0.006556912220952062]
velocities: [1.2148129175714388, 1.2148129175714388, -0.07275552637463709]
accelerations: [21.37, 21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 110549512
Count :  59
POINT:
 positions: [0.24130293395862673, 0.24130293395862673, 0.005178276231798753]
velocities: [1.2148129175714386, 1.2148129175714386, -0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 129498395
Count :  60
POINT:
 positions: [0.2604857242760295, 0.2604857242760295, 0.0037996402426454436]
velocities: [0.809875278380959, 0.809875278380959, -0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 148447279
Count :  61
POINT:
 positions: [0.2719953984664712, 0.2719953984664712, 0.0024210042534921344]
velocities: [0.40493763919047954, 0.40493763919047954, -0.07275552637463709]
accelerations: [-21.37, -21.37, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 167396162
Count :  62
POINT:
 positions: [0.27583195652995174, 0.27583195652995174, 0.0011662186765533911]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [1.0]
time_from_start:
  secs: 2
  nsecs: 186345046
Count :  63
POINT:
 positions: [0.27583195652995174, 0.27583195652995174, 0.0011662186765533911]
velocities: [0.0, 0.0, 0.0]
accelerations: [0.0, 0.0, 0.0]
effort: [0.0]
time_from_start:
  secs: 2
  nsecs: 286345046
Count :  64

as I reduce the control cycle to 0.01 and lower the motion seems laggy during the return motion, i.e it seems like it is jumping steps or getting overridden by the next point. My objective is to achieve as low a control cycle as possible for smoother motions, We were earlier using UART and thought that was the bottleneck, but we have shifted currently to UDP and are sending msgs at 1.12ms times, so the current bottleneck now seems to be the way FastAccelStepper generates the motion and whether it is able to update at such high frequencies.
Your input would be greatly appreciated as you would have a better understanding of its capabilities, I am not able to figure out what the issue could be.
Thank you for your help in advance!

You could try to reduce the forward planning time to a bare minimum using setForwardPlanningTimeInMs(uint8_t ms). If the motor behaves strangely, then the queue has run out of commands. I would assume, that on esp32 5ms could still work. It must be for sure larger than 4ms stepper task cycle time.
On  the other side, with this high degree of control of the motion is the ramp generator in use at all ?

Another try is to reduce the stepper task cycle time below 4ms. This can be done only by changing the code in this function: https://github.com/gin66/FastAccelStepper/blob/e57f7b4fe676d5ea3ee44a0048b92d1770e5c7da/src/StepperISR_esp32.cpp#L107
If this is e.g. 1ms and forward planning time is e.g. 2ms, this should be quite performant. If the cpu can cope with this load is another question. I think you need to ensure, that wifi and stepper are running on different cores.

If this is successful, then I can extend engine.init with cycle time as an optional parameter

Hi Thank you for your quick response!

I have to set setForwardPlanningTimeInMs for each stepper right?.  ill try this and get back to you here.

Also I will incrementally test with 15 ms 10 ms and then go to 5ms. For now even reaching 8ms, would be a great improvement in performance for me.
The end goal being trying to push the device and see how performant it gets, I will later test in a more controlled environment, for going below 5ms, where changes need to be made in the ISR Code.

Regarding your question, I too had a doubt since you have mentioned the in the readme regarding multi-axis control that the  library's ramp generator would be less useful and its recommended to implement low-level access  directly using the library, At what point would the ramp generator prove insufficient? would that depend on how low I am going with my cycle time?

Yes. The forward planning time needs to be set for each stepper and will be kept. In case a new stepper is allocated afterwards, then the forward planning time will be adjusted for all allocated steppers again. This will overwrite any earlier setting. If the forward planning time is set after all steppers are allocated, then the new value will be used and not overwritten anymore. This mean, if the steppers are allocated and configured in a loop, then the forward planning time need to be set in a second loop following the stepper allocation loop.
Thanks for your support in testing this functionality to the limits. Until now, I have only found a simulator for avr uCs. Great would be an esp32 simulator, so I can set up automated testing to check some of these advanced API features. Until then, those advanced features are only by design and not tested by me.
As I understand your use of FastAccelStepper the ramp generator will always ensure the limits for maximum acceleration and maximum speed. By design this is independent from the cycle time - unless there is any hardcoded value or implicit assumption in the code, which I do not believe, but am not 100% sure about. So there is no point, where the ramp generator will be insufficient. Just that the expectation of how the steppers should perform and the actual executed steps may not match, because of the constraints the ramp generator imposes on the stepper movements.
My expectation of the ramp generator is, that independent of the rate or magnitude of the changes in position/speed/acceleration, the stepper must always run within the limits of max speed/acceleration and always on the shortest round to the targeted position or speed.

I tried adding ForwardPlanningTime as below -
  engine.init();
  for (int num = 0; num < MOTOR_COUNT; num++) {
    // Input for Limit Pins
    pinMode(MOTOR_LIMIT_PINS[num], INPUT_PULLUP);
    stepper[num] = engine.stepperConnectToPin(MOTOR_PUL_PINS[num]);
    if (stepper[num]) {
      stepper[num]->setDirectionPin(MOTOR_DIR_PINS[num]);
      // You might also need to set enable pin if you have one
      setMotorSpeedInMMPerSec(num, SPEED_IN_MM_S);
      setMotorAcceleration(num, ACCEL_IN_MM_S);
    }
  }

  // Set future planning time limit for lower control cycles
  for (int num = 0; num < MOTOR_COUNT; num++) {
      stepper[num]->setForwardPlanningTimeInMs(10);
  }

I tried with values 5, 10, 15. I didn't see any difference in my motion. I will attach videos of my execution to help you understand what the issue could be:
Control Cycle = 0.02 secs
https://github.com/user-attachments/assets/c4eb0143-4654-4871-93a6-91e463d952ac
Control Cycle = 0.01 secs
https://github.com/user-attachments/assets/e4a2d040-e190-478e-9d35-9cd4be0da6cd
Control Cycle = 0.01 secs with fixed delay of 3ms
https://github.com/user-attachments/assets/a89207d0-1fc0-4413-aa99-1c7b8d61ae9a
The control Cycle of 0.01secs run with fixed dalay of 3ms, shows that the motion plan generates points based on smaller control cycle and  follows the actual C path, but the execution at the esp end is suspect.

Thanks for sharing the video. Gives an idea, how you use the system.
Your sequence of the initialization is ok: First the motor, then the forward planning time
From the code in FastaccelStepper I only see, that in this line the condition should be put in brackets ()
https://github.com/gin66/FastAccelStepper/blob/e57f7b4fe676d5ea3ee44a0048b92d1770e5c7da/src/FastAccelStepper.cpp#L386
Besides this, I cannot find anything suspicious in the code. If I find time the next days, I will make a test case running on simavr to check, that this function works as expected.
From the video I am not convinced, that the issue is related to FastAccelStepper. It could be network performance via UDP.  This connection may lag due to WiFi communication, esp32 UDP/wifi stack implementation or esp32 task management. I assume, there is no flash write somewhere in the code. Perhaps it is a good idea to add a timestamp to the UDP commands and check on esp32 side, if expected UDP commands have arrived too late.

Thanks for checking, that UDP is not the issue. So there are two possibilities:

Please modify the mentioned line and add the brackets () around the condition
Skip the ramp generator and generate the commands directly from the UDP commands.

As mentioned, that I can add a test case only within a few days to check the general function. Besides the mentioned brackets, which may be the root cause, I am confident, that the feature is working on FastAccelStepper side.

Sure, Ill make the changes and test once with the brackets around the condition.

Regarding skipping the ramp generator and generating the commands directly from the UDP commands, can you provide any references as to how to go about this? I checked your low-level access comments and got a gist of it, but some reference would be really helpful.

If we can identify that FastAccelStepper is not the issue, then we might have to investigate on the driver and motor end. Most AC Servo drivers come with response times in the range of 10us, so that was planned to be my last option to investigate. You can check on your end as and when you get time, ill make the changes and see if it yields me any results

On master branch I have added a test case to check, if
setForwardPlanningTimeInMs() works as expected and I have added the mentioned brackets for clarity. From my side, I do not see the reason for the observed behavior. Sorry for this.
From the video it appears, the stepper gets the command to stop or decelerate during movement. This does not hint to servo driver response time of physical limits of the motor.
In your first post, it can be observed, that the acceleration is in consecutive calls jump around the three values -21.37/0/+21.37. Could it be, that those initiate those stops ?
As this pick and place robot performs a complex motion for the steppers, it is not so obvious, what is correct behavior. How to determine, if the generated positions being sent via UDP are correct ?

Hi the video named 1500RPM_motion_0.02cc_sliderview.mp4 , in one of the above commends runs at control cycle of 0.02, where it runs proper motion. The way we are verifying whether the positions are proper is I have run the entire trajectory generated at 0.01 control cycle, but added manual delays of 30ms between each point and run the motion as seen in  - 1500RPM_motion_0.01cc_3msdelay.mp4 -above. It shows the positions are proper.
How do we check if the accelerations/velocities are proper is currently only by running the motion physically :P sort of catch 22. But those acceleration spikes are normal, its following a trapezoidal trajectory generation, and the plots seem proper comparing to motions above control cycle of 0.02 which we could test physically. We do not currently have a physical simulator setup that can replicate the mass and inertia to simulate the acceleration and velocities properly, so that leaves us with testing on the actual hardware.
My current suspect is now the drivers, the datasheet does not have the exact stat so I am waiting on response from their team. A basic google search on the driver gave me the control frequency on these drivers as 50Hz but again not in any of their specification sheets. If it is 50Hz it could explain why we are being limited to 0.02 right now.
So once I can confirm that I can even test out using ForwardPlanningInMs with drivers at  higher control frequency say 100 or 200 Hz. I tested with the brackets, there seems to be no difference, so ill check on the drivers and get back.

Thanks for explanation.What is still not clear to me, which of the stepper‘s parameters of position, speed and/or acceleration are controlled and how this is done? What could be of interest to monitor rampState().
The point is that for a given set of parameters, the ramp generator may decide, that stop needs to be executed and the next calculated set gives another result. If too high acceleration values the motion will be stuttering.
If you control position and another value, then best sequence is to set speed/acceleration, then a move command. Do not call update applySpeedAcceleration(). It could be that between applySpeedAcceleration() and the move command, the stepper task is executed and this combination of new speed/acceleration and old position requires unwanted movements…just a thought .

How I am executing the motion is as follows,
void setMotorPosition(int num, float pos_mm) {
  if (stepper[num]) {
    float pos_steps = static_cast<float>(pos_mm * STEPS_PER_MM);
    stepper[num]->moveTo(pos_steps);
  }
}

void setMotorSpeedInMMPerSec(int num, float speed_mm_s) {
  if (stepper[num]) {
    float speed_steps_s = speed_mm_s * STEPS_PER_MM;
    stepper[num]->setSpeedInHz(speed_steps_s);
  }
}

void setMotorAcceleration(int num, float accel_mm_s2) {
  if (stepper[num]) {
    float accel_steps_s2 = accel_mm_s2 * STEPS_PER_MM;
    stepper[num]->setAcceleration(accel_steps_s2);
  }
}

void set_point(int num, float pos, float velo, float accel) {
  setMotorSpeedInMMPerSec(num, velo);
  setMotorAcceleration(num, accel);
  setMotorPosition(num, pos);
}
    for (int num = 0; num < MOTOR_COUNT; num++) {
      set_point(num, packet.positions[num] * 1000, packet.velocities[num] * 1000, packet.accelerations[num] * 1000);
    }

I set the velocity and acceleration, then run the moveTo for the next position. So any specific point in the path generated is basically the speed and acceleration needed right now to move to the next position in the required time. This ensures the end-effector reaches the object on the conveyor at the right time.
the stepper task is executed and this combination of new speed/acceleration and old position requires unwanted movements

This could be true for a  moment of time in microseconds i guess, but its running pick and place on a moving conveyor at control cycles more than 0.02. Of course, we have not tested on mm level precision, where this could actually be causing impacts coz of unwanted movements for that small a time.

Thanks for sharing.
In general I am always confused to see a float being fed into a function expecting an integer. Apparently it works, but I would expect the compiler to issue some warning.
First, setAcceleration() expects only positive values and returns -1 in that case (even though the parameter is defined as signed integer). Second, I would assume, it has advantages to set the acceleration to the machine capability once and leave it unchanged. The movement is already fully controlled by position and speed. Similarly, setSpeedIn..() expects only positive values, too. A negative float will be converted into a big integer, which represents a pretty low speed. Any pulse representing low speed will be completed, even though new commands are coming in. The pause is not interruptible. If e.g. a pulse is generated with 1step/s and the step has just been generated, then the remainder of the time till 1s is complete, no other pulse will be generated.
Just my two cents from looking at the code. If the speed/acceleration values are all positive, then this can be safely ignored.

The sequence of setting speed, acceleration and then position is completed fine and there is no possibility by task switching in between to cause an issue with unsynchronized updates. Only the moveTo() will apply the previously changed speed/acceleration.

Hello, I have a similar issue. At the beginning of the thread, it seems like a ROS trajectory output, which I also use. My question is about creating the command queue. If I understand correctly, the stepper creates a queue of commands that arrive faster than it can process each one, so it continues with the original target value and then moves on to the next in the queue – is that correct? If so, how is the queue generated over time? I'm trying to understand if, when I set speed and acceleration and then call moveTo, the motor moves... and if, before it finishes moving, another speed, acceleration, and moveTo are called, will the new speed and acceleration be applied only at the new position, or will they change immediately when moveTo is called?

The ramp generator fills the stepper queue with commands and keeps track of position/pulse rate at queue end … normally some time in the future. For very low speeds e.g. 1step/s this future can be even 2 seconds: one command in process and one command prepared in queue. For a move to complete, it may need 1 or 10 or 100000 commands to complete - depending on the move. Those commands can be steps, multiple steps or pauses. The queue will be minimally filled to have 20ms planned in the future. Any new move/moveTo/stop/applySpeedAcceleration will only append command to queue end and will not change existing commands. If one move is 1 step at 1step/s, then the next command will be processed after completing the 1s.

The ramp generator is processed every 4ms in cyclic interrupt or task depending on the uC

So the queue only stores the position?

The struct is here:
https://github.com/gin66/FastAccelStepper/blob/f83a711c012b7e7557407acbc06cfd98fc0c5103/src/fas_arch/common.h#L50

The ramp generator keeps its own queue end related data, which is defined here:
https://github.com/gin66/FastAccelStepper/blob/f83a711c012b7e7557407acbc06cfd98fc0c5103/src/RampConstAcceleration.h#L31

The queue does not care about the current speed/acceleration, so the queue end structure only keeps position related info. The ramp generator need to know those values, so more data is kept.
If commands are removed from the queue, then the ramp generator’s data structure would be out of sync.

This means that for precise synchronized movement of multiple motors to achieve linear motion of my manipulator's end effector, the high-level application of FAS is not very suitable. It is not possible to accurately set acceleration and speed at transition states over time because, when I want to use Moveto at exact time intervals designated for movement, the previous motion is already decelerating at that moment? I tried to address this issue with a slight "lead," setting the commands earlier than the end of the movement, but this causes significant desynchronization.

Alright, I'll try to dive into it and see what can be done. Thanks a lot for the consultation. I really appreciate your work, as it allows me to do things I could hardly manage on my own. Do you have any suggestions on where to start studying the problem so that it makes sense for my project? And is there any description on how to work with the low-level aspects beyond the documented API? It's quite a complex topic for me... and I would need something detailed.

some doc is in #86
examples:
examples/Pulses/Pulses.ino
examples/RawAccess
examples/RawAccessWithPause

Hi @gin66, I'm very much interested in high-frequency positioning. My ESPs control loop runs at 1ms or lower and likewise, the moveTo() is called. The servo I use has a step/dir interface that accepts pulses up to 300kHz.
Any chance we get a simple API like
moveToPositionWithoutRamp(targetPosition), ignoring any acceleration limits and only taking into account the maximum pulse frequency of the interface? Repetitive calls of the function should overwrite the previous target position immediately.
BR

I have another question: How is it possible to achieve high frequencies using "addQueueEntry"? According to the description, it is possible to have MIN_CMD_TICKS set to 3200, which translates to 5000 steps per second. Or did I misunderstand something?

The minimal command duration is defined by MIN _CMD_TICKS. If this value is 3200 ticks, then the command can be e.g. 1 step or pause with >=3200 ticks, or 10 steps at >= 320 ticks, or 20 steps at >= 160ticks,… A command can be either a pause or 1…255 steps with the related ticks.

Thanks, that's clear. Now I "just" need to calculate it so that the accelerations and decelerations work for my application
. So, is acceleration and deceleration a combination of incrementing ticks/steps in a single command?

Thanks, that's clear. Now I "just" need to calculate it so that the accelerations and decelerations work for my application
. So, is acceleration and deceleration a combination of incrementing ticks/steps in a single command?

a single command has a fixed pulse rate. Acceleration and deceleration needs several commands in sequence.

That's what I meant, for example, 6000 ticks/10 steps, then the next command 5000 ticks/10 steps, and so on... acceleration and conversely deceleration, or the same number of ticks but with a decreasing or increasing number of steps. Is that correct?

The algorithm is bit complex. For slow speeds (lower than 1kHz) normally each command contains one step. If the step rate is even lower than 65535 ticks, then pause commands will be included between steps. For higher speeds, the algorithm tries to settle on a 2ms command time by requesting several steps per command. Depending on the position on the ramp, or if during coasting the deceleration start is approaching, the number of steps and thus the command time can be decreased.

I understand that the implementation will be complex, but essentially it's about combining the pause between commands, tick and step, and tick/step (it’s important not to end up with a remainder or exceed the MCU frequency). I'll try to put it together somehow
It would be a great feature to simply input points with their attributes into a queue and create a path through multiple points, not just from A to B, which is insufficient for my application. If it works out, I’ll be happy to share the code. We could even add it here if needed ;)

@gin66 I've implemented a very specialized and rudimentary version of this awesome library without acceleration and learnt a ton from your work.
To compare the libraries, a benchmark has been setup, in which a sine wave target signal (10Hz) has to be followed. Examples of the pulse following are depicted below. The blue line is the target position, the green line is the current position from "FastAccelStepper" and the red curve is the current position from "FastNonAccelStepper".
"FastAccelStepper" lib:

"FastNonAccelStepper" lib:

The FastAccelStepper settings from the benchmark script resulted in significant position lag. Furthermore, the "FastAccelStepper" trajectory looks a bit jittery.
Do you have some settings in mind, which would improve the benchmark behavior?
BR
Chris

Thanks for the new measurements. Actually I am surprised, that forward planning time 1ms has worked without motor stalls. Reducing the task period together with short planning time should improve the results.

Thanks again for measurements. For esp32 adding the option to adjust the stepper task rate makes apparently sense. Then the app developers have more control about FastAccelStepper performance.
The 4ms task rate was just a carry over from avr. In order to have as much code overlap as possible and reuse the test suite from avr, the 4ms will remain to be the default.
I do not remember to have hit a limit with esp32 load or bad performance, but the mcpwm/pcnt combo is sensitive to too long interruption blockages design. There is code included to recover from an overrun, but difficult to test. esp32 cpu load measurements haven’t been performed., but I know, that writing to flash while running a stepper is not a good idea. The stepper task will stop filling the queue, which leads to an abrupt stop and with delay a sudden restart at previous speed. At least no step will be lost, because the interrupts are in IRAM. For espidf 5.x I am not so sure anymore, because here a good deal of espressif code is in use.

g
In our case, the negative values simply signify the direction of the motion in the case of speed. So we have negative acceleration which will increase the speed in the negative direction. Positive acceleration will increase the speed in the positive direction of motion. As can be seen from the first few values of position, speed and acceleration commands in the first comment.  In case of float data being sent, i believe the compiler simply truncates the float to integer and hence the function runs smoothly.

Although If negative accelerationis not accepted by the function call setAcceleration, do you mean to say that the motion is running purely based on the position and speed controls provided by the trajectory? My question is for control cycles more than 0.02, the motion is quite accurate, and we seem to be facing stops or speed change issues only at higher update rates (< 0.02), should I try running the motion with signed int values for speed to see if the issue still persists below 0.02 control cycle.
For me the current culprit is the driver which we are in the process of upgrading. Based on the above plots by users above , it seems the forwardPlanning is working even for upto 1ms, so can we for sure claim this is not an issue with the library?

„For sure“ is difficult to say. It highly depends on the other code running on the esp32 in which FastAccelStepper is a part of. The OS is normally configured with 1ms task rate. So 1ms delay in the StepperTask loop may result in the StepperTask only running every 2ms.

Yeah but still my current requirements are not that high either. I am working with 20ms currently, so even if I can get the cycle down to 10ms or 5ms, we are still reaching industrial motion controller standards. Upto 10ms I guess should be feasible or do I need to run cpu utilization scripts parallel with the stepper calls to confirm if this works? I'm currently stuck between both where I am unable to confirm if the bottleneck is the driver or the esp32.

@ChrGri has obtained good results at 2ms delay. Perhaps you can try something like 2ms delay and 5ms forward planning


Where do I put the bing search API key?

Sorry for being total noob here. i don't know where to put Bing search API and endpoint. Could you guys please guide me. Thank you in advance!

文件夹：assets/config/node.yml
bing:
api_key:  *
endpoint: https://api.bing.microsoft.com/v7.0/search


Make rdfToObject public

Hey, I'd like to use rdfToObject() in cayleygraph/quad.
Is it possible to make it a public function so I'll be able to import it?

@iddan yes, that makes sense. Will submit a PR today.

@kazarena Thank you!!!

@iddan the fix has been merged into master. It will be included into a formal release later this week.


exit status 2

What is the issue?
exit status 2
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
ollama version is 0.5.1

Server logs will aid in debugging.


fix: collection on mobile is broken

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #5448
[ ] Requires deployment <>

Before submitting pull request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </bsx/collection>
[ ] I've tested PR on mobile
[ ] I've written unit tests 🧪
[ ] I've found edge cases

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

this brakes the design. it needs to remain 2 columns on mobile.
from figma:

For 2 columns struct, the text would overflow out of the screen. I guess placing them in one column on mobile could contain more text content. WDYT @exezbcz

@Jarsen136 yes. that is better, I made it like that to make it simpler to convert the desktop design to mobile.
In this case I dont mind that, but thanks for noticing! @daiagi

Tested on pixel
Before

AFTER

Sooo last fixes and LG (let's go/ life's good)(choose for yourself) 🚀

pay 30 usd

😍 Perfect, I’ve sent the payout
💵 $30 @ 32.69 USD/KSM ~ 0.918 $KSM
🧗 Caiv9TbPz68q5dC8EcHu5xKYPRnremimGzqmEejDFNpWWLG
🔗 0x6a9c557c89c010eb06b670ed682b642500ce4bc3d3df71d2b65bf6485845166c
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Developing methods and libraries to ingest in situ data into Google Earth Engine

Montana State University
Mentors
Dr. Eric Sproles; Department of Earth Sciences, Montana State University
Dr. Sean Yaw; Department of Computer Science, Montana State University
Information for Students
Please see ESIP’s general guidelines.
Project Ideas
Developing methods and libraries to ingest in situ data into Google Earth Engine
Abstract
SnowCloud, an end-to-end cloud-computing framework comprised of (i) SnowCloudMetrics, cloud-based tools that transition RSS products into actionable snow metrics; and (ii) SnowCloudHydro, a simple hydrologic model for snow dominated watersheds that relies solely on monthly Snow Cover Frequency (SCF) and previous streamflow to forecast monthly streamflow with a one-month lead-time. The ability the current iteration of SnowCloudHydro to effectively predict streamflow is limited to watersheds that snow dependent and with limited liquid precipitation. Advancing the predictive capacity of SnowCloudHydro will require new space borne and in situ (field) data. Google Earth Engine (GEE) readily serves space-borne data in a cloud-based environment. However, linking these satellite data in GEE with in situ measurements remains a challenge yet unsolved.
Technical Details
We propose for the Summer Google of Code student to develop a library or routine that can ingest point-based measurements into Google Earth Engine. The data sets that would be of most value are stream gage data from the United States Geological Survey (USGS), though we are equally interested in stream gages from other regions of the world.
A successful project would be characterized by:
A.	Code that is readily deployable in GEE that will read USGS (or equivalent agency) data into the SnowCloudHydro framework.
B.	Code that can automatically be incorporated into SnowCloudHydro predictions of streamflow.
Helpful Experience
The student should have a solid understanding of hydroclimatic and spatial processes, both from an applied and computational perspective. Applied skills can be satisfied by coursework, though hands on field work is preferred, as is experience in snowy climates. Helpful skillsets in the spatial sciences include raster analysis and visualization. Experience using Google Earth Engine is preferred, but no required. Computational skills that would be most valuable are data assimilation, model calibration and validation, and the ability to code in Python and/or JavaScript.
First steps
Read the paper that describes the SnowCloudHydro modelling framework (https://www.mdpi.com/2072-4292/10/8/1276/htm) to familiarize yourself with the model structure. You should also familiarize yourself with the SMAP, TRMM, and GPM datasets available on Google Earth Engine (https://developers.google.com/earth-engine/datasets/).
You should then gain access to Google Earth Engine (https://signup.earthengine.google.com/), and complete any tutorials needed to bring you up to speed. Once you are familiar with Google Earth Engine download and experiment with the SnowHydro code that drives snow cover analysis (https://github.com/MountainHydroClimate/SCF_ESIP/)Version6.
Next, please familiarize yourself with the United States Geological Survey’s (USGS) National Water Information Portal (NWIS), and then learn about how to read-in USGS data (https://waterdata.usgs.gov/nwis).
Finally, get creative and experiment with getting real time USGS data into Google Earth Engine.

Hey,how I could I reach mentors in this project?

I have gone through the links provided to get familiar with the project, but the github link for SnowHydro code does not work.

@esproles mailed you :)

I have gone through the links provided to get familiar with the project, but the github link for SnowHydro code does not work.

https://github.com/MountainHydroClimate/SCF_ESIP/
go for version 6

Hey @esproles how I could I reach mentors in this project?

The best way to contact us is through this GitHub page.

Oh ok,so actually I have gone through the documents and looked at the code , Should I start looking at drafting the proposal or do you propose to do something before hand. Also how do I send my proposal to you after drafting the first version.

@esproles any information you could provide @ritwikagarwal on ways to get started?

@ritwikagarwal
Sorry for the delayed response.
I suggest:

providing example code that demonstrates a near-real time feed of USGS stream gage into a web-based interface, preferably Data Studio or Sheets. Fusion Tables are not a great option as they will be deprecated in Dec 2019.

providing an example of how to transition the results from the GEE code into Data Studio using Big Query GIS.

two sites that might help are:
https://cloud.google.com/blog/products/gcp/bridging-the-gap-between-data-and-insights
http://whrc.org/wp-content/uploads/2016/02/Thau_Google.pdf

Looks like a fun project! Are there any plans to also incorporate precipitation data (i.e. rain gauges) into the model, or will the focus over the summer be primarily on the stream gages?

@rpalomaki -
Thanks for your interest - yes the goal will be to eventually incorporate other in situ data. The USGS is simply a preliminary step in the process. Ideally this would happen over the summer.

E

Hi @esproles - I wrote a small package to extract USGS/NWIS stream gage data for export into Google Sheets. It's written in python, so not yet deployable into the JS SnowCloudHydro model. But, that is one thing I would hope to accomplish over the summer if I have the chance to work on this project.
Currently, the data extractor handles only the most recent values posted by the USGS. I am working now to handle data requests over longer periods, which I think would be a useful feature for the end-users of the model. Please let me know if you have any feedback. Thanks!

Hi @rpalomaki -
Thanks for your efforts. This is a great start to getting the USGS data into GEE. I am not sure that it would need to be converted into JS, as you could make a call from GEE.
Yes you are correct - the model would need both longterm and recent data. This would be a logical next step.
My second question is does this package grab daily data? The SnowCloudHydro Model uses monthly averages, though we want to test it for weekly data as well. Could you specify the temporal bin (hourly, daily, weekly, monthly) in the package? While you could do the calculations in Google Sheets, the end goal is to make the SnowCloudHydro model as seamless as possible for the end user.
Thanks again for your efforts -
esproles

@esproles Currently the package only retrieves the most recent instantaneous value for a given variable and station. I believe this this is typically an hourly value, but could be daily depending on the station. But when I add the functionality to retrieve a longer period of data, it should be no problem to also add in temporal averaging and other statistics. This would give the user the ability to access and export e.g. a year's worth of weekly averages of discharge at multiple sites.
Regarding python and javascript - I am somewhat new to GEE and the web-based IDE, but I was under the impression that the IDE is set up only for JS. I've come across the GEE Python API, but it looks like this is installed/run on a local machine instead of the IDE. Have you had any luck in the past with running python scripts using the web-based IDE? Perhaps this is a non-issue if the NWIS data extractor can be a standalone package. But if the goal is to nest the data extractor inside the larger SCF model, this may be a hurdle to get over.

@rpalomaki - thanks for your response. Moving the package towards providing a temporal average of data (weekly, bi-monthly, monthly) will be a big step in creating a seamless framework for SnowCloudHydro.
Yes - hopefully the NWIS data extractor could be a stand alone package, but could the model incorporate other in situ data such as precip or SWE? These data would also come from sources other than USGS.

@esproles - Yes, I think the current package could be expanded to incorporate other data. Do you have a particular dataset in mind for precip and SWE? There may be some differences in the data portals provided by different agencies.

@rpalomaki - for precip and SWE data SNOTEL would provide a single digital stop for data. Even though these are limited to the western US, these data would be a great place to start.

Hi all - a friendly reminder that there is ONE WEEK LEFT to submit your proposals for this project! Best of luck and we're excited to see what is submitted!

@esproles - Great, I'll start looking into it!

Hi @abburgess - I submitted a draft proposal a few days ago. Do you anticipate that I will be able to receive some feedback before the final versions are due?

@esproles can you please make sure to review the draft proposal submitted by @rpalomaki to make sure he is on the right track and the proposal is as successful as possible?

@abburgess @rpalomaki -
I read the draft proposal, and it looks very solid. Great job.
@rpalomaki - did you submit it to the GSoC website or here on GitHub?
Thanks!


Add interactive project selection to start and stop command

The Problem/Issue/Bug:
As a user I want to start a project by name. If the current working dir is not the project root, then I need to know the project name. Then I have to use ddev list to find the right name. Developers are lazy. So they have to copy the name to the clipboard.
How this PR Solves The Problem:
Provide an interactive selection of the project by adding a parameter -s to the start and stop command.
Manual Testing Instructions:
Run ddev start -s or ddev stop -s
Automated Testing Overview:
There are two new function in ddevapp.

ddevapp.ExtractProjectNames
ddevapp.GetInactiveProjects

There is a new file util_test.go which covers both new functions.
For the interactive command is currently no test available, because I do not know how we can test it.
Related Issue Link(s):
Release/Deployment notes:

Thanks for this! I won't be able to look at it for a couple of weeks. On Camino de Santiago in Spain with only a phone.

Wow! What a great idea. Works well
Test

Open PR in Gitpod
Using the browse panel, search for "easy" to confirm site working
Stop DDEV

$ ddev stop
Container ddev-d9simple-db  Removed
Container ddev-d9simple-web  Removed
Network ddev-d9simple_default  Removed

Using the browse panel, search for "easy" and get expected 8080 error
move to different directory

mkdir ../laravel
cd ../laravel

attempt to start DDEV

gitpod /workspace/laravel $  ddev start
Failed to get project(s): could not find a project in /workspace/laravel

Start d9simple project with new command

gitpod /workspace/laravel $ ddev start -s
The ddev-ssh-agent container has been removed. When you start it again you will have to use 'ddev auth ssh' to provide key authentication again.
Search: █
Projects:
  ▸ d9simple
Starting d9simple...
...
Successfully started d9simple
Project can be reached at https://8080-cmuench-ddev-2dawctvhsvj.ws-us39a.gitpod.io

Using the browse panel, search for "pasta" to confirm site working
attempt to stop DDEV with new command

gitpod /workspace/laravel $ ddev stop -s
✔ d9simple
Container ddev-d9simple-db  Removed
Container ddev-d9simple-web  Removed
Network ddev-d9simple_default  Removed

attempt to stop when no project is running

gitpod /workspace/laravel $ ddev stop -s
No project is currently running

Thanks for this! I won't be able to look at it for a couple of weeks. On Camino de Santiago in Spain with only a phone.

There is not pressure here.
Enjoy your time in Spain.

Rebased

@rfay buildkit job is now running for 15h. Seems something broken.


removing the all the events bound to an element when it's unmounted

I am still optimizing the memory heap of riotjs.  Thank you!!


Remove ConfigureDefaultOptions

@DamianEdwards @danroth27 are we sure about this one? The default binders do not work for Kestrel.

Yes, the config support for kestrel is getting pulled for 2.0.

Reverted the original change instead https://github.com/aspnet/KestrelHttpServer/issues/1875


Remove duplicate calls to URI.toString()

@nicksnyder,
Thanks for having already signing the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks


Improve the inspector plugin documentation and remove a confusing statement

Partially address https://github.com/godotengine/godot-docs/issues/5144. I've also added a link to the appropriate tutorial and touched up some other descriptions in the related classes.

Thanks!


SBOM updated on dev instead of main branche (protected)

:tada: This PR is included in version 1.4.0 :tada:
The release is available on:

GitHub release
v1.4.0

Your semantic-release bot :package::rocket:


Item start time occasionally incorrect in the Show Manager

In the Show Manager of QLC+ (10.10.2a), when you have a sequence and open the "Item start time and duration" dialog, the leading zeros are trimmed, making the time incorrect if the millisecond is less than .1 seconds. For example (see below), if the start time is 49.08 second, it actually displays 49.8 seconds.

10.10.2a doesn't exist. You meant 4.10.2a
4.10.2a is not the latest build. Please use 4.10.2b
I am aware there are still cases of failure in the time display.
Can you please indicate the exact steps from an empty project to quickly reproduce the issue.
Or share an existing workspace...which can't be attached on GitHub. That's why I always suggest to use the forum first and then in case we move here.

Yes, the version was a typo. 4.10.2a is the version I'm runnning. I have a production this weekend, after which I'll update and try to reproduce the issue and post in the forum for further discussion.

@mcallegari While I'm at it, are you OK with changing the precision down to 1ms instead of 10ms ?

From the UI perspective it would make sense, but keep in mind that the engine (granularity is 20ms)[https://github.com/mcallegari/qlcplus/blob/master/engine/src/mastertimer.cpp#L45], so all the time values less than 20ms will be rounded (or ignored) at some point in the Function::write methods.
It makes sense instead in both areas when using a BPM based system (which I intend to implement later this year).
In conclusion, let's get rid of this "centisecond" measurement, but be prepared to reply to questions in the forum like "342ms are actually 340ms"

The engine tick happens every 20ms yes.
This is not an issue, and having a precision down to the ms will improve things for things running for a long time.

In conclusion, let's get rid of this "centisecond" measurement, but be prepared to reply to questions in the forum like "342ms are actually 340ms" (or even worse, 333ms turns into 320ms, or 340ms probably)

The issue would already be present: I can select duration of 30ms for a matrix.
This commit fixed the issue with a 30ms duration: f5b5b86fcb709f0073a8c16744bab1c1dcb8a463
The 4 first step changes should happen at:
30, 60, 90, 120
The step changes, without the commit, happened at:
40, 80, 120, 160
After the commit, they actually happen at:
40, 60, 100, 120
So 4 steps per 120ms.
The actual step change time is sometimes shifted, but in the long run, the time does not drift. That's what's important.
I don't know if I'm clear enough.

That's clear to me :wink:


Towards test coverage for xet cli.

This PR adds integration tests that hook up with CICD. The remote test repo and account is specified under the project settings/variables/actions.
Also fix https://github.com/xetdata/pyxet/issues/82 for handling Windows path

Thanks for refactoring all the path manipulation stuff!


is it possible to enforce at specific context of a HashMap at type level?

Hi
Thanks for this awesome library!
I'd like to ensure at type level that a HashMap passed as argument to a function was create using specific context with a custom eq function. Is this possible?

Thanks Adrian!
It is indeed possible to do what you want, if I understand it correctly. But it is not easy, because you need to create a new collection type in the same way it is done in other places in Rimbu. I'll present an example but I admit that it would be nice if this could be done in an easier way. The main limitation is that TypeScript does not support higher-kinded types in a natural way. Most of the code below consists of workarounds for this issue. Let me know if this helps.
import { RMapBase } from '@rimbu/collection-types/map-custom';
import { HashMap } from '@rimbu/hashed/map';

// Start ceremony to create custom map types
export interface MyHashMap<K, V> extends RMapBase<K, V, MyHashMap.Types> {}

export namespace MyHashMap {
  export type Context<UK> = RMapBase.Context<UK, MyHashMap.Types> &
    HashMap.Context<UK> & {
      // this is needed to ensure HashMap type is not assignable to this map type
      _PHANTOM_TAG: 'MY_HASH_MAP';
    };

  export interface NonEmpty<K, V>
    extends RMapBase.NonEmpty<K, V, MyHashMap.Types> {}

  export interface Builder<K, V>
    extends RMapBase.Builder<K, V, MyHashMap.Types> {}

  export interface Types extends RMapBase.Types {
    normal: MyHashMap<this['_K'], this['_V']>;
    nonEmpty: MyHashMap.NonEmpty<this['_K'], this['_V']>;
    context: MyHashMap.Context<this['_K']>;
    builder: MyHashMap.Builder<this['_K'], this['_V']>;
  }
}
// End ceremony

// Create constructors
const _defaultContext = HashMap.createContext({
  /* YOUR CONTEXT OPTIONS */
}) as unknown as MyHashMap.Context<any>;

export const MyHashMap = {
  ..._defaultContext,
  defaultContext<UK>(): MyHashMap.Context<UK> {
    return _defaultContext;
  },
};
// End create constructors

// END CUSTOM COLLECTION DEFINITION

// Examples of usage

const thisWorks = MyHashMap.of([1, 'a']).addEntry([2, 'b']);
// inferred type: MyHashMap.NonEmpty<number, string>

function onlyMyHashMap(map: MyHashMap<number, string>) {
  // this function only accepts MyHashMap
}

onlyMyHashMap(thisWorks);

// this gives a type error because the phantom tag is not in the HashMap type
onlyMyHashMap(HashMap.of([1, 'a']));

function normalHashMap(map: HashMap<number, string>) {
  // accepts both HashMap and MyHashMap
}

normalHashMap(thisWorks);
normalHashMap(HashMap.of([1, 'a']));


x509: certificate relies on legacy Common Name field, use SANs instead

latest reva complains:
2022-05-30 14:52:10.958 WRN ../../reva/internal/grpc/services/authprovider/authprovider.go:158 > error authenticating user error="authsvc: error in Authenticate: Post \"https://nc1.docker/index.php/apps/sciencemesh/~einstein/api/auth/Authenticate\": x509: certificate relies on legacy Common Name field, use SANs instead" pid=2954 pkg=rgrpc traceid=2cdb60435b81269ffb0e24747a0ca47f

It seems I'm already using the --addext from https://jfrog.com/knowledge-base/general-what-should-i-do-if-i-get-an-x509-certificate-relies-on-legacy-common-name-field-error/ yet apparently it's not setting the subjectAltName in the cert, and the workaround there doesn't help.

Assuming that it's something that needs to go into the csr command.

See also https://security.stackexchange.com/a/183973/264910
to be continued :)

Fixed thanks to https://www.golinuxcloud.com/openssl-generate-csr-create-san-certificate/


refactor: test model names to be PascalCase

Closes https://github.com/ButterCMS/buttercms-csharp/pull/22
Closes https://github.com/ButterCMS/buttercms-csharp/issues/21

This is PascalCase, not snake_case, tho. Please fix the commit message and PR's title (refactor: test model names to be PascalCase). Apart from that, the PR LGTM.

Crap... fixed


Added Universidad Ricardo Palma

Universidad Ricardo Palma changed its domain from @urp.edu.pe to @urp.pe

@jeancedron unfortunately the website urp.pe doesn't open. Could you please somehow prove it's alive and belongs to the university?

@zweizwei There's a problem with my University. It used to have @urp.edu.pe as domain in its email, but now it has changed to @urp.pe. You can get into this link: http://www.urp.edu.pe/correolive/index.php?urp=informacion and see that there's a migration of emails. Also, to get into the inbox of @urp.pe, we have to go to https://www.outlook.com/urp.pe. The domain for the website it's still the same www.urp.edu.pe but the domain is not.

Also, you can see in this image who is the registrator and the administrator of urp.pe domain.

Source: www.whois.com

@jeancedron thank you for the explanation, I'm adding the domain


xrCreateSession returns XR_ERROR_VALIDATION_FAILURE, but validation layer gives no information

    XrGraphicsBindingOpenGLWin32KHR binding = { XR_TYPE_GRAPHICS_BINDING_OPENGL_WIN32_KHR, NULL, wglGetCurrentDC(), wglGetCurrentContext() };
    XrSessionCreateInfo sessionCreateInfo = { XR_TYPE_SESSION_CREATE_INFO, &binding, 0, systemId};
    XrSession xrSession;
    XrResult result = xrCreateSession(context.xrInstance, &sessionCreateInfo, &xrSession);

Is returning XR_ERROR_VALIDATION_FAILURE. However, in spite of the validation layer being enabled and seemingly working correctly if I introduce errors into other openXR functions, no information is output by the layer on what exactly is being done wrong.

After extensive tinkering I've finally found the solution: I wasn't properly calling xrGetOpenGLGraphicsRequirementsKHR before session creation. However, the lack of information from the validation layer remains an issue, as well as the fact that no mention of this requriement exists in the specification for the graphics binding or session creation; the requirement is only listed in the specification for the offending function itself.

What runtime was this? We added an error code specifically for that (XR_ERROR_GRAPHICS_REQUIREMENTS_CALL_MISSING) quite a while ago to help fix this problem.
The docs here do mention that error in the part that would get extracted to the ref pages. (between the parameters and the implicit valid usage, second paragraph) but that part doesn't explicitly list the functions, just the function name pattern. I see that the application must: part (with the list of explicit function names) does appear above the function, where it won't be seen in the ref page, was this the problem you hit? https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#session-creation (See second sentence of second paragraph).

I was experiencing the issue on SteamVR for windows.


[zh] Fix link for debian-base

[zh] Fix link for debian-base
en PR: https://github.com/kubernetes/website/pull/29068

Thanks.
/lgtm
/approve


Design Feedback Profile (M)

Profile:

[x] Avatar Widget is clickable
[x] Remove "Weekday" from Avatar Widget
[ ] Contributions & Assignments for other peoples profile: "Add View Proposal" Button
[x] Add "see more" Button to "Recent Votes" Widget
[x] Add more spacing in between lines of Wallet Widget
[x] Wallet make Amount Bold

Design:
to be done

@pugakn here are the designs for the "view proposal button" for other members profile
https://xd.adobe.com/view/2e6dc275-76dc-4722-a922-cc60c5d7d653-7b3e/screen/4b9e65b4-2ffd-4aac-b615-2c2c0916ff78


Deprecate bower and src/frontend/vendor

WIP
Need to wait for https://github.com/JedWatson/classnames/issues/40 fixed

@EragonJ yo.
Issue of classnames is not a function is fixed after downgrading classnames to 2.1.2. It's time to take a look at this PR.

@rickychien just noticed that if we remove baseUrl, gulp build will fail QQQQ ~~ why we have to remove that in this patch !? (Forgot to ask this part when I did the review, sorrry xD)

Oops! forgot to test this patch with gulp build is my mistake. I'll fix it tonight.


Allow the creation of databricks connections with service accounts

The current API doesn't allow creating adapters (required for databricks connections) authenticated as a service account and requires being authenticated as a user.
The code of the provider is handling this and raising an error if a user tries to create an adapter with a service token but we should revisit this once the API endpoint logic has been updated on the dbt Cloud side.

Quick update that this is being worked on the dbt Cloud side and could be unblocked soon.


[V1] Simpify vision block hash for prefix caching by removing offset from hash

Reuse the example in https://github.com/vllm-project/vllm/pull/11187
Taking a series of 3 blocks as an example: T0,T1,P00,P01 | P02,P03,P04,T2 | T3,P10,P11,P12, where Ti is i-th text token and Pxy is the y-th placeholder token of the x-th image, so this prompt has 2 images (P0 and P1). Assuming the image hash of P0 and P1 is aaa and bbb, respectively, and mm_positions=[(offset=2, length=5), (offset=9, length=3)], the hash of 3 blocks in https://github.com/vllm-project/vllm/pull/11187 is as follows
# (Parent hash,
#  token ID w. placeholders,
#  image hash, start)
hash0 = hash(None, T0,T1,P00,P01, (aaa,0))
hash1 = hash(hash0, P02,P03,P04,T2, (aaa,2))
hash2 = hash(hash1, T3,P10,P11,P12, (bbb,0))

But offset is redundant and the following hash format is enough:
# (Parent hash,
#  token ID w. placeholders,
#  image hash)
hash0 = hash(None, T0,T1,P00,P01, aaa)
hash1 = hash(hash0, P02,P03,P04,T2, aaa)
hash2 = hash(hash1, T3,P10,P11,P12, bbb)

Simple proof:
We need to distinguish the above example with the following cases:

The same image but different offset, e.g., T0,T1,T2,P00 | P01,P02,P03,P04 | T3,P10,P11,P12. The hash0 becomes hash(None, T0,T1, T2,P00, aaa), which is different
The same offset but different image, e.g.,  T0,T1,P20,P21 | P22,P23,P24,T2 | T3,P10,P11,P12. The hash0 becomes hash(None, T0,T1,P20,P21, ccc), which is different

This hash format has almost the same speed as previous one, but can avoid the confusion about why we need to add offset to the hash.
Benchmark result on H100 with the script in https://github.com/vllm-project/vllm/pull/11187: https://gist.github.com/comaniac/ea26df17fdffa533cf53d53b8455bc31 I ran 3 times for each commit
VLLM_USE_V1=1 VLLM_ENABLE_V1_MULTIPROCESSING=1 python3 mmmu_bench.py --model llava-hf/llava-v1.6-mistral-7b-hf --num-prompts 500  --image-hit-rate 0.3
Without this pr:
Throughput: 15.84 req/s
Throughput: 16.09 req/s
Throughput: 16.00 req/s

With this pr:
Throughput: 16.11 req/s
Throughput: 15.94 req/s
Throughput: 15.84 req/s

Note that the following format that only adds the image hash to the first block of this image is also correct, but is a little slower (15.50 reqs/s). The code is here https://github.com/vllm-project/vllm/commit/539e84c58f8ac08d8764573f402057e58ca6d7d2
# (Parent hash,
#  token ID w. placeholders,
#  image hash)
hash0 = hash(None, T0,T1,P00,P01, aaa)
hash1 = hash(hash0, P02,P03,P04,T2, )
hash2 = hash(hash1, T3,P10,P11,P12, bbb)

I guess we previously overlooked the fact that the offset information can be already inferred from the token sequence and the hash of the previous block. Thanks for this simplification!


Ease development of server-side viewer panels

Changes:

Added developer reference docs generated from derived state's property descriptions
New module ext that deals solely with the server-side contributions
Introduced new derived state for server-side contributions
Updated the demo panel "2D Histogram", it is still lacking some useful features like showing progress, disablement, and some info text

To verify

make sure dev reference works: extensions and derived state is documented
make sure the demo panels work, please leave comments with possible enhancements or ideas for other panels

See https://github.com/xcube-dev/xcube/pull/1092

As requested, here are some ideas for enhancements

Thanks! Once we have a new release, let's please add those as a feature request.

@forman done, see #452


Add Dark Mode Support

Fixes Issue
Closes #1838

Changes proposed

Added Dark Mode Support in Tailwind Config File
Installed next-themes package which enables us to change to dark mode programmatically
Added Dark Mode Toggle Button
Fixed Text that weren't changing on switching

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

I found that the menu button for mobile-view doesn't work, should I create a new issue and PR for it?

How can I fix this? I
would also be open to suggestions on my work

Sorry @Keshraf for my slow reply, I will take a look today

I found that the menu button for mobile-view doesn't work, should I create a new issue and PR for it?

I just saw your comment @Keshraf, it would be better to fix it in this PR

Okay @eddiejaoude, I will fix it in this PR 👍

Sorry @Keshraf I just realised we might be talking about different menu buttons. Are you talking about the light/dark mode or the "hamburger" one? If for the existing button that is not required for this PR, sorry I assumed you meant for your new button
Please clarify and we can hopefully get this merged soon, thanks 👍

I was talking about the "hamburger menu" button. Should I add it to this PR?

Yes please, if you can add it to this PR as it is related to the changes here 👍
Sorry you have some conflicts to resolve now because other PRs have been merged in


Update ESLint configuration

Update to Apache ECharts 5.4.3
Update to Grafana 10.0.2
Remove Grafana 8.5 support
Update ESLint configuration

Codecov Report
Patch and project coverage have no change.

Comparison is base (208c34b) 92.23% compared to head (9f5a644) 92.23%.

:exclamation: Current head 9f5a644 differs from pull request most recent head 82bc640. Consider uploading reports for the commit 82bc640 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #9   +/-   ##
=======================================
  Coverage   92.23%   92.23%
=======================================
  Files          14       14
  Lines         103      103
  Branches       11       11
=======================================
  Hits           95       95
  Misses          6        6
  Partials        2        2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Extend Interface: misleading error message

TypeScript Version:
1.8.10
Code
export interface MyInterface {
  foo(): void;
}

export class MyImplementation extends MyInterface {
  public foo(): void {
    console.log("foo!");
  }
}

Expected behavior:
Error TSXXXX: Cannot 'extend' interface. Use 'implements' instead.
Actual behavior:
Error TS2304: Cannot find name 'MyInterface'.

Yeah, this message is very annoying.

Is this up for grabs? If yes, I would like to fix this

Go for it @schultyy! Keep us posted!

I started to dive into the codebase and probably found the place where the current error message is used: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L7381
But I'm not sure completely sure where to make the change to use the new error instead. Can you give me a hint?

Edit diagnosticMessages.json and run jake generate-diagnostics to regenerate the diagnostic message types.

@schultyy I also have a try to add this new error report. You can take a look on it. I'm also new to tsc. So just take it as reference.


Ability to edit user profile picture from Site Admin section

Gitea version (or commit ref): 1.15.0
Operating system: Docker

Description

...
I didn't find this issue so I'm opening one.
At our company users are logging in through LDAP. But there is no picture loaded and I, as root/admin, can't edit profile picture of those people which refuse to upload it themselves. Or upload something improper...
As I can edit their names, mail, etc... I would like to edit their profile picture.
Edit: Found a gogs issue: https://github.com/gogs/gogs/issues/3324

Closing as this feature has been implemented in #17661 and from manually testing on my latest main branch (840ad7eefe2b49ab453b9a89b153a264a8c9f8a2) I am able change user avatars as an admin.