murphy lives - the kernel doesn't support insmod params of type char
I was hoping to do "loadrt stepgen step_type=0,0,1,0 ctrl_type=p,p,v,p"
to specify position and velocity mode step generators
(velocity mode replaces freqgen)
I guess I could use an array of strings
but I bet that involves quoting on the command line
jmkasunich: I don't see why ctrl_type=p,p,v,p wouldn't work if ctrl_type was an array of strings
I'm giving it a try
it only works if the parsing code in the kernel treats , as an array separator and not just another char in a string
you used arrays of strings for sampler and streamer, and documented them with commas as separators
dunno whether it works that way :-P
it seems like it does
halcmd: loadrt stepgen step_type=0,0,0,0 ctrl_type=foo,bar,blat
Mar 15 20:51:26 ke-main-1006 kernel: [1781883.240484] ctrl_type = 'foo'
Mar 15 20:51:26 ke-main-1006 kernel: [1781883.240493] ctrl_type = 'bar'
Mar 15 20:51:26 ke-main-1006 kernel: [1781883.240496] ctrl_type = 'blat'
Mar 15 20:51:26 ke-main-1006 kernel: [1781883.240499] ctrl_type = 'p'
(I inited the array with "p"
SWPadnos_ is now known as SWPadnos
do you guys understand the stepgen regression test differences and can we say the new behavior is right?
* jmkasunich blushes
I haven't been running regression tests
* rayh runs for cover.
they would have failed anyway
unsurprisingly, stepgen output is different... I don't know how different
because the "gold standard" was defined by the old stepgen
right - the stated goal was to change the output because I saw output that was incorrect
jmkasunich: I wasn't until recently, but I'm really happy to have interpreter (cutter comp) tests
the problem with regression for stepgen is getting a suitable gold standard
that's always the problem
it gives one step less than the old one did
you have to somehow convince yourself "it looks sane today"
oh that's what the 600 lines of diff mean?
in addition to stepping at different times of course
stepgen.2 (I think) is a test that counts the number of steps issued, I had hoped it would be more robust :-P
even after changing it so all the numbers were exact as floating point it's still 1 step less in the new stepgen
I suppose I should look at that test
is it ok to have all the stepgen functions on the same thread?
test $COUNT -eq 1280
hmm, 32000*.04 is not 1279 is it
.04 is inexact though
oh I see what you mean
I think with this change, everything is exact as a float, but it's still one step too few: http://pastebin.ca/396806
er .. 1280, not 1280.1
with 1280.1 it does 1280 counts
the initial position is 0.0 steps
the final position is 1280.0 steps
a step is emitted every time it crosses x.0
* jmkasunich babbles because he doesn't know what is happening
after running the test (manually) I set the position command back to 0.0
and the final value for position feedback was 2.264045e-9
0.0000724 steps off
did it issue the same number of steps to get back there?
stepgen's position value is the result of adding a valut to a register many many times, so the final value may not be hit exactly
cradek: I wasn't counting
it was, and it says yes
(the count variable agrees that 1279 steps were issued the when going to 0.04
since a step is issued when the bit changes, going to 1280.0 will not take the last step, but 1280.000000000001 will
can a simple tweak (adding half a step somewhere initially) make it always settle on the nearest step position?
I'd have to add the half step every time I read the accumulator
I dunno -- will going to -1280 behave the same way?
or rather, add it initially, and then subtract it every time I read the accum
-0.04 => -1280 0.04 => 1279
interestingly, there seems to be some hystersis
o->+0.04->0 returns to zero counts
0->-0.04->0 returns to -1 counts
I probably should put a half-step offset in there
Is this anything like the problem with percent complete on a spreadsheet?
numbers never sum to 100%, you mean?
Right and you always must go back to the starting value?
rather than adding the current percent to the last one.
I think it's in that class of problems, but not due to successive addition
the output is an internal (integer) count * some scale value
not the repetetive summation of the scale value into a float accumulator
its due to the transition from one step to the next being at 0, 1, 2, 3, instead of 0.5, 1.5, 2.5, 3.5
jmkasunich: doesn't 1279.9999 -> 1280.0000 change the value of the bit you're looking at?
I thought it was changes in the ones bit, and that's a change..
its a change in the ones bit of the accumulator
interestingly, a 32-bit stepgen (or encoder) accumulator can't be fully represented with a float, even under ideal conditions
but its possible that the position control loop begins commanding zero velocity when the position feedback is at 1279.9999999999
SWPadnos: actually, the accumulator is 64 bits, split as 36.28
and the internal position loop uses doubles
well, anything beyond 24 isn't useful in a float output
but the hal pins (both cmd and feedback) are floats
and even 24 is only useful to a point, depending on the scale value
that type of round-off error could actually cause problems for regression tests
I suspect that use of a power-of-2 scale could help
the 24 bit resolution of HAL analog signals is a sore point for me
(like 1/1024 or 1/4096)
I'd like to make them doubles someday
setp stepgen.0.maxvel 8192
setp stepgen.0.maxaccel 65536
setp stepgen.0.position-cmd 1024
setp stepgen.0.enable 1
setp stepgen.0.position-scale 1
with everything power-of-two it still goes one step less than desired
it was the scale I was thinking of
perhaps I should reboot into my Ubuntu install. bbiab
(at least it looks that way..)
how do you run the test? (and do the tests work with realtime?)
the setexact thing doesn't fill me with confidence
if you want to run just one test, change to that directory and "runtests"
otherwise, run "runtests" from the top emc2 or tests directory
that'll run them all
I'm getting multiple failures
things like abs are failing
but stepgen.2 passed ;-)
hooray for the little things
I thought abs only failed on 64-bit systems
it is producing correct output - out = abs in
yeah -- but the numbers don't quite match...
abs works for me
but the input isn't the exact same sequence as expected
how does abs get its input numbers -- I forget. freqgen?
maybe all the tests I wrote suck
@@ -223,3 +223,3 @@
those are the only errors for abs
they unintentonally test too many things
like the exact behavior of sin() or printf()
are the errors in the 6th decimal place because of output formatting?
I'd expect a float to have a place or two more precision - that's why I ask
SWPadnos: the compare is being done on the string, so print rounding sets the accuracy
right -- but if the calculations have 24 bits precision, why are they different at around bit 20?
ok, somebody update and run the stepgen tests on a sim box
jepler: they're not
one value ias probably 0.81000148, and the other was 0.81000151
printing rounded them
I bet it the printing was done to 8 digits, there'd be a lot more mismatches
* jepler waits and waits for 'cvs up'
the advantage of string compares is that they're type-neutral. unfortunately, that also means they're type-stupid :(
jepler: isn't it on your local network?
hmmm. I should probably wait until the system update finishex before trying to recompile. I think there was a compiler in the list of upgrades
jmkasunich: it's still really slow right now
ok, so it's not just me
this hotel has a nice connection speed at this time of night - I got ~350kB/sec downloading updates
on the road again, eh?
just for fun, in my case - my wife has a conference tomorrow (and a birthday the day after tomorrow :) )
poor cvs server...
heh - poor DSL line :)
5 minutes and counting on 'cvs up'
wonder if something went wrong
nope, it's still going
ping time 120mS
ok - it just started going again
had been hung for a bit
hmm, something is borked tho
the farm's update attempt failed
(after 4 retrys)
is there a timeout?
it's swapping pretty bad, just be patient
and the log file indicates that is what happened
I bet the other farm slots are/were hitting it too
6 anon cvs plus a few of us, all at once
need a bigger machine (at least more ram)
it's a laptop though, right?
wow, that must have been a much awaited fix ;-)
yes it might be maxed
there mine finished
I gave up and stopped mine
* jepler starts it again
synaptic's still chugging along though
farm is currently trying to update the 2.0 tree
stepgen.1 fails, stepgen.2 succeeds
is one looking for exact step timings? or just correct results?
.0 and .1 are looking for exact step timings
then they are most likely gonna fail
I'd say they're both bad tests, except that .1 completely failing to run was what tipped me off to quadrature output being broken
that was a "duh, is my face red" mistake
thanks for catching it
(and fixing it)
the one jepler fixed,or the one I just fixed?
jepler's is already
yours - jepler did his
I'll do it
jeez - I'm off by half a step, and they never give me any peace.....
now the errors would show up if the stepgen thread runs long enough for that half step to show up ...
the timing of the steps will be pushed toward the middle of the period instead at the end
so although the likelihood of an error at the end of a move is lower, the probablility of one in the middle is higher
and it'll depend on the exact time that RTAI assigns to the BASE_PERIOD
I must be thick tonight
I have no idea what you are talking about
me, me :)
I could be totally wrong - I'm not able to see the commit diffs right now (without significant web browsing effort)
[02:28:30] <cradek> http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/stepgen.c.diff?r1=1.51;r2=1.52
all I do is add one-half step to the initial accum, and subtract it when I read the accum in capture_position and update_freq
it's an offset to the time that the step is generated
so they're 1/2 step "earlier" than the were
they, not the
or later, depending on how you look at it
but IMO, they are now happening at the right time
since the accumulator is preloaded, I see the step as occuring earlier in time than before
when the reported position passes the half-way point between two integral step positions, it outputs a step
SWPadnos: yes, the timing changed from before
but before was wrong
oooh - the compile finished
if you were at 0.000, and commanded -0.001 (steps) you would get one negative step before, right away
now, you don't get a negative step until you reach -0.5 steps
right - we had discussed some biasing before
when Ed first brought up his problem, I think
compile farm thrashes the cvs server once again....
0 and 1 fail for me, 2 passes
these tests are now "actual thread timing" sensitive
before, the step timings were in units of "thread periods"
thats what "exact" mode is all about
RTAPI lies and says the periods are exactly what was requested, not what the RTOS could supply
hmmm - ok
I think the lies are at the HAL level, not RTAPI
well, somebody's telling fibs anyway
[02:38:25] <SWPadnos> http://pastebin.ca/396907
that's what I get for , 1, and 2
maybe I should update again - there could have been a CVS problem
I just changed 1 so I expect it to pass now
I'm not surprised 0 continues to fail
hard to type on the laptop (quieter) keyboard
maybe .0 should just be ditched
or alternately, it should be updated with: mv result expected; cvs commit
so - that new checkresult makes sure no wild non-gray code gets output, but doesn't check the timing
(it doesn't even check that the expected number of transitions are made)
I had hoped that after I made the infrastructure, smart people like jmkasunich would figure out what aspects of components made sense to test
hey - I think I could fix it so it did :)
did anything about 'encoder' change lately?
I don't think so
1252 313 313
-1253 313 313
-1254 313 313
+1253 314 314
+1254 314 314
1255 314 314
last change 2007/01/27
the columns are: x4 encoder counts, x1 encoder counts, counter counts
probably when I added the velocity output
I am surprised that the changes in x1 encoder counts are at different positions with respect to the x4 encoder counts
(the differences are actually greater than that, I squeezed repeated lines in 'result' and 'expected', then diffed the squeezed versions)
(because the quadrature input comes from stepgen, I think)
when does your "expected" file date from?
only change since then was the high-res velocity
but that entailed changes to the core counting routine
(it captures the time of each count, as well as the number of counts)
as usual, a big diff - I cleaned up stuff while I was in there
shame on me
I'll do some 'cvs up -D' tomorrow and see if I can figure out if that change is really what made the test start failing
there's only been the one commit to encoder.c
I thought a few days ago all the tests passed
in fact I'm nearly sure of it
well, if stepgen is being used as the input for encoder, a change to stepgen will change the results
oh ok, it is, duh
might be better to use sim_encoder for the test
that would be sensitive to changes in sim_encoder ...
nothing is perfect
but sim_encoder is less likely to be changed - its a much simpler thing than stepgen is
it also makes an index pulse, I doubt the existing test even attempts to test index
(I haven't looked at it)
ok -time for bed. see you later
we've all done that...
well, I've made some progress toward eliminating freqgen
I could stay up till 2 and finish it, or I could get some sleep
I think I'll be smart for a change
me too - goodnight
Guest674 is now known as skunkworks_
wow - to be that angry - for so long.
Isn't that the truth.
Dale's statement wasn't FUD
FUD is propoganda that's meant to keep people scared of an existing product while you work to develop one to compete with it
The little bit I echoed back did grate on me just a bit.
[12:21:58] <cradek> http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt
rayh: I think he meant his message (as a whole) as a compliment, but it was a poorly-worded one.
when I started using EMC, it had some serious bugs, and in the spirit of free software, I started fixing them - that's when paul invited me into the project
any software will have fewer serious bugs over time - unless people are really doing something wrong :-)
that makes sense ;)
that a piece of software used to have more bugs shouldn't be taken as an insult
that it used to be a POS and now it's not, well ... that's not very gracious, but it's saying the same thing maybe
so - I fiddled with the stepgen.1/checkresult script
it now counts the quadrature output and checks that the resulting count is 1280
I haven't figured out a way to make sure the timing is right though
is there a HAL "increment" block?
I don't think so
the new checkresult can easily count the number of samples the outputs stay the same, but I'm not sure how to get that output from HAL
bummer. maybe it makes sense to have an integer version of sum2
though the float may be OK since there should be no quantization errors in whole numbers
ok. I must be low on caffeine. the only way I'm coming up with for HAL to count the number of periods the outputs stay the same is to use a match8 fed by the quadrature outputs, and for each phase, a mux configured as a sample/hold, a sum2, and another mux as a sample/hold for the sum (so it can be reset when the outputs don't match)
if it sounds confusing, that's because it is :)
err - how do I get manual/pydoc help for "comp" (the component compiler, not the comparison HAL component)?
man comp gives info on the HAL component, pydoc comp gives an error ...
SWPadnos: at the moment, there's only the .pdf manual for comp
it's in the hal reference pdf
[14:00:22] <cradek> http://linuxcnc.org/docs/2.1/html/hal/comp/index.html
I just browsed the manual but didn't browse carefully enough :)
jepler: did you mean to make those extra changes? some lines were at least reordered
lerman_ is now known as lerman