#emc-devel | Logs for 2007-03-16

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