Back
[00:21:46] <jmkasunich> jepler: around?
[01:02:12] <cradek> http://timeguy.com/cradek-files/emc/pict6434.jpg
[01:02:30] <cradek> oops, wrong picture
[01:02:40] <cradek> http://timeguy.com/cradek-files/emc/pict6436.jpg
[01:02:41] <cradek> better
[01:08:05] <jmkasunich> knobs
[01:08:39] <jmkasunich> only 6 after two days?
[01:08:46] <cradek> * cradek kicks jmkasunich
[01:08:52] <jmkasunich> thought you'd have about 60 by now
[01:08:54] <SWPadnos> single-point knurling?
[01:09:00] <cradek> SWPadnos: nope
[01:09:04] <jmkasunich> heh, how many people have asked that?
[01:09:06] <SWPadnos> cheater :)
[01:09:07] <cradek> knurling-tool knurling
[01:09:16] <jmkasunich> Al, right?
[01:09:25] <cradek> I made a video - not sure it's worth the trouble - can't see a whole lot.
[01:09:25] <cradek> yes
[01:09:39] <cradek> bored to .1975 for a press fit
[01:10:04] <jmkasunich> can you make a knob in one chucking? face, drill, bore, turn, knurl, part?
[01:10:33] <cradek> all except for cleaning up the top. the bottom shoulder is .4375 to fit another collet so the top of the knob can be faced.
[01:11:01] <cradek> but what you see in the photo is just how they come off the bar, one every time I hit 'run'
[01:11:04] <jmkasunich> so why didn't you make a few dozen while you were set up? it's not like they use a lot of expensive material
[01:11:22] <cradek> I'll make more before I undo it
[01:11:44] <jmkasunich> might I suggest that the boring step include a small chamfer on the hole entry?
[01:11:48] <jmkasunich> make it easier to press onto a shaft
[01:12:03] <cradek> yeah, good idea
[01:12:26] <cradek> but for these I'll just whirl the deburring tool once or twice.
[01:12:31] <jmkasunich> yeah
[01:13:03] <cradek> I'm nervous about the boring bar. it's very small - cutting .001 x .002 at a time
[01:13:17] <SWPadnos> huh. how do you actually use the knurling tool? (I ask because my understanding is that the diameter needs to be some multiple of the tool spacing, but if you press inward, then you're applying the tool to varying diameters)
[01:13:24] <jmkasunich> I saw a comment yesterday about boring bars, did you break another one?
[01:14:01] <cradek> SWPadnos: a good technique will knurl any diameter since the knurler pushes the material into submission
[01:14:23] <cradek> the trick is to smash it into the work completely before one revolution is over, so when it comes around to the initial spot, it meshes
[01:14:26] <SWPadnos> ok, so you get those nice rounded tops if you force it right :)
[01:14:35] <cradek> you have to be very bold to knurl :-)
[01:14:41] <SWPadnos> heh
[01:14:52] <cradek> and oil helps
[01:15:38] <cradek> I'm feeding in at 20ipm (100rpm) and then over at 1ipm (200rpm). once it was set up, I have had every knurl turn out.
[01:21:06] <jmkasunich> you change speed min-knurl?
[01:28:43] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: hide this tool-change move from the AXIS preview - for other guis this won't do anything.
[01:30:24] <cradek> jmkasunich: yes, right after the plunge - doesn't seem to hurt anything
[01:31:38] <jmkasunich> you have a VFD on that, right?
[01:31:42] <cradek> yes
[01:39:58] <jmkasunich> so, on the topic of #emc-devel
[01:40:18] <jmkasunich> I've been pondering the problem of not being able to see other people's halscope pics
[01:40:54] <cradek> I added a menubar with file/save, it has file/open greyed out
[01:40:59] <jmkasunich> heh
[01:41:03] <cradek> from there it's a SMOP
[01:41:09] <jmkasunich> there are a lot of UI differences
[01:41:32] <jmkasunich> starting with, it would be nice to be able to open a view a scope capture without even having RTAPI/HAL loaded
[01:41:45] <jmkasunich> it seems like two modes to me
[01:41:48] <cradek> true but I think that could be a secondary goal
[01:42:26] <jmkasunich> in "view a file" mode, you can't change channels (you probably don't have the same pins and signals that the original person had, and you might not have any at all)
[01:42:38] <jmkasunich> you can't change sample rate
[01:42:49] <jmkasunich> you can't change trigger source or position
[01:43:05] <jmkasunich> really, all you can change is scaling (horiz and vert) and which channel is highlighted
[01:43:58] <jmkasunich> if you solve the problems of "my HAL doesn't match the HAL of the guy who captured the data", you are probably 95% of the way to solving "I don't have HAL running at all"
[01:44:11] <cradek> I bet you're right
[02:37:40] <jepler> cradek: ingrid likes your knobs
[02:38:28] <cradek> that's very nice of her
[02:38:44] <cradek> they will look nicer when the tops are finished...
[02:40:10] <cradek> I made ten - maybe I should make more while it's set up. I could give them away on halloween.
[02:40:27] <jepler> heh
[02:40:33] <jepler> do you get many trick-or-treaters?
[02:40:42] <cradek> we used to get one - but he moved
[02:48:03] <SWPadnos> I think the road construction may reduce the number we get this year
[02:48:11] <SWPadnos> from 3 or 4 to 0 or 1
[02:50:00] <cradek> I sure like the new tool-change-at-g30
[02:50:20] <cradek> for this machine it's nice to save all that extra motion
[02:50:26] <SWPadnos> I sure wish there were a suitable lathe within 1000 miles of me :(
[02:50:41] <SWPadnos> then again, I should retrofit the BP first
[02:51:02] <cradek> I thought you had found one
[02:51:30] <SWPadnos> I haven't bought it - it's still on eBay though (the $2250 HNC)
[02:51:43] <cradek> ouch
[02:52:07] <cradek> I'd rather finish a conversion around $2250 instead of starting there
[02:52:08] <SWPadnos> yeah, I'm thinking that'll be a bit of a high price soon
[02:52:14] <SWPadnos> heh, yeah
[03:15:00] <cradek> uh
[03:15:13] <cradek> what happened to my error message?
[03:26:07] <cradek> oh, I guess it's a different one
[03:26:17] <cradek> so stupid
[03:26:43] <cradek> "g0 x1 exceeds +X limit"
[03:28:37] <cradek> oh that's why I never see it - I was using rfl, which is like tkemc's verify. it gives a different message.
[03:28:50] <cradek> comes from task instead of motion - motion's is better
[03:28:55] <cradek> redundant code
[03:29:02] <SWPadnos> bad
[03:30:09] <cradek> what did you guys decide about param-to-pin?
[03:30:31] <SWPadnos> judging from the flurry of commit messages, it looks like it was decided upon
[03:30:38] <SWPadnos> (to do the conversion)
[03:30:48] <cradek> I thought there was talk of backing those changes out
[03:31:09] <SWPadnos> oh. I've miseed most of the conversations since last Wednesday - been on the road
[03:39:09] <cradek> 32775 float OUT 2.962901e+09 encoder.0.velocity ==> spindle-rps-raw
[03:39:13] <cradek> umm no
[03:40:01] <SWPadnos> sounds a bit quick
[03:40:26] <cradek> this config worked before I cvsupped
[03:40:44] <SWPadnos> hmmm
[03:41:19] <cradek> looks like encoder.N.counts is insane
[03:44:27] <cradek> *(cntr->raw_counts)++;
[03:44:44] <SWPadnos> +()
[03:44:47] <cradek> I wonder how many times he wrote this bug :-/
[03:44:51] <SWPadnos> heh
[03:45:33] <SWPadnos> twice there anyway
[03:47:03] <cradek> the crazy thing is the parens aren't needed anywhere he put them
[03:47:52] <SWPadnos> I probably would have done the same thing - I usually add more parens than are strictly required
[03:47:56] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/hal/components/encoder.c: fix bogus pointer increment/decrement
[03:49:04] <Fisia> hi
[03:49:12] <SWPadnos> hi
[03:49:55] <Fisia> :) i ve try ubuntu EMC2 and study it
[03:50:18] <Fisia> it is a great stuff
[03:50:26] <SWPadnos> I agree
[03:51:14] <Fisia> does any one know how FAST in resolution is RTAI ? (for using stepper, in uS/mS per step resolution...)
[03:51:34] <Fisia> and howfast the PID & Calculation per move...?
[03:51:55] <garage_seb> just upgraded TRUNK, pid fails to load
[03:52:03] <Fisia> i need to know machine & system minimum respose time capable of.
[03:52:05] <cradek> garage_seb: error message?
[03:52:16] <Fisia> :)
[03:52:22] <garage_seb> looks like a bunch oif hal_pin_foo functions get called with the old param directionality constants
[03:52:25] <SWPadnos> Fisia, most PCs can handle a BASE_PERIOD of 20000-25000 ns
[03:52:40] <SWPadnos> garage_seb, funny - we were just discussing that :)
[03:52:51] <SWPadnos> (or something related anyway)
[03:53:12] <garage_seb> Oct 27 21:40:32 skynet kernel: [ 813.982685] HAL: component 'pid' initialized, ID = 02
[03:53:12] <garage_seb> Oct 27 21:40:32 skynet kernel: [ 813.982696] HAL: ERROR: pin direction not one of HAL_IN, HAL_OUT, or HAL_IO
[03:53:12] <garage_seb> Oct 27 21:40:32 skynet kernel: [ 813.982699] PID: ERROR: loop 0 var export failed
[03:53:24] <cradek> garage_seb: I kind of suspect a lot of things ar ebroken
[03:53:33] <Fisia> hmm.. yes...
[03:53:42] <garage_seb> yeah... i just reverted my sandbox :-/
[03:54:09] <cradek> I recommend updating to a few days ago - maybe 2008/10/26 08:00:00
[03:54:10] <garage_seb> when i'm rich and have lots of idle time, i'm going to add a test suite to emc2 ;-)
[03:54:15] <cradek> there is one
[03:54:29] <garage_seb> rilly?
[03:54:30] <Fisia> so, computer do calculating during (inside) PWM pulse of stepper
[03:54:59] <SWPadnos> PIS and step generation are separate functions
[03:55:02] <SWPadnos> PID too ;)
[03:55:33] <SWPadnos> PID is pretty quick - maybe a few hundred CPU cycles
[03:55:40] <SWPadnos> per channel (joint)
[03:56:03] <Fisia> PID for Stepper, it is new for me... im interrest in the calculating step, and capable of computer on doing this
[03:56:09] <cradek> garage_seb: Runtest: 25 tests run, 8 successful, 16 failed + 1 expected
[03:56:21] <cradek> garage_seb: the test suite says things are in a sorry state
[03:56:26] <garage_seb> how do you run it?
[03:56:39] <garage_seb> it should probably be run by the buildbot
[03:56:40] <cradek> . emc-environment, runtests
[03:56:53] <garage_seb> cool, i'll try it
[03:56:53] <cradek> or runtests some/test/dir
[03:57:00] <SWPadnos> PID for steppers requires special hardware, and isn't directly supported by EMC2
[03:57:19] <cradek> IMO, the more correct answer is you don't use PID for steppers
[03:57:34] <SWPadnos> well, that's certainly true at the moment ;)
[03:57:40] <Fisia> ...
[03:57:43] <Fisia> i see
[03:57:49] <garage_seb> PID requires feedback, which steppers dont provide
[03:57:52] <SWPadnos> and will continue to be true until someone tries to use specialized hardware
[03:57:56] <Fisia> yup
[03:58:09] <cradek> Fisia: can you ask a more specific question? what is your application?
[03:58:36] <cradek> your questions are so open it's hard to give the right answer
[03:58:43] <Fisia> im trying to study EMC2, perhaps do something positive ...if i could... in my capacity
[03:58:59] <garage_seb> Fisia: you could add a testcase for pid... ;-)
[03:59:03] <Fisia> wait
[03:59:11] <SWPadnos> PID/encoders + steppers may be a bit of a large problem to start on ;)
[03:59:44] <cradek> better to pick a problem, with a solution, that needs solving
[04:00:10] <Fisia> so, in stepper, how stepper do (computer/emc2) calculate a circle
[04:00:21] <Fisia> yes true PID needs Encoder
[04:00:34] <SWPadnos> the part of EMC2 that deals with arcs and lines doesn't care a bit about steppers
[04:01:09] <SWPadnos> it outputs positions, and the underlying hardware or software drivers convert those posittions to step velocities (or analog output, or PWM ...)
[04:01:22] <Fisia> can u tell me where part of files *.* on EMC that deal cyrcle calculating? G**?
[04:02:11] <cradek> most of the circle/arc math is in the posemath library
[04:02:30] <Fisia> IF stepper no need PID, why using RTAI...? i wonder
[04:03:11] <SWPadnos> you still need accurate timing to generate steps or PWM or analog velocity/torque commands
[04:04:23] <garage_seb> brb rebooting
[04:07:11] <Fisia> SWPadnos, and the fastest resolution of 'acurrate timing' is might about '20000-25000 ns'(u mention before)
[04:07:32] <Fisia> im trying time-machine here. :)
[04:07:43] <SWPadnos> no, I said that most PCs can handle that as a fast thread interval
[04:07:56] <SWPadnos> many machines can go significantly faster
[04:08:25] <Fisia> so, what is the fastest timing of PWM/stepper step on EMC2 ?
[04:08:43] <SWPadnos> are you asking what the step rate limit is?
[04:08:57] <SWPadnos> ie, how many steps per second EMC2 can generate
[04:09:05] <Fisia> mm, fastest and the limit okey
[04:09:13] <Fisia> would be okey
[04:09:27] <SWPadnos> there's no set limit, it's dependent on the PC you use
[04:09:58] <cradek> goodnight
[04:10:05] <SWPadnos> the fastest I've heard of was ~100k steps/second
[04:10:20] <Fisia> okey, the fastest PC economic on the market? a commont speed please? :)
[04:10:29] <Fisia> ah
[04:10:31] <SWPadnos> but depending on the timing your drives need, it could be double that
[04:10:39] <SWPadnos> this was an Athlon 1800 I think
[04:10:40] <garage_seb> goodnight cradek
[04:10:52] <Fisia> good night friends
[04:11:04] <Fisia> good night my friend
[04:11:06] <LawrenceG> hmm... current cvs is broken, 1 week ago broken, 1 month ago seem OK, by broken I mean wont build... I understand a lot of new changes are going through at the moment... will wait for it to settle a bit
[04:11:16] <SWPadnos> heh - me too - it's bedtime here
[04:11:25] <Fisia> hei
[04:11:29] <SWPadnos> LawrenceG, back out the parameters->pins changes Alex did
[04:11:39] <Fisia> and the limit speed... the slowest?
[04:11:51] <Fisia> im still here..
[04:11:53] <Fisia> ()
[04:12:01] <SWPadnos> the slowest what?
[04:12:30] <LawrenceG> SWPadnos, yea... no problem, I only use cvs for testing in sim mode
[04:12:37] <Fisia> the slowest resolution of step/pwm/pulse to the motor that EMC2 can handle... or the most PC slowest one
[04:12:59] <Fisia> .... i think the answer is any slow would be ok yah
[04:13:07] <LawrenceG> SWPadnos, the -D "1 month ago" option works well!
[04:13:24] <SWPadnos> a couple of seconds, depending on the clock source in your PC
[04:13:28] <SWPadnos> heh
[04:13:41] <SWPadnos> are you sure 1 week ago doesn't work?
[04:13:59] <LawrenceG> it build but wont run
[04:14:40] <Fisia> i trying to move Stepper, but its get HOT when i stand it still with the 1 step for a long time.. is it the right way to control stepper?
[04:14:40] <LawrenceG> I can try again to see what the problem was...
[04:14:55] <SWPadnos> steppers get hottest when holding still
[04:15:19] <SWPadnos> LawrenceG, try the end of the day on October 25 (or beginning of October 26)
[04:15:51] <Fisia> YES, that i wanna says.. :) is any way that would do the same job 'holding still' without getting HOT
[04:16:06] <SWPadnos> use servos instead
[04:16:23] <Fisia> circuit that adjusting ampere?
[04:16:30] <SWPadnos> or get drives that can reduce holding current somewhat (but won't screw up if you actually need that torque)
[04:17:21] <Fisia> yup, cos is not holding still, i might loose counting
[04:17:48] <SWPadnos> ok, now it's really bedtime. good night
[04:18:20] <Fisia> servo not have the problem its true
[04:18:35] <Fisia> ok thanks for
[04:18:54] <Fisia> your greats answer i appriciated
[04:19:20] <garage_seb> goodnight SWPadnos
[04:19:36] <Fisia> SWPadnos, have a good time, have a nice day my Friend :)
[04:20:31] <Fisia> been great seen u SWPadnos, and the other Friends here.
[04:24:29] <LawrenceG> SWPadnos, Compiling hal/utils/halsh. hal/utils/halsh.c:4:17: error: tcl.h: No such file or directory.. This is new... I even installed tcl 8.5 to see if it needed newer version than 8.4
[04:25:31] <Fisia> TCL is a compiler?
[04:26:02] <LawrenceG> yea.. some of the gui stuff uses it
[04:26:41] <Fisia> is axis GUI can be runs on TCL?
[04:27:07] <Fisia> pyton?
[04:27:22] <LawrenceG> mostly python, but some tcl/tk calls
[04:28:13] <Fisia> u mean TCL/TK can also compile Axis, right?
[04:28:49] <LawrenceG> python calls tcl/tk widgets libraries
[04:30:04] <Fisia> if it do, if i install whole Python, should i install TCL/TK in a whole also, or just the widget-lib
[04:30:20] <Fisia> to get axis compiled
[04:30:51] <LawrenceG> the wiki has build instructions... let me find link for you
[04:31:07] <Fisia> or made a change, shape, do work on axis
[04:31:40] <Fisia> yes.. wiki says just type 'make...' youre on compile process
[04:32:24] <LawrenceG> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#On_Ubuntu_6_06_or_8_04_from_source
[04:32:53] <Fisia> i need to re design somes GUI on axis, what should i do?
[04:32:56] <Fisia> oh
[04:33:16] <LawrenceG> from wiki... it gets most of the needed stuff Use apt-get to install additional packages required to rebuild emc2:
[04:33:16] <LawrenceG> sudo apt-get build-dep emc2
[04:36:01] <LawrenceG> SWPadnos, got cvs up -D "25 October 2008" -Dp to build after rerunning ./configure, but it wont run due to a HAL error HAL: ERROR: pin direction not one of HAL_IN, HAL_OUT, or HAL_IO
[04:36:01] <LawrenceG> STEPGEN: ERROR: stepgen 0 var export failed
[04:36:20] <LawrenceG> Need a version before Oct 25
[04:37:57] <Fisia> WOW, sites says Jepler is one of AXIS developer, Cradek also? COOL
[04:38:19] <LawrenceG> yes.... the main guys all hang out here
[04:38:25] <Fisia> COOL
[04:38:34] <Fisia> ...
[04:38:52] <Fisia> ..i never expected
[04:40:09] <Fisia> it
[04:40:50] <Fisia> i must admit They done GREATz job ever
[04:41:37] <Fisia> i think i must get surf before get askin more
[04:44:12] <Fisia> i wonder if this 100k pulse/sec (100.000 pulse/sec) i can convert to a MEM, so there is no calc needed
[04:44:26] <Fisia> at machine work
[04:44:55] <Fisia> u see what i mean...
[04:46:56] <Fisia> 1 pulse require 1 combination of stepper step, u see
[04:47:22] <Fisia> or multiple by existed axis
[04:47:50] <Fisia> :)
[04:48:05] <Fisia> can it be workin?
[04:48:59] <Fisia> if these true, we can lose RTAI a bit
[04:50:55] <Fisia> the question is, how many combination of step that could be loaded into that MEM... mean: HOW many step of stepper required by stepper in 1 G-CODE Project, at most Many?
[04:52:22] <Fisia> 1 megabyte?(easyest) 1 gigabyte? need hard work
[04:54:35] <LawrenceG> not sure of your question.... nothing is precomputed in emc.... each 1ms, a new position is calculated for each axiis, the user feed overrides are evaluated and then either the servo code or the stepper code try to keep up
[04:56:30] <Fisia> as far as i know, ... stepper not require Feedback, so there is no change during workin-machine
[04:56:35] <Fisia> :)
[04:56:49] <Fisia> what do u think?
[04:58:47] <Fisia> what i mean is... computer dump the sequence data to external MEM, then the external MEM do the job in line
[04:59:49] <Fisia> while MEM execute the step, computer is free to do any job, including calculating next job that external-MEM would do
[05:00:00] <Fisia> so mC would be needed
[05:00:49] <Fisia> 100k pulse/sec, most mC today could do this INTerrupt
[05:00:55] <Fisia> uC
[05:02:10] <Fisia> sorry, SWPadnos say that 20000-25000 ns
[05:03:08] <Fisia> mean 25uS to check load the stepper sequence
[05:03:37] <Fisia> actually mean 25uS to check & load the stepper sequence from MEM
[05:03:48] <Fisia> haha
[05:05:36] <Fisia> come on, comment me, this atleast all i can do to help on EMC2, by givin idea, since i still fighting to study the source...im kindda slow on software Linux
[05:06:16] <Fisia> c programming on linux, gui, so forgive me to askin dumb question on that
[05:07:07] <Fisia> 25uS Interrupt !
[05:07:12] <Fisia> on uS
[05:07:15] <Fisia> un uC
[05:07:34] <Fisia> i mean on uC...
[05:08:14] <Fisia> but i need to know how much the load to feed on MEM before uC feed it to Stepper
[05:09:07] <Fisia> how much time it required to update it MEM
[05:09:43] <Fisia> so there is no Lack of time for machine for doin their job, milling stuff
[05:10:00] <Fisia> :)
[05:12:42] <Fisia> in my country it a day light... might a night for u... ill comeback latter time.
[05:13:09] <Fisia> thanks LawrenceG, u help much
[05:13:14] <Fisia> also
[05:13:17] <Fisia> :)
[05:20:14] <seb_kuzminsky> i can't get to cvs.linuxcnc.org
[05:20:29] <seb_kuzminsky> ssh: connect to host cvs.linuxcnc.org port 22: No route to host
[05:20:46] <seb_kuzminsky> my traceroute ends at:
[05:20:48] <seb_kuzminsky> 21 unpythonic.net (206.222.212.218) 3014.644 ms !H 3002.228 ms !H *
[05:22:04] <seb_kuzminsky> i just wanted to commit the 5i22 hm2 driver before going to bed :-)
[05:25:32] <Fisia> :)
[05:25:53] <Fisia> <LawrenceG> hmm... current cvs is broken, 1 week ago broken, 1 month ago seem OK, by broken I mean wont build... I understand a lot of new changes are going through at the moment... will wait for it to settle a bit
[05:26:13] <fenn> same here
[05:27:01] <Fisia> this is LawrenceG comment today few hour ago
[05:33:13] <seb_kuzminsky> goodnight all
[05:38:44] <seb_kuzminsky> i was gonna go to sleep but chris's hardinge is making me too horny
[05:39:32] <seb_kuzminsky> http://timeguy.com/cradek/01225159413
[06:10:37] <Fisia> http://www.todopic.com.ar/foros/index.php?topic=21154.140
[06:11:03] <Fisia> check this out... 3D
[08:37:16] <Fisia> can any one tell me, where can i download AXIS source...without accessing CVS
[08:38:17] <Fisia> i search wiki & Axis sites, i could not find it
[08:38:24] <Fisia> *.rar
[11:27:16] <BigJohnT> looks like the cvs is down :(
[11:31:59] <alex_joni> BigJohnT: 1-2h max till jepler wakes up :)
[11:36:48] <BigJohnT> dang he sleeps late :)
[12:32:09] <jepler> cvs should be fixed now, sorry for the downtime.
[12:32:51] <alex_joni> works here
[12:35:48] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/po/ (sv_axis.po se_axis.po): the language code for swedish is sv, not se
[12:40:43] <skunkworks> Good morning
[12:40:50] <jepler> hi skunkworks -- what's new?
[12:40:54] <jepler> * jepler is watching cradek's lathe video
[12:41:23] <jepler> http://timeguy.com/cradek/01225159413
[12:41:57] <alex_joni> very cool stuff :)
[12:42:15] <alex_joni> skunkworks: seen the stuff petew told you in #emc ?
[12:42:26] <alex_joni> he had some remarks reffering to your h-bridge
[12:43:32] <skunkworks> Yes - I acutally increased the gate resistors and added the diode. I have not smoked a driver chip yet.
[12:43:58] <skunkworks> (but it is still early) ;)
[12:46:29] <skunkworks> Cool video! Nice work
[13:03:53] <cradek> seems like I need a camera that focuses and zooms
[13:04:16] <cradek> mine focuses at two distances: "far" and "about a foot"
[13:04:59] <fenn> * fenn suggests a magnifying glass
[13:07:55] <jepler> from time to time I'm tempted to buy a digital video camera .. luckily for me, I've resisted so far
[13:08:41] <SWPadnos> in a couple of months, they should be about as inexpensive as they're gonna get
[13:08:49] <SWPadnos> for a while anyway
[13:10:09] <cradek> found another obscure bug last night - but it's probably mine, since changing from g64 to g61 fixes it
[13:10:09] <jepler> you mean because of the "global financial omgwtfbbq" or for some other reason?
[13:11:08] <SWPadnos> overstock from the omgwtfbbq + christmas sales
[13:11:36] <SWPadnos> but as manufacturers scale back production, supply will tighten, so the prices will go back up
[13:19:07] <cradek> cvs update: src/po/se_axis.po is no longer in the repository ?
[13:21:22] <SWPadnos> it's sv now
[13:21:30] <cradek> oh ok
[13:24:48] <skunkworks> reading the app notes from the gate drivers - the onlything that really can take them out is supply voltage spikes and under shoot on the Vsense pin.
[13:33:26] <skunkworks> * skunkworks flunked scope.
[13:58:37] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/tp.c: what was I thinking? Fix g0z0 / g1z1g95f.020 / g0z2 / g1z3 (the z2 rapid did not rapid)
[14:06:32] <skunkworks> heh
[14:08:26] <Fisia> hi
[14:10:04] <cradek> oh look, a commit telling me about that rename
[14:10:21] <SWPadnos> heh
[14:14:21] <Fisia> :)
[14:15:17] <Fisia> sometime it is embaresh to askin stupid question thats why
[14:15:45] <SWPadnos> stupid questions go in #emc ;)
[14:16:31] <cradek> questions go in #emc - stupid or not - this channel is more for talk about development
[14:16:40] <Fisia> :) okey ..
[14:17:28] <Fisia> hei, about my last posting that u guys were not here (at late night)
[14:20:30] <Fisia> that u say before that 20000-25000 ns is the speed..mean: 25uS on PWM of stepper step
[14:20:55] <cradek> Fisia: take it to #emc please
[14:21:07] <Fisia> okey
[14:28:41] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/hal/components/ (counter.c debounce.c freqgen.c sampler.c streamer.c): fix more runaway pointer bugs caused by incorrect param-to-pin conversion
[14:30:26] <BigJohnT> so I can update the man pages for the above now?
[14:31:19] <cradek> I don't know ... I think there is still debate about these changes
[14:31:28] <BigJohnT> ok, I'll wait
[14:31:59] <cradek> (although I bet they will stay)
[14:32:33] <SWPadnos> I guess the main difference between pins and params is that params are "private" in a running HAL
[14:32:54] <SWPadnos> and the question is whether it's sensible to allow private data
[14:49:58] <alex_joni> not really "private"..
[14:50:17] <SWPadnos> pseudo-private
[14:50:36] <SWPadnos> it's not really accessible to other RT HAL functions
[14:50:48] <SWPadnos> at least not easily or predictably
[15:05:40] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/hal/components/pid.c: fix pin_float_new arguments and also uninitialized pointer dereferences caused by param-to-pin conversion
[15:07:23] <alex_joni> crap, seems I really borked it :/
[15:09:05] <cradek> now I've moved on to trying to figure out what's wrong with stepgen :-P
[15:09:30] <alex_joni> :/
[15:09:46] <BigJohnT> how did you type that face in alex_joni ?
[15:09:56] <alex_joni> : /
[15:10:09] <BigJohnT> :/
[15:10:14] <BigJohnT> ok got it
[15:10:15] <Fisia> :)
[15:10:26] <alex_joni> luckily I see no faces over here :D
[15:10:54] <cradek> I see a : and a /
[15:11:23] <alex_joni> right.. that's what a proper IRC client shows
[15:24:14] <cradek> ok I found one problem in stepgen. see how the step_space pin is only created for certain step types? Previously even though the param was not exported to hal, it was set to a default and then used in calculations.
[15:24:47] <cradek> same for other parameters. the code needs significant rework to fix these problems.
[15:25:38] <jepler> I'd rather see the change reverted than have a broken stepgen for weeks..
[15:26:19] <cradek> I don't think stepgen is the only remaining breakage, it's just where I got bogged down
[15:26:51] <SWPadnos> pins have a default storage location in the pin struct. those should be set to the default value
[15:29:46] <alex_joni> revert it..
[15:44:37] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/hal/components/stepgen.c:
[15:44:37] <CIA-37> EMC: revert param-to-pin changes. currently when a param is inappropriate for a
[15:44:37] <CIA-37> EMC: certain step mode, it is not exported to HAL but is set to a default value
[15:44:37] <CIA-37> EMC: internally that makes the calculations, etc., work out. this kind of code has
[15:44:38] <CIA-37> EMC: to be restructured if those are pointers.
[15:47:26] <cradek> jepler: I can't decide whether the loadrt.1 test is right. now that there is .all, "loadrt mux2 names=m.q,m.r" gives functs m.q, m.r, mux2.all
[15:47:41] <cradek> if you think it's right, I'll fix the test.
[15:47:55] <jepler> cradek: yes, ".all" is a new feature of comp that probably needs to be documented
[15:47:56] <cradek> or was it you who added the .all?
[15:48:19] <cradek> is this interaction with names= correct?
[15:49:00] <jepler> oh, now I see what you're getting at
[15:49:27] <jepler> you're wondering if it shouldn't somehow turn out to be 'm.all'? No, I think mux2.all is the right name for the "all" function.
[15:49:48] <cradek> ok, thanks
[15:50:30] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/tests/loadrt.1/expected: with .all, these new functs are expected
[15:53:50] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/tests/modparam.0/expected: this change was caused by converting freqgen's params to pins
[15:54:17] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/tests/modparam.0/test.hal: this change was caused by converting freqgen's params to pins
[15:56:40] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/tests/save.0/expected: this change was caused by converting sampler's params to pins
[15:57:20] <cradek> Runtest: 25 tests run, 24 successful, 0 failed + 1 expected
[15:57:46] <jepler> yay cradek
[15:57:47] <cradek> I think (hope) I have the system pretty much unbroken now
[15:57:52] <jepler> (I thought we deprecated freqgen anyway)
[15:58:55] <seb_kuzminsky> good morning
[15:58:59] <jepler> hi seb
[15:59:00] <cradek> hi
[15:59:02] <jepler> you should be able to commit your code now
[15:59:06] <seb_kuzminsky> yay
[15:59:26] <jepler> I temporarily broke cvs by running out of disk space on the system where its virtual machine is hosted
[16:02:01] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/ (hm2_5i20.9 hm2_pci.9 hostmot2.9):
[16:02:01] <CIA-37> EMC: support the 5i22 in hm2_pci (as well as the 5i20 and 4i65)
[16:02:01] <CIA-37> EMC: hm2_5i20 is now deprecated, users should switch to hm2_pci
[16:02:06] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog TODO hm2_pci.c hm2_pci.h):
[16:02:06] <CIA-37> EMC: support the 5i22 in hm2_pci (as well as the 5i20 and 4i65)
[16:02:06] <CIA-37> EMC: hm2_5i20 is now deprecated, users should switch to hm2_pci
[16:04:10] <seb_kuzminsky> have you guys seen the Bazaar "Patch Queue Manager"?
[16:04:17] <seb_kuzminsky> it keeps the tree from breaking with bad commits
[16:04:51] <cradek> does that mean someone does patch review?
[16:04:53] <seb_kuzminsky> when anyone tries to commit, it first builds & test the commit, and only if it doesnt regress does the PQM let the commit into the public tree
[16:05:05] <cradek> ah
[16:05:21] <seb_kuzminsky> there's an option for a mailing list to review the commit along with pqm's testing
[16:07:00] <alex_joni> heh, cool :)
[16:07:41] <seb_kuzminsky> the mailing list review of patches is called "bundle buggy", it's good stuff :-)
[16:08:12] <alex_joni> I also saw another way of doing things..
[16:08:15] <cradek> heck I'd never get anything checked in.
[16:08:22] <seb_kuzminsky> lol
[16:08:25] <alex_joni> when someone commits something borken, the tree automatically closes
[16:08:37] <cradek> alex_joni: their commit access is removed
[16:08:42] <alex_joni> and most devels can't commit anymore, until the issue is resolved
[16:08:42] <seb_kuzminsky> heh
[16:08:55] <seb_kuzminsky> the key i think is to not let the bad commit pollute the tree in the first place
[16:09:03] <alex_joni> the branch manager still ahs access obviously
[16:09:28] <seb_kuzminsky> we should try to keep the main tree we all use in a buildable, working state at all times
[16:09:49] <seb_kuzminsky> robots and test suites can help with this
[16:10:04] <cradek> if alex had forseen how invasive these changes were, I suspect he would have used a branch until they were stable
[16:10:28] <seb_kuzminsky> branches are good too :-)
[16:10:39] <alex_joni> or (more likely) not done them at all :)
[16:10:44] <skunkworks> logger_dev: bookmark
[16:10:44] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-28.txt
[16:11:12] <alex_joni> seb_kuzminsky: the compile farm helps lots with that
[16:11:21] <seb_kuzminsky> why are there hal params at all? aren't pins enough?
[16:11:30] <seb_kuzminsky> alex_joni: agreed, the compile farm rocks!
[16:11:49] <cradek> seb_kuzminsky: yes that is the question at hand
[16:11:55] <BigJohnT> if we built the docs separate from EMC would it matter how they got built?
[16:13:46] <fenn> BigJohnT: what are you asking?
[16:14:21] <alex_joni> BigJohnT: they were outside initially
[16:14:31] <alex_joni> but keeping them inside is so much better in linking version together
[16:14:35] <jepler> BigJohnT: that's how it used to be, but putting them together and building them at the same time as the software seems to be better in terms of (A) building the packages -- the alternative is a manual step of "copy these files from somewhere into the source tree periodically" and (B) some programmers actually adopting a practice of updating the documentation when they write new features
[16:14:57] <jepler> (and (C) some documentation -- for instance, the manpages generated from .comp files -- cannot be separated from the program source)
[16:15:05] <alex_joni> jepler is beeing funny about (B)
[16:15:15] <alex_joni> actually it was true, but BigJohnT borked that up
[16:16:03] <fenn> i like having the Real Documentation in the source files, is that possible with asciidoc?
[16:16:37] <fenn> or maybe that's my sleep deprived brain talking
[16:17:19] <jepler> I haven't seen a "literate programming" feature in asciidoc
[16:17:35] <jepler> at one time there was an abortive attempt to add docbook documentation, but nobody's contributed to that in ages as far as I know
[16:17:51] <jepler> (I wrote manpages for the stuff I cared about; my personal bias is towards manpages and against docbook)
[16:17:59] <jepler> er, not docbook
[16:18:02] <jepler> what's it called?
[16:18:09] <fenn> doxygen?
[16:18:17] <jepler> yeah, that
[16:18:27] <fenn> yeah that sucks
[16:18:35] <BigJohnT> I was looking at asciidoc
[16:18:53] <cradek> at one time someone on the project thought we should use doxygen - there are some dropping remaining here and there
[16:20:10] <skunkworks> docygen? cute.
[16:21:03] <BigJohnT> fenn: sorry got distracted but I was asking about dependencies like if we used asciidoc
[16:22:04] <fenn> BigJohnT: oh, i've been pushing (half assed) for separate docs package, so it wouldnt matter how many dependencies are needed to build the docs, it woudlnt affect `build-dep emc2`
[16:22:34] <BigJohnT> that's what I was wondering
[16:23:41] <BigJohnT> anyhow I've been working on getting a sample of a pdf and a html from asciidoc but have not finished one yet :/
[16:23:56] <alex_joni> see you later
[16:24:03] <BigJohnT> see you later
[16:25:02] <BigJohnT> jepler: can man pages be built from the C components like the .comp ones?
[16:25:26] <jepler> BigJohnT: no, they can only be automatically built from .comps
[16:25:35] <BigJohnT> ok
[16:27:37] <BigJohnT> fenn: what do you mean by Real Documentaion?
[16:28:13] <fenn> stuff that gets converted to html or pdf
[16:28:22] <fenn> not just comments
[16:30:20] <BigJohnT> You write an AsciiDoc document the same way you would write a normal text document, there are no markup tags or weird format notations. AsciiDoc files are designed to be viewed, edited and printed directly or translated to other presentation formats using the asciidoc(1) command.
[16:30:22] <BigJohnT> The asciidoc(1) command translates AsciiDoc files to HTML, XHTML and DocBook markups. DocBook can be post-processed to presentation formats such as HTML, PDF, DVI, LaTeX, roff, and Postscript using readily available Open Source tools.
[16:30:45] <BigJohnT> a quote from here
http://www.methods.co.nz/asciidoc/#_overview_and_examples
[16:35:34] <BigJohnT> bbl
[16:56:38] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/motion/kinematics_fr.lyx: french translation update
[17:06:13] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/motion/kinematics_fr.lyx: french translation fix typo
[19:46:22] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/files.c: changes for loading/saving modbus com params with everything else
[19:51:19] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/config_gtk.c: changes for clarity of info-The page is ugly I need to learn more about GTK
[20:03:14] <seb_kuzminsky> here's a good paper on open-source development:
http://people.ubuntu.com/~ianc/papers/community-agile/community-agile.html
[20:05:52] <seb_kuzminsky> and here's a joke about over-analyzing your processes:
http://dilbert.com/strips/comic/2008-10-28/
[20:06:02] <alex_joni> whee.. so many words :)
[20:06:32] <cradek> seb_kuzminsky: I understand your second link more than the first
[20:07:13] <cradek> the first paragraph had too many buzzwords and not enough plain English to get me to read the rest
[20:07:29] <seb_kuzminsky> i just liked ian's application of agile methods to open-source projects
[20:07:56] <seb_kuzminsky> <shrug>
[20:08:01] <alex_joni> cradek: I skipped the first 2-3 chapters, it started beeing interesting :)
[20:08:14] <SWPadnos> http://dilbert.com/strips/comic/2008-10-25/
[20:08:37] <seb_kuzminsky> alex_joni: dont skip 3.3 and 3.4 ;-)
[20:08:38] <cradek> so very true:
http://people.ubuntu.com/~ianc/papers/community-agile/community-agile.html#knowledge-over-co-location
[20:09:13] <SWPadnos> ha, too funny:
http://dilbert.com/strips/comic/2008-10-23/
[20:10:20] <cradek> SWPadnos: have you noticed that dilbert is usually better if you remove the last frame?
[20:10:30] <SWPadnos> hmmm. not really
[20:10:39] <cradek> try it - you will see.
[20:15:42] <SWPadnos> I think I like them better with the last panel most of the time
[20:15:47] <SWPadnos> but I should do more research
[20:15:53] <cradek> oh, maybe it's just me then
[20:18:48] <cradek> http://dilbert.com/2008-10-26/ is a good example
[20:19:03] <skunkworks> well - h-bridge ran all day without self distructing..
[20:19:22] <cradek> yay
[20:19:27] <SWPadnos> yes, that one works nicely without the last pane
[20:19:37] <cradek> also
http://dilbert.com/2008-10-23/
[20:20:08] <seb_kuzminsky> this one needs the last panel:
http://www.qwantz.com/archive/000815.html
[20:20:57] <alex_joni> heh
[20:21:01] <alex_joni> no dilbert though :P
[20:21:12] <alex_joni> skunkworks: whee..
[20:24:15] <skunkworks> :)
[20:24:17] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder.c: changes to be able to load modbus without a seperate config file
[20:33:01] <jepler> "All the commits related to a logical change are merged into the trunk at a single point in time instead of being intermingled with other changes over several days/weeks. As a consequence, it is easier to find what change introduced a bug and easier to back out a logical change if required." <-- the argument for distributed revision control systems in a persuasive nutshell (you can't do this with svn or cvs)
[20:34:02] <seb_kuzminsky> that's a good one, but i think there are others :-)
[20:34:11] <seb_kuzminsky> local commits are nice, for instance
[20:34:28] <jepler> that's a prerequisite for this, imo
[20:34:49] <seb_kuzminsky> could be
[20:35:14] <jepler> the alternative, keep a lot of stuff in your sandbox and hope you can merge TRUNK into it every day or week, sucks -- that's why everyone commits changes to TRUNK so readily.
[20:35:34] <jepler> the limitations of cvs feed into the community's habits, until you no longer know whether the cart came before the egg
[20:36:20] <seb_kuzminsky> our tools definately shape our culture
[20:36:39] <seb_kuzminsky> "architecture is politics" -- mitch kapor
[20:36:54] <cradek> jepler: you can't change handbaskets mid-descent
[20:37:01] <seb_kuzminsky> heh
[20:38:17] <jepler> A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."
[20:38:22] <jepler> bahaha
[20:38:48] <cradek> That's when the fight started.
[20:38:58] <seb_kuzminsky> we're doing scrum at work, it's working out pretty well
[20:39:24] <seb_kuzminsky> real
[20:39:29] <jepler> reading the wiki page on it, I see that my manager has tried to incorporate some of these ideas
[20:39:34] <jepler> it hasn't led to revolutionary change, however
[20:42:11] <seb_kuzminsky> we used to use this monstrous waterfall model, with a long design phase, followed by implementation, then integration, then testing
[20:42:20] <seb_kuzminsky> scrum was a big step forward for us ;-)
[20:42:49] <jepler> oh, here at the office we skip everything besides implementation
[20:43:01] <seb_kuzminsky> "it compiles, ship it!"
[20:43:14] <SWPadnos> "ship it! does it compile?"
[20:43:32] <cradek> nowadays I'd talk more openmindedly about switching away from cvs. I don't know whether I was ever one of the hard ones to convince though.
[20:44:01] <cradek> cvs has two huge advantages in our project: it's working, and we all know how to use it
[20:44:29] <seb_kuzminsky> those are two pretty good feature
[20:44:35] <seb_kuzminsky> features even
[20:44:39] <cradek> yeah
[20:45:35] <seb_kuzminsky> when i switched from cvs to svn i was surprised how easy svn was to pick up - it's basically command-line equivalent to cvs, with a few improvements
[20:46:09] <SWPadnos> I haven't used svn much, but I'm not terribly impressed by the couple of projects I have used it for
[20:46:17] <seb_kuzminsky> after that, playing with the three big distributed rcs'es was pretty easy, the same 5 or so commands work the same pretty much everywhere
[20:46:25] <SWPadnos> though it is better with regard to file moving/renaming
[20:46:44] <cradek> I am not impressed [understatement] by svn either
[20:46:48] <seb_kuzminsky> SWPadnos: i think of svn as cvs with working mv and proper directory support
[20:47:03] <seb_kuzminsky> you guys prefer cvs to svn?
[20:47:03] <cradek> seb_kuzminsky: and broken tags and branches
[20:47:05] <SWPadnos> yep - so not worth much trouble to move to it IMO
[20:47:28] <SWPadnos> yeah, I really don't like the branch mechanism much
[20:47:35] <seb_kuzminsky> cradek: what's wrong with svn tags & branches?
[20:47:45] <cradek> seb_kuzminsky: it doesn't have them
[20:47:57] <seb_kuzminsky> i dont understand
[20:48:08] <seb_kuzminsky> they're implemented differently in svn than in cvs, sure
[20:48:20] <seb_kuzminsky> but i wouldnt say svn doesnt have tags & branches
[20:48:40] <SWPadnos> I see that it could be considered an advantage to have everything in one directory tree (instead of separate checkouts for different tags/branches), but I never quite got the hang of it
[20:48:42] <cradek> I understand why you might not say that, but I do
[20:49:12] <seb_kuzminsky> SWPadnos: i almost always have separate working directories for different svn branches
[20:49:35] <cradek> it makes the programmer handle things he shouldn't have to
[20:49:41] <seb_kuzminsky> cradek: what do you do with cvs tags & branches that svn is too broken for?
[20:49:47] <jepler> here's one way an svn tag seems to be broken: how do you get a list of change messages since tag alpha and before tag beta? it doesn't seem to be possible.
[20:49:51] <jepler> (I think that's the thing)
[20:50:01] <cradek> for instance if you make a branch off a branch, you have to remember where it came from
[20:50:27] <seb_kuzminsky> jepler: that's awkward, true
[20:50:29] <SWPadnos> sure, you can do multiple checkouts like CVS, but it seemed to me that I got all the branches in each checkout (or at least root dirs for them)
[20:50:52] <SWPadnos> it just seemed weird to me - I'm certainly no expert on it (especially since I used it as little as possible;) )
[20:50:53] <seb_kuzminsky> you'd find the rev of the two tags, then "svn log -r $A:$B"
[20:50:53] <cradek> SWPadnos: if you aren't careful you will get N copies of the entire project, where N = (#tags + #branches)
[20:51:00] <SWPadnos> rigtht
[20:51:04] <SWPadnos> uh - right
[20:51:06] <jepler> disk space "doesn't matter"
[20:51:23] <alex_joni> bandwidth doesn't either
[20:51:29] <cradek> seb_kuzminsky: if it had tags, you'd do svn log -r tag1:tag2
[20:51:53] <jepler> seb_kuzminsky: I don't think that does it
[20:51:56] <seb_kuzminsky> cradek: agreed... that's one thing i like better about bzr, it does tags like that
[20:52:23] <jepler> seb_kuzminsky: because the "difference" between those tags is that one set of files exist in tags/alpha, and that a different set of files exists in tags/beta
[20:52:30] <seb_kuzminsky> SWPadnos: if you check our $REPO/branches/the-one-i-want you'll get what you want ;-)
[20:52:33] <jepler> and, if I recall correctly, the log message you get is simply the one creating "beta"
[20:52:46] <cradek> now if I really want to argue I'd say bzr doesn't do branches either
[20:53:14] <SWPadnos> how BiZzaRre
[20:53:33] <jepler> but I haven't used svn lately, maybe I'm mistaken
[20:53:35] <SWPadnos> or BiZaRre even
[20:53:39] <seb_kuzminsky> jepler: if the tags are vs the trunk, then you get all commits (to the part that you're asking svn log about) between the commits that created those two tags
[20:54:11] <seb_kuzminsky> cradek: that one you're going to have to explain!
[20:54:13] <cradek> I don't know what my complaint about git is yet - I haven't used it enough to say.
[20:54:38] <seb_kuzminsky> my complaint against git is the command-line interface is too big - there are over 200 commands last time i checked
[20:54:48] <cradek> yeah that's true
[20:55:06] <cradek> that was my first turnoff as well - but I bet there are a few common things you do, like with any of these systems, and you learn the rest one at a time.
[20:55:20] <jepler> bbl
[20:55:25] <seb_kuzminsky> seeya jeff
[20:55:30] <cradek> whee, 4:00
[20:55:53] <seb_kuzminsky> cradek: i'm curious why you think bzr doesnt do branches
[20:55:57] <jepler> hah, they still haven't fixed this bug:
http://maps.google.com/maps?q=60,-120
[20:57:11] <cradek> seb_kuzminsky: because you cannot push branches to a central repository except by having copies of everything, and remembering where in history they came from, not unlike svn
[20:57:43] <seb_kuzminsky> i dont think that's true
[20:57:51] <cradek> bzr seems like svn with tagging fixed and distributed stuff added
[20:58:00] <seb_kuzminsky> it's true that bzr "branches" carry their history with them
[20:58:20] <cradek> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1
[20:59:05] <cradek> look at this picture - you can see where in history development split, and that history is all stored in one repository, and there is a heirarchy to the branches that the revision control system remembers for you.
[20:59:50] <seb_kuzminsky> those are all good things, and each of them is doable with bzr
[21:00:10] <cradek> can you point me to documentation that says how? I have looked.
[21:01:19] <cradek> note most of those branches are dead-ends but they are still preserved. all the docs/faqs seem to be about merging, and the dead-ends being forgotten on some developer's machine somewhere.
[21:01:49] <seb_kuzminsky> here are some workflows that bzr supports:
http://bazaar-vcs.org/Workflows
[21:02:10] <seb_kuzminsky> it's the devloper's choice whether their branches are public (on the central server) or private (on their local work machine)
[21:02:20] <cradek> I know - they are all merge-or-forget
[21:02:32] <seb_kuzminsky> anything on the central server is visible by everyone for all the future
[21:03:48] <seb_kuzminsky> feature branches are one of bzr's big strenghts, imo
[21:04:15] <cradek> so it seems to me all you can have on the central server is a whole bunch of project/some-developer/some-bad-idea/abandoned-stuff with no big picture except what you remember manually
[21:04:47] <seb_kuzminsky> well, you can easily tell when those bad ideas branched off from the trunk
[21:05:14] <seb_kuzminsky> and you can tell what has moved between those branches and when
[21:05:16] <cradek> not by looking at the trunk - you have to look at each of the branches (which are entire copies of the project, with history, and some changes on top)
[21:05:28] <seb_kuzminsky> sure by looking at the trunk
[21:05:48] <cradek> if that's true then I misunderstand it
[21:06:30] <cradek> (I would be happy to learn this)
[21:06:37] <seb_kuzminsky> i'm looking for something similar to your pic, hold on a sec
[21:06:49] <cradek> thanks
[21:07:39] <seb_kuzminsky> (lp just switched to "shared repos", so pushing a branch that you've forked from a branch they already have only transmits the delta)
[21:14:56] <cradek> I have to run - bbl. Thanks seb_kuzminsky. I have trouble believing it has these obvious (to me?) problems. (but I think that about svn too.) I will be happy if you correct me. I will read back later.
[21:15:16] <seb_kuzminsky> ok chris, ttyl
[21:29:43] <seb_kuzminsky> ok so i didnt find a web interface that's like cvsweb, but here's a screencap from a local client running on my laptop:
[21:29:55] <seb_kuzminsky> http://imagebin.org/29756
[21:30:57] <seb_kuzminsky> the gray-colored dots represent commits on a branch called "emc2-upstream-slurp"
[21:31:22] <seb_kuzminsky> the blueish dots represent commits on a branch called "hm2"
[21:31:33] <seb_kuzminsky> lines represent ancestry
[21:32:05] <seb_kuzminsky> the highlighted commit is a merge, it has two parents: one in emc2-upstream-slurp and one in hm2
[21:32:18] <seb_kuzminsky> 578.1.5 has a tag named hm2-0.14
[21:32:46] <seb_kuzminsky> that commit was merged into emc2-upstream-slurp (and from there I "cvs commit" to our TRUNK)
[21:34:03] <seb_kuzminsky> this can run on any repo/branch you have a URL to, not just local ones
[21:40:29] <seb_kuzminsky> the bzr web interface is called loggerhead and does not yet provide a view like "bzr visualize" and cvsweb do
[21:47:45] <seb_kuzminsky> you can play around with this easily if you're running ubuntu:
[21:47:54] <seb_kuzminsky> apt-get install bzr bzr-gtk
[21:49:01] <seb_kuzminsky> then: bzr vis
https://code.launchpad.net/~seb-highlab/emc/hostmot2
[21:50:21] <seb_kuzminsky> it works quicker on a local branch...
[21:50:30] <seb_kuzminsky> ok enough talking to myself for now
[21:52:22] <jmkasunich> hi seb
[21:52:44] <seb_kuzminsky> hi john
[21:53:08] <seb_kuzminsky> i was trying to dig up bzr features to get chris excited
[21:53:23] <jmkasunich> today is the 2nd time that you've asked "why HAL params" and I wasn't around to answer
[21:53:30] <jmkasunich> first time, when I was around, you weren't
[21:53:48] <seb_kuzminsky> this is one of the things i dont like about irc - we have to both be here at the same time
[21:54:11] <seb_kuzminsky> but now we are, so yay!
[21:54:13] <jmkasunich> anyway, the original HAL model was based on electroncis - components have stuff that connects to the world, and stuff that (I initially thought) was "local"
[21:54:21] <jmkasunich> think of an old analog servo amp
[21:54:28] <jmkasunich> inputs and outputs are naturally pins
[21:54:33] <jmkasunich> all the tuning pots are params
[21:54:37] <seb_kuzminsky> right, with params as knobs or switches on top
[21:54:40] <seb_kuzminsky> i see
[21:55:05] <jmkasunich> over time, I've realize that the distinction is somewhat artificial
[21:55:45] <jmkasunich> the component designer probably has a pretty good idea of what things are connections and what are local, but he can't anticipate what future users of the comp might want to do
[21:56:04] <seb_kuzminsky> it's more a question of how it's used, not how it's implemented internally in the component
[21:56:28] <SWPadnos> the complication is that some parameters are used to change the way something else works
[21:56:29] <seb_kuzminsky> so is alex working on getting rid of params now?
[21:56:40] <jmkasunich> well.....
[21:56:45] <seb_kuzminsky> SWPadnos: why is that a complication?
[21:56:54] <jmkasunich> we've talked on and off about doing it, but never formally decided to
[21:57:09] <SWPadnos> because there's no way to gracefully do a callback for a parameter change (at the moment anyway)
[21:57:09] <jmkasunich> alex decided to stop talking and get started
[21:57:34] <seb_kuzminsky> there's no callbacks for pins or params, right?
[21:57:48] <jmkasunich> I don't think callbacks per-se are the issue
[21:57:49] <seb_kuzminsky> they're basically shared memory - you poll if you want to see them change
[21:57:57] <SWPadnos> so the components all have to check each parameter to see if it has changed, and whether that change requires some other internal state to change
[21:58:09] <SWPadnos> it's partly the frequency of changes
[21:58:10] <seb_kuzminsky> SWPadnos: and that's true for pins too
[21:58:21] <jmkasunich> SWPadnos: that is an issue (for performance), but it is not a difference between pins and params
[21:58:21] <seb_kuzminsky> you check everything each time through the loop
[21:58:41] <SWPadnos> no, you apply a formula to a pin (usually)
[21:58:57] <SWPadnos> PID output = (some formula based on input and
[21:59:02] <SWPadnos> params)
[21:59:05] <jmkasunich> you "apply formulas" to params too
[21:59:35] <SWPadnos> sur
[21:59:36] <SWPadnos> e
[21:59:40] <SWPadnos> argh
[21:59:44] <jmkasunich> heh
[22:00:15] <seb_kuzminsky> jmkasunich: is there any deep reason why hal objects (primarily pins & params) can't be created & destroyed at runtime (ie, between hal_ready() and hal_exit())?
[22:00:47] <SWPadnos> I don't think so - jepler had a patch to do that at one point
[22:00:50] <jmkasunich> can't do it in realtime code, because the process might block
[22:01:07] <SWPadnos> hmmm - maybe that's why it was reverted/never included ;)
[22:01:15] <jmkasunich> pin lists and other metadata needs to be protected against concurrent access
[22:01:22] <seb_kuzminsky> might block on the memory allocation?
[22:01:34] <SWPadnos> you need to search for name collisions
[22:01:38] <jmkasunich> might block because somebody else is accessing the metadata
[22:01:51] <SWPadnos> it's also an unbounded operation
[22:02:11] <SWPadnos> (practically bounded by the size of HAL shared mem though)
[22:02:59] <seb_kuzminsky> jmkasunich: isnt it the case that rt code might be running while a new rt component is added?
[22:03:06] <jmkasunich> yes
[22:03:13] <seb_kuzminsky> how is that different?
[22:03:32] <SWPadnos> the new code can't be executed until it has finished initializing
[22:03:41] <SWPadnos> and the running code doesn't need access to the metadata to do its work
[22:03:50] <jmkasunich> right
[22:04:09] <jmkasunich> loading a comp means that an interruptable thread of execution is running that comp's init code
[22:04:28] <seb_kuzminsky> when the new rt code is initializing, it's calling hal_pin_new() etc, which is preemptible (not yet rt), but it's modifying the pin list, no?
[22:04:35] <jmkasunich> that thread needs to access the metadata, and we have semaphores, etc to make sure it can do that safely
[22:04:42] <jmkasunich> that thread can also block
[22:04:53] <jmkasunich> yes, it is modifying the pin list
[22:05:10] <seb_kuzminsky> the rt thread takes a semaphore for the pin list, preventing hal_pin_new from running
[22:05:13] <seb_kuzminsky> ?
[22:05:14] <SWPadnos> the more interesting case is when you remove an active module while it's running :)
[22:05:44] <jmkasunich> seb_kuzminsky: no, the RT thread doesn't need to lock the list
[22:06:21] <jmkasunich> the only thing the RT code in a component ever does is access the values of its own parameters, and access the values of the signals that its own pins are linked to
[22:06:47] <jmkasunich> RT code never makes or breaks a link, or adds or removes anything from the lists
[22:06:55] <seb_kuzminsky> jmkasunich: ok
[22:06:58] <jmkasunich> and it never accesses any list item that doesn't belong to it
[22:07:29] <seb_kuzminsky> the pin list and semaphore are purely up in the non-rt kernel
[22:07:32] <seb_kuzminsky> where it's ok to block
[22:08:02] <jmkasunich> yes (to be pedantic, "changes to the pin list")
[22:08:18] <seb_kuzminsky> ok
[22:09:21] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/hal_priv.h?rev=1.30
[22:09:30] <seb_kuzminsky> thx
[22:09:32] <jmkasunich> that has the structs that make up the various lists
[22:09:52] <SWPadnos> even if a link is broken, the pin pointer is updated atomically to point to the dummy storage in the pin struct, so there's never a problem with writing to nonexistant memory (on architectures where a pointer write is atomic anyway)
[22:10:05] <SWPadnos> or reading from it, for that matter
[22:10:43] <jmkasunich> right - there is one possible "funny" thing that can happen when you remove a comp
[22:10:50] <jmkasunich> say you have comps A and B
[22:11:07] <jmkasunich> pins A.pin drives signal S, which is also linked to B.pin
[22:11:26] <jmkasunich> internally, S is the location of the value, and A and B both point to it
[22:11:43] <jmkasunich> if A or B is removed, nothing changes for the other comp
[22:11:55] <jmkasunich> the data remains in S, and is accessed there by the remaining comp
[22:12:14] <jmkasunich> however if you delete signal S, then A and B are both reset to point back at their own dummy value
[22:12:54] <jmkasunich> so B will see the value change from whatever S was, to whatever was in its dummy var, which by default is zero, but in any case is unlikely to match the previous value of S
[22:13:46] <jmkasunich> anyway, all of this is implementation detail
[22:13:48] <SWPadnos> right - we had discussed the possibility of replacing the dummy value with the signal value at disconnect time
[22:14:13] <jmkasunich> the distinction between pins and params (and whether we should preserve it) should be based on how people want to use them
[22:14:22] <seb_kuzminsky> that all makes sense, thanks jon
[22:14:27] <seb_kuzminsky> *john
[22:14:48] <jmkasunich> in theory, the change from param to pin can be somewhat transparent
[22:14:54] <jmkasunich> a param is set using setp
[22:15:09] <seb_kuzminsky> internal to the comp they're pretty different tho
[22:15:11] <SWPadnos> I like the idea of having things that are more or less private for the RT components
[22:15:25] <jmkasunich> an unconnected pin points to its own dummy storage, and if you issue a setp to a disconnected pin, the value will be written to that dummy storage
[22:15:27] <seb_kuzminsky> if they're private, don't export them to hal!
[22:15:32] <SWPadnos> but I understand that it would be good for userspace (at least) to have access to them
[22:15:46] <SWPadnos> no, not really private, just no way to get access to them in the RT code
[22:16:08] <jmkasunich> userspace is one application, but another (very important IMO) is tools like halscope and halmeter
[22:16:09] <SWPadnos> like PID (though I understand that some people may want adaptive PID, so maybe that isn't a good example ;) )
[22:16:27] <jmkasunich> many params are the equivalent of testpoints on a component
[22:16:41] <jmkasunich> not something you expect the user to connect to, but damned handy when something is amiss
[22:16:50] <seb_kuzminsky> i can see that
[22:17:10] <seb_kuzminsky> can halscope see params?
[22:17:14] <jmkasunich> yes
[22:17:29] <jmkasunich> halscope and halmeter both have three lists of viewable things, pins, params, and signals
[22:17:47] <jmkasunich> often the sig list is most usefull because it is shorter and has meaningfull names
[22:18:02] <seb_kuzminsky> i realize i'm the only one clamoring for this feature, but... i'd really like to be able to add and remove pins at runtime
[22:18:17] <SWPadnos> you're not the only one :)
[22:18:18] <seb_kuzminsky> what if we had a mechanism like bottom-half interrupt handlers to do it?
[22:18:33] <jmkasunich> from within realtime code? (a HAL function?)
[22:18:53] <seb_kuzminsky> the atomic context of the rt code schedules a non-atomic (preemptible) function to run after it returns
[22:18:58] <SWPadnos> synchronization would be a PITA I think
[22:19:06] <seb_kuzminsky> the preemptible code takes the sem and monekys with the lists
[22:19:15] <SWPadnos> sure, but when can the module use the newly created object?
[22:19:16] <seb_kuzminsky> SWPadnos: yes ;-)
[22:19:26] <jmkasunich> so you _do_ want to initiate this from RT code?
[22:19:37] <seb_kuzminsky> jmkasunich: i think so
[22:19:50] <jmkasunich> I was thinking more like "I would like another sum2 block, but I've already loadrt'ed it with count=2"
[22:20:05] <seb_kuzminsky> that would be nice too
[22:20:20] <seb_kuzminsky> here's my use case:
[22:20:32] <jmkasunich> we have discussed the idea of separating the current "loadrt sum2 count=2" into "loadrt sum2" and "newinst sum2 <optional-instance-name>"
[22:21:05] <seb_kuzminsky> "setp hm2_5i20.0.pwmgen.00.turn-on 1", and having the rt code respond by removing the gpio pins and creating pwmgen pins
[22:21:42] <jmkasunich> ok, you have two things in there
[22:22:03] <jmkasunich> 1) the idea of being able to change/add/remove pins after loading the comp, without reloading it
[22:22:13] <jmkasunich> 2) the mechanism of using a parameter to do it
[22:22:23] <jmkasunich> I agree that 1 is very desirable
[22:22:35] <jmkasunich> I'm not sure 2 is the only or best way to initiate the action
[22:23:02] <seb_kuzminsky> true, i just seized on 2 because the comp is what knows what pins need to be created and removed
[22:23:10] <seb_kuzminsky> maybe there's better ways to do it
[22:23:37] <jmkasunich> if I can stretch the unix "everything is a file" metaphor (a lot)
[22:23:43] <seb_kuzminsky> heh
[22:23:47] <jmkasunich> RT code is somewhat like read() and write()
[22:24:00] <jmkasunich> loadrt and friends are open() and close()
[22:24:12] <jmkasunich> and adding new stuff during runtime maybe like ioctl()?
[22:25:21] <jmkasunich> lets take your example - how many "turn-on" params (or pins) would there likely be?
[22:25:25] <jepler> I don't like ioctl() because it is not possible for sim -- sim should work without kernel-level access
[22:25:36] <jmkasunich> metaphor jeff
[22:25:38] <jepler> hi
[22:25:41] <jmkasunich> hi
[22:25:43] <jmkasunich> ;-)
[22:25:48] <jepler> I know I arrived late to the conversation, just wanted to get that in there
[22:25:49] <seb_kuzminsky> jmkasunich: one for each module instance, so call it 30 or 40 for now?
[22:25:53] <seb_kuzminsky> hi jepler
[22:26:19] <jmkasunich> ok - so the RT function that is part of the driver would have to sample 30 or 40 parameters every time it runs
[22:26:32] <seb_kuzminsky> yep
[22:26:34] <jmkasunich> 99.9999999% of the time it samples them, nothing will have changed
[22:26:45] <seb_kuzminsky> yep
[22:26:52] <jmkasunich> that doesn't belong in a RT thread, IMO
[22:27:02] <seb_kuzminsky> in fact i imagine folks will set these things at load time and then leave them alone
[22:27:07] <jmkasunich> this is where SWPadnos's hypothetical callbacks would make sense
[22:27:09] <seb_kuzminsky> maybe rt isnt the place for it
[22:27:23] <SWPadnos> sorry - the wife's here now
[22:27:31] <seb_kuzminsky> oh no the wife!
[22:27:32] <seb_kuzminsky> oops
[22:27:34] <jmkasunich> the user space code in halcmd that is executing the "setp" would ideally (somehow) tell the driver "check your params"
[22:28:23] <seb_kuzminsky> jmkasunich: that'd be nice for a lot of seldom-changing things
[22:28:27] <jmkasunich> and the driver would do that in a non-rt thread, running in the same context as the initialization thread - blockable, able to get the sem and modify the metadata, etc
[22:28:52] <seb_kuzminsky> there's still the issue of communicating the change in available pins to the rt thread
[22:29:20] <jmkasunich> well, only to that driver's RT code
[22:29:26] <seb_kuzminsky> right
[22:29:46] <seb_kuzminsky> maybe schedule a one-shot rt function that modifies the comp's internal state
[22:29:54] <seb_kuzminsky> a rt callback
[22:30:04] <jmkasunich> why does it need to be RT
[22:30:05] <jepler> my old implementation of newinst had two parts: first, write some stuff in a buffer. second, kick off the instance creating code. That part was different for sim or rt. in sim, it invoked rtapi_app in a special way; rtapi_apps have a way of communicating through sockets to get things done. in rt, it accessed a proc entry which was an easy way to cause some kernel-land code to execute
[22:30:38] <jepler> in neither case was this executed code in the real-time context, so it would be free for instance to call kernel device detection routines or register IO ports
[22:31:19] <jmkasunich> yeah, we need to be clear about the discinction between RT context and "normal kernel" contect
[22:31:20] <jmkasunich> xt
[22:31:52] <seb_kuzminsky> the rt code is reading & writing the pins that non-rt is creating and destroying, right? so there needs to be some communication between them about what's there
[22:32:17] <jmkasunich> actually remarkably little
[22:32:45] <jmkasunich> and it is all contained within the component, it doesn't involve unrelated components
[22:32:50] <jmkasunich> lemme find another source file
[22:33:01] <seb_kuzminsky> agreed, it's all within the one component whose pins are getting changed
[22:33:18] <jepler> if there's a "-all" function, it needs to start "running on" the new instance only after the instance is fully created.
[22:33:31] <jepler> beyond that, the normal "create functions last" order will prevent problems
[22:34:12] <jmkasunich> I think this is among the simplest C components
[22:34:13] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/components/supply.c?rev=1.19
[22:34:32] <jmkasunich> .comp ones add another layer, easier to write, harder to understand what is going on
[22:36:04] <jmkasunich> struct hal_supply_t contains the pointers (for pins) or the values (for params) - it doesn't contain the metadata
[22:36:26] <jmkasunich> calling hal_pin_new, etc associates metadata to the struct member
[22:36:34] <seb_kuzminsky> right, there each instance has its own function, so supply instances are fairly independent of each other
[22:36:54] <jmkasunich> you could define a big struct that has members for every possible config, and let the code access them (or not) by any method it chooses
[22:37:16] <jmkasunich> whether or not tell hal about those members is a separate decision
[22:37:46] <SWPadnos> hmmm
[22:37:55] <seb_kuzminsky> is that true? hal pins dont point anywhere in particular until you call hal_pin_new on them, no?
[22:37:59] <SWPadnos> (wife's upstairs now, so I can participate again ;) )
[22:38:09] <SWPadnos> correct
[22:38:21] <jmkasunich> seb_kuzminsky: true, I glossed over that part
[22:38:30] <SWPadnos> once you call hal_pin_new, they point to a dummy data value in the newly allocated pin struct
[22:38:44] <seb_kuzminsky> hal_pin_new both allocates memory for the pin and exports it to hal
[22:38:55] <jmkasunich> but it's a SMOP to have the components init code point them someplace safe
[22:39:19] <seb_kuzminsky> yes
[22:39:22] <SWPadnos> of course, if you called a hypothetical hal_pin_delete(), there could be issues
[22:39:33] <jmkasunich> hal_pin_new allocates memory for the metadata (which includes the dummy value), and points the pin ptr at the dummy
[22:39:40] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder.c: handle pauses that are => than 1 second
[22:39:59] <jmkasunich> the pin ptr already existed tho, it was part of the "hal_supply_t" struct (or whatever component specific struct)
[22:40:22] <seb_kuzminsky> jmkasunich: right
[22:40:40] <seb_kuzminsky> i think i see now
[22:41:36] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/config_gtk.c: fix config window so it does not open multiply times-is toggleable and displays message in status window now
[22:41:39] <seb_kuzminsky> the comp would initialize memory for all the pins in rtapi_app_main before hal_ready, but the pins would not necessarily be exposed to hal at that time
[22:41:47] <jmkasunich> right
[22:41:52] <seb_kuzminsky> a preemptible function would do that later
[22:42:01] <seb_kuzminsky> basically splitting hal_pin_new in half
[22:42:11] <seb_kuzminsky> hal_pin_alloc and hal_pin_export
[22:42:11] <jmkasunich> not really
[22:42:31] <jmkasunich> oh, I see - you want to allocate the dummy
[22:42:47] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder_gtk.c: fix config window so it does not open multiply times-is toggleable and displays message in status window now
[22:42:49] <seb_kuzminsky> dont we have to? so the comp doesnt have to be involved later
[22:42:51] <SWPadnos> how many pins though?
[22:42:59] <seb_kuzminsky> oh, tons
[22:43:00] <jmkasunich> SWPadnos: that would be component dependent
[22:43:12] <SWPadnos> should PID allocate enough storage for MAX_PID structs?
[22:43:13] <seb_kuzminsky> 500 maybe for hm2 on the 5i22
[22:43:21] <jmkasunich> seb_kuzminsky: there are at least three ways to deal with this
[22:43:43] <jmkasunich> 1) hal_pin_alloc allocates memory, either the complete metadata, or just the dummy, and points the pin at it
[22:44:03] <jmkasunich> hal_pin_export fills in and exports the metadata (and allocates space for it if needed)
[22:44:12] <jmkasunich> that is I think what you were suggesting
[22:44:12] <SWPadnos> unless you preallocate enough space for everything possible, you need to deal with linked lists or something else less easy than an array
[22:44:39] <jmkasunich> SWPadnos: what allocation are you talking about? the actual comp specific stuff, or the metadata?
[22:45:05] <SWPadnos> probably comp specific - maybe I'll listen for a bit :)
[22:45:13] <jmkasunich> every comp allocates structs or arrays or arrays of structs or whatever that contain the pin pointers only
[22:45:38] <jmkasunich> like "hal_supply_t" in supply.c
[22:45:39] <SWPadnos> sure, but loadrt pid count=2 means that the component only allocates an array of 2 of those structs
[22:45:50] <jmkasunich> correct
[22:45:57] <SWPadnos> instead of 16 or 32 or whatever the max is
[22:46:07] <jmkasunich> if seb is doing a driver that might have 500 pins, the struct would have 500 pointers
[22:46:20] <jmkasunich> so it would be about 2K - not terrible at all
[22:46:22] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/config_gtk.h: fix config window so it does not open multiply times-is toggleable and displays message in status window now
[22:46:34] <jmkasunich> OTOH, the metadata for 500 pins would be about 25K
[22:46:48] <jmkasunich> (or more, I think hal names are longer now)
[22:46:52] <SWPadnos> is that 500 pins * the number of devices supported by the driver?
[22:47:03] <seb_kuzminsky> if it's ten times that it's no big deal
[22:47:05] <SWPadnos> ie, 8 boards * 500 pins ...
[22:47:20] <jmkasunich> in the case of a driver, if you tell it you have 8 boards, then it would allocate 8 structures
[22:47:40] <seb_kuzminsky> in my particular case i dont allocate the hal objects unless the board is detected
[22:47:40] <SWPadnos> heh - no hotplug?
[22:47:42] <SWPadnos> * SWPadnos ducks
[22:48:00] <seb_kuzminsky> * seb_kuzminsky ducks too
[22:48:46] <jmkasunich> in the case of loadrt sum2 count = 2 followed by newinst sum2, you could either have the loadrt allocate 2 structs, and the newinst allocate another, or you could have a MAX_INSTANCES number, and loadrt would allocate that many, newinst would just use one already allcoated
[22:49:16] <jmkasunich> I think I'd favor the former - the latter is only important if one RT function needs to update all the instances
[22:49:45] <jmkasunich> anway, I was talking bout 3 ways to do it
[22:50:05] <jmkasunich> 1) two calls to hal lib, one to allocate, one to export
[22:50:57] <jmkasunich> 2) the component specific struct contains the pointers and a dummy for each one, the components init code points the ptrs at those dummys
[22:51:13] <jmkasunich> (not the dummies that might later be part of the metadata)
[22:51:46] <jmkasunich> then the RT code can do whatever it wants, and a later call to hal_pin_new will point it at the metadata dummy, and eventually (after a link) to a signal
[22:52:40] <jmkasunich> 3) the component specific struct contains only the pin pointers, and the component also has private flags. the pin pointers initially point nowhere, and the RT code uses the flags to say " I shouldn't access that pin"
[22:52:59] <jmkasunich> when the driver exports new pins (or deletes pins) it sets/clears flags
[22:53:32] <jmkasunich> flags need not be on a per-pin basis, the comp would do whatever makes sense
[22:53:53] <seb_kuzminsky> in 3, when does allocation happen?
[22:54:27] <jmkasunich> allocation of the pin pointers? they are part of the comp specific struct, there would be one per board allocated at loadrt
[22:54:37] <seb_kuzminsky> allocation of the dummies
[22:54:47] <seb_kuzminsky> allocation of the pin itself, if you will
[22:54:59] <jmkasunich> the dummies would be part of the metadata as now, and allocated when you call hal_pin_new
[22:55:33] <seb_kuzminsky> i dont understand 3
[22:55:38] <jmkasunich> "the pin itself" is a tricky term
[22:55:40] <seb_kuzminsky> or 2 i guess
[22:56:07] <seb_kuzminsky> how does a pin go from "hidden inside the comp" to "visible in hal" and back?
[22:56:21] <jmkasunich> is the pin the pointer that the RT code dereferences (part of hal_supply_t or whatever component specific struct), or is it the struct that contains the name, etc (metadata)
[22:56:31] <jmkasunich> if it has metadata, it is visible
[22:56:54] <jmkasunich> the metadata structs are the ones in hal_priv.c, and are maintained in linked lists
[22:56:59] <jmkasunich> hal_pin_new adds them, etc
[22:57:07] <jmkasunich> halcmd show traverses the lists, etc
[22:57:40] <jmkasunich> the pin pointer (or a parameter value) is not part of the metadata
[22:58:29] <seb_kuzminsky> ok i think i need to read the hal code
[22:58:45] <jmkasunich> pointer city unfortunately
[22:58:50] <SWPadnos> feel free to add documentation that makes sense to you :)
[22:58:52] <seb_kuzminsky> i'm ok with that
[22:59:04] <SWPadnos> there's documentation there already, but if it doesn't make sense ...
[22:59:05] <seb_kuzminsky> it looks pretty well commented already :-)
[22:59:08] <SWPadnos> yep
[22:59:14] <jmkasunich> the structs in hal_priv.h and hal.h are probably the most important things to understand, more so than the code in hal_lib.h
[22:59:44] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/hal_priv.h?annotate=1.30
[23:00:02] <jmkasunich> lets talk about pins - line 194 in the above file
[23:00:26] <seb_kuzminsky> i gotta go pick the kids up from preschool...
[23:00:31] <jmkasunich> ok
[23:00:39] <jmkasunich> I gotta eat dinner, so that works out
[23:00:44] <seb_kuzminsky> :)
[23:00:49] <SWPadnos> hmmm. food sounds better than kids ;)
[23:00:52] <seb_kuzminsky> ok, talk to you later
[23:00:54] <jmkasunich> I'll be around most of the evening, so we can pick this up later
[23:01:26] <seb_kuzminsky> i might not come on later tonight, i want to try out the 5i23 adn 4i68 support in hostmot2 :-D
[23:01:41] <seb_kuzminsky> but i might
[23:01:45] <seb_kuzminsky> otherwise, later!
[23:01:47] <seb_kuzminsky> buy guys
[23:01:50] <seb_kuzminsky> *bye
[23:23:32] <BigJohnT> I'm trying to do a cvs checkout on another computer... I did a export CVS_RSH=ssh but the checkout still asks me for a password
[23:23:46] <BigJohnT> does cradek need to do his voodo?
[23:24:05] <jepler> if you want a non-anon checkout, you either have to (A) copy your private key from the old machine or (B) send a new key to cradek
[23:24:25] <BigJohnT> ok I got it I think
[23:24:30] <BigJohnT> thanks jepler
[23:24:58] <jepler> if you just want a check-out now, put anon@ at the right spot in the checkout command
[23:24:58] <BigJohnT> hmmm, key where did I put the key
[23:25:19] <BigJohnT> I was wanting to do a checkout on my hardy machine
[23:25:36] <BigJohnT> I could do anon
[23:41:59] <BigJohnT> ok it works now
[23:42:09] <jepler> good
