Possible issue with LinearCmd

[AaxAisa]

I'm testing this with Kiiroo Keyon.
My idea is to have the down stroke a different speed than the up stroke.

Here's the code snippet that runs on a loop:

        // calculate position - this one simply switches between 1.0 and 0.0
        double position = calculatePosition();

        // calculate duration - This selects a position randomly within range but also keeps in mind the slow-fast-slow-fast rule 
        int duration = durations.get(durationIndex).value();
        previousPosition = position;

        // do stroke
        System.err.println(duration);
        GlobalSettings.device.sendLinearCmd(position,duration);
        Thread.sleep(duration);

The device does the strokes just like it should, without missing a beat. Up-down-up-down.
So there's no doubt that each sendLinearCmd goes through as intended and is received and processed by the device.

There is also no doubt that the duration alternates between fast and slow. Here's the output snippet:

2023-08-17 19:31:22.920 18502-19063 System.err              com.gir.keyoncommander               W  0.0   277
2023-08-17 19:31:23.206 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1155
2023-08-17 19:31:24.371 18502-19063 System.err              com.gir.keyoncommander               W  0.0   281
2023-08-17 19:31:24.660 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1159
2023-08-17 19:31:25.825 18502-19063 System.err              com.gir.keyoncommander               W  0.0   285
2023-08-17 19:31:26.118 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1163
2023-08-17 19:31:27.289 18502-19063 System.err              com.gir.keyoncommander               W  0.0   289
2023-08-17 19:31:27.587 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1163
2023-08-17 19:31:28.759 18502-19063 System.err              com.gir.keyoncommander               W  0.0   289
2023-08-17 19:31:29.053 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1168
2023-08-17 19:31:30.230 18502-19063 System.err              com.gir.keyoncommander               W  0.0   294
2023-08-17 19:31:30.531 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1174
2023-08-17 19:31:31.710 18502-19063 System.err              com.gir.keyoncommander               W  0.0   300
2023-08-17 19:31:32.016 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1174
2023-08-17 19:31:33.197 18502-19063 System.err              com.gir.keyoncommander               W  0.0   300
2023-08-17 19:31:33.502 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1172
2023-08-17 19:31:34.683 18502-19063 System.err              com.gir.keyoncommander               W  0.0   298
2023-08-17 19:31:34.988 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1170
2023-08-17 19:31:36.168 18502-19063 System.err              com.gir.keyoncommander               W  0.0   296
2023-08-17 19:31:36.473 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1168
2023-08-17 19:31:37.650 18502-19063 System.err              com.gir.keyoncommander               W  0.0   294
2023-08-17 19:31:37.955 18502-19063 System.err              com.gir.keyoncommander               W  1.0   1166

Also, the minimum duration that my Keyon can sustain is 260 milliseconds, for what it's worth.

What I observe:
Most of the time, the device does what it should. Slow up stroke, fast down stroke.
But sometimes the up stroke is also fast. There is no instance when the issue is reversed (i.e. slow downstroke).

Speculation:

1. Since we know the signal is reaching the device and carries the correct data, perhaps the device itself is not able to switch the speed this fast. In that case, this is not an intiface bug, because there's nothing you can do, really.
2. Perhaps the position and duration are internally sent as separate packets. The position is received first, and the device starts moving before the new duration arrives, using the duration from the previous iteration. This is possible, because I observe a slight delay on the longest stroke setting, in other words you tell the device to reach position over 1000 ms, and the program waits for 1000 ms, but the device actually reaches destination in 900 ms, and is motionless for 100 ms. This delay on the long stroke may explain why it has extra few ms to receive the data.
3. Speculation 3 (Also device internal): I tell it to wait for 300 ms and send another command 300 ms later. But it actually takes 320 ms to reach the destination, so the piston is slower than expected. When the device receives the new command while still moving - it accepts the next Position, but discards the speed change and just executes the new position with the same speed as soon as it can.

p.s. adding an additional forced 50 ms delay after the fast stroke seems to be enough to fix the issue.

This is super low prio, just posting as something worth keeping an eye on, perhaps?

[blackspherefollower]

This might be a bug in the Keon that came from the Launch: if a new vector arrives whilst the device is in motion, the speed was not updated, just the target destination