cradek: so I think after removing those ttf- packages, if I remove all the compiz stuff it will be small enough.
since we tell people to turn off desktop effects anyhow, shouldn't that be fine?
sorry to say it, but I have not seen problems with desktop effects vs opengl on lucid
hmm, what about rhythmbox? it's pretty large, and there would still be totem for playing files
that sounds fine to me
ok, I still need to trim off 21 meg from the iso. any other ideas of things to nuke? f-spot?
I don't know how to pick :-/
you're trying to get down to 700MB, not 650MB, right?
I fixed the spindle - motor is beyond repair
so I need to find a way to get a bit of 10krpm from 120vac
cradek: yes, 700 mb. I removed evolution and still need a little more! I'm still thinking replacing openoffice may be the best route.
is that the spindle on junior?
no, on max
[03:07:21] <cradek> http://timeguy.com/cradek-files/emc/stethem-spindle-on-max.jpg
does anyone have any thoughts about how I'd find a replacement motor like that?
the motor plugs directly into 120vac and spins about 10krpm
That would be a universal AC motor. http://en.wikipedia.org/wiki/Electric_motor#Universal_motors
aha, that's an important keyword
np. dremel goes up to 30,000 rpm Maybe you could use one of those?
Actually, it's just a universal motor: AC or DC
yeah I wonder what I'd get if I took a dremel apart
I've had them apart. I don't know if you could do much with it, but you might could mount a pulley in one!
haha, I could put a pulley in the dremel collet
probably. and the collar unscrews and you can mount it in a threaded hole.
I will keep that in mind as a backup plan - sounds mechanically less elegant that what I had
[03:27:12] <mozmck> http://cgi.ebay.com/120V-AC-DC-HIGH-SPEED-ELECTRIC-MOTOR-1-5-HP-TOOL-/230487053082?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item35aa19531a
livecd is down to 708 meg
very close - but looks too big
for scale, the spindle in that picture is 3/4" dia
rotary table is 4"
yeah, I think I've seen those being sold somewhere.
708 is close - sure is hard to get those last few megs
I removed ubuntuone and transmission (bittorrent client)
If I replaced openoffice with abiword and gnumeric it would be easy! Then I'd have extra room. but that may not be best either.
also removed f-spot
evolution and pitivi as well
[03:31:27] <cradek> http://cgi.ebay.com/110-Volt-AC-DC-Motor-High-RPM-/350283446924
I think this is the exact motor that's on it
oh well, bedtime good night.
considering andypugh's mail: I bet this means I don't have index homing either
I hope seb will have an idea why that change fixes index! It seems implausible to me.
I bet some status bits get cleared when you read them, so the 3ppwm read clobbers them
or something like that anyway
EMC: 03jepler 07v2.4_branch * r653d1eafde97 10/configs/ppmc/ppmc.ini: use Axis GUI
EMC: 03jepler 07v2.4_branch * rdb25ffc927e5 10/configs/univpwm/univpwm_io.hal: update for pendant
EMC: 03jepler 07v2.4_branch * r070c920c4b77 10/configs/univstep/univstep.ini: update to Axis GUI
EMC: 03jepler 07v2.4_branch * r1cbfd739c2ba 10/configs/univpwm/univpwm.ini: update to Axis GUI and add some uptions
EMC: 03jepler 07v2.4_branch * r4bf6ba1f3978 10/configs/univpwm/pendant.hal: add pendant file
EMC: 03jepler 07v2.4_branch * rc32299c24037 10/src/hal/drivers/hal_ppmc.c: make error message more informative
EMC: 03jepler 07v2.4_branch * rd3cbdd4318e8 10/configs/univpwm/spindle.xml: add spindle display xml file
EMC: 03jepler 07v2.4_branch * r69d182a28a89 10/configs/univpwm/spindle.hal: add spindle speed hal file
speak real soon if there's anything else that needs to be done before 2.4.2!
thanks for finding the cause of that encoder problem
did the changes that allow direct input to feed override get put into 2.4?
no. that new feature is in master only.
Building 2.4.2 now. Same as tip plus version bump and changelog. Lots of stuff there!
mozmck: are you building cds because you are satisfied with the kernel? If so, let's get a proper package repo going on linuxcnc.org.
The cd needs to ship with an apt setup that can get updates later without more configuration, and that depends on having a debian repository for that version of ubuntu
I recall something about homing to index having a problem is that in dev too?
the homing to index problem was not in v2.4.x, it was only in master
that's what I run on the lathe
I should get that fix pushed, though
I just did a git pull on master does that include the fix?
now it does, a minute ago it didn't.
EMC: 03jepler 07master * r953ad5fc206d 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: hostmot2: fix encoder index bug introduced at c9add70
ok, I got it
did the bug cause the home to miss an index and not home to the same spot?
probably that's something it could make happen
I just centered my drilling holder with my test indicator then shut down EMC and started back up then homed and reloaded that tool and it is exactly in the center of the spindle at X0
yesterday I zeroed the same tool holder and just a few minutes ago X0 was off about 1/4" from center
so you mean you think that change from a few minutes ago fixed a problem?
if so, good :)
yes, I was scratching my head after my chicken check when the tool was off by 1/4" from center at X0
then I remembered something about the index bug...
I have some reservations about the patch Don't know if Andy P is here but the tppwm code should not touch the encoder hardware
I don't think it does (not intentionally anyway)
hm2->llio->read(hm2->llio, hm2->tp_pwmgen.enable_addr, hm2->tp_pwmgen.enable_reg, (hm2->tp_pwmgen.num_instances * sizeof(u32)));
I was trying to make sense of the patch
the modified function is the one that does all the reading for each different module
JT-Hardinge: "chicken check"?
yes, move to a known place and see if it is correct on the DRO ... I'm chicken to just let it fly :)
got bit twice on the lathe...
just double checking it's what it sounded like, our boss is more "set tools, set workshift, close doors, hit cycle start" (he hates seeing us single blocking and using 1-2-3 blocks to check tool to part positions)
ah git, you give me enough rope to shoot myself in the foot
:( but at least I noticed the problem before I signed the repository with those packages :)
uh-oh, what'd you do?
I nearly released without those last ppmc-related changes is all (but with the mentioned in the changelog)
so, 2.5.0 next weekend?
(I'm sure thrilled with the rotation stuff and touchy improvements)
you people are sure all using master again quickly
you, jt, andy...
yeah, I just switched.
does anyone understand the cause and fix of the index problem?
There are no read side effects in currently supported HM2 hardware
looks like maybe the hm2_tp_pwmgen_read breaks tram reads somehow (and it looks like it should be a tram-read anyway)
cradek: did you have the index problem on your lathe?
JT-Hardinge: I haven't updated the lathe for ages
smart move sometimes
JT-Hardinge: are you a 5i20 user?
yes on both the hardinge and the plasma
Hey all, I'm doing setup on a stepper gantry mill with a 5i23 and 7i47. Yesterday I had motion going pretty nice and smooth. Today I tried to get position feedback going with my quadrature input, and changes to my hal/ini files made motion really rough. I went back to the old (smooth running) hal/ini files, and the problem persists!
Any ideas how that could be?
I haven't touched my wiring at all, I've power cycled everything in the system multiple times, I've gone back several versions in my hal and ini files
lepton: response on #emc
thansk cradek :)
please don't jump in here if someone doesn't have an answer right away on #emc - we like to keep this for devel talk.
indeed, sorry for that
pcw_home pointed me here
EMC: 03jepler 07v2.4_branch * rba91b0556365 10/ (VERSION debian/changelog): release v2.4.2
it'll be awhile before packages get online
great, there are master vs v2.4_branch conflicts in pncconf.glade again
I wonder why his luck with glade seems so much worse than mine
I wish I knew
I stupidly started up IRC then went into the garage for 4 hours..
Any idea what that encoder problem is ?
andypugh: no, but you said your change fixed it so I believed you
I think we're all scratching our heads a little bit about it
Yes, but, all I did was move the call to the 3pwmgen service routing to after the call to the encoder service routine. I am still left with the assumption that something in the 3pwmgen routine (all 4 lines of it, testing a flag) is either writing to the encoder index reset, or leaving something on the stack, or has a pact with Beelzebob.
Shouldn't the fault read call really be a tram read anyway? (since its done every time)
It should, but I got the impression that tram read wasn't actually working at the moment.
I might be wrong about that, it's been a few weeks.
Its not doing anything useful at the moment, but I was thinking maybe mixing normal read and tram reads was what causes the bug
ultimately tram read should speed up the 7I43 data transfer about 33% and smooth the transition to DMA on the 9054/56 based PCI cards
I think I might just have got lazy, deciding it wasn't worth the bother for reading one bit of one register.
(and make future packet based interfaces easier to support)
There is a tram_write function in 3pwmgen.
The theory is that things that are done all the time are done with a packetable interface
and only setup or exceptions are done in the plain read and write routines
(this is not quite the situation now but I would like to head that way)
I will investigate changing it. I also noticed a few missing bits in the main Hostmot2, HM2_PCI and hm2_7i43 files, places where there is a mention of a pwmgen, but no 3pwmgen.
I have now notinced that the missing bits aren't missing.
And I also think I see why 3pwmgen has no tram read, it is because normal pwmgen doesn't have one and I was just blindly copying.
Shouldn't be any functional difference, just a matter of style for now
jepler has changed the topic to: EMC2 development -- http://linuxcnc.org/
| Latest release: EMC 2.4.2
jepler: thanks for doing the release! I like how you arrange the release notes by category.