hm forgot classicladder
hmm.. this is odd, some are double in the /var/lib/dpkg/status
fenn: build a package, install it, and see if apt breaks
cradek: I get too many config files in the emc2 package, which breaks apt
it seems apt only handles 32k of tagfiles (whatever those are)
our configfiles + MD5SUMs are bigger than 32k for TRUNK
by how much?
I'm rebuilding TRUNK atm, to make sure
some of those configs are crap, but I doubt half are
somehow things end up twice in the list I got
last summer I added configs/vismach with a few in it
jmkasunich: it's 697 vs. 286
but 697 does sound like a bogus number
I know my additions didn't cause the problem, but they contributed to it
it's not a big issue to move things to /usr/share/emc2/sample-configs/
oh, this isn't helpfull.. when an older config doesn't exist in the new package, it gets added to the list of configs, but marked obsolete
I think I just found a bug in the docs
juve@dapper-vm:~$ less emc2_2.3.0~alpha1.configlist | wc -l
manual for parport says: The address for a PCI card is usally shown in “lspci -v” in an “I/O ports” line, or in the kernel message log after executing “sudo modprobe -a parport_pc”.
but we've got parport_pc aliased or replaced or something, with "/bin/true"
yup, that won't ever work
but insmod /path/to/parport_pc would
hmm, I have three parport_pc modules, for three of the four installed kernels - but not for the rtaismp kernel
[00:22:11] <alex_joni> http://eneas.juve.ro/~juve/emc/emc2_2.3.0~alpha1.configlist
<- grep "emc2/sample-configs" from /var/lib/dpkg/status after installing emc2-2.3.0~alpha1 (RT version)
jmk-robot: probably didn't mark the module as M when building that kernel ;)
reboot might be fastest
lspci doesn't provide enlightenment
not even lspci -vv ?
[00:25:54] <jmk-robot> http://pastebin.ca/1337552
try sudo lspci -vv
but I don't see a PCI parport board
it is an onboard parport
then you won't find it with lspci
02:17 < jmkasunich> manual for parport says: The address for a PCI card is usally shown
I assumed (incorrectly I guess) that the onboard I/O was on the PCI bus
try BIOS, or the obvious 0x378, 0x278, 0x3bc
it is.. but it's inside one of the big chips
maybe hostbridge, not sure
aha.. it's part of 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
"The LPC Bridge provides a data and control path to the Super I/O (the normal attachment for the keyboard, mouse, parallel port, serial port, IR port, and floppy controller)"
which doesn't list any I/O regions
yup .. "nice" isn't it..
I found mention of the parport in lshal, but no addresses
tried one of the default values?
along with hal_parport
doing that now
I don't think I've seen a machine that doesn't use 0x378 in the last 2 years
you're beeing too thorough :P
[00:36:53] <alex_joni> http://eneas.juve.ro/~juve/emc/emc2-sim_2.3.0~alpha1_i386.configlist
<- from the emc2-sim package
I actually tried hal_parport with no cfg string first - I thought it used to default to 0x0378
the manual says there is no default now
emc2 manual, parport section
* alex_joni looks towards BigJohnT
I thought 'loadrt hal_parport' was the same as 'loadrt hal_parport cfg="0x378" '
so when I tried hal_parport by itself and it didn't work, I started looking for the address elsewhere
I think the manual is correct - it says you have to specify an address
"There is no default address; if <config-string> does not contain at least one address, it is an error."
can I hijack the conversation back to configs ?
its unfortunate that such errors are invisible
I'm the hijacker, sorry
it seems the config list is around 31-32k
(for both emc2 and emc2-sim built from TRUNK)
we can probably squeeze that to work, by removing some cruft/unused examples from the configs
but I don't think it's a long-run solution
yeah, but we'll be on the edge
for example configs/classicladder/cl-estop/*
that's a folder that isn't going to be understood by the config picker
and the config is generated by stepconf, not really usefull imo
I'm afraid I was too busy with robot stuff to pay much attention to the problem
then there's demo-sim-cl and demo-step-cl and so on
the base issue is that apt and dpkg treat all the sample configs as "configuration data" for the package, and they can't handle that much data
but for regular users dpkg is not existing
they will only see that once they installed an emc2 package nothing else will ever work again
no more updates, no synaptics, etc
something tells me that other packages don't deliver a large number of sample configs
not this large ;)
etc is not for "sample configurations" it's for actual configurations
thats where I was going
we put the files in the wrong place according to the debian way of doing things
jepler: I think we're fine for 2.2.x though
by the skin of our teeth
22k vs. 33k
ok, so the idea is to move the sample configs from /etc/emc2/sample-configs to somewhere else
that can be /usr/share/emc/sample-configs
right. under /usr/share/emc (a directory our package already creates) or under /usr/share/docs/emc2 (another directory our package already creates) seem like two likely places
the docs one seems like a better choice to me
many packages put example in /usr/share/doc/<packagename>/examples
think users go there more often?
users drool on pickconfig
if pickconfig can find them users will be happy
well, it will ;)
slip of the meter probe and another blown fuse
I need a fuseholder (the fuse is currently soldered in, and buried inside)
putting configs in /usr/share/doc/emc2/sample-configs causes some of the textfile to get compressed with gzip by default
alex_joni: comment out dh_compress in debian/rules
I added the relevant exceptions
(for example odg's can be compressed)
pdf, txt, hal, ini, clp, var, nml, tbl, xml
that works too
it seems to build ok, and run from the built package
testing run-in-place noce
ok, RIP works too
jepler: want me to commit this?
guess we can always revert ;)
EMC: 03alex_joni 07TRUNK * 10emc2/debian/ (emc2.files.in rules.in): move install location for the sample-configs from /etc/emc2/sample-configs to /usr/share/doc/emc2/sample-configs - should be transparent for the regular user, fixes a problem with apt (too many config files break apt)
EMC: 03alex_joni 07TRUNK * 10emc2/src/ (Makefile configure configure.in): move install location for the sample-configs from /etc/emc2/sample-configs to /usr/share/doc/emc2/sample-configs - should be transparent for the regular user, fixes a problem with apt (too many config files break apt)
alex_joni: I'm getting good at reverting :-P
but really, thanks for learning about the problem and then working on it
cradek: should I file an sf item about the "cutter comp not turned off after error" behavior?
um, I haven't been watching
I don't think ngc says what state the interp is in after an error
also I haven't figured out the system for erroring - seems like some errors cause an abort and no AXIS preview, some show the aborted preview
I bet this is related to that difference
cradek: cradek this was along the lines of "after one bad run, emc says 'can't change units in cutter comp mode -- oh well, I guess I have to restart emc"
(I think it's one of those things that m2 fixes)
it's sure a gotcha, though if m2 fixes it, all you have to do is teach each user of comp to remember to do it every time
how much state is available for troubleshooting after an error, which would be destroyed by automatically doing M2 after an error?
(ie, is there a downside to just doing all the stuff you do for M2 when an erorr occurs)
currently you get an error displayed but the machine keeps going, and when it gets to the error spot, it simply stops, leaving everything unchanged
I'm pretty sure other (?) kinds of errors cause an abort when the bogus line is interpreted
hmmm. I guess some things like offsets might get unapplied with M2, which could make you wonder where the machine thought it was
I'd prefer that abort behavior for emc's interpreter, but the run-blissfully-on-as-long-as-possible for AXIS's interpreter
oh - I didn't read back too far, so I probably don't understand the problem
maybe jepler is talking about 2.2, since you CAN change units with comp on
making the sample config files NOT apt "config" files might bite us
if a user changes a sample config and runs it from there, apt will now overwrite his changes without asking
don't users have to work to be able to write to those files?
users are surprisingly resourceful when screwing stuff up
well, that is truw
does feature freeze mean I can't commit a new hal comp?
what is it?
it takes a 2D vector (pins x-in and y-in) and rotates it by some angle, to give x-out and y-out
jepler gets to make the final decision but I bet it would be ok if you want it to be in 2.3
does it also take an offset as input? (so you can rotate about a point that's not the origin)
you can always subtract using sum blocks
I think alex is already testing packaging - this probably would affect his tests a bit.
I can just do it on this box and not commit it
committing is mostly for my convenience - makes it easy to get the comp onto any other box
but I really shouldn't need to do that anyway
maybe you should do it after the 2.3 branch then
i use local branches all the time to move not-ready-to-share software between machines (a couple of VMs and a couple of real machines)
does cvs have local branches?
yes, if you don't commit ;)
but if you don't commit, you can't fetch it from another system
"local" implies to me that you don't transfer it to the repo
SVN is a bit different from CVS in that it appears to have all the branches locally
there's a pivot command of some sort that lets you change to a particular revision locally
cvs and svn don't have local branches; i use bzr
git and hg (and others) also have local branches
I guess with SVN you'd also have to not commit
can't you create a branch and then "stash" it though?
in svn anyone with commit access can make new branches (svn cp trunk branches/my-branch)
but to share it to another computer you have to upload it to the central repo
this is pretty quick with svn, a cp is like a copy-on-write symlink
I thought there was also some support for swapping between branches (locally)
I guess cd../other-branch might do it ;)
git has a notion of "switching" which branch is "visible" in a checkout
strikes me as a bit weird
that's also where "stash" comes from
work on stuff, then stash those changes away so you can look at some other stuff on the unmodified branch
then get the stashed stuff back later
bzr calls that "shelve"
there's also "loom", which is even cooler... the stashed patches-in-progress stack on each other, and you can move up and down the patch stack, modifying patches as you go
with full commit/log/diff/revert on each patch
the bzr equivalent(or superset) of quilt?
built into the revision control system, instead of on top of it
it's more like mercurial 'queues' in that way, than quilt
damn. the gas height adjuster on my chair seems to be stuck in the "adjust" Position
so I sink to the bottom all the time, a kind of hard stop
retrofit with ballscrew, preloaded ballnuts, and servo
you know you want to
considering that it's still under warrantee, I may pass ;)
I'm very confused - PID is being weird
it seems like the sign of error is inverted
getting positive feedback?
(right now I just have the default gains: P = 1, others = 0
you're not using at_pid are you?
(not that I see anything in it)
I think I found the problem
I'm summing the output of two PIDs - one to steer, one to control speed
I forgot about the 2nd one, and had the summer gains set wrong
I figured ssomeone would have noticed 100% runaways by now
cradek: the other choice would have been to keep configs in /etc/emc2/ and really be carefull what to include there (strip half of the stuff from emc2/configs)
I don't think that's a better idea than biting users who mess around where they shouldn't
we'll put a big warning in the manual, and that should be it
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: add more info
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: some clean up
are the mailing lists broken, or is there a problem on my end? The last I have from any emc list is over 12 hours ago, [Emc-commit] TRUNK emc2/src Makefile, 1.281, 1.282 configure, 1.153, 1.154 configure.in, 1.156, 1.157
oh hey -- I ask, they arrive
rut row, test this axis is broken in 2.3 http://imagebin.ca/view/aNT3Nr.html
BigJohnT: I won't have a chance to look into that for a week, so please file it on sf so it's not forgotten
ok will do
have a good trip
thanks, I plan to
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/images/ (5 files): update images
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ (5 files): some clean up and image updates
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/install/installing_emc2.lyx: some minor clean up
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: more updates
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Linux_FAQ.lyx: clean up layout
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: more info added
BigJohnT_ is now known as BigJohnT
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: a few more edits
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/images/ (4 files): move images
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ (6 files): moved to images directory
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: minor edit