Back
[00:15:36] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch 0b5fce5 06linuxcnc 10docs/src/hal/comp.txt docs: fix up some comp docs that had rotted a bit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b5fce5
[00:16:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-comp-fix fc2068c 06linuxcnc 03tests/biquad/expected 03tests/biquad/runstreamer 03tests/biquad/test.hal add a very basic test of the biquad component * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc2068c
[00:16:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-comp-fix 8630421 06linuxcnc 10src/hal/components/biquad.comp biquad: fix a crash-when-enabled bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8630421
[00:16:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-comp-fix 938881f 06linuxcnc 10src/hal/utils/comp.g comp: remove an unused and confusing global variable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=938881f
[00:16:48] <seb_kuzminsky> cradek: 2.5-comp-fix fixes the bug gaston48 reported on the forum,
http://www.linuxcnc.org/index.php/english/forum/24-hal-components/27804-rt-component-biq
[00:17:04] <seb_kuzminsky> i think it belongs in 2.5
[00:18:12] <seb_kuzminsky> all our comps build and all our tests pass, after that commit
[00:18:39] <seb_kuzminsky> it's possible that there are out-of-tree comps that compile with 2.5.4's comp, but not with this one
[00:18:45] <seb_kuzminsky> but! that's a good thing
[00:20:22] <seb_kuzminsky> the .comp code that's now disallowed (at compile-time) is the kind that gaston48 discovered, that causes runtime null-pointer dereference as soon as it runs
[09:08:16] <cradek> seb_kuzminsky: wonderful! I was just going to work on that, but a stealthy person already fixed it in the dark of night.
[09:08:31] <cradek> thanks for the clear explanations in the commit messages
[09:09:35] <cradek> why did you use the do while(0)? I can't think of any difference that makes (outside a #define)
[09:10:39] <seb_kuzminsky> yeah that's a bit weird looking isnt it
[09:11:00] <seb_kuzminsky> it's so i could change the returns to breaks and not have to restructure the code
[09:11:07] * seb_kuzminsky <--- lazy
[09:11:47] <cradek> ohhh
[09:12:34] <cradek> well I would have never guessed that
[09:13:06] <seb_kuzminsky> yeah, it's weird, i'm not proud
[09:14:08] <cradek> I don't understand how this ever worked. has nobody ever run it?
[09:14:42] <seb_kuzminsky> it's possible that it used to work when it was written, but then someone changed comp and broke it
[09:14:45] <cradek> does your comp fix make the old crashy biquad not compile?
[09:14:51] <seb_kuzminsky> but it's sure been broken for a long time
[09:15:05] <seb_kuzminsky> yes, the new comp fails to compile the old biquad
[09:15:11] <cradek> that's great
[09:15:22] <seb_kuzminsky> you get a super-cryptic compiler error instead :-/
[09:16:46] <seb_kuzminsky> hal/components/biquad-old.comp: In function ‘Biquad_CalcCoeffs’:
[09:16:46] <seb_kuzminsky> hal/components/biquad-old.comp:129:8: error: ‘__comp_inst’ undeclared (first use in this function)
[09:17:10] <seb_kuzminsky> and the author's like "what? i dont have a __comp_inst variable"
[09:17:32] <seb_kuzminsky> and the linuxcnc nobs are like "noob go read
http://www.linuxcnc.org/docs/2.6/html/hal/comp.html#_convenience_macros"
[09:17:34] <cradek> oh that's fine. everyone using comp knows they're using comp.
[09:19:29] <micges> cradek: do we need any signing of mesaflash.deb ?
[09:19:40] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch 938881f 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=938881f
[09:19:44] <seb_kuzminsky> micges: i like the sound of this question!
[09:19:52] <seb_kuzminsky> yay, thanks cradek :-)
[09:20:00] <cradek> thanks for doing the work!
[09:20:12] <seb_kuzminsky> sure :-)
[09:20:25] <micges> seb_kuzminsky: :)
[09:21:05] <cradek> someone can make that code less weird in later branches if offended. I approve of making the minimal change for 2.5.
[09:21:25] <seb_kuzminsky> micges: if you have debs that you think should be published on linuxcnc.org, send me or cradek a link and we'll roll them in to the deb archive there, and re-sign the archive metadata
[09:21:35] <seb_kuzminsky> cradek: that makes sense to me
[09:21:57] <cradek> micges: I don't think it's necessary to sign the deb. but one of us has to sign the whole deb archive, as seb says.
[09:22:31] <cradek> micges: and yay, I'm excited about this too
[09:22:49] <cradek> micges: as soon as we have updated firmware packages too, everything will be beautiful in the world
[09:23:42] <KGB-linuxcnc> 052.5-comp-fix 938881f 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=938881f
[09:24:45] <cradek> I finally started on building a debian 7 live cd
[09:24:54] <seb_kuzminsky> oh cool
[09:25:06] <cradek> it's probably not going to fit on a regular cd without a lot of sacrifices. I think I'm ok with that.
[09:25:09] <micges> ok, will do, just need to add some readme, later maybe some man too
[09:25:14] <seb_kuzminsky> i started on a precise one but didnt make any real progress yet
[09:25:35] <seb_kuzminsky> yes, but how many floppy disks will it require? that's the real question
[09:26:11] <cradek> only about 70 boxes
[09:26:41] <cradek> I think even the freebsd folks no longer support install from floppy
[09:27:37] <seb_kuzminsky> i keep all my live cds and install cds and things on a tiny usb stick, with a grub config that lets me pick among them at boot time
[09:28:12] <seb_kuzminsky> so the 650 MB or 800 MB or whatever it is size limit doesn't matter to me personally
[09:28:19] <seb_kuzminsky> maybe it does to other folks, i dont know
[09:28:37] <cradek> that sounds like a very nifty setup
[09:29:04] <seb_kuzminsky> it's not as nifty as i had hoped, some install cds dont handle it perfectly
[09:29:30] <seb_kuzminsky> ubuntu desktop workes without any issues, ubuntu server and debian both need a couple of manual steps during the install
[09:29:44] <seb_kuzminsky> i haven't tried our lucid live cd yet
[09:30:27] <cradek> guess a handful of sticks is still the way to go for me...
[09:31:19] <seb_kuzminsky> i just looked through the comp and biquad.comp logs, i think it's been broken since May of 2007
[09:31:45] <seb_kuzminsky> 74bfbc5e5920fc1d0a5c586d01ec5f418ac4ef98 broke it
[09:32:12] <seb_kuzminsky> comp never supported that use case (of using the convenience macros from non-primary functions)
[09:32:16] <seb_kuzminsky> bbl work :-/
[09:45:14] <cradek> seb_kuzminsky: weird. so I guess he never tried it after adding those features.
[10:14:00] <seb_kuzminsky> "it compiles, ship it!"
[10:15:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 505f5ae 06linuxcnc 10src/hal/utils/comp.g Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=505f5ae
[10:50:39] <linuxcnc-build> build #2078 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2078 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:50:54] <seb_kuzminsky> well that's unexpected
[10:51:36] <cradek> ooh, mesa_7i65.comp
[10:53:47] <cradek> is it the unused get_count()?
[10:54:59] <cradek> which is also in mesa_uart
[10:55:31] <pcw_home> the 7i65 comp has not worked for a while...
[10:56:54] <seb_kuzminsky> i bet it crashes when it calls its read() function
[10:58:36] <seb_kuzminsky> i bet all the realtime rip builders will fail the build too
[11:00:22] <cradek> pcw_home: is it unneeded or something? (and what other breakage do you know about?)
[11:01:25] <pcw_home> It would be nice if it still worked (segv'ed that last time i tried)
[11:09:30] <linuxcnc-build> build #1282 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1282 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:12:48] <cradek> the debian installer sure asks a lot of questions
[11:13:07] <cradek> they're easy ones (for me), but still it doesn't feel as simple as the ubuntu installer.
[11:17:46] <cradek> I bet I could use preseed to eliminate the questions I don't like, but then it'll step on someone's windows installation they want to keep for some reason I don't understand or care about
[11:27:32] <skunkworks> cradek, trying to make a new livecd?
[11:29:12] <zultron> cradek, I've dug deep into preseeding partman, and found that although it's possible to set up a dual-boot config manually in the installer, it's impossible to do so through preseeding out of the box.
[11:29:33] <cradek> ah I remember us talking about that before
[11:29:43] <zultron> Any preseeding of partman will wipe all partitions squeaky clean. :P
[11:29:53] <cradek> fortunately, I absolutely don't care about dual-boot installs
[11:30:24] <cradek> the partitioning steps would be the ones I wouldn't ever be bold enough to remove in something distributed to others
[11:30:26] <linuxcnc-build> build #2081 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2081 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:31:34] <cradek> but it's tempting to remove stuff like "do you want to install grub to the mbr?" "do you want apt to use the network?"
[11:31:59] <cradek> I'd have to go through it again and keep track
[11:32:26] <cradek> anyway this is down the road a bit. replacing the live and installed kernel is the important step I haven't tackled yet
[11:33:23] <cradek> zultron: I think you advised me when I was setting up installs at work - squeaky was what I wanted...
[11:33:29] <zultron> I can't recall whether the grub question would cause wiping, but it's certainly possible to preseed the network & other config, and go through the partman stuff manually.
[11:52:11] <linuxcnc-build> build #2082 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2082 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:54:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 53339d2 06linuxcnc 10src/hal/drivers/mesa_7i65.comp fix NULL pointer deref in 7i65 driver * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=53339d2
[11:54:25] <seb_kuzminsky> pcw_home: would you see if that fixes the 7i65 driver in 2.6?
[11:56:32] <skunkworks> seb_kuzminsky, i think the new tp is as tested as it can be at the moment...
[11:57:04] <skunkworks> sounds like they accepted robs thesis - so he is a happy camper
[11:59:12] <seb_kuzminsky> skunkworks: that's great, thanks for all your work on that
[12:11:04] <seb_kuzminsky> i want to finish the P-word verification test for that branch, then i'll advocate merging it into master
[12:11:19] <seb_kuzminsky> speaking of which, who wants to be RM for 2.7?
[12:18:34] <pcw_home> I will try the 7I65 driver out later today
[12:19:48] <cradek> seb_kuzminsky: this reminds me - there are no 2.6 wheezy debs. are there any obstacles to buildbot making those? the ones I built myself worked perfectly fine.
[12:20:33] <cradek> fwiw, I also agree the new planner should go into master asap if rob says he's ready
[12:23:16] <seb_kuzminsky> no obstacles, i just need to stand up a wheezy-rtai buildslave
[12:23:35] <seb_kuzminsky> maybe... saturday night (yes i'm a wild man)
[12:23:39] <cradek> are you running out of computer?
[12:23:52] <seb_kuzminsky> i was, but then i bought a new one and now i'm not
[12:24:04] <cradek> awesome
[12:24:24] <seb_kuzminsky> i put lots of ram in the new one so i can do most of the builds on ramdisks, that makes a huge difference
[12:24:40] <cradek> that really surprises me
[12:25:07] <seb_kuzminsky> you'd think the checkout & build would happen mostly in cache anyway?
[12:25:13] <cradek> I've never seen that replacing the system's caching with ramdisk juggling actually helps
[12:25:34] <seb_kuzminsky> compare the wheezy-sim and the precise-sim buildslaves' build times
[12:25:35] <cradek> our QA guy at $DAY_JOB fiddled with that for a while and it wasn't helpful
[12:26:05] <cradek> I believe you... I'm just surprised
[12:26:45] <seb_kuzminsky> precise: 31:55
[12:26:49] <seb_kuzminsky> wheezy: 18:06
[12:27:00] <seb_kuzminsky> not a totally fair comparison, but still
[12:27:12] <cradek> yeah, I wonder if your fruits match up
[12:27:23] <cradek> ooh, lunchtime
[12:28:25] <seb_kuzminsky> actually that particular example is not good, the precise buildslave only has one virtual cpu
[12:28:48] <seb_kuzminsky> vs 2 for the wheezy box
[12:29:00] <cradek> ok, maybe I don't believe you now :-)
[12:29:02] <seb_kuzminsky> hmm, that might explain the increase right there
[12:29:27] <seb_kuzminsky> i was fiddling with the ramdisk builds when i was adding lame buildslaves that had to build on sd-cards, and maybe i tricked myself
[12:29:52] <seb_kuzminsky> bbl
[12:30:04] <seb_kuzminsky> have a nice lunch :-)
[12:34:15] <mozmck> seb_kuzminsky: an ssd sped up compiles as well as most everything else here.
[12:35:11] * skunkworks hugs his ssd...
[12:51:36] <cradek> I'd expect adding more rams to help more than switching to an ssd, but the ssd answer might sure be cheaper
[12:51:47] <cradek> but clearly seb should do both, since it's his money and not mine
[12:56:08] <cradek> we added about 60 new SSDs at $DAY_JOB six months ago and to my great surprise, none of them have bricked yet
[12:56:16] <cradek> they are clearly better than a few years ago
[12:56:48] <cradek> ... I guess also we bought the ones that were expensive and well-reviewed
[13:17:29] <skunkworks> samsung pro's?
[13:18:14] <cradek> scsi 0:0:0:0: Direct-Access ATA Samsung SSD 840 DXM0 PQ: 0 ANSI: 5
[13:18:17] <cradek> maybe?
[13:18:27] <skunkworks> yep
[13:18:57] <mozmck> even the Samsung 840 evo has really good reliability ratings.
[13:19:32] <skunkworks> that is what I bought (evo..)
[13:19:46] <skunkworks> I couldn't bring myself to spend the money on the pro
[13:20:35] <skunkworks> I need to check to see if 14.04 trims automagically - or if I have to do something
[13:21:23] <mozmck> Even my ocz agility3 has worked fine for a year and a half, and it wasn't rated so good.
[13:21:50] <mozmck> trims?
[13:22:20] <skunkworks> some sort of ssd house keeping...
[13:22:29] <mozmck> huh.
[13:23:12] <skunkworks> http://askubuntu.com/questions/18903/how-to-enable-trim
[13:24:50] <mozmck> http://www.leaseweblabs.com/2013/12/ubuntu-14-04-lts-supports-trim-ssd-drives/
[13:25:15] <skunkworks> yay
[13:28:13] <skunkworks> I have been pretty happy with 14.04 so far.
[13:28:42] <zultron> seb_kuzminsky, gotta run, but real quick, maybe there's something interesting in my buildbot config @
https://github.com/zultron/machinekit-buildbot
[13:29:33] <zultron> It has a funny workflow where builds happen on a many-CPU host, and tests run on single CPU hosts. Builds only take about a minute, then it's just the run tests that (necessarily) take a while.
[13:30:23] <mozmck> skunkworks: do you use unity?
[13:30:43] <zultron> That is, builds happen in chroots on a many-CPU host, so you just need one of those for all distro/arch combos, duh.
[13:30:44] <skunkworks> yes... I have gotten used to it.... (used it on 12.04 also)
[13:31:54] <mozmck> I used it a little, and I thought it was better than gnome shell, but it's Cinnamon, Mate, or XFCE for me.
[14:19:16] <seb_kuzminsky> zultron: that's cool
[14:21:31] <seb_kuzminsky> yay, sounds like the biquad comp works for gaston48 now
[14:36:42] <skunkworks> pcw_home, is there anyting to test for a compter that doesn't recognize the 5i25?
[14:37:01] <skunkworks> older dell dimension 3000 (celeron)
[14:37:11] <CaptHindsight> not recognized in LSPCI?
[14:37:31] <skunkworks> no
[14:37:38] <skunkworks> mesaflash doesn't see it either
[14:38:05] <skunkworks> /done and cr4 are lit
[14:38:46] <CaptHindsight> properly seated? works fine in another PC?
[14:38:56] <micges> does this 5i25 works in different pc?
[14:40:55] <micges> DONE means fpga doesn't configured properly so it won't be visible in lspci or mesaflash
[14:43:58] <cradek> uh-oh, does that mean it's bricked?
[14:44:41] <skunkworks> works in another pc - seen by mesaflash. (no lights on)
[14:44:54] <skunkworks> (jsut tried it)
[14:45:35] <skunkworks> tried it in 2 different slots in the non working system
[14:47:05] <cradek> do other pci cards work right?
[14:47:56] <seb_kuzminsky> are you sure the computer is turned on?
[14:49:39] <cradek> did you try taking it out, blowing on the connector, and putting it back in?
[14:50:49] <micges> speaking of mesa: ultra low cost 7i90 connected to pc via rs232/422:
http://pastebin.com/YsTyAY4N
[14:51:59] <cradek> wow, funky. what's it good for?
[14:52:24] <micges> it's could be possible to connect it to every board which have rs422 (2.5Mb) and could run hostmot2
[14:53:46] <cradek> hey cool, the image I built usb-boots
[14:54:57] <cradek> if I just figure out how to replace the kernel, I'll really have something.
[14:55:10] <skunkworks> it has a wireless pci card that works...
[15:00:19] <skunkworks> I suppose I should pull the wirelss card out and see..
[15:02:13] <skunkworks> the second you turn on the computer - the 2 lights are lit. /done and cr4
[15:03:43] <micges> cr4 is INIT
[15:04:02] <micges> so board doesn't start
[15:04:18] <micges> you need PCW for more info
[15:04:25] <skunkworks> heh
[15:04:36] <skunkworks> right
[15:05:02] <skunkworks> I didn't notice the lights have 2 lables
[15:07:17] <skunkworks> micges, how is the new driver coming?
[15:07:27] <micges> not good
[15:07:32] <skunkworks> yeck
[15:07:48] <micges> works under stock kernel but not rt-preempt ;)
[15:08:29] <skunkworks> so - almost working! :)
[15:09:07] <micges> in between I finished mesaflash, and it's ready to release, need just tests under windows
[15:09:34] <micges> like always - almost :)
[15:11:33] <micges> now I'm preparing faster pc for driver tests, last one was done on atom, maybe there is bottleneck somewhere
[15:12:35] <micges> driver takes 100% of cpu after few seconds
[15:12:51] <skunkworks> darn
[15:16:39] <skunkworks> bbl
[15:28:40] <cradek> seb_kuzminsky: I expected to find linux-image-3.4.55-rtai-2 in l.o wheezy/base but it's not there. can you put it there (or am I thinking about this wrong?)
[15:29:01] <cradek> uh I don't really recall where I got it...
[15:29:22] <cradek> it needs to be in apt space somewhere for me to continue my grind
[15:34:25] <cradek> oh it's in precise/base! no problem then.
[15:47:02] <micges> skunkworks_: do you have any screenshots with mach -> 7i80 -> linuxcnc testing?
[15:47:17] <micges> also linuxcnc -> 7i80 -> linuxcnc
[15:47:58] <skunkworks_> I have video... would that work?
[15:48:00] <skunkworks_> http://www.youtube.com/watch?v=HfU4uyGgLZw
[15:48:21] <skunkworks_> http://www.youtube.com/watch?v=qo74moJ30H4
[15:50:14] <micges> any part with mach don't obey acc?
[15:50:20] <cradek> seb_kuzminsky: new problem: the linux-image-3.4.55-rtai-2 package Depend:s should be for wheezy (I think) kmod|module-init-tools, linux-base (>= 3~), initramfs-tools (>= 0.99~) | linux-initramfs-tool
[15:51:22] <cradek> with this being the only kernel package installed, nothing is giving me update-initramfs and friends, so the bootstrap fails
[15:51:55] <cradek> ... it may sure also be wrong for precise - someone would have to look at a real precise kernel
[16:04:09] <seb_kuzminsky> cradek: i'll look in to it
[16:04:22] <seb_kuzminsky> i need to revitalize the rtai deb building anyway
[16:09:50] <cradek> yay, thanks
[16:17:51] <cradek> I may hack it (add those dependencies manually, elsewhere) and continue
[16:28:53] <skunkworks_> micges: seems a few places.. I did a little write up here..
[16:30:04] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewTrajectoryControl
[16:32:56] <micges> ah yes that I was looking for - thanks!
[16:40:14] <PCW> skunkworks_: if you get 2 stuck on red lights on the 5I25, it usually means you have out-of-spec 3.3V (FPGA reset is asserted if 3.3v is less than ~3.0V)
[16:42:36] <skunkworks_> ok - I will play with it monday
[16:42:58] <PCW> There's a solder jumper option to reset the FPGA with PCI reset instead of /POWERGOOD if you want to use your PC power supply as is
[16:43:23] <skunkworks_> I should have other power supplies I can test :)
[16:44:17] <cradek> seb_kuzminsky: hack didn't work, not clear why - I'll try again after you redo the kernel package...
[16:47:51] <seb_kuzminsky> the pressure is on
[16:48:52] <cradek> the failure is that the initrd doesn't magically appear
[16:49:33] <cradek> I haven't dug into their scripts to see what is supposed to build it -- but I'm guessing it might be automagic when the dependency on initramfs-tools is in there
[16:50:19] <cradek> I hope it's not more complicated than that
[16:55:58] <seb_kuzminsky> seems reasonable
[16:56:19] <seb_kuzminsky> can you hack around my shortcomings by requesting iniramfs-tools.deb be included "by hand"?
[16:57:24] <cradek> yes I did that
[16:57:37] <cradek> that makes the failure more mysterious
[16:58:59] <cradek> I added kmod, linux-base, initramfs-tools
[16:59:10] <cradek> I think those are the three that a correct kernel would give me
[17:00:29] <cradek> I must be missing something else though; I get System.map-..., vmlinuz-..., config-... in /boot but not initrd.img-... which it expects to find
[17:00:58] <cradek> in my working machine's /boot at home, I do have the initrd.img
[17:02:34] <cradek> hm, in the build log, there are many update-initramfs calls, but they ALL say "update-initramfs: deferring update (trigger activated)"
[17:02:43] <cradek> maybe it just never runs
[17:09:10] <cradek> I may be thwarting it because we don't have a "flavour metapackage" like linux-image-amd64
[17:10:31] <seb_kuzminsky> yeah, i don't really know what we're supposed to provide :-/
[17:20:22] <cradek> oh hey I might've beaten it with the right stick...
[17:25:14] <cradek> nope
[17:28:23] <CaptHindsight> cradek: it looks like to bring lucid or Precise up to date for camview to have all the plugins including the DRO is having to include halio plugin that was in Hardy
[17:40:57] <CaptHindsight> http://wiki.linuxcnc.org/uploads/halio.c
[17:42:27] <CaptHindsight> ^^ this needs to be packaged
[18:13:36] <seb_kuzminsky> CaptHindsight: what is that thing?
[18:15:21] <CaptHindsight> seb_kuzminsky: halio ties the DRO to camunits
[18:23:51] <seb_kuzminsky> do you think it belongs with linuxcnc, and not with camunits? (i'm asking, is it useful for anything other than camunits?)
[18:24:08] <seb_kuzminsky> bbl
[18:28:24] <PCW> I wont be able to test the 7i65 comp today, but will on Monday (had to install ubuntu 10.4 again on a test computer)
[18:32:38] <CaptHindsight> seb_kuzminsky: cradek was talking about maybe hosting the camunits and plugins at linuxcnc
[19:10:11] <andypugh> 7i65 comp? I think I had a hand in that. Is there a problem?
[19:14:29] <micges> andypugh: pcw said that it doesn't work
[19:15:30] <micges> andypugh: also
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=53339d2
[19:16:13] <andypugh> Yeah, I think it used that.
[19:16:34] <andypugh> (I didn’t do that bit)
[19:18:10] <andypugh> PCW: It’s late here now, and I am out and about all weekend. Can you email me a problem description?
[20:36:35] <FungiFox> if people add a conveyor belt to their print surface they can have an abnormally large x axis.
[21:10:06] <pcw_home> Some change in comp made it segv