Some of us have been playing around with using the Speed multipler and a question came up if it was working properly, so I wrote a quick and dirty program that allowed me to enter a sequence number and a multiplier and it ran the sequence until we thought it was done. The code did a QPL0 command to see the status and when it detected that a new step started I did a toggle of an IO pin, which I connected a Logic Analyzer to. In addition to this, I used a hardware timer (TimerA on Bap28) to time this. The timings I printed out appeared to match the timings I saw with the logic Analyzer.
Here is an extract of the timings I saw.
SSC Ver: SSC32-V2.06Alpha1B-EGP
Enter sequence Number:1
ÂSpeed multiply -200 to 200: 100
Sequence took: 7471
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 100
Sequence took: 7471
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 128
Sequence took: 5505
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 128
Sequence took: 5505
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 150
Sequence took: 5505
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 150
Sequence took: 5373
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 200
Sequence took: 5373
Enter sequence Number: 1
ÂSpeed multiply -200 to 200: 200
Sequence took: 5505
The timings are in ms.
Kurt
P.S. - Please note the program is a real quick and dirty… testgptimings.bas (3.73 KB)
I’m afraid you might have found another bug. I’m on a roll I guess.
At first I thought this might be related to the max speed settings in the sequence, which would cause the playback speed to max out. (The GP sequencer follows the same rules as group moves, so if any servo reaches its max speed, then all servos are slowed down so they end together.)
But it looks like it is a simple typo that has gone unnoticed until now. The qualification code for the speed multiplier looks like this:
// Store the unsigned value, limited to 200
if ( cmd_arg_int > 100 )
{
cmd_wks . pl_cmd . speed = 200 ;
}
else
{
cmd_wks . pl_cmd . speed = cmd_arg_int ;
}
This code is supposed to clip the magnitude of the input value to 200, but should pass any value less than 200 unchanged. But instead of comparing with 200, it compares with 100. Then, if the value is greater than 100, it forces it to 200. I would expect that if you go from 100% to 101%, the speed will suddenly double. Not good. I’ll do a test to verify this, and will release new firmware if it turns out to be as I expect. Sorry.
We all (Xan, Kurt and me) did some testing around this issue.
I didn’t thought of testing 101 either. I assumed 128 gave the max value.
Actually, it was Xan that first found this bug 3 days ago.
I just updated my SSC with the latest firmware version. I could be wrong but the GP player doesn’t beheave as I expect it to do. But I could be wrong as well.
I’m using Zenta’s latest video as a reference. As far as I know (so Zenta, please correct me if I’m wrong) this is one of the sequences located in the PEP. I’ve got this same sequence loaded in my phoenix for the test. But my phoenix is a lot slower then shown in the video. Saidly enough I don’t see any visual difference between the 100 or 200 value.
So I did some testing with Kurts “Quick and Dirty but Effective” test program
Here are the results:
SSC Ver: SSC32-V2.07Alpha1A-EGP
Enter sequence Number: 0
Enter ÂSpeed multiply -200 to 200: 100
Sequence took: 19005
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 50
Sequence took: 20840
Enter sequence Number: 0
Enter ÂSpeed multiply -200 to 200: 200
Sequence took: 18612
I started with a speed of 100. Playing the sequence on normal speed takes 19 seconds.
With the speed of 0 the sequence stops. So entering a number of 50 should slow down the sequence to halve the speed which should result in 38 seconds? But instead it takes just 20.8 sec?
If I double the speed to 200 the sequence should only take 9.5 sec. But it took 18.5 seconds.
The difference between 100 and 200 is .5 sec and results in a speed of 102.6%…
Zenta, Did you try this firmware?
Do some of you have an idea what is going on here?
I solved it by adding a little pause between the serin/serout.
These are my findings for the sequence I think Xan are referring to:
SSC Ver: SSC32-V2.07Alpha1A-EGP
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 50
Sequence took: 16252
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 80
Sequence took: 10485
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 100
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 101
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 110
Sequence took: 8519
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 120
Sequence took: 7864
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 150
Sequence took: 7340
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 200
Sequence took: 6815
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 128
Sequence took: 7602
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 105
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 100
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 115
Sequence took: 7864
Enter sequence Number:
I ran the test program while the hex actually did the sequence. FYI, in seq 0 (Flip box) one step length at SM=100 is 160 mS for step 1 to 14 and 35 to 47, for step 15 to 34 the speed is 200 mS. Using Excel to summary this gives the total value of 8320 mS for the complete sequence. So buy looking at the values from Kurt’s test program these values are not very far from each other at SM=100 8388 vs 8320 mS.
When increasing the speed I could clearly see a visible difference on the robot too. Looking at the values SM=200 don’t give double speed than 100, but its much more than what Xan find. I’ve no idea of why. Do we use the same sequence?
Anyway, as far as I can see the GP player seem to work acceptable between 0 - 100. But can Mike answer what the SM (speed multiplier) really is? The result does not seem to be linear.
And there are something strange above 100, look at the readings at 110, is it suddenly slower than at 100. But I didn’t notice this difference when watching the robot though. A little confusing…
We already discussed this in the chat but it’s good to have some things central.
Anyway, Thanks for checking this out. Your findings between 0 and 100 are much better then mine. I will see if I can find the PEP with the original sequences to see if we’ve got the same source. I can also reprogram the EEPROM to see if this will make any difference. I’ll let you know as soon as I find something!
I emailed Mike about this so hopefully he will be able to look at it soon. Another test I would like to do is to copy a sequence, half the times and see how long it takes, or if someone beats me to it that would be great. Mike pointed out to me earlier that we could be running into max servo speed issues.
The adjusted move time (AMT) is calculated as AMT = MT * SM / 100.
The AMT is prorated based on the current position of the servos. This is intended to make the move time reasonable when a sequence is first started, and should not affect subsequent moves once a sequence is playing.
The GP sequencer calls the same function that is used for normal group moves to start the servos moving. Servo numbers, pulse widths, and speeds (#, P, and S parameters) are taken directly from the sequence. The time (T) parameter is the AMT previously calculated.
The 4 steps above actually turn into a fairly long and complex bit of code, but that is the gist of it.
I hate to ask, but do the PO values for the servos make any difference in the move times for this issue?
Thanks for explaining this mike.
SM values from 0 to 100 seem to confirm the formula. But above 100 there are something strange going on and the result does not match the formula.
It would be interesting if there was a way to read the actual AMT value, or… hey the QPL command return the 4. byte
The remaining time in the step, 100ms per bit (e.g. if there are 700ms remaining, the value will be 7)
Ok, this resolution isn’t good enough for testing this.
I’ve not tried this after your last firmware update. Is there a fast way to backup and restore the PO values? It take some time to re-enter the PO values in LynxTerm.
From Lynxterm, you can temporarily zero out selected pulse offsets without changing the register values.
“#0PO0”
“#1PO0”
etc.
The new values will be used until the SSC-32 is power cycled, at which time the values from the registers would be reloaded. Maybe this process could be put into a macro.
I am playing around with my VB app, and can enter a multiply in percentage into a dialog and change the times. So with normal run I have:
Enter sequence Number: 1
Enter Speed multiply -200 to 200: 100
Sequence took: 7471
Enter sequence Number: 1
Enter Speed multiply -200 to 200: 150
Sequence took: 5898
Enter sequence Number: 1
Enter Speed multiply -200 to 200: 200
Sequence took: 5505
Enter sequence Number:
When I ran my program and told it to half the times, which should be equivalent to running at value 200, I get:
SSC Ver: SSC32-V2.07Alpha1A-EGP
Enter sequence Number: 1
Enter Speed multiply -200 to 200: 100
Sequence took: 3014
Enter sequence Number:
So I am not sure what is going on…
I have uploaded a zip file with a couple of sequences in it and also the same ones that had the step times cut in half…
Kurt
P.S. - Zenta, I also changed my program to pause a bit such that the echoed characters are lost… Seqs.zip (19.3 KB)
No, i can’t say it did any big changes by removing the PO values:
SSC Ver: SSC32-V2.07Alpha1A-EGP
ALL PO Disabled
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 110
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 128
Sequence took: 7733
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 50
Sequence took: 16384
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 100
Sequence took: 8388
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 200
Sequence took: 6815
Enter sequence Number: 0
Enter Speed multiply -200 to 200: 150
Sequence took: 7208
Hi Kurt,
Well, that certainly prove that SM=200 won’t double the speed.
I double checked it again and now I am not so sure
I used sequence 1 instead of 0, which is defined with all times are 90 and there are 44 steps so expect about: 3960.
Timing at 100 is: 4456
Timing at 200 is: 3014
At 100, most of the detected changes from step to step were about 100ms, at 200 most were at 60 but several were around 80
So then I reloaded the double time, which had all of the steps defined as 45, so in theory we would expect: 44*45: 1980
Timing at 100 was: 3014, at 200 was: 2752 at 50 was: 4456
So this appears to be consistent with original.
As I mentioned with original at 200, some steps were 60 but some measured 80. If I look at those steps, I believe there are some servos with a delta over 200. So the question is what is the largest deltas that Seq will allow servos to change per 20ms servo cycle?
the QPL command return the 4. byte 