Back
[00:50:30] <seb_kuzminsky> zultron: i know you're not mhaberler, but i'm hoping you can answer a question about one of his commits
[00:50:41] <zultron> Hi seb_kuzminsky
[00:50:47] <seb_kuzminsky> i'm trying to fix debian packaging in ubc3
[00:50:54] <zultron> Just about to head to bed. Got a link?
[00:51:36] <seb_kuzminsky> hm, no, but the commit is d4f65e4b896d89524c99803e319d0223fb1139f4
[00:51:55] <seb_kuzminsky> the part i'm confused about is, it changes how the debian makefile calls src/configure
[00:52:02] <zultron> Ok. I'll pull that up
[00:52:12] <seb_kuzminsky> it uses "--with-kernel=/boot/config-mumble"
[00:52:31] <seb_kuzminsky> but --with-kernel is not documented in src/configure, and seems to be ignored?
[00:53:06] <seb_kuzminsky> it's not a hurry, i dont want to keep you up if you meant to go to bed
[00:53:53] <zultron> Hmm, well, remember we've never built a Debian package since the Unified Build.
[00:54:08] <seb_kuzminsky> but surely you use src/configure?
[00:55:02] <seb_kuzminsky> are you guys targetting redhat in your fork? or some other distro?
[00:55:13] <zultron> Yes, but that's debian/configure. Hold on, I haven't read it carefully
[00:55:51] <seb_kuzminsky> the part i'm wondering about is what src/configure does with "--with-kernel=/boot/config"
[00:56:00] <zultron> Uh oh, the f*** word!
[00:56:12] <zultron> :) j/k
[00:56:23] <zultron> I'm building for Red Hat, yes.
[00:56:25] <seb_kuzminsky> just being real
[00:56:45] <zultron> mah likes Debian.
[00:57:23] <seb_kuzminsky> there seems to be multiple ways to ask src/configure to target specific flavors/kernels
[00:57:51] <seb_kuzminsky> --with-kernel is one, but it's not in the --help info
[00:58:14] <zultron> Yeah. I suspect that mah was trying to keep debian/configure up to date with his work on Debian, but he wasn't up to date with the Universal Build at that point (it was new in March).
[00:58:15] <seb_kuzminsky> there's also --with-$FLAVOR
[00:58:37] <zultron> There is a way to specify kernel, but it's not using --with-kernel. Hold on.
[00:58:50] <seb_kuzminsky> hmm, as i recall in march i was still asking him for a look at his new-rtos branch
[00:59:04] <seb_kuzminsky> water under the bridge, i guess
[00:59:48] <zultron> I don't know. I forget when I did the Universal Build, which is not the same as RTOS, but it took him a while to grok what it was about.
[01:00:50] <zultron> For example, check around line 744 of configure.in.
[01:01:02] <zultron> --with-xenomai-kernel-sources="<ksrc_dir> <ksrc_dir>..."
[01:01:10] <zultron> What are you trying to do?
[01:02:01] <zultron> There shouldn't be multiple ways, no, and I don't believe --with-kernel works.
[01:02:26] <seb_kuzminsky> ok, i'll ignore that part then
[01:02:50] <seb_kuzminsky> i guess we (you?) should take it out of src/configure if it's not working and not documented and not wanted
[01:02:52] <zultron> I might've gone overboard with the options, though, and there's pretty fine control over what flavors and kernel versions can be selected.
[01:03:01] <seb_kuzminsky> maybe i should ask this question instead:
[01:03:19] <seb_kuzminsky> what's the preferred way to ask src/configure to build specific flavors, for specific kernels (where appropriate)
[01:03:23] <zultron> fine control == confusing control, sometimes.
[01:03:41] <seb_kuzminsky> i'm in favor of lots of knobs in the build system :-)
[01:03:47] <seb_kuzminsky> even if it confuses me sometimes
[01:03:58] <zultron> ./configure --with-xenomai builds *only* xenomai flavor.
[01:04:15] <zultron> ./configure --with-xenomai --with-posix builds *only* those.
[01:04:33] <zultron> ./configure --without-xenomai builds everything it can build, *except* xenomai.
[01:04:34] <seb_kuzminsky> is it fair to say --with-$FLAVOR enables $FLAVOR, independent of what other arguments are given
[01:04:42] <seb_kuzminsky> ?
[01:05:05] <seb_kuzminsky> err, no, that's not quite right
[01:05:14] <zultron> I don't quite understand the question. Yes, that should enable $FLAVOR, and also disable other flavors.
[01:05:39] <seb_kuzminsky> does --with-xenomai enable both the xenomai and xenomai-kernel flavors?
[01:05:52] <zultron> No, only xenomai (userland).
[01:06:06] <zultron> You can do that with --with-xenomai --with-xenomai-kernel.
[01:06:11] <seb_kuzminsky> oh!
[01:06:29] <seb_kuzminsky> oh, i see that now
[01:06:30] <zultron> Those are considered separate flavors.
[01:06:42] <seb_kuzminsky> right, i missed the --with-xenomai-kernel option
[01:07:47] <zultron> And in the case of --with-xenomai-kernel, to confuse things further, you can select which kernels to build for with --with-xenomai-kernel-sources="<ksrc_dir> <ksrc_dir>...", in case, for some wacky reason, you have more than one installed, or it's in a weird place.
[01:07:51] <zultron> :P
[01:08:00] <zultron> Same with RTAI.
[01:08:02] <seb_kuzminsky> if i say --with-rtai-kernel to enable the rtai flavor, can i tell it which rtai headers to use? --with-rtai-kernel-sources maybe?
[01:08:11] <seb_kuzminsky> aha
[01:08:11] <zultron> You can.
[01:08:19] <seb_kuzminsky> i see we think alike :-)
[01:08:20] <zultron> (I hope.)
[01:08:23] <seb_kuzminsky> ok that makes sense
[01:09:21] <seb_kuzminsky> ok, i think that clears up that one question i had: i'll ignore --with-kernel and use the --with-$FLAVOR and --with-$FLAVOR-kernel-sources arguments instead
[01:09:24] <seb_kuzminsky> thanks!
[01:09:28] <seb_kuzminsky> next question!
[01:09:34] <zultron> Glad it makes sense. I think I went too far on configurability, but hopefully the defaults are what people expect, anyway.
[01:11:20] <zultron> Why do you want to use --with-$FLAVOR-kernel-sources, though? It can usually find all relevant installed sources.
[01:12:02] <seb_kuzminsky> i guess it's not needed
[01:12:10] <zultron> I envisioned that being useful when you wanted to build for just one particular version when more than one set of headers was installed, or else when it's in a non-standard place.
[01:12:38] <zultron> Yeah, keep it out of your scripts or you'll be updating version numbers whenever you update the kernel.
[01:12:55] <seb_kuzminsky> i have a machine with two versions of rtai kernel headers installed, and i was surprised when it built for both of them
[01:13:05] <seb_kuzminsky> i only needed /usr/src/linux-headers-$(uname -r)
[01:13:06] <zultron> Oh, well, then maybe it does apply.
[01:13:18] <seb_kuzminsky> agreed, version numbers need to be detected, not hardcoded
[01:13:22] <zultron> Ah, of course. Then by all means. ;)
[01:14:34] <zultron> I'm always building in chroots, and yelling at people who embed `uname -r` in scripts, so I forget there are rare cases where that actually applies.
[01:14:52] <seb_kuzminsky> heh
[01:15:05] <seb_kuzminsky> i always build in VMs and rely on uname -r to be meaningful
[01:15:47] <zultron> For the buildbot, where the 'test host' is the same as the build host, that makes sense.
[01:17:24] <seb_kuzminsky> do you guys build packages on one host and test on another? i've sometimes thought that'd be a better way to do it
[01:17:39] <zultron> I'm hoping to set one fat VM up for each distro/arch combo and do a Universal Build of all flavors in one run, and have 'runtests' in a separate builder with skinnier VMs that have the correct kernel for each respective flavor.
[01:17:49] <zultron> That's a bit far off, though. :P
[01:18:17] <seb_kuzminsky> it's a good idea - test what you actually ship to your users
[01:18:48] <zultron> Hmm, an advantage I hadn't considered before. :)
[01:19:48] <zultron> The big advantage I saw was doing the build just once on a VM with lots of CPUs so you get your result faster.
[01:20:44] <seb_kuzminsky> only if make -j works ;-)
[01:21:02] <zultron> Take the build time down from ~15 minutes on a single CPU to (hopefully) three minutes on five CPUs.
[01:21:29] <zultron> make -j works fine for the source builds. It's the docs that break, but that's a separate builder.
[01:21:43] <zultron> (hopefully we'll fix that!)
[01:37:08] <linuxcnc-build> build #1672 of lucid-rtai-i386-clang is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1672 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:00:13] <linuxcnc-build> build #1673 of lucid-i386-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1673 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:25:05] <linuxcnc-build> build #1676 of lucid-i386-realtime-rip is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1676 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:27:28] <linuxcnc-build> build #1675 of lucid-amd64-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1675 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:07:04] <linuxcnc-build> build #1677 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1677 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:30:55] <KGB-linuxcnc> 05remove-obsolete-hook e3eca06 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3eca06
[03:31:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 4f28d7e 06linuxcnc 04debian/D99kernel-img.conf deb: remove unused pbuilder hook file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f28d7e
[03:42:17] <linuxcnc-build> build #1677 of lucid-i386-realtime-rip is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1677 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:42:57] <linuxcnc-build> build #1674 of lucid-i386-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1674 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:44:24] <linuxcnc-build> build #1673 of lucid-rtai-i386-clang is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1673 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:45:56] <linuxcnc-build> build #1676 of lucid-amd64-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1676 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[04:29:01] <linuxcnc-build> build #1678 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1678 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:50:08] <CaptHindsight> we are looking into writing a new Linuxcnc UI for 3D printers (glue guns are a subset)
[09:50:41] <CaptHindsight> I've always liked AXIS for mills and lathes
[09:52:44] <CaptHindsight> but I'm not sure if we should just modify AXIS to accommodate Laser/DLP SLA, Inkjet and GGG printers or start from scratch
[09:54:05] <cradek> what would it mean in the gui to accommodate those?
[09:54:45] <CaptHindsight> http://www.repetier.com/documentation/repetier-host/object-placement/ Repetier has a pretty good handle of what it might look like
[09:55:57] <cradek> that is so different I am not sure what you're proposing to do
[09:55:59] <CaptHindsight> preview, preflight/simulation of the print, placement on the build surface
[09:56:05] <cradek> built-in scaling and rotation?
[09:56:38] <CaptHindsight> yes, as well as tabs for slicing, editing g-code
[09:58:05] <cradek> placement/slicing/editing are all gcode generation steps and those seem like they could and maybe should be totally separate from the machine control
[09:58:24] <cradek> these 3d printers that use a black box interpreter/controller have that same separation
[09:59:11] <CaptHindsight> they would be on separate screens/tabs
[10:00:14] <CaptHindsight> we would support this GUI, it could be included in Linuxncnc if you wanted it
[10:00:30] <seb_kuzminsky> sounds like a good idea to me
[10:00:33] <CaptHindsight> not forcing it on anyone
[10:00:52] <cradek> I know you're not forcing, I'm just wondering aloud whether it's the best way to solve the problem you're trying to solve
[10:00:56] <CaptHindsight> but the 3D printer GUI's out there now are really clumsy
[10:00:59] <seb_kuzminsky> the 3d printer folks understandably like integrated guis for their machines, and that's a weakness in linuxcnc right now
[10:01:08] <cradek> and I sure don't fully understand the problem
[10:01:22] <CaptHindsight> throwing this out for feedback
[10:01:38] <seb_kuzminsky> cradek: 3d printers are much simpler to operate than subtractive machines, but our guis don't reflect that
[10:01:56] <cradek> the proliferation of entire guis is contrary to my unixy mindset where tools should be simple and separate
[10:02:06] <seb_kuzminsky> they really (or nearly) can be made as simple as "configure some facts about your printer, then hit the Print button"
[10:03:01] <CaptHindsight> there are some other differences between printers and cutting machines
[10:03:15] <seb_kuzminsky> mine too, and i predict that if i had a 3d printer i'd prefer my cad/cam/mc layers to be separate, but i'm open to folks experimenting with it
[10:03:21] <seb_kuzminsky> bbl
[10:03:45] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386
[10:03:46] <linuxcnc-build> no such builder 'lucid-i386'
[10:03:50] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386-sim
[10:03:51] <linuxcnc-build> build #1675 forced
[10:03:51] <linuxcnc-build> I'll give a shout when the build finishes
[10:03:56] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-amd64-sim
[10:03:57] <linuxcnc-build> build #1677 forced
[10:03:57] <linuxcnc-build> I'll give a shout when the build finishes
[10:04:15] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386-realtime-rip
[10:04:17] <linuxcnc-build> build #1678 forced
[10:04:18] <linuxcnc-build> I'll give a shout when the build finishes
[10:04:38] <seb_kuzminsky> and by "bbl" i meant "i'm going to stop talking to you guys, and talk to my robots instead"
[10:05:15] <CaptHindsight> http://download.lulzbot.com/AO-101/documentation/current/source/images-original/printrun.png
[10:05:18] <linuxcnc-build> build #1675 of lucid-i386-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1675
[10:05:28] <CaptHindsight> I never understood how this ever became popular
[10:07:48] <cradek> that's a sure sign of "doesn't know how widgets work". I can't tell if those are buttons or radiobuttons or tabs
[10:08:07] <cradek> the added colors are a sure sign of gui cluelessness
[10:08:34] <cradek> I know, we'll make them red and green so people know they group together (?)
[10:09:10] <CaptHindsight> people say that they get used to it but it's not exactly intuitive and easy to use
[10:09:40] <cradek> yeah you can learn to use any gui, no matter how bad
[10:10:06] <cradek> with a GOOD gui people can walk up to it and have a grasp of how it works because the widgets are familiar and used in standard ways
[10:10:46] <cradek> the 80s board game thing at the left is baffling to me
[10:11:30] <CaptHindsight> heh, I call it the Radar Screen
[10:12:06] <CaptHindsight> but the makerfolk defend it like a bible to a preacher
[10:13:00] <CaptHindsight> but that is not the intended user
[10:14:54] <CaptHindsight> we'd like to make something useful for printer appliances as well as service bureaus
[10:15:23] <CaptHindsight> with simple menus and advanced menus
[10:15:59] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-i386-sim
[10:16:00] <linuxcnc-build> build #1676 forced
[10:16:00] <linuxcnc-build> I'll give a shout when the build finishes
[10:17:03] <cradek> it would be interesting if you could have only the tiniest link to linuxcnc, so minimal in fact that you could generate a new config based on printer settings in your gui, and restart linuxcnc
[10:17:36] <CaptHindsight> it should also work where the host runs Linuxcnc and the GUI is remote
[10:17:39] <cradek> generating the config is the hard part of using linuxcnc for printing
[10:18:03] <cradek> er, A hard part? I dunno for sure
[10:19:39] <CaptHindsight> glue guns are similar to mills with 3 axes, DLP printers just have 1 axis but display an image between each z move
[10:20:25] <CaptHindsight> 5 axis inkjets are similar to a mill only with 1-1k's of nozzles as a tool
[10:21:04] <CaptHindsight> these are also combined into hybrids
[10:21:26] <CaptHindsight> Linuxncnc can handle all the motion control
[10:21:58] <CaptHindsight> and we have no desire to write some new cnc control application for AVR's :)
[10:22:26] <cradek> ugh
[10:22:56] <seb_kuzminsky> CaptHindsight: by "ugh" cradek means "i agree"
[10:22:57] <CaptHindsight> so it's just adding features for additive manufacturing and UI's
[10:23:05] <CaptHindsight> heh yeah
[10:23:27] <cradek> seb_kuzminsky: but not always...
[10:23:43] <seb_kuzminsky> i think that sounds great, and i can tell that printer people really want their motion controllers tiny and embedded, and i think we can fit into that niche well
[10:24:08] <CaptHindsight> for simple printers that are appliances they do
[10:24:49] <cradek> now I'm fascinated by the idea of getting slices and temperatures and all that stuff set up right, and you poke PRINT, and an appropriate config is generated, linuxcnc starts it, runs the gcode, and exits
[10:24:54] <CaptHindsight> they need to be low cost, so stamped out of sheet metal and use a $1 uC if possible
[10:25:34] <cradek> because it sounds like almost all our existing idea of guis is unnecessary/wrong
[10:25:53] <CaptHindsight> but we also work quite a bit on the opposite end of that spectrum as well
[10:26:30] <CaptHindsight> a printer for eyeglasses will print the frames as well as the lenses
[10:27:38] <CaptHindsight> or a printer that makes circuit boards
[10:28:30] <cradek> haha 3d printed lenses I'll believe when I see
[10:28:38] <cradek> ...through
[10:28:40] <CaptHindsight> hold on
[10:28:58] <CaptHindsight> http://www.3ders.org/articles/20140114-luxexcel-raises-5-million-from-investors.html
[10:29:14] <CaptHindsight> been done for a while for optics and inkjet
[10:29:27] <archivist> going to need to polish a turd there :)
[10:29:39] <CaptHindsight> no polishing
[10:29:49] <CaptHindsight> they aren't extruded lenses
[10:29:59] <CaptHindsight> printed with photopolymers
[10:30:50] <CaptHindsight> it started maybe 10+ years ago for producing miniature lenses
[10:30:51] <cradek> you can have my CR39 when you take it from my cold dead blurry hands
[10:34:13] <cradek> otoh, it would mean a lot for peopple in developing countries if you could make even fairly lousy glasses on-site and cheaply
[10:34:51] <linuxcnc-build> Hey! build lucid-amd64-sim #1677 is complete: Warnings [8warnings compile]
[10:34:51] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1677
[10:35:38] <CaptHindsight> there is a company in Italy that currently makes ~80% of the worlds eyeglasses
[10:36:03] <CaptHindsight> they even bought RayBan a few years ago
[10:36:33] <CaptHindsight> they are the reason $20 of materials sell for $500 at all the optical shops
[10:38:25] <kwallace1> You have hit a sore spot with me. Charging $300 for glasses with no frills is just wrong. I've been thinking about a system to make glasses by hand. Maybe using the curved jar bottoms to hand grind lenses.
[10:38:35] <linuxcnc-build> Hey! build lucid-i386-realtime-rip #1678 is complete: Warnings [8warnings compile]
[10:38:35] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1678
[10:39:45] <CaptHindsight> the eyewear lens patent might throw a curve at printing eyewear in the west
[10:40:07] <kwallace1> I have ground a couple of telescope mirrors to a much higher accuracy than needed for eyeglasses. It's not that hard.
[10:40:13] <CaptHindsight> but I've already looked at making low cost lens grinders/polishers and printing the frames
[10:40:14] <cradek> kwallace1: anyone can use the online importers to get glasses really quite cheaply
[10:40:32] <cradek> I have wondered about making my own (post-apocalypse?), though
[10:40:58] <kwallace1> Prescription?
[10:41:15] <cradek> ?
[10:41:29] <archivist> reading glasses from lidl cheap as chips
[10:41:44] <CaptHindsight> lenses can be premade with one outside curve, you just need to finish the inside or outside curve to meet the Rx
[10:42:21] <kwallace1> Can one get cheap prescription glasses? Reading glasses don't count.
[10:42:27] <CaptHindsight> most frames just have an interference fit for the lenses
[10:42:31] <cradek> in the old days they'd put the spherical part on one surface and the cylindrical on the other surface - I'd recommend trying that if hand-grinding
[10:42:49] <cradek> kwallace1: sure, $25 will get you a pair of any single-vision shipped to you
[10:43:43] <kwallace1> I guess I haven't been looking hard enough. Thanks.
[10:43:46] <cradek> I'm shocked more people don't do this
[10:43:58] <cradek> I have used zenni, eyebuydirect, and probably others
[10:44:08] <CaptHindsight> it's become a near monopoly in the US
[10:44:35] <CaptHindsight> sunglass hut, lens crafters, pearl are all owned by the same corp
[10:44:48] <cradek> yeah, but screw those guys, we have the web now
[10:45:14] <cradek> go get a rx from your local non-chain eye guy and order what you want
[10:45:23] <CaptHindsight> Luxottica s.a.s
[10:45:25] <cradek> (but I do my own refractions now)
[10:45:51] <CaptHindsight> http://www.youtube.com/watch?v=voUiWOGv8ec
[10:45:57] <linuxcnc-build> Hey! build lucid-i386-sim #1676 is complete: Warnings [8warnings compile]
[10:45:57] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1676
[10:46:46] <CaptHindsight> eyewear is just another additive manufacturing application
[10:46:58] <CaptHindsight> we still need good GUI's
[10:47:27] <CaptHindsight> before we start to get lost in all the bad ones popping up
[10:47:27] <kwallace1> At least for the frames, could be pretty cool thing.
[10:49:12] <cradek> I bet the actual machining and polishing of lenses is straightforward, if you can get the material
[10:49:21] <CaptHindsight> yes it's easy
[10:49:29] <cradek> but I bet the whole supply line is closely controlled, at least in the US
[10:49:50] <CaptHindsight> the materials are ~3/lb for plastics
[10:50:01] <CaptHindsight> $3
[10:50:52] <CaptHindsight> glass is more, but eyeglass shops don't even carry glass lenses anymore
[10:50:57] <CaptHindsight> it's special order
[10:51:15] <cradek> some onlines will still make you glass lenses
[10:51:21] <kwallace1> I can see a guy with a 3D printer at the flee market printing custom glasses in an hour.
[10:52:11] <kwallace1> flea too
[10:52:14] <CaptHindsight> there is some skill involved, you want a good fit, be sure it's made right, meets the Rx etc
[10:52:16] <cradek> few of us carry our presciptions to the flea market...
[10:52:36] <CaptHindsight> that why you want someone with some training involved
[10:52:47] <cradek> sounds very close to practicing medicine without a license
[10:52:55] <kwallace1> That's the other part, self exams.
[10:52:56] <cradek> it'd be better if people could do it for themselves
[10:53:31] <kwallace1> Doctors are mostly worthless these days.
[10:53:34] <cradek> self exam is easy but it takes a lot of knowledge
[10:53:48] <CaptHindsight> depends on the people
[10:53:49] <cradek> and some equipment
[10:53:58] <cradek> yeah I mean for a basic refraction
[10:54:08] <CaptHindsight> maybe some in this channel but would you trust anyone in say #reprap?
[10:54:08] <kwallace1> We need an app for that.
[10:54:14] <cradek> there's the whole eye-health thing where you probably want a real doctor
[10:55:13] <kwallace1> For many of us seeing a doctor is not an option, but heal thy self might be.
[10:55:16] <CaptHindsight> printing functional prosthetics is another area
[10:55:44] <CaptHindsight> you have multiple materials and more that one additive tech involved
[10:55:51] <CaptHindsight> that/than
[10:56:32] <CaptHindsight> most of what I discuss about 3D printing has little to do with glue guns (reprap)
[10:56:44] <archivist> there are enough axes in linuxcnc to make a basic eye measuring machine probably
[10:57:13] <CaptHindsight> plenty
[10:57:32] <CaptHindsight> we just need UI's
[10:58:28] <kwallace1> I have no idea what a 3D printer needs for a UI.
[10:58:32] <CaptHindsight> as good as the CAM/slicing software might be it should perform printing preflight/simulation
[10:59:18] <CaptHindsight> kwallace1: not this
http://download.lulzbot.com/AO-101/documentation/current/source/images-original/printrun.png
[11:00:37] <CaptHindsight> kwallace1: something more along these lines or AXIS
http://www.repetier.com/documentation/repetier-host/object-placement/
[11:05:58] <kwallace1> My guess is that to do a proper UI, you need focus groups and field studies. I suspect when I see a symbol, the average young person sees something different.
[11:07:36] <kwallace1> Can anyone here channel Steve?
[11:11:03] <CaptHindsight> borrow from android and istuff
[11:12:09] <CaptHindsight> I consider DIY/maker pretty much ruined by now in the west by printrun and similar
[11:13:10] <CaptHindsight> a 3D printer appliance should work like a microwave or toaster oven
[11:13:32] <kwallace1> I'm not sure I understand, do you mean the Maker movement is dying?
[11:13:36] <CaptHindsight> limited settings
[11:13:55] <CaptHindsight> not dying but very happy with duinos and printrun
[11:14:44] <CaptHindsight> 3D printer appliances would be for non tinker types
[11:15:04] <CaptHindsight> people that just want to load a file and press print with limited options
[11:15:48] <CaptHindsight> the other end of the spectrum is hybrid printers with lasers, inkjet and extruders all in one
[11:16:26] <CaptHindsight> those will require a much more sophisticated UI until they become an appliance down the road
[11:17:21] <CaptHindsight> I see 3d printer appliances and 3d printers as tools in a factory the same as CNC machines
[11:22:03] <kwallace1> Should 3D printing considered an appliance. To me I expect anything worth doing needs months or years of training.
[11:23:05] <CaptHindsight> there is a spectrum, with appliance at one end
[11:23:41] <seb_kuzminsky> depends if you want to build a 3d printer or use a 3d printer
[11:24:21] <CaptHindsight> the plastic widget vending machine just needs to be an appliance
[11:24:21] <seb_kuzminsky> years ago, before i started hacking on linuxcnc, i sat down in front of a commercial Stratasys FDM machine and was printing parts within 10 minutes
[11:25:29] <CaptHindsight> complex parts will require a much more complicated machine with a trained operator
[11:26:41] <CaptHindsight> Linuxcnc fits the bill for motion control but might be a bit bloated for simple appliances
[11:27:39] <kwallace1> To a factory easy is better. To a maker/tinkerer easy is fun at first but gets boring?
[11:28:22] <CaptHindsight> when Haier builds a 3D appliance we'll look at writing something small, dedicated and new
[11:30:51] <CaptHindsight> I haven't tried Linuxcnc on a vortex SOC yet
[11:31:11] <CaptHindsight> http://www.vortex86dx.com/
[11:32:08] <kwallace1> Maybe put together a bare bones UI, then add features as the need arises? The more I think about it, the less clear it becomes.
[11:32:26] <CaptHindsight> but the AMD apu's are under $20ea so you can build an complete x86 system for under $100
[11:33:33] <CaptHindsight> and we're also running Linuxcnc on $6 ARM socs with enough GPU power to play video games in HD
[11:35:33] <CaptHindsight> complete system with FPGA and 10" LCD is <$100
[11:37:20] <CaptHindsight> Linuxcnc fits in most situations except for <$10 uC board
[12:01:48] <JT-Shop> GError: Failed to open file '/usr/bin/../share/linuxcnc/stepconf/main_page.glade': No such file or directory
[12:02:01] <JT-Shop> running an installed master from buildbot
[12:02:18] <JT-Shop> File "/usr/bin/stepconf", line 656, in __init__
[12:02:19] <JT-Shop> self.builder.add_from_file(os.path.join(datadir,'main_page.glade'))
[12:02:28] <cradek> cmorley has replaced stepconf but I bet he didn't test packaging
[12:04:01] <JT-Shop> I'd take that bet :)
[12:06:06] <JT-Shop> I sent cmorley and email
[12:06:13] <cradek> he's here, too
[12:17:42] <seb_kuzminsky> i wish the buildbot would test our packaged files, instead of (or in addition to, maybe) our rip builds
[12:17:57] <seb_kuzminsky> probably wouldnt have helped here since we have no tests for our guis, but still
[12:23:54] <psha> seb_kuzminsky: sort of piuparts?
[12:24:04] <psha> or something more serious?
[12:24:56] <seb_kuzminsky> psha: i was imagining including tests/* and runtests in the deb, then installing the deb and running runtests
[12:25:06] <seb_kuzminsky> so, like piuparts plus our runtests
[12:25:26] <seb_kuzminsky> maybe make the tests a separate deb, so users dont need to install it
[13:45:51] <psha> seb_kuzminsky: separate deb looks better
[13:46:20] <psha> sort of testsuite that user may install to verify his setup
[14:45:02] <zultron> Re: 3D printer GUIs, I wish folks would develop GUIs as separate projects that depend on LinuxCNC, instead of assuming they must be shipped in the LinuxCNC tarball.
[14:45:19] <cradek> yes yes yes
[14:46:02] <cradek> especially for printing - I really think about 10% of the new program will be related to running linuxcnc.
[14:46:51] <zultron> Yeah, that's what made me think of that (yet again): CaptHindsight's GUI sounds like CAM + CNC rolled into one app.
[14:47:04] <cradek> to me it seems that to start by writing a linuxcnc gui with jogging and tool table editing and all the other stuff is just going about it wrong
[14:47:55] <cradek> it's striking how little you need/expect from the actual control for 3d printing
[14:48:40] <cradek> I recently watched a guy describing his height-adjustable nozzle - he loosens a setscrew to set the height to the table
[14:49:08] <zultron> :) That works!
[14:49:20] <cradek> I guess so
[14:49:26] <zultron> Not much harder than clicking a GUI button.
[14:49:37] <cradek> it makes me realize I don't know what the expectations even are
[14:50:46] <cradek> well to me, software that lets you set the origin is an obvious thing you need; software to let you level the table for this run because it doesn't home reliably is stupid and you should just fix your machine already
[14:51:06] <cradek> so who knows what people really need - I don't and they may not either
[14:51:09] <zultron> I think it's good not to make too many assumptions. Increases the chance that folks will come up with something we've never thought of before.
[14:51:19] <cradek> hmm, I might be ranting
[14:51:50] <zultron> Well I agree, but I also don't want to discourage anyone.
[14:52:31] <zultron> As long as I don't have to look at it every day, anyway. That would drive me nuts.
[14:54:48] <seb_kuzminsky> i'm in favor of folks build-depending on our linuxcnc-dev package and going off in their own direction from there, but i think the barrier to entry is quite high
[14:55:11] <seb_kuzminsky> they'd need their own build infrastructure, etc, and i bet that discourages people
[14:56:50] <zultron> What does 'build-depending' mean, exactly? Looking for LinuxCNC libs+headers in e.g. autoconf, or looking for a linuxcnc-devel package in a source package?
[14:58:23] <zultron> If the first, it should be easy enough if LinuxCNC packages are already available.
[15:00:19] <seb_kuzminsky> what i meant was, i would like it if people built their stuff using the interfaces and headers and things that we export in our packages, without those folks putting their application into our repo
[15:01:00] <seb_kuzminsky> so i guess yes, the first thing you said - looking for our headers when they configure and build their application
[15:02:19] <zultron> Yeah, me too. Hey, let's split out the current GUIs to do something like JMK's BLOCs, package the GUIs separately, and then present them as examples for other GUI authors to follow!
[15:03:11] <seb_kuzminsky> sounds good to me
[15:03:28] <skunkworks> I think in the grand scheme of things - that is what mharberler is working on...
[15:04:15] <seb_kuzminsky> i have no idea what he's working on, and when he shows me a 6 month old branch with a million merges and backtracks i'm none the wiser
[15:04:34] <skunkworks> heh - although that sounds to me like 'wait for mach4 - it will be in that'
[15:08:18] <seb_kuzminsky> there is some overlap between a hypothetical Blocs project (what we call HAL) and the linuxcnc project built on top of that project - mostly the build system i guess
[15:09:02] <zultron> There's a pretty good doc about what's been added with UBC:
https://github.com/zultron/linuxcnc/blob/unified-build-candidate-3/docs/src/common/UnifiedBuild.txt
[15:09:23] <CaptHindsight> I must have missed the earlier drama over GUI's for Linuxcnc
[15:10:57] <zultron> Yeah, BLOCS, as I understood, was HAL, motion, io, rtapi, etc. core bits, separated into a separate distribution.
[15:11:00] <CaptHindsight> there were a couple of people at the fest last year that demos of GUI's and gui builders
[15:12:26] <CaptHindsight> Linuxcnc to control the machines and just make it not too difficult for people to write their own UI's
[15:13:47] <zultron> JMK set up a project for BLOCS:
http://sourceforge.net/p/blocs/wiki/Home/
[15:17:02] <zultron> Ah, an overview of his intent:
http://blocs.cvs.sourceforge.net/viewvc/blocs/blocs/docs/design-notes?revision=1.1&view=markup
[15:20:19] <CaptHindsight> blocs, about 8-10 years ago that became a popular term for building hardware, object oriented programming was also buzzwords of the time
[15:22:38] <seb_kuzminsky> if we're going to split the project into smaller stand-alone projects, i think motion and io don't belong in the 'hal' project
[15:37:08] <cradek> I think this is a false dichotomy. I think we can support external gui writers' desire to build external guis to our APIs without having to split up our own distribution.
[15:39:58] <zultron> That's very true, that the API can be used to build external GUIs, and is not a technical reason to split up the distribution.
[15:41:11] <zultron> There are other reasons as well, like all the package dependencies that aren't needed for someone just needing the core functionality.
[15:43:27] <zultron> I actually don't see much reason *not* to, except that it's a lot of un-fun work.
[15:46:43] <CaptHindsight> maybe the first step is getting (provided by me) someone to work on the API?
[15:47:18] <mozmck> logger[mah]: log
[15:47:18] <logger[mah]> mozmck: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-15.html
[15:47:22] <CaptHindsight> that way everybody who is currently developing can stay working on the fun parts that they currently enjoy
[15:48:40] <cradek> zultron: we have supported externally-built GUIs for about a decade; at least since AXIS was distributed this way
[15:48:42] <zultron> I haven't touched GUIs at all, practically. What API issues do you see?
[15:48:48] <cradek> none
[15:49:13] <zultron> Great!
[15:49:53] <zultron> AXIS isn't distributed separately, is it?
[15:49:55] <seb_kuzminsky> CaptHindsight: are you putting memleak to work again? ;-)
[15:49:55] <cradek> by support, I meant culture/documentation support more than anything
[15:50:01] <cradek> no, but it was for some years
[15:50:29] <cradek> sorry, it seems I'm much less clear than usual today
[15:50:30] <seb_kuzminsky> why was axis merged into linuxcnc? some practical reason of infrastructure & distribution?
[15:50:48] <zultron> What was the thinking behind bundling it with LinuxCNC?
[15:51:00] <cradek> everyone wanted it always
[15:51:00] <CaptHindsight> seb_kuzminsky: nope he's working on real time kernels for ARM right now
[15:51:02] <zultron> Seb asked it better. :)
[15:51:39] <cradek> also, it was a bit tedious to install, particularly since it was python, and it was the dark ages
[15:52:51] <skunkworks> by the time emc2 came out - it was combined - wasn't it? I don't remember axis being a separate package///
[15:52:59] <CaptHindsight> this is where the devs in China can come in handy since they will most likely also make GUI's
[15:54:06] <cradek> heh, the AXIS blog is gone
[15:54:34] <cradek> skunkworks: I don't remember but for a while AXIS would run both emc and emc2 and I think it was separate from both
[15:54:46] <skunkworks> huh - interesting
[15:56:02] <skunkworks> http://emergent.unpythonic.net/01155174717
[15:57:29] <skunkworks> hmm - thinking about it - I bet I did have to do something special to run axis initally
[16:01:49] <alex_joni> initially AXIS was for emc1 only
[16:02:03] * alex_joni remebers hacking build stuff so it worked with emc2
[16:02:24] <seb_kuzminsky> that's really cool
[16:02:37] <alex_joni> it was around the time the emc2 build system underwent constant change, so that had to be done again every couple of days :D
[16:03:04] <cradek> I was certainly still using emc1 when we started on it
[16:03:12] <seb_kuzminsky> now the build system only changes when zultron gets a bee in his bonnet ;-)
[16:03:29] <alex_joni> http://emergent.unpythonic.net/01227191152
[16:03:33] <zultron> :D
[16:04:01] <cradek> my first posts to emc-users were in May '04, so I'm coming up fast on 10 years doing this
[16:04:01] <alex_joni> initially it wasn't even called AXIS
[16:04:33] <alex_joni> cradek: yeah.. been a while ;)
[16:07:49] <CaptHindsight> having only browsed through the Linuxcnc tree, how is AXIS tied into EMC currently?
[16:08:39] <skunkworks> wow - that still looks like a current gui.. (I may be biased..)
[16:08:56] <seb_kuzminsky> CaptHindsight: do you mean what linuxcnc apis does axis use?
[16:09:10] <cradek> it's like any other gui except it also embeds an interpreter whose callbacks generate opengl calls
[16:09:38] <CaptHindsight> seb_kuzminsky: yeah
[16:10:47] <alex_joni> 2004-07-18 <alex_joni> is it possible to use estop with minimill?
[16:11:00] <CaptHindsight> since we would do most of the work, how do you suggest we do this with as little disruption to the current devs?
[16:12:00] <seb_kuzminsky> CaptHindsight: about axis apis, it imports a bunch of linuxcnc python modules: linuxcnc, rs274, hal, gcode, maybe others
[16:12:05] <CaptHindsight> will anyone else ever require an new GUI?
[16:12:26] <seb_kuzminsky> CaptHindsight: you're asking how to collaborate on a huge restructuring task, this has not historically been our strong point ;-)
[16:12:34] <CaptHindsight> heh
[16:12:53] <cradek> there is no restructuring needed to build an external gui
[16:13:07] * seb_kuzminsky agrees
[16:13:33] <seb_kuzminsky> but that's not the driver for this thought-experiment, is it?
[16:13:55] <cradek> well I wasn't doing a thought experiment
[16:14:09] <cradek> I was thinking about how to answer CaptHindsight's question
[16:14:38] <cradek> http://media.unpythonic.net/emergent-files/01167419757/jdi.py
[16:15:00] <cradek> this is a UI that loads and runs a program (probably needs updating because the module is no longer called emc)
[16:15:24] <cradek> if you build your new gui in python it'll look like this
[16:15:45] <cradek> if you build your new gui in C, it'll look like xemc's guts, but the libraries and headers you need are in the -dev package already
[16:16:37] <CaptHindsight> If I ask the guys in China to look at this without any clear directions they might come back with "why don't we just port this to Windows" :)
[16:17:11] <seb_kuzminsky> i'm not sure an outside consultant is the best entity to do this job
[16:17:15] <skunkworks> on the forum there are a couple of new gui's people are developing.. like mocca and gscreen
[16:17:19] <cradek> maybe you'll have to do the work to figure out how to support your programmers then
[16:17:25] <CaptHindsight> I'd rather have them build something that is of use to everyone
[16:17:38] <cradek> seb_kuzminsky: what is "this job" that you are talking about?
[16:18:17] <seb_kuzminsky> i think CaptHindsight is offering to hire chinese programmers to split linuxcnc.git into hal.git and linuxcnc.git
[16:18:24] <alex_joni> side question: did the monthly meet take place recently?
[16:18:29] <cradek> seb_kuzminsky: that is not my understanding
[16:18:34] <seb_kuzminsky> oh
[16:18:34] <cradek> CaptHindsight: ?
[16:18:45] <cradek> alex_joni: no they haven't happened for months - no agenda
[16:18:50] <CaptHindsight> they are in house
[16:19:20] <CaptHindsight> they just need to be given the project and clear directions
[16:19:33] <cradek> seb_kuzminsky: now I'm just as baffled as I thought you were
[16:19:44] <seb_kuzminsky> CaptHindsight: is that repo-splitting the project we're talking about?
[16:20:05] <cradek> I thought we were talking about how to build a separate 3d printer gui project
[16:20:27] <CaptHindsight> yeah, what Cradek said
[16:20:37] <seb_kuzminsky> ok, than it's me who's confused
[16:20:39] <CaptHindsight> gui project for a start
[16:20:46] <seb_kuzminsky> and yes, you can already do that, no work needed
[16:21:27] <CaptHindsight> maybe after they get comfortable with Linuxcnc they could help with the git split
[16:21:58] <alex_joni> cradek: so much for that
[16:22:06] <CaptHindsight> they already wrote their own cnc control app that we won't be using :)
[16:22:21] <cradek> alex_joni: it's next week, if you have an agenda
[16:22:36] <alex_joni> nope.. I plan to hit the slopes next saturday ;)
[16:22:45] <cradek> alex_joni: I don't think the process is a failure just because there is sometimes no agenda
[16:23:00] <andypugh> alex_joni: Where are you going?
[16:23:01] <alex_joni> I didn't say it's a failure
[16:23:11] <cradek> then I misread "so much for that"
[16:23:24] <alex_joni> just that people were very excited and it had to happen, because they had so many issues
[16:23:25] <cradek> to me, that's an expression that means "well that experiment failed"
[16:23:40] <alex_joni> and a couple months later there is no wind in the sails
[16:23:45] <alex_joni> andypugh: zillertal
[16:24:03] <alex_joni> cradek: yeah, it did sound a bit like that
[16:24:24] <andypugh> I am heading to Tignes this weekend, then Zell am See at the end of February
[16:24:51] <seb_kuzminsky> zultron: one of the changes ubc does is move linuxcnc_module_helper, pci_read, and pci_write from /usr/bin to /usr/libexec, was that intentional?
[16:25:10] <alex_joni> http://emergent.unpythonic.net/01101411814
[16:25:27] <alex_joni> andypugh: cool, hope you'll have some snow
[16:26:00] <zultron> Intentional, but you tell me if it's correct: gnu coding standards call for executables not run by end-users and only by scripts into libexec.
[16:26:09] <cradek> I bet that's right
[16:26:49] <zultron> I didn't do a complete job, however, and others executables might need to be moved there, too.
[16:26:52] <seb_kuzminsky> that makes sense for linuxcnc_module_helper for sure
[16:27:18] <seb_kuzminsky> i'm not sure what pci_read and pci_write are for, i dont think anything uses them
[16:27:30] <seb_kuzminsky> maybe debugging helpers for jmk's m5i20 work?
[16:27:53] <alex_joni> cradek:
http://emergent.unpythonic.net/01118085817
[16:28:48] <zultron> usermode PCI drivers
[16:28:54] <skunkworks> that's it - I remember getting the nightly snapshots...
[16:29:24] <seb_kuzminsky> zultron: written in bash? shelling out to those helper utilities?
[16:29:50] <zultron> I'm going by 'grep -rl pci_read *'
[16:30:23] <zultron> Now let me actually look....
[16:30:34] <seb_kuzminsky> i think utils/upci is no longer used by anything that anyone uses
[16:30:58] <seb_kuzminsky> (not a problem with ubc, a problem with master and maybe 2.5 if i'm right, for very weak values of "problem")
[16:32:26] <zultron> Yeah, I don't see the pci_read executable being used anywhere.
[16:35:31] <seb_kuzminsky> inivar and flavor are also in libexec, because they shouldn't be visible to users?
[16:37:43] <zultron> Not 'shouldn't', but 'don't need to be'.
[16:38:39] <zultron> If you think there's a case for making them available for end-users, move them back to /usr/bin.
[16:39:12] <zultron> I'm definitely weak on the end-use of LinuxCNC.....
[16:39:54] <seb_kuzminsky> what does flavor do?
[16:40:06] <seb_kuzminsky> err, what does /usr/libexec/flavor do? ;-)
[16:40:24] <seb_kuzminsky> "flavor tells you if something is tasty or not, seb"
[16:42:06] <zultron> run it, and it will tell you the default/bestest thread flavor.
[16:42:32] <zultron> It also has some args that present some flavor-specific params.
[16:42:38] <zultron> It's used in the realtime scripts.
[16:42:53] <seb_kuzminsky> aha
[16:43:10] <seb_kuzminsky> i ran it and saw the output but wasnt clean on what exactly i was looking at
[16:43:11] <zultron> For run-time flavor configuration.
[16:43:43] <seb_kuzminsky> so at compile-time you choose a subset of the possible flavors to build for, and the flavor program remembers what's available and tells you about it?
[16:43:44] <alex_joni> heh, completely forgot about
http://imagebin.org/index.php?mode=image&id=286938
[16:45:04] <zultron> 'flavor' runs some checks to see whether the needed resources (e.g. kernel support) exist. It checks all flavors, regardless of compile-time options.
[16:45:20] <seb_kuzminsky> hmmm-kay
[16:45:26] <zultron> That way, 3rd-party flavor modules may be added to a base package distribution.
[16:50:37] <CaptHindsight> andypugh: how is the Udoo coming along?
[16:50:47] <andypugh> Badly
[16:50:58] <CaptHindsight> maybe I'll order one today
[16:51:40] <andypugh> I can't figure out where to look to sort out these compiler errors:
http://pastebin.com/EhgtsLAM
[16:54:03] <andypugh> It is less easy than it looks. bufp.c is a symlink to the xenomai code. It doesn't contain the text "dma_alloc_non" or the text "fec_enet_init"
[16:57:02] <CaptHindsight> andypugh: did the Udoo bring SPI out to any headers?
[16:57:11] <andypugh> I think so, yes.
[16:57:18] <andypugh> I haven't got that far yet.
[16:57:54] <CaptHindsight> then I can get a fpga connected as well
[16:58:09] <CaptHindsight> I'll look it over
[17:45:59] <alex_joni> night all
[17:53:09] <seb_kuzminsky> seeya alex_joni
[18:00:31] <KGB-linuxcnc> 03Dewey Garrett 05master 9c69e81 06linuxcnc 10lib/python/popupkeyboard.py popupkeyboard.py: take advantage of linuxcnc.SHARE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c69e81
[18:12:53] <linuxcnc-build> build #1674 of lucid-rtai-i386-clang is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1674 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:27:50] <seb_kuzminsky> that's my mistake, not dgarr's
[18:27:54] <seb_kuzminsky> i'll fix it
[18:30:56] <seb_kuzminsky> linuxcnc-build: force build --branch=master lucid-rtai-i386-clang
[18:30:57] <linuxcnc-build> build #1675 forced
[18:30:57] <linuxcnc-build> I'll give a shout when the build finishes
[18:31:03] <seb_kuzminsky> maybe now?
[18:33:59] <seb_kuzminsky> yeah, now it's running
[18:41:45] <linuxcnc-build> Hey! build lucid-rtai-i386-clang #1675 is complete: Warnings [8warnings compile]
[18:41:45] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1675
[19:00:43] <linuxcnc-build> build #1679 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1679 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:13:57] <owhite> Greetings everyone. I'm using a mesa 5i20 board to drive steppers and bunch of other i/o. The hostmot2 driver is invoked in my .ini file with the following command: "firmware=hm2/5i20/SVST8_4.BIT etc..."
[19:14:18] <owhite> I created a custom circuit board that interfaces with the mesa card, and I assumed I could control the pins that have step/gen signals. From poking around the docs it looks like the default pin settings for the 5i20 is set up in this file:
[19:14:47] <owhite> SVST8_4.PIN
[19:14:56] <owhite> My question is, in order to change the usage of the pins, do I need to recompile the firmware that is loaded on the board, or could I just modify this file and new pins would be used at run time?
[19:15:21] <andypugh> Not as such, that file simply tells you, the human, what pin is which. The pon mapping is actually defined by the .bit file
[19:15:53] <andypugh> If you want to move pins around you need to recompile the bitfile.
[19:15:58] <owhite> who says I'm human - on the internet no one can tell that your a dog.
[19:16:18] <owhite> is there documentation on recompiling the bitfile?
[19:16:19] <andypugh> But.. If you don't need all the steppers, you can turn some off, and use their pins as GPIO.
[19:17:30] <cradek> pcw is quick at building custom firmwares, but I'd change wiring if at all possible, so you can continue to use one of the standard ones.
[19:17:57] <andypugh> To see this in action halrun // loadrt hostmot2 // loadrt hm2_pci confif="firmware=hm2/5i20/STSV8.4.bit" // exit // dmesg
[19:17:59] <owhite> it's not that I need more GPIO or need to turn off the steppers, the issue is that I have to control the exact pins on the 5i20 that have step/dir (and also pwm) functions.
[19:18:35] <owhite> cradek: sorry, is pcw a user, or a program?
[19:18:40] <andypugh> Ah, it might have been easier to make the hardware suit the bitfile.
[19:18:45] <cradek> heh, he's a guy, I've even met him.
[19:18:52] <cradek> I figured for a long time he was a robot, but no.
[19:19:16] <cradek> in only two tries can you get your board made in such a way that you can use the standard bitfile? that's going to be less painful in the long run I suspect.
[19:19:24] <owhite> andy: I know. I blew it. I even came on here and asked if I the pin assignment was constrained, and I tried to do the research to check, but I thought it would be okay.
[19:19:50] <cradek> I'm happy when it only takes two tries to make something come out right...
[19:19:54] <owhite> kind of bites because I already had my pcb made.
[19:20:17] <owhite> yeah so far I havent found any other errors in the pcb. so this is strike one.
[19:20:46] <cradek> how different is it? I've rearranged ribbon cables before in similar situations
[19:20:56] <cradek> you know, disassemble and twist part of it, etc
[19:21:26] <owhite> hm. I could think about that. I take it recompiling is prohibitively complicated?
[19:21:32] <andypugh> If you want to make your own bitfiles (and I have managed to do it, so it can't be that hard) have a look at :
http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=tree;h=3e97b6f53ad38c8cd05db36da8b888e5b7ac3850;hb=3e97b6f53ad38c8cd05db36da8b888e5b7ac3850
[19:21:40] <andypugh> Specifically the "README"
[19:22:10] <cradek> I've never done it. it takes many gigabytes worth of downloads which is enough to turn me off.
[19:22:57] <owhite> what is pcw's favorite type of pizza?
[19:23:17] <andypugh> This is the file you would need to edit to move the pin allocations.
http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=blob;f=PIN_SVST8_4_72.vhd;h=7c46fb0222b4694147b10c3f7b4771cf0057efa3;hb=3e97b6f53ad38c8cd05db36da8b888e5b7ac3850
[19:23:54] <andypugh> Just moving pins isn't that hard, the problem is getting the compile environment set up.
[19:24:13] <owhite> I hear that.
[19:26:02] <andypugh> The readme describes what you need to work with that particular (very outdated) repository.
[19:26:49] <andypugh> But the 5i20 is an old card (still current, but old) so is fully supported by that repositpry and the version of webkit that it recommends.
[19:27:18] <owhite> one last question - if I ask a friend to make the firmware, he succeeds in compiling it, would I be able to use the firmware on my environment? The execution environment of the firmware is different than compilation environment of the firmware?
[19:34:48] <andypugh> The bitfile runs on the FPGA, so it is always cross-compiled anyway.
[19:35:23] <andypugh> I have a virtual machine with a working Hostmot2 compile environment on it somewhere.
[19:35:30] <owhite> right, but the compile happens on the desktop?
[19:35:41] <owhite> oh wow, that'd be useful.
[19:35:46] <andypugh> Yes, or in a Linux VM in my case
[19:45:01] <andypugh> Unfortunately the VM is 54GB, so it isn't something I could email out...
[19:46:07] <Tom_itx> it's not too difficult to roll your own bit files
[19:47:14] <andypugh> I just made a 5i23 verison of SVST8_4, so it seems that the system still works.
[19:47:26] <andypugh> Took about 10 minuts.
[19:47:41] <Tom_itx> what does he want to change?
[19:48:34] <andypugh> Pin locations
[19:48:57] <Tom_itx> that's it?
[19:49:03] <andypugh> Yes.
[19:49:05] <Tom_itx> no function scramble?
[19:49:27] <andypugh> As I said, compiling the firmwares is not all that hard, but setting up the system to do it can be.
[19:50:16] <Tom_itx> time consuming getting the software
[19:51:15] <owhite> hey folks.
[19:51:55] <owhite> tom - the only thing I want to do is change the pins used for step/gen and pwm
[19:53:25] <atom1> which bit file are you looking at?
[19:54:02] <owhite> http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=blob;f=PIN_SVST8_4_72.vhd;h=7c46fb0222b4694147b10c3f7b4771cf0057efa3;hb=3e97b6f53ad38c8cd05db36da8b888e5b7ac3850
[19:54:34] <Tom_itx> PIN_SVST8_4_72 ?
[19:55:21] <owhite> yeah I believe so.
[19:57:18] <atom1> looks like the whole of the second connector is set up for stepgen
[19:59:53] <atom1> do you know what pins you would like to move?
[20:08:25] <andypugh> Night all
[20:08:34] <atom1> later andy
[20:09:50] <owhite> ski-dattling. Thanks to everyone, as always.
[20:39:22] <KGB-linuxcnc> 03Dewey Garrett 05master 96762c7 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc 10src/emc/rs274ngc/interp_read.cc 10src/emc/rs274ngc/rs274ngc_return.hh interp: show number of erroneous user m code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96762c7
[20:39:22] <KGB-linuxcnc> 03Dewey Garrett 05master 7a30619 06linuxcnc 10nc_files/M101 M101 example: print file location to stdout * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7a30619
[22:54:15] <seb_kuzminsky> i pushed a new rtai-modules deb to w.l.o, it just adds some missing package metadata to let ubc compile
