please dont require gnome for emc
right now, X is a dependency of the EMC .deb
neither X nor gnome should ever be required for a compiled version
actually, i dont think it is (or at least it wasnt two years ago)
oh - could be
I don't see X in the immediate depends, though I'd think that some of the tk items would pull in X for you
tk requires libx11 which requires x11-common which appears to be just some filesystem stuff
is there some tool for examining package dependencies that's better than synaptic or debconf?
probably, but I don't know what it is
right now i'm looking at 'apt-cache show'
jmkasunich - first run of the poke program hard-locked the PC :)
that's how you know it's working
but some of the LEDs did shut off, which is a good-ish thing
fenn: at this point I think configure requires some X devel stuff to be present, as does the runscript. nothing that somebody capable of putting together an xless distro couldn't handle, and if he sends patches I'd likely want to see them incorporated
this business about gnome is for a particular GUI tool, but because we make the emc package monolithic it'll be a requirement for anyone who installs the official .deb package -- but if you want an xless distro you are probably not starting with ubuntu, "server install CD" notwithstanding
right, but the .deb is still useful for other situations
like that guy in brazil for example
what's the main advantage to using the wizard widget?
it automatically does .. stuff
it does the right layout of the screen so that it looks like other gnome wizards -- so user experience is better
i can't even get glade to tell me why it's crashing because i dont have gnome-desktop properly installed for bug-buddy argh
fenn: visualize deb dependencies with graphviz: http://netthink.com/archives/date/2007/04
"To start, I wrote a simple script in Ruby (my first Ruby program) to recursively call "apt-cache depends" beginning with the debian package of our choice. The script results are a recursive list of package dependencies output in DOT graph format, which you can then enter into Graphviz to create your graphs."
heh - that's cool :)
looks like his example .svg files are served with the wrong doctype or something, but they display in eog after download (I tried the gnome one)
I did figure out what I did wrong to cause the hardlock - it helps to write to one of the regions that goes to the FPGA instead of writing to the PLX9054 control area
any method to choosing FERROR / MIN_FERROR values for stepper systems?
some small number of steps maybe?
more than one step
there may be a way of calculating it based on the ratio of BASE to SERVO periods plus accel and maxvel
is there some harm in making the values too large?
but I really don't want to think about that right now :)
I bet there isn't
truly huge (e.g., 1") and obviously you'll start to hide insufficient step rate
as long as - right
right now stepconf simply has hardcoded values, not even dependent on machine units
print >>file, "FERROR = 0.050"
print >>file, "MIN_FERROR = 0.010"
there still needs to be some way of telling the user that they can't do what they want if they configure a speed that the base period cn't manage
jepler: those might be a bit small for mm
I'd just take 5 or 10 steps and round up to the nearest "round" number
for now I'll put 1 / .25 for mm
ferror is checked before outputting a new position, right?
I have to read the source every time I want to know the details
I'd have to figure out how to read it, so you're at least one ahead of me there
but then what are you going to use all those AT supplies for?
Note that in the GIT newspeak, the operation being performed by cg-update is now called pull, even though in the past, pull was the name for the operation being now done by cg-fetch, which is even still aliased to cg-pull. Please do not let this confuse you. (Cogito won't call this update operation pull, since about everyone but GIT and BK users uses it in the fetch meaning.)
well *now* I am enlightened
obviously you're not a BK user
It's been about 6 years since I ate there
[02:55:42] <jepler> http://git.unpy.net/view?p=stepconf.git;a=commitdiff;h=313fe88353356ae87c3125882181b24e65038686;hp=c5dff0d5569c3fe987ef7e7aee4de548ea2ac530#patch2
^^^ git even properly represents the change in file modes when I decided to make stepconf.py executable
you can do that with cvs - just change the permissions on the rcs file
but will CVS notice that and log the change?
not even close, no
didn't think so :)
I was kind of joking
the permissions beome different through all of time
just curious, why didnt you switch to svn when moving away from sourceforge?
jepler: will you check in stepconf soon?
cradek: yes, soon
fenn: please read the archives if you're curious about historical arguments
see you. it is getting late, isn't it?
the dependency visualizer doesnt actually draw all the dependencies...
I'm torn about using "spinbuttons" (those entry fields with up/down arrows at the right-hand side) in stepconf
on the one hand, that seems to be the gtk way of restricting a field to contain a number
on the other hand, it means I have to choose minimum and maximum acceptable values for each field
on the third hand, I should go to the office
Guest222 is now known as skunkworks__
on the gripping hand, well, I don't know
skunkworks__ is now known as skunkworks_
so, does anyone have an opinion on whether I shuold commit this PCI utility that lets you hardlock your machine pretty easily?
normally - that is called a virus..
though it does require a MESA card
a very specific virus..
viruses don't generally have rights to hardlock Linux computers :)
but this gets setuid, so it's easier ;)
any ideas on why it is doing it?
yes - it works as designed (worked first time, I think)
but if you tell it to write the wrong thing to the wrong place, the machine can lock
ah - cool - I think ;)
I discovered this by writing the wrong thing to the wrong place the first time I used it :)
SWPadnos: is it useful when you aren't running it with the wrong arguments?
then I guess you should stop writing the wrong things :P
I can probably restrict it to only write to RAM and user regions, which should make it less likely to hardlock the PC
though it could be more useful the way it is - it could be used to change PCI bridge options
I am sure there are already plenty of ways you can lock your system up if you have the power to run setuid binaries that come with emc2
(halcmd loadrt threads period1=1000 and so on)
I'll add some comments and commit it then
in a sense, it forms the backend for a generic PCI card tester
except that you can't read from the card ;)
so, this program is primarily of use to developers (of FPGA configs), any preference as to where it should go?
jepler: what values are you considering putting in spinbuttons?
the source is currently in hal/utils (along with bfload), and I currently have the executable going to the bin dir
cradek: all the numeric ones with the exception of parport address because spinbuttons can't seem to show numbers in hex
I found that scanf "%u" also doesn't seem to like hex
don't spinbuttons just take integers?
0x378 is an integer
right but scale isn't
no, these can contain floating-point numbers
dargh, I also have to choose the number of digits to display
use another spinbutton for that
just use text entry widgets?
* SWPadnos ducks
cradek: well, that's where I started
can't you just validate them when the user hits next?
nobody is going to enter Input Scale: PANTS
if they do, you should tell them they screwed up
I would, just to see what happens
naive me, I figured that using the gtk widget specifically for the purpose of accepting a numeric value would be the easiest way to "validate" these fields
just because of this discussion, PANTS should now be a special keyword in stepconf, which means ... 42
or e or pi or something
so-o-o -- how many digits after the decimal point should I allow for "Motor steps per revolution"?
no, it's got to be float
is the backend python?
err - nevermind
0 is fine
what motor has a non-integer number of steps?
* cradek squints at SWPadnos
I was thinking UNITS, forgetting that this app calculates that for you ...
by the way, can we please change INPUT_SCALE to OUTPUT_SCALE for stepper systems???
especially with all the questions about steppers+encoders lately, it's likely to be a point of confusion
as far as I can tell from a bit of grepping, INPUT_SCALE isn't actually used in "the core" anymore, it's just used in hal files
right - hal and ini
how about SCALE ?
I thought one or more guis read that value for some debatable reason
they can be fixed to follow the new standard with fallback
for jogging something
at least the ones that are actively maintained and live in the source tree
xemc uses it to set the smallest jog increment
ok, simple to fix
I think axis uses it to decide the lowest useful jog speed
the lintini.py script checks it
you're supposed to be able to get 1 step per second
iniaxis.cc still refers to it, but I think that line is in a comment
hmmm. any idea what went wrong if I have a zillion .o and .mod.[co] files in my emc/src directory?
shouldn't those be in objects/ or something?
can't help that
they get created in the dir from where the build invokes the build in the kernel dir
ok - I just don't remember seeing that stuff in src/
and you have to use relative paths to that dir
try make clean :P
SWPadnos: kbuild shits those in working directory and I don't know how to fix it
yeah that's a "feature" of kbuild
(or alongside the source file as the case may be)
ok - no problem. I just didn't remember seeing that before
seems you didn't compile emc2 in a long time :P
maybe PM him and see how much he wants.
prime minister him?
is that some kind of slang or double-entendre?
any updates on the bot?
if I do, he'll think I'm trying to steal them from you
I got a dial indicator and measured that the table varies by 0-10 on X and 0-5 on Y (mils, I think) .. then I broke the dial indicator mounting trying to reposition it and didn't touch the machine the rest of the weekend
heh - I could private message him and tell him to look for you PM
if you are interested
jepler: ouch. I know how you feel.
what part did you break?
"Hi, it's my mill that Sam is asking about. He pointed me to your message. ... "
cradek: I bent out the claws that hold the ball in
cradek: sure - If he has any doubts - He can always pm me and ask..
skunkworks_: I sent it, thanks
wouldn't kill me to have his spare amps too
strange - no commit message / cia message from my earlier commit
but the files are in CVS
/var/spool/mqueue is empty
Total requests: 0
it'll come I bet
was it 08:36?
1+ hour ago
ok - cia works from a mail also (?), so upstream mail server problems would affect both
yes, sounds right
I don't see any sign of problem on our end
have you gotten the message?
err - received the commit message :)
hmm - must have lost internet at home..
wonder where it went
more likely - the wife unplugged the laptop ;)
they seem to do that, don't they
alex_joni: vacation was good?
yeah, but after the day I had today, it's long forgotten :D
or was the day so good that it made your vacation look like work? ;)
haha, I wish
Is there a handy way to tell EMC that an axis is not homed any more?
Didn't think so.
Is there a any way to tell EMC that an axis is not homed any more?
start homing then estop
heh, I wouldn't have thought of that, but I bet it works
I don't think abort even works on homing these days.
yes it does
I thought I hit abort during a home and nothing happened.
how sure are you? I'm pretty sure it works.
Okay. I believe you...
I thought both it and feed override were locked out during home
I tested abort and it works fine
heh, that's a crazy idea :)
* alex_joni likes it
The question was why does an estop not cause the loss of home position.
I would think that would only be a problem on a non closed loop system
my bridgeport makes me rehome after estop, but I don't know why it should
as long as the encoders have power I don't see why position would be lost
because some machines can keep position over estop? (i understand that many can't, either because they're open loop or the encoders are among the things that lose power in an estop)
I think most machine tools require home after estop.
that aside, can you say why? I don't see why it's always necessary
With steppers I'd guess that they don't ramp down and can loose steps.
yes steppers will definitely lose position if you turn off the drivers
But that is one of those things that should be configurable by parameter so such.
or such integrator configuration variable
maybe there should be a 'position lost' input to axis.N; then an integrator would have the freedom to make estop (or other things) unhome an axis
I think I agree with jepler
for instance you could hook /amp-enable to it
because for my stepper mill, it's NOT estop that causes (potential) loss of position, it's amp-enable off
How you doing Alex
pretty nice, just finished vacation
How is the family?
weeell.. vacation was nicer
all is well, thanks for asking
I hope the same on your end?
rather vacation then end-of-vacation 'eh.
Only one kid in crisis and that's her own making... job change.
rayh: you have kids? I didn't know that.
grown and mostly gone.
its the ones that keep coming back you have to worry about ;)
and their friends ;)
I still like em a lot even most of the friends.
are any of them into cnc?
Sharon was very happy with the way you interacted with your granddaughter, FWIW :)
I answer to most any name.
My father was a totally different person after the grand-kids. Hi dad ;)
Hey granddaughter is taking horse riding lessons.
cool. one of my nieces is very into horses as well
Tell Sharon hi and thanks.
she's taking horse acrobatics classes - the kind you'd need to join a circus
I'm trying to remove my admin status at sf. It says, " Project administrators are not permitted to remove their own admin status. Please have another administrator on your project remove your admin status,"
it's a race condition
Don't everyone trip over each other helping me.
I would appreciate it if one with the ability would do that for me.
hopefully one of those who's used to adminstering SF stuff can do that :)
If you are logged in you can administer members. click on my name and tick the admin box.
I can do that ray
any reason for it?
Hey thanks. Now I can rag on the rest of the "dead" admins to get themselves conformed to the current state of the project at SF.
After it knows which pins an axis are on, seems like a SMOP to let the user test an axis while varying the accel and vel constraints: http://emergent.unpy.net/files/sandbox/stepconf-test-axis.png
when you press "Go" it will begin commanding a trapezoidal-profile move around the current position according to these limits and the scale specified elsewhere
any reason for trapezoidal?
I suppose you use siggen for the signal
well, maybe I can do it with a combination of existing components
but at the larger level I need something that takes as inputs "Go", "Jog-", "Jog+", "Accel", "Vel", "Test Area" and gives as outputs "Step" and "Direction"
it sounds like siggen to me
test area = amplitude
yes, a square wave from siggen plus accel/vel limiting in limit3 or stepgen is not far off
but I'd use sine (much smoother profile)
in some sense I don't want a smooth profile -- I want a profile similar to the one emc will throw at it
a sine position corresponds to what emc outputs imo
or is that better than limited accel?
limited accel = triangle velocity profile = sine position profile
I mean trapezoidal velocity profile
but I don't think that's sine position profile
it's .. something else
a section of a parabola, followed by a constant-slope line, followed by some other more different section of parabola
SWPadnos: you saw those compile problems right?
jepler: if it's small enough you can use a sine instead
I mean, that's what I use when I first try to spin a stepper
skunkworks_: that guy wants $50 to copy the manual!
skunkworks_: he also implies in his message that the drives are worth $350 or more, each
well - it takes all kinds I guess
sorry - back now
forgot to add a file maybe?
no, I was going to split some common info into a header, and I forgot to remove the include when I decided against it
well, CIA seems to be working again
the farm will have to make clean, or someone will need to remove the bogus .d file
curse that stupid build system deficiency
I guess we'll see what happens :)
seems like it sometimes cleans, I don't know what causes it
I think some builds are done with "clean" first and others aren't ..
wasn't it a build fail that makes it clean?
I thought that was added
it probably should make clean on the build after a failure
(if it doesn't already)
maybe it does
if so it would have cleaned after the earlier failed build
that was my thought
git is soooo nice to use. since everything but push & pull is local, it's all very fast.
I'm not sure how it works when multiple developers all "push" to the same master
hmmm. that's a good question
another shortcoming is that unlike cvs it's not an essentially monolithic binary -- in fact a lot of it is shell scripts, with some python and/or perl thrown in for good measure.
the Linux kernels have a gatekeeper for each version I think
last I knew (a while ago), the maintainer for each branch would either merge patches or pull changesets from developers
I don't think it operates the same way as CVS regarding multiple developers "checking in" changes
but since the anonymous server can be a dumb HTTP server over the filesystem, you can give anonymous access without giving a shell equivalent
any developer already gets a lot of trust (I could put a line in Makefile and root a bunch of developer systems before it was noticed, not just cvs.linuxcnc.org)
that would be annoying
looks like it works pretty similar
in 12 hours there will be an automatic full build
if I 'push' but someone else did since I last 'pull'ed, I get an error:
error: remote 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'. maybe you are not up-to-date and need to pull first?
I then did 'git pull && git push origin' which merged the other change and then the push succeeded
so that leaves the question of whether two simultaneous 'git push' operations are locked against each other, otherwise it acts a lot like CVS
did you have changes to a single file in both changesets?
yes, I had changed the same file
hmmm. I wonder where the changes were merged - at pull or push stage (or both, solving the 3-way problem by making it two 2-way problems)
I think 'pull' does it
'pull' knows the common ancestor so it can do a 3-way merge with (ancestor, new1, new2)
[21:33:57] <jepler> http://emergent.unpy.net/files/sandbox/git-merge.png
some of the hostnames are funny because I didn't have my environment set up right..
I like jepler@sofa :)
yeah if only @india were literal to
so just like CVS, resolving files that have been changed by two people is the responsibility of the second person who finalized the change ("commit" in CVS, "push" in git)
* alex_joni heads to bed
good night guys
good night alex
I'm convinced that anybody who knows CVS could adapt to git pretty easily .. two cases: CVS is known by rote? learn git by rote. CVS is known by deep understanding? git is understood soon enough.
see you Alex
other case: CVS is known by consulting the manpage|web|other developers every time: GIT is already known to that level of proficiency :)
I also like the gitweb.cgi interface better than viewcvs-style, since it's centered on revisions and not files .. http://git.unpy.net/view?p=stepconf.git;a=summary
yeah - it doesn't seem all that easy to look at "what changed recently" in CVS
though history of an individual file is still available http://git.unpy.net/view?p=stepconf.git;a=history;f=stepconf.glade;h=a38d35c804df6e4d814809a195dffca24665999b;hb=14763e96a3be1b9ab93823b9c8f6ba8953e9e7cb
one big downside is that the initial checkout takes much longer.. you effectively download every revision of every file ever, even those now removed from the tree
(and the attendant disk usage)
did you import the CVS repo into git when you started fiddling with it?
I have imported emc2's CVS into git, but in this case I have a repo with just stepconf in it
ok. just wondering about the actual HD (and therefore bandwidth) usage of the whole EMC history in git
looks like it was about 27 megs on 9/6
that's september 6
ok, that's not much
I know Linus basically didn't care about disk usage when writing git
his argument was more or less "buy a 1G larger hard drive for $0.50 more"
and mow it's only $0.20
~10 minutes to download on cvs.linuxcnc.org's pipe (384kbps) though, and that's if you're not competing with anything else
I'd love to set it up on DH, but there's the problem of no root access and that kind of thing
hum, I wonder if that 27 meg figure is right
I have several versions and one of them is 65 megs
du . -hs ;)
I updated and put it on git.unpy.net for fun: http://git.unpy.net/view?p=emc2.git;a=summary
however, it may be damaged -- I can't "git clone" from it
* jepler removes and imports from CVS again
SWPadnos: but you shouldn't be expressing interest in this now.. you should be working on your proyec
I get 403 forbidded trying to look at the diff from that last commit
probably because I removed it
oh yeah. thanks
I figure you must have forgotten
oh, that could be
not bloody likely ;)
Committed patch 239 (origin +0000 2004-06-12 17:00:21)
the import takes awhile
are you doing that locally or over the intarweb?
Committed patch 307 (origin +0000 2004-09-05 14:13:48)
ok - I imagine it's a lot slower remotely :)
I'm sure; if anyone but me were to do this, he should start with a copy of the CVS repository on local disk
luckily that's downloadable from DH
supposedly you can keep a git repository updated from CVS, not be forced to redo it from scratch every time
Committed patch 1201 (origin +0000 2005-11-06 22:16:20)
it's done, and the new number is even smaller: 16832kb
(size on client after 'git clone', it's a bit bigger on the server and I am not sure why)
time to clone (equivalent to 'cvs co') on local network: 30 seconds 'real'
time to pull (equivalent to 'cvs up') on local network: 7 seconds 'real
hm, then I broke it
apparently the dapper version of git doesn't know about whatever 'git-pack-refs' does on the server
I'd call whoever made that decision a complete crack-addict and total
idiot, but it might be me, so I'll just tread carefully and call the
so jmkasunich, you got the loader working, and I got the tester working (though the compile farm may lie and say it doesn't)
we now have the ability to program and operate 5i22-1.5 cards
* jmkasunich is still reading back
I haven't tried to load a bitfile generated with your UCF file yet though
damn you guys talk a lot
mostly drivel - you can probably ignore it
(at least when I was here)
yeah I don't remember anything of substance...
oh - rehome after abort/estop
that's possibly of interest
finally caught up
I just kicked off complete builds on the compile farm
ok. that would have been automatic at midnight though, right?
it would be automatic on the first commit that is 12 hours or more after the last complete build
I thought we had discussed doing complete builds after failed ones, but maybe there was some problem with that idea
I really like this new box
a wee bit faster?
the main downside of that is that 95% of failed builds don't need a make clean, and when you are trying to fix a problem is when you appreciate the speed of incremental builds the most
although maybe with this new box that doesn't matter
all three complete builds are done
that was at least 30 seconds
all green now
do you have a -j in there, or are the VMs uniprocessor?
longer than that, I said that I kicked them off after doing the last one, each one takes a few lines of typing
actually, you could probably use -j 2 or -j 3 on UP as well
the VMs are uni, since I simply copied them over from my older box
its fast enough that I'm not gonna spend any time tweaking it
I just realized that with the VMs on my new machine, the dapper build is massively out of date
(since I didn't use a VM for that)
I haven't run the farm scripts on my dapper RT box in a while
how big are the farm VMs?
in disk space, that is
8G I think
probably about half full
are the disk images full size or sparse mode?
my understanding is that full size is either more robust or faster or both
yes - certainly more robust if the host disk ever gets close to full
it takes a while to move a VM from one machine to another, even over 100M ethernet
do you know how well they compress?
I'm wondering if it's feasible to stick copies on linuxcnc somewhere
I'm sure its gonna be at least the better part of 1 gig each
they are complete ubuntu installs, plus other stuff
yeah, I'd imagine
the VMs themselves aren't irreplacable - you can always do a fresh install on a fresh VM
the farm scripts are in CVS
yeah - that's true
it would be kind of nice if the CVS server was in a VM
there's a copy of it somewhere
thats good to know
I think that's how it is anyway
I think you are right - ISTR cradek telling me about that
you should know - you have cvs2 ;)
CVS2 was a slot in the old cubix rack
which went bye-bye in December
righto. I wonder if I shuold remove it fom DNS