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