Back
[00:47:46] <pcw_home> sserial is about 80/90 usec for most things, added channels dont add much more (maybe a few usec per channel)
[00:51:01] <KimK> Hi Peter. OK, great, so one (or two?) full 7i44's should be less than 720us? (1440us?) That would help.
[00:51:14] <pcw_home> (that is all channels xmit and recv at once so its possible to run 16 channels or more at multi-KHz rates)
[00:52:58] <pcw_home> Yes that 80-90 usec turnaround is non cumulative (but there is a few usec per channel for reading/writing the data)
[00:53:42] <KimK> OK, great, that sounds good. And this is with "default"(?) speeds? Or is this with "clock tweaking"(?) or some such?
[00:54:27] <pcw_home> this is standard (most time is the 4 usec per character time at 2.5 MBaud)
[00:55:54] <pcw_home> it is possible to run most remotes at 10 MBaud which will bring the max times down to ~50 usec
[00:59:01] <KimK> OK. But that should be pretty fast then, does micges time of 500us (give or take) for his (analog servo+piggyback_i/o plus stepper_i/o+piggyback_o) seem right?
[00:59:16] <pcw_home> KimK: I got the Cincinatti I/O rack outputs working (can now blink the Neon lights on a ACO module)
[01:00:12] <pcw_home> No, it should be quite a bit faster
[01:01:26] <pcw_home> I think micges was thinking the sserial response times are cumulative, but they are all done ~in parallel
[01:04:50] <KimK> Re: Cinci, excellent! What did you use for the 12v output driver, open collector something? Reason is, I'm looking around for something for the opposite purpose, a small fast +/- 15V in comparator so I can protect my OpenSourceSniffer Logic analyzer. I made up the physical adapters for the Cinci some time ago, but had to stop when I put a scope on it and saw the (0-12v, wasn't it) swings. Never got back to it, but I'd still like to be
[01:04:50] <KimK> able to look at the protocol.
[01:04:55] <KimK> Oops
[01:06:15] <KimK> s/wasn't it)/wasn't it?)/
[01:06:37] <pcw_home> I just used resistor dividers for input level shifting (only needed for reading data)
[01:07:06] <pcw_home> and 4054s for 5V --> 12V conversion
[01:10:02] <KimK> OK. And the loading looked good that way?
[01:10:05] <KimK> I was hoping to have a pot-variable threshold, but resistors *are* cheap, lol.
[01:10:44] <pcw_home> Ive got rack and card address figured out still some mysteries with control signals, but I can extinguish the IBA fault lights
[01:10:45] <pcw_home> and have the ACO cards Neons counting in binary
[01:12:38] <pcw_home> In my case the dividers are local (on my side of a HEF40245? 12 V buffer)
[01:14:03] <pcw_home> You could use a 26ls32 and a 2/1 input divider as a fast 12V receiver with settable threshold
[01:14:27] <pcw_home> Ill send you a IBAIF card when I get a chance
[01:18:26] <KimK> OK, IBAIF, I forgot, is that the Cinci rack card or is that your new card? And if I can get something kludged together to protect my OSS LA, would it help you if I observed a machine running live?
[01:19:41] <KimK> The OSS is said to be able to do protocol analysis, though I haven't tried it.
[01:19:51] <pcw_home> yeah if i could get original timing info that would help
[01:22:23] <pcw_home> the Cinci bus adapter is called a IBA (first slot) the IBAIF is a 50 pin FPGA daughtercard with 50 pin header and DB25
[01:22:25] <pcw_home> connector to Cinci Rack (mainly a 5 <--> 12V level translator)
[01:25:07] <KimK> OK, I'll put together an OSS LA isolator using your suggested HEF40245 driving resistive dividers. Ah, OK, so the IBAIF (IBA InterFace?) is your new one, great! Yes, I'd love to have one, thanks!
[01:25:50] <pcw_home> I thought the I/O cards were bit addressed but they are 8 bit parallel
[01:26:33] <KimK> Yes, 8-bit data, and what, 10-bit address? I forgot.
[01:26:59] <pcw_home> next step is to loop back 8 ACO module outputs to 8 ACI inputs and try reading data
[01:28:44] <pcw_home> there are:
[01:28:45] <pcw_home> 4 RS addresses (rack select - the thumbwheel on the IBA)
[01:28:47] <pcw_home> 4 CS addresses (for the up to 16 cards in a rack)
[01:28:48] <pcw_home> and maybe 3 per card addresses
[01:31:07] <pcw_home> The RS and CS addresses work as expected (card closest to IBA is CS0)
[01:34:06] <KimK> Where CS0 is the "zero/first" card, you mean? OK, great. And for the OSS, how about if I wanted a more generalized +/- 12 (or 15?) fast comparator, so I can pick the slice point with a pot? What would you suggest then? I was looking at some fast comparators, but some limited the speed, compared to the OSS. Some were big and pricey.
[01:35:30] <seb_kuzminsky> linuxcnc-build: force build --branch=seb/2.7/docs-reorg 0000.checkin
[01:35:31] <linuxcnc-build> build #2769 forced
[01:35:31] <linuxcnc-build> I'll give a shout when the build finishes
[01:36:11] <KimK> And (again on the OSS) who's good lately for small PCB proto runs (on a budget, lol!)
[01:36:17] <pcw_home> Its hard to get fast and wide common mode range together
[01:36:38] <KimK> Yes, that's what I was finding.
[01:37:05] <pcw_home> I dont know we usually tack protos on multi up-panels with small production lot cards
[01:37:29] <KimK> OK, I'll ask around.
[01:38:17] <pcw_home> so we only pay about $0.15 per square inch for 4 layer protos but we end up with 50 cards
[01:39:33] <pcw_home> (which is good if they are close enough for production but a waste otherwise)
[01:40:33] <pcw_home> oops eyes hooding over... 'nite
[01:40:46] <KimK> Ha, nice! If you think of any advice on the comparator version, please post it, I'll check it out. Thanks in advance.
[01:41:03] <KimK> Thanks! Goodnight. More later.
[01:43:14] <linuxcnc-build> build #2757 of 1300.rip-precise-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2757
[01:43:46] <linuxcnc-build> build #915 of 1403.rip-wheezy-amd64 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/915
[01:43:58] <linuxcnc-build> build #1106 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1106
[01:43:58] <linuxcnc-build> build #2758 of 1200.rip-lucid-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2758
[01:44:07] <linuxcnc-build> build #2759 of 1306.rip-precise-amd64 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2759
[01:44:07] <linuxcnc-build> build #915 of 1400.rip-wheezy-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/915
[01:44:24] <linuxcnc-build> build #1959 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1959
[01:44:53] <linuxcnc-build> build #426 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/426
[01:45:08] <linuxcnc-build> build #2758 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2758
[01:45:23] <linuxcnc-build> build #2758 of 1202.rip-lucid-amd64 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2758
[01:45:47] <linuxcnc-build> build #573 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/573
[01:49:37] <linuxcnc-build> build #945 of 1405.rip-wheezy-armhf is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/945
[01:57:26] <seb_kuzminsky> well shit
[01:58:31] <seb_kuzminsky> oh, it's just my broken branch
[01:58:46] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[01:58:52] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[01:59:31] <linuxcnc-build> build #2769 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2769
[01:59:32] <linuxcnc-build> build #2770 forced
[01:59:32] <linuxcnc-build> I'll give a shout when the build finishes
[02:00:00] <KimK> seb_kuzminsky: It's OK, there's no blamelist, we don't blame anybody around here, lol!
[02:21:35] <seb_kuzminsky> heh
[02:21:57] <seb_kuzminsky> i think i have a fixed version of that branch around here somewhere...
[02:24:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/docs-reorg 542eec6 06linuxcnc 10(83 files in 9 dirs) docs: reorg Getting Started (English) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=542eec6
[02:24:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/docs-reorg b0900be 06linuxcnc 10(78 files in 8 dirs) docs: reorg Getting Started (French) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b0900be
[02:24:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/docs-reorg 9740391 06linuxcnc 10(23 files in 5 dirs) docs: reorg Getting Started (Spanish) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9740391
[02:51:27] <linuxcnc-build> Hey! build 0000.checkin #2770 is complete: Success [3build successful]
[02:51:27] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2770
[03:10:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 5bf7771 06linuxcnc 10docs/src/config/lathe_config.txt 10docs/src/config/lathe_config_fr.txt make lathe_config{,_fr}.txt comparable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bf7771
[03:10:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a e084aa6 06linuxcnc 10debian/control.in build-depend on po4a, for translated docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e084aa6
[03:10:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 19b164b 06linuxcnc 03docs/src/config/lathe_config.fr.po 03docs/src/config/lathe_config.se.po add lathe_config po files for french and swedish * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19b164b
[03:10:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 6e0931a 06linuxcnc 10docs/src/config/lathe_config.fr.po Clear the "fuzzy" tags in in the french .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e0931a
[03:10:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 5902457 06linuxcnc 10docs/src/config/.gitignore ignore the translated docs made by po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5902457
[03:10:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 2f1053d 06linuxcnc 10docs/src/config/lathe_config.se.po set author in swedish .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f1053d
[03:10:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 7e637ae 06linuxcnc 10docs/src/config/lathe_config.se.po update swedish .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e637ae
[03:10:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 1a593fa 06linuxcnc 10docs/src/config/lathe_config.se.po docs: more swedish translations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1a593fa
[09:41:44] <mozmck> Is it an error to connect to a HAL pin that does not exist?
[09:41:59] <mozmck> or will it just ignore it?
[09:43:23] <cradek> halcmd: net what not-a-pin-name
[09:43:23] <cradek> <stdin>:1: Pin 'not-a-pin-name' does not exist
[09:44:42] <mozmck> ok. I'm (finally) working on a component, and it would be nice to have pins created automatically if devices are detected.
[09:45:42] <cradek> yeah I think you only get one chance to create pins at initialization time
[09:45:43] <pcw_home> ifdef halpin {
[09:46:24] <mozmck> I can just create pins and do nothing with them if the device is not present, but that not quite as flexible as what I was thinking of.
[09:46:58] <mozmck> pcw_home: I'm not sure I understand?
[09:47:54] <pcw_home> Ive often wished the hal parsed haf a if_exist hal pin function
[09:48:20] <pcw_home> hal parser had
[09:49:20] <pcw_home> so it could at least bellyache more expressively if something was missing
[09:49:39] <mozmck> ah, yes. my thoughts are probably similar. a hal file could connect pins and nets, and the ones that don't exist get ignored until they do exist, then start using them.
[09:50:23] <mozmck> That might slow things down just a little though. Exactly how is a hal pin implemented? Is it a function?
[09:51:14] <pcw_home> I presume its a pointer
[09:51:59] <mozmck> since a userspace component is a separate process, I would assume it has to be more than just a pointer?
[09:52:19] <seb_kuzminsky> a hal pin is a pointer
[09:52:32] <seb_kuzminsky> into memory shared with the rest of hal
[09:54:04] <mozmck> ah, ok.
[09:55:37] <seb_kuzminsky> in the hostmot2 driver we do all the device detection early, then hal_pin_new, then hal_ready
[09:57:19] <mozmck> So if a device is not present, then pins for it don't get created?
[09:57:29] <seb_kuzminsky> right :-/
[09:57:33] <mozmck> Then if the hal file has connections for those pins it fails?
[09:57:37] <seb_kuzminsky> yep
[09:57:41] <mozmck> ugh
[09:58:16] <seb_kuzminsky> i suppose at startup you could create hal pins speculatively, for all the devices you might discover in the future
[09:58:25] <seb_kuzminsky> that way the pins'll be there and you can hook them up
[09:58:43] <seb_kuzminsky> they just wont do anything until the component discovers the device later (if at all)
[09:58:57] <mozmck> Yes, that's my thought, or probably what I'll do is have options passed to the component telling it which devices I want it to make pins for.
[09:59:34] <cradek> I don't understand yet what problem you're trying to solve
[09:59:52] <cradek> you want pins for hardware that might be plugged in later?
[10:00:01] <mozmck> yes.
[10:00:32] <cradek> what kind of hardware setup is making you want that?
[10:00:41] <mozmck> then the hal file can be more staic.
[10:00:44] <mozmck> static
[10:01:36] <mozmck> we have a USB->RS485 hub that talks to our devices.
[10:03:46] <mozmck> it would be nice (I think!) to be able to have a hal file that has connections for many devices - if they exist.
[10:06:04] <cradek> I think I can imagine some times that might be useful - like a probe that you only plug in when you need it
[10:06:09] <mozmck> anyhow, I'm currently just trying to figure out what can be done to figure out the best way to do what I need to do.
[10:06:39] <cradek> if the probe plugs into an opto22, it's fine if you unplug the wire, who cares, the opto22 is still wired to the mesa card and the mesa driver still presents the hal pin to hook up to motion's probe input
[10:07:35] <cradek> but if your probe is much smarter than that - part of a hotplug system like usb - the scheme breaks down
[10:07:46] <mozmck> yes, so I can do it by just have my component make hal pins for everything that might be hooked up, or I can pass in arguments telling it what to create.
[10:08:30] <mozmck> I think the latter may be what I want
[10:08:32] <cradek> yeah I think in the probe case you'd tell the hub's driver "I have the smartprobe device I might plug in sometimes" so it gives you a pin to hook to motion's probe input pin
[10:09:15] <cradek> then you have the same hookup (that is sometimes inactive) as my probe via opto22 setup
[10:09:47] <archivist> if you have a pin but no device you need to set a default state for it maybe
[10:10:06] <cradek> yep
[10:10:28] <cradek> the hub driver should know what an unplugged smartprobe should do
[10:10:49] <mozmck> heh, yes - or you read 398740928 volts on the power supply :)
[10:11:08] <archivist> or run to a stop with no stop switch
[10:13:50] <cradek> a smartprobe that's unplugged should probably show low (probe is not touching) but a smartlimitswitch that is unplugged maybe should show high (on limit)
[10:14:18] <cradek> I think the hub driver should know these things
[10:15:09] <mozmck> yes, the component will handle all of that - and there's nothing like a limit switch on it, but probably will be relays at some point.
[10:16:13] <cradek> yeah I'm not guessing what your hardware is - just thinking of simple examples to help me picture how the design could work
[10:17:33] <mozmck> right now, mostly a THC, hand controller, and information from a power supply and drives.
[10:19:40] <mozmck> So for every configuration, I'll need different hal files. Hmm, can you #include hal files in others?
[10:34:02] <seb_kuzminsky> mozmck: yes
[10:34:36] <mozmck> seb_kuzminsky: thanks - that is nice.
[10:36:31] <pcw_home> ifdef (halipin)
[10:36:32] <pcw_home> #include frimmle.hal
[10:36:34] <pcw_home> endif
[10:38:38] <mozmck> pcw_home: but the ifdef (halpin) doesn't work - right? that would be nice.
[10:39:02] <pcw_home> Yeah its a joke
[10:40:03] <pcw_home> gets a bit ugly if the hardware subsequently disappears
[10:40:53] <mozmck> and the hal pins that go with it?
[10:42:38] <pcw_home> I guess the hal pins could stay if thay were reassigned decent values at least one hal pin indicatd that the hardware is not present
[10:42:52] <pcw_home> and at least
[10:44:32] <pcw_home> so users readouts for example could either fold up shop and go away or display "unknown" for remote data
[10:51:49] <mozmck> yes. I wonder how hard it would be to add and ifdef or if (pin_exists()) to hal?
[11:04:45] <cradek> halpr_find_pin_by_name is already implemented but I don't know if it's supposed to be part of the external api
[11:04:54] <cradek> searching the list of pin names is a common thing hal has to do
[11:05:21] <cradek> I don't understand how this helps you solve your problem, though
[11:06:18] <cradek> ah halpr_ means private
[11:06:24] <cradek> so no, that's an implementation detail
[11:08:52] <seb_kuzminsky> yeah there are two things under discussion here
[11:09:29] <seb_kuzminsky> 1. how to create hal pins for devices that are not present at component creation time?
[11:09:47] <seb_kuzminsky> 2. how to dynamically wire hal circuits based on available pins?
[11:11:02] <seb_kuzminsky> i remember i wanted 1. when i was writing the hostmot2 driver, but ended up working around it by doing all detection at component creation time
[11:11:55] <cradek> I understand the desire for #1 after the smartprobe thought experiment, but I don't really get #2 yet
[11:12:13] <seb_kuzminsky> for 2 we have haltcl, might that be useful mozmck ?
http://linuxcnc.org/docs/2.6/html/hal/haltcl.html
[11:12:35] <seb_kuzminsky> cradek: a situation that wants 2 that i've imagined is this:
[11:13:15] <seb_kuzminsky> we could have example config files that include drivers for hardware that users might not have
[11:13:23] <seb_kuzminsky> such as those usb joystick jogger things
[11:13:30] <seb_kuzminsky> and the xhc-hb04 jog pendant
[11:13:31] <seb_kuzminsky> and others
[11:13:48] <seb_kuzminsky> and a smart/programmable hal file (haltcl maybe) could do something like:
[11:14:07] <seb_kuzminsky> try to load all these optional drivers
[11:15:10] <seb_kuzminsky> for all the ones that succeeded in loading, OR or ADD together their jog pins => axis.N.jog-counts
[11:15:29] <cradek> ah, you're inventing plug-and-play
[11:15:39] * seb_kuzminsky ponders
[11:15:47] <seb_kuzminsky> sort of
[11:16:05] <seb_kuzminsky> 2 is init-time plug-n-play, 1 is part of runtime plug-n-play
[11:18:07] * seb_kuzminsky shrugs
[11:29:36] <archivist> I can for see 2 for some of the odd setups like a 5 axis mill with a switch to a geared setup mid job
[11:30:38] <archivist> that being evil mid gcode program perhaps #3
[11:33:53] <archivist> I did the gearing in gcode for my bevel generation but really it should have been closer to the hobbing setup but with a programmable offset for the two passes
[14:25:40] <seb_kuzminsky> francis tisserant (the guy who translates our docs to french) got back to me with positive feedback on the po4a idea
[14:26:21] <seb_kuzminsky> he offered to do the french translation in the new gettext/po4a framework once/if that gets set up
[14:26:47] <seb_kuzminsky> he acknowledged that the structure of the french docs has diverged from the english, and that it would be a hassle to unify them in order to use gettext
[14:27:06] <seb_kuzminsky> but also that that's probably a better option than the current diverged situation
[14:27:29] <seb_kuzminsky> so that all resonates with my understanding of the situation and my hopes & fears for po4a
[14:33:57] <cradek> wow, you're both awesome
[15:22:47] <seb_kuzminsky> the po4a package in jessie, 0.45, has better support for asciidoc than the package in wheezy (0.42) does
[15:23:06] <seb_kuzminsky> the jessie po4a debs install without trouble in wheezy
[15:23:20] <seb_kuzminsky> i'm not sure what exactly the difference is, but it's called out in their changelog
[17:30:57] <KGB-linuxcnc> 05dgarr/moveoff_squashed 0ade81d 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ade81d
[17:31:57] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/lib_for_halfiles 0fc2239 06linuxcnc 10(11 files in 6 dirs) linuxcnc.in: support halfiles in a system lib * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0fc2239
[17:33:19] <KGB-linuxcnc> 05dgarr/moveoff_touchy 6067d8b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6067d8b
[18:50:51] <linuxcnc-build> build #2217 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2217 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:53:16] <linuxcnc-build> build #2222 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2222 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:54:34] <linuxcnc-build> build #2222 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2222 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:57:50] <linuxcnc-build> build #1056 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1056 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:08:17] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/lib_for_halfiles be2fe9e 06linuxcnc 10(11 files in 6 dirs) linuxcnc.in: support halfiles in a system lib * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be2fe9e
[19:11:50] <linuxcnc-build> build #787 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/787 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:12:45] <linuxcnc-build> build #311 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/311 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:13:06] <linuxcnc-build> build #2219 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2219 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:13:12] <linuxcnc-build> build #786 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/786 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:13:21] <linuxcnc-build> build #2216 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2216 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:14:28] <linuxcnc-build> build #272 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/272 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:16:39] <linuxcnc-build> build #489 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/489 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:04:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 615bedc 06linuxcnc 10docs/src/Submakefile docs: remove an old obsolete incorrect comment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=615bedc
[20:08:56] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9a20e81 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a20e81
[20:29:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a f5a6013 06linuxcnc 10docs/src/config/lathe_config.txt 10docs/src/config/lathe_config_fr.txt make lathe_config{,_fr}.txt comparable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f5a6013
[20:29:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a e576046 06linuxcnc 10debian/control.in build-depend on po4a, for translated docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e576046
[20:29:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 1805ff2 06linuxcnc 03docs/src/config/lathe_config.fr.po 03docs/src/config/lathe_config.se.po add lathe_config po files for french and swedish * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1805ff2
[20:29:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 16db1c9 06linuxcnc 10docs/src/config/lathe_config.fr.po Clear the "fuzzy" tags in in the french .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=16db1c9
[20:29:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 645d31c 06linuxcnc 10docs/src/config/.gitignore ignore the translated docs made by po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=645d31c
[20:29:36] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 0c680b1 06linuxcnc 10docs/src/config/lathe_config.se.po set author in swedish .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0c680b1
[20:29:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a e7eb73f 06linuxcnc 10docs/src/config/lathe_config.se.po update swedish .po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e7eb73f
[20:29:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 370e478 06linuxcnc 10docs/src/config/lathe_config.se.po docs: more swedish translations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=370e478
[20:29:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a a0c0683 06linuxcnc 10docs/src/Submakefile build translated asciidoc files from master files + po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0c0683
[20:29:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a 5e5dd39 06linuxcnc 10docs/src/config/lathe_config.fr.po new lathe_config.fr.po, made by po4a 0.45 (from jessie) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e5dd39
[20:29:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a fbc7577 06linuxcnc 10docs/src/config/lathe_config.fr.po un-fuzzy lathe_config.fr.po * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fbc7577
[20:29:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a ca40078 06linuxcnc 10docs/src/Submakefile docs: supply asciidoc lang attribute from Submakefile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca40078
[20:30:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/po4a b79d19c 06linuxcnc 10docs/src/config/lathe_config.txt dont override lang attribute in the master asciidoc source * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b79d19c
[20:30:21] <mozmck> hmm, why use tcl for hal scripting?
[20:32:35] <linuxcnc-build> build #2218 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2218 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:35:11] <linuxcnc-build> build #2223 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2223 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:36:06] <linuxcnc-build> build #2223 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2223 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:40:09] <linuxcnc-build> build #1057 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1057 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:49:08] <linuxcnc-build> build #788 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/788 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:49:34] <seb_kuzminsky> mozmck: because the guy who wrote it likes tcl ;-)
[20:50:00] <linuxcnc-build> build #312 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/312 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:50:28] <cradek> tcl is an entirely adequate scripting language
[20:50:41] <linuxcnc-build> build #787 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/787 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:51:15] <linuxcnc-build> build #273 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/273 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:52:33] <dgarr> try again sigh
[20:53:03] <cradek> :-/
[20:53:17] <cradek> and it's not nice that it calls you dummy each time
[20:53:54] <dgarr> mozmck: because it works, its easy, its built-in,it knows about the infile ref from 5 years ago:
http://www.mail-archive.com/emc-developers%40lists.sourceforge.net/msg02513.html
[20:55:17] <linuxcnc-build> build #490 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/490 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:56:24] <dgarr> cradek any thoughts on the concept ?
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=be2fe9e072288d9bb5ed51efda06949f76dcef2e
[20:56:50] <linuxcnc-build> build #2220 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2220 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:58:04] <linuxcnc-build> build #2217 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2217 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
[20:59:38] <mozmck> seb_kuzminsky: dgarr: that makes sense - I just wondered.
[21:00:03] <mozmck> everything seems to be python now, and I've rarely seen tcl (except some in linuxcnc)
[21:00:16] <mozmck> guess I have another language to learn.
[21:01:01] <mozmck> had to learn some lua for a project recently.
[21:03:35] <dgarr> mozmck: an example that replaces the usal sim hal files (its not that complicated)
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob_plain;f=configs/sim/axis/simtcl/twopass_demo.tcl;hb=be2fe9e072288d9bb5ed51efda06949f76dcef2e
[21:05:04] <mozmck> dgarr: thanks.
[21:07:41] * mozmck wonders how tcl compares to lua for embedding scripting in a program... both claim to be great!
[21:13:50] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/lib_for_halfiles c64644f 06linuxcnc 10(11 files in 6 dirs) linuxcnc.in: support halfiles in a system lib * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c64644f
[21:14:11] <dgarr> third time the charm (maybe)
[21:15:26] <Tom_itx> heh
[21:22:21] <skunkworks> mozmck: have you played with mach4 yet?
[21:23:52] <dgarr> mozmck: the example i gave is a little complicated because it uses twopass, a more straightforward example that does a lot of stuff :
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob_plain;f=configs/sim/axis/xhc-hb04/xhc-hb04.tcl;hb=be2fe9e072288d9bb5ed51efda06949f76dcef2e
[21:31:13] <mozmck> dgarr: thanks! those will help
[21:31:23] <mozmck> skunkworks: no I haven't, have you?
[21:31:54] <skunkworks> no - just saw you mention lua - didn't know if it was because it is used in m4
[21:32:24] <mozmck> ah! no, I wrote a plugin for sheetcam
[22:15:43] <skunkworks> pcw_home:
http://www.machsupport.com/forum/index.php/topic,28627.0.html
[22:17:28] <Tom_itx> huh
[23:42:27] <linuxcnc-build> build #953 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/953 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <jthornton@gnipsel.com>, Dewey Garrett <dgarrett@panix.com>