Back
[03:01:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd d4d282e 06linuxcnc 289 commits pushed, 10499 files changed, 0337249(+), 0457548(-)
[03:24:01] <linuxcnc-build> build #1662 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1662 blamelist: dummy, bebro <bebro@users.noreply.github.com>, andypugh <andy@bodgesoc.org>, Norbert Schechner <nieson@web.de>, Chris Radek
[03:24:01] <linuxcnc-build> <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Andy Pugh <andy@bodgesoc.org>, Daniel Rogge <drogge@tormach.com>, Jeff Epler <jepler@unpythonic.net>, Moses McKnight <moses@texband.net>, Benjamin Brockhaus <burning@burning-world.de>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Dewey Garrett <dgarrett@panix.com>
[03:41:01] <linuxcnc-build> build #3321 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3321 blamelist: dummy, bebro <bebro@users.noreply.github.com>, andypugh <andy@bodgesoc.org>, Norbert Schechner <nieson@web.de>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>,
[03:41:01] <linuxcnc-build> Andy Pugh <andy@bodgesoc.org>, Daniel Rogge <drogge@tormach.com>, Jeff Epler <jepler@unpythonic.net>, Moses McKnight <moses@texband.net>, Benjamin Brockhaus <burning@burning-world.de>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Dewey Garrett <dgarrett@panix.com>
[06:31:56] <skunkworks> zlog
[06:48:21] <KGB-linuxcnc> 03Robert Ellenberg 05feature/tangent-improvement-2.7-rebase c4b1edd 06linuxcnc New branch with 25 commits pushed, 1036 files changed, 032439(+), 041918(-) since 2.7/0b8a3a1
[06:49:42] <skunkworks> oohhh yaahhh
[06:49:54] <skunkworks> Thanks rob!
[08:08:28] <KGB-linuxcnc> 03John Thornton 052.7 8c6319e 06linuxcnc 10(9 files in 4 dirs) Docs: more work on cleaning up the anchors and links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c6319e
[08:08:28] <KGB-linuxcnc> 03John Thornton 052.7 9ec0939 06linuxcnc 10(24 files in 6 dirs) Docs: finish cleaning up anchors and links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ec0939
[08:08:28] <KGB-linuxcnc> 03John Thornton 052.7 3622d00 06linuxcnc 10docs/src/code/contributing-to-linuxcnc.txt Docs: remove extra cr/lf * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3622d00
[08:08:30] <KGB-linuxcnc> 03John Thornton 052.7 3b2f220 06linuxcnc 10(70 files in 6 dirs) Docs: arrange docs to match the getting started guide * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3b2f220
[08:09:32] <jthornton> one more thing checked off the list
[08:10:10] <skunkworks> jthornton, thank you for all your work!
[08:11:22] <jthornton> I actually wrote a program to grep for me to save time
[08:40:43] <skunkworks> Ship it!!
[08:40:54] <skunkworks> well - the 0-word fix would be nice...
[08:40:58] <skunkworks> *o
[09:04:34] <bjmorel_work> I was working on setting up my 7i92 / 7i76 last night, and was trying to verify the pins available via dmesg. per the integrators manual. I wasn't getting any output in dmesg. This is a clean debian install / not off the live cd, so I assume I didn't have something set up right.
[09:05:16] <bjmorel_work> I remember something about changing the logging system, but I can't remember if that was before or after the machinekit split, and google is only pulling up machinekit pages for me.
[09:05:29] <mozmck> I'm not sure if the 7i92 uses dmesg
[09:06:05] <bjmorel_work> I was able to get the info I needed via halrun, so it's not really an issue
[09:06:23] <skunkworks> it will output to dmesag when the hme_eth driver loads
[09:06:31] <skunkworks> dmesg
[09:07:15] <bjmorel_work> hm2_eth and hostmot2 should both report since they are real time modules being loaded, or at least that is my assumption
[09:07:16] <skunkworks> I think the 7i76 pins don't show up in dmesg - those you would have ot look in hal
[09:08:55] <bjmorel_work> I did get the pins for both the 7i92 and 7i76 in halrun, although I couldn't pipe the output of "show pin" to a file like I found on a site.
[09:09:09] <bjmorel_work> I was able to copy and paste though, so not really a problem.
[09:09:41] <mozmck> It seems like when I looked at dmesg the information was not there either, but I could be remembering something else.
[09:14:08] <mozmck> To pipe hal pins to a file, you can do this: halcmd show > halpins.txt
[09:14:27] <mozmck> That will list all pins and write it to halpins.txt
[09:16:06] <skunkworks> mozmck, how is your interface coming?
[09:17:20] <skunkworks> mozmck,
http://www.plasmaspider.com/viewtopic.php?f=52&p=99832
[09:17:28] <skunkworks> I think your boss posted there though...
[09:18:43] <skunkworks> (I don't remember names very well)
[09:22:34] <mozmck> It's mostly done pending more testing. I wrote a small GUI to modify (and soon generate) configs for our stuff. Similar to stepconf in some ways but simpler interface and it doesn't need an xml file.
[09:27:43] <skunkworks> awesome!
[10:00:43] <pcw_home> halcmd show pin > foo works fine for me
[10:01:14] <pcw_home> a bit of "foo"
[10:01:16] <pcw_home> 25 float OUT 14.3926 hm2_7i76e.0.7i76.0.0.fieldvoltage
[10:01:17] <pcw_home> 25 bit OUT FALSE hm2_7i76e.0.7i76.0.0.input-00
[10:01:19] <pcw_home> 25 bit OUT TRUE hm2_7i76e.0.7i76.0.0.input-00-not
[10:02:43] <seb_kuzminsky> bjmorel_work: hm2_eth runs in user space, not kernel space, so its output does not appear in dmesg
[10:02:46] <mozmck> yeah, you can show just one component or pin that way
[10:03:10] <mozmck> ah, I thought I didn't see anything in dmesg for the 7i92!
[10:03:38] <mozmck> pcw_home: did you remember to send me a package?
[10:04:01] <mozmck> (or have time is probably more like it?)
[10:06:07] <CaptHindsight> pcw_home: has hm2_eth worked on any laptops yet?
[10:07:18] <jepler> I would expect it to work but I haven't tested it
[10:07:51] <pcw_home> works fine on my Dell
[10:08:18] <CaptHindsight> https://www.mail-archive.com/emc-users@lists.sourceforge.net/msg56080.html intel i5 laptop?
[10:08:24] <pcw_home> Yeah sent
[10:09:30] <CaptHindsight> you need to turn off IRQ coalescing : sudo ethtool -C ethN rx-usecs 0
[10:09:37] <CaptHindsight> making a note
[10:09:42] <skunkworks> heh - sorry. When I said dmesg I meant terminal.. duh
[10:12:52] <seb_kuzminsky> linuxcnc-build: force build --branch=hy-vfd 0000.checkin
[10:12:54] <linuxcnc-build> build forced [ETA 1h07m33s]
[10:12:54] <linuxcnc-build> I'll give a shout when the build finishes
[10:12:58] <pcw_home> with Intel MACs the linux driver has that option so it needs to be turned off
[10:12:59] <pcw_home> the other common MB MACs = Realtek dont have that option so work as-is
[10:15:27] <pcw_home> linuxcnc running on the Dell E6420:
[10:15:29] <pcw_home> http://freeby.mesanet.com/linuxcnc.png
[10:15:30] <pcw_home> latency:
[10:15:32] <pcw_home> http://freeby.mesanet.com/e6420.png
[10:19:28] <CaptHindsight> the $150 chromebooks use a Rockchip RK3288 with integrated GMAC, I'll have to try it
[10:20:09] <CaptHindsight> if not there are ~$250 x86 laptops
[10:20:16] <jepler> CaptHindsight: there are chromebooks with ethernet ports?
[10:22:09] <CaptHindsight> jepler: ah thats right they only included USB, HDMI, audio and SD slots
[10:22:22] <CaptHindsight> so low cost x86 laptop it is!
[10:22:44] <jepler> most users won't use it, it adds to the cost, and probably breaks their thinness goals...
[10:23:30] <jepler> I sure do love my 11" arm chromebook (samsung 303c)
[10:23:30] <CaptHindsight> http://www.pcworld.com/article/2904093/hands-on-the-149-hisense-chromebook-succeeds-at-being-incredibly-affordable.html
[10:23:52] <jepler> it's the device I did linuxcnc's arm port on
[10:25:28] <CaptHindsight> I was just running the numbers for a BOM to put together a complete small milling machine for polypropylene
[10:26:07] <CaptHindsight> to make patters for custom candy, chocolate, cake frosting etc
[10:26:28] <CaptHindsight> patters/patterns
[10:26:36] <jepler> sounds like a fun application
[10:26:42] <jepler> afk
[10:36:22] <linuxcnc-build> build #984 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/984
[10:52:20] <linuxcnc-build> build #3324 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3324
[11:04:13] <skunkworks> peter tells customer to move a smd resistor if he doesn't what to replace is crappy power supply. Classic support...
[12:45:34] <skunkworks> 2.7 is || close!
[14:07:14] <Tom_itx> yay!
[14:18:48] <JT-Shop> Tom_itx, as soon as I get done with the current doc tasks I'll add the expand/collapse all to the html (I think I can)
[14:19:20] <Tom_itx> (I hope you can) !
[14:19:45] <Tom_itx> if it's not too much grief that is..
[14:20:23] <JT-Shop> I think all the grief is behind me now
[14:20:57] <Tom_itx> have you been working on an easier way to maintain them as you go too?
[14:32:42] <JT-Shop> yes, trying to clean up and organize a bit
[14:56:38] <skunkworks> ||
[14:57:57] <skunkworks> so are there going to be 2 live cd's? one for uspace and one for rtai?
[14:59:34] <jepler> that's a very good question, but as always it depends on who decides to do the work
[14:59:57] <skunkworks> sure
[15:00:01] <seb_kuzminsky> it's unfortunate that each of our realtime platforms can do some things the other one can't - there's not a single choice that's best for everyone
[15:00:02] <jepler> I think that it would be feasible from a technical standpoint to do it, following cradek's work for the debian wheezy live image
[15:00:29] <jepler> .. and using the kernels available for wheezy, which unfortunately is now debian's "oldstable" release so it's getting stale
[15:00:30] <seb_kuzminsky> we currently have a 2.7 rtai cd, iirc
[15:00:52] <Tom_itx> yes i think so
[15:01:09] <jepler> in fact they should just rename their stable release to "stale", it's a letter shorter
[15:01:12] <cradek> it's no big thing anymore
[15:01:28] <cradek> although they'd be 99% the same and it feels silly
[15:01:40] <seb_kuzminsky> cradek: it's no big thing to make new install images? that's great :-)
[15:01:41] <cradek> but people really don't want to install the OS and then a few more packages
[15:02:23] <skunkworks> lazy bastards
[15:02:39] <cradek> of course the image could have both kernels
[15:02:40] <seb_kuzminsky> the 2.7 install docs (
http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html) say: use the install image to install rtai + 2.7~pre, or do this fancy complicated thing by hand for uspace
[15:02:54] <Tom_itx> it could since it's DVD size now anyway
[15:03:08] <jepler> cradek: but it can't have both packages (can it?)
[15:03:15] <cradek> nope
[15:03:36] <cradek> or, I think, even point to both the sources
[15:04:01] <jepler> as a post-boot or post-install step, it could install the linuxcnc that matches the kernel .. ugh, you'd never get the script right in 99 tries
[15:04:30] <seb_kuzminsky> i think jepler just dissed your script-fu
[15:04:39] <cradek> but does that make him wrong?
[15:04:52] <Tom_itx> what about a downloader that does a remote install based on your choice?
[15:04:57] <Tom_itx> or is that out of the question
[15:05:13] <cradek> booting live and trying it is a really nice feature I hate to screw up
[15:05:26] <jepler> it would be a shame to require a network
[15:05:27] <cradek> ("does this computer even work?")
[15:05:39] <jepler> if that's what you mean by "remote install"
[15:05:39] <Tom_itx> cradek, true
[15:05:54] <Tom_itx> jepler, the iso's are already stored on a network
[15:06:18] <cradek> what
[15:06:25] <Tom_itx> the point being, not all machines would be on ethernet
[15:06:40] <seb_kuzminsky> the uspace debs and the rtai debs have disjoint names... i think they could live in the same deb archive...
[15:06:44] <cradek> I have a stick in my pocket (not a euphemism) and I can use it to try a machine at goodwill
[15:07:05] <seb_kuzminsky> but they install the same files (/usr/bin/linuxcnc etc), so they can't co-exist
[15:07:09] <cradek> no networks needed
[15:07:24] <seb_kuzminsky> but i think you could install one or the other based on which kernel you chose
[15:07:27] <cradek> seb_kuzminsky: if they can conflict and you can switch between them with an apt-get, that would be awesome
[15:07:27] <jepler> right, they're not co-installable
[15:07:38] <mozmck> You could have both kernels (rtai and preempt) installed, default to linuxcnc-rtai, and make a simple way to change to uspace?
[15:07:53] <jepler> case `uname -a` in *rtai*) install rtai version ;; default) install uspace version; esac
[15:08:05] <seb_kuzminsky> mozmck: you can definitely have both rtai & preempt kernels installed simultaneously, i do that all the time
[15:08:08] <cradek> that's backwards
[15:08:11] <mozmck> I know
[15:08:25] <cradek> the linuxcnc package depends on its special kernel
[15:08:26] <jepler> what is backwards?
[15:08:26] <mozmck> But we don't on the livecd now.
[15:09:02] <seb_kuzminsky> switching which linuxcnc flavor you have installed is "apt-get install --force linuxcnc-$FLAVOR", or something similar, should work fine (untested tho)
[15:09:05] <cradek> the livecd builder requests linuxcnc and gets those dependencies
[15:09:16] <cradek> no special kernel is running when linuxcnc is installed
[15:09:20] <mozmck> A script could be made that would un-install the linuxcnc-rtai package, and install the uspace package and vice-versa.
[15:09:28] * skunkworks hides
[15:09:32] * cradek points at seb_kuzminsky
[15:09:37] <cradek> that's how it should work
[15:09:57] <jepler> cradek: in this case you'd end up having to manually include at least one of the special kernels (rtai or preempt-rt) since no installed package would pull it in as the dependency
[15:10:13] <mozmck> Doesn't the rtai build depend on the rtai packages and kernel?
[15:10:21] <cradek> mozmck: yes
[15:10:25] <cradek> jepler: in what case?
[15:10:37] <seb_kuzminsky> and you'd need to talk to the user to figure out which kernel (and matching linuxcnc flavor) they want this time
[15:10:40] <jepler> cradek: for the live media to have a choice of both kernels
[15:11:19] <cradek> jepler: oh ok, I see what you mean now. is having them both available for live boot an important goal?
[15:11:40] <jepler> I am imagining that the live image could (optionally?) present the user with a menu to choose a rtai kernel or a preempt-rt kernel
[15:11:49] <seb_kuzminsky> it'd be nice to try latency on a particular machine with both kernels, to see if you can get away with rtpreempt
[15:11:54] <jepler> and the boot-up process would pull in the matching linuxcnc package from the media
[15:12:14] <jepler> and ditto the install process, pulling the matching linuxnc package into the installed system
[15:12:28] <jepler> that's the thing I said that (generic!) you wouldn't get right in 99 tries
[15:12:30] <cradek> ok I see, but I think that's not how any of it works :-/
[15:12:32] <cradek> yeah
[15:12:35] <seb_kuzminsky> i guess it'd be easy to have the initial grub menu offer "Live (RTAI)", "Live (RT-Preempt)", and matching "Install" boot options
[15:12:43] <cradek> oh it's specific me :-)
[15:12:48] <mozmck> ooh, I hadn't thought of switching linuxcnc on bootup!
[15:12:51] <jepler> only because you're the person who would actually try
[15:13:30] <jepler> .. this is part of why the machinekit people wanted to have one debian package that supported multiple RTOSes.
[15:13:40] <seb_kuzminsky> that's sure a nice feature
[15:13:53] <jepler> we never got to the point of evaluating that part of the work on its merits
[15:14:23] <seb_kuzminsky> i looked at their unified build stuff some
[15:14:40] <jepler> (but I'm pretty sure it thorougly broke the build system and made some questionable choices about how to switch userspace between the different implementations)
[15:14:51] <seb_kuzminsky> i thought we all did, that time in witchita, before mah asked us to not review it yet, again
[15:15:12] <cradek> let's move on
[15:15:18] <seb_kuzminsky> heh
[15:15:18] <jepler> heh
[15:15:43] <seb_kuzminsky> i'll try making a deb archive with rtai & uspace debs in the same place and see if that works
[15:15:47] <jepler> at this point I'd use emoji if text-mode irc clients supported it
[15:16:01] <jepler> seb_kuzminsky: source packages have the same name, I think that's the remaining problem
[15:16:13] <seb_kuzminsky> ah
[15:16:17] <seb_kuzminsky> U+1F4A9
[15:16:45] <cradek> seb_kuzminsky: it would be cool if that worked, and apt could switch between them easily
[15:17:13] <seb_kuzminsky> i think jepler is right, it's just the dsc that collides
[15:17:30] <seb_kuzminsky> ... i'll look into renaming them
[15:24:09] <jepler> or invoking the whole danged build process twice on a platform that has rtai
[15:25:02] <jepler> (the packaging could invoke configure && make && make install twice without supporting multiple RTOSes directly in the src/Makefile)
[15:25:24] <jepler> not sure how much we should try to change things this late in 2.7
[15:57:48] <seb_kuzminsky> good point jeff
[16:34:25] <skunksleep> Awesome
[17:39:17] <andypugh> So, this bug in carousel_demo is in lerman ’s code. Have you had a chance to look at it?
[17:39:28] <andypugh> I am vaguely lost.
[17:45:15] <cradek> actually I think it's the mdi and remap-specific goop in task
[17:45:50] <cradek> I spent a few hours on it and went slightly mad
[17:45:53] <cradek> I wish I was more help
[17:48:58] <andypugh> Well, I see different stuff in inter_o_word.cc depending on whether it is going to work or not.
[17:49:14] <andypugh> I am actually a bit surprised that the first test returns zero.
[17:49:28] <andypugh> But then I might not understand what the test is testing.
[18:27:01] <jepler> as far as I could tell, the settings->sequence_number had the wrong value when MDI and remap were involved. I am realizing now that when I modified the program to not be remap, I was also not invoking it via MDI
[18:27:26] <jepler> so that would be worth pursuing, where writing an MDI O-call produces the problem
[18:29:31] <cradek> I agree the sequence number seems wrong in the failure case
[18:38:54] <andypugh> (I am afraid I am still rebuilding my setup here, tonight I re-assembled the Rivettt 608 and now I am installing Windows in a VM to run Inventor). Not likely to see any LinuxCNC debugging progress today.
[18:39:16] <cradek> I love your planer
[18:39:39] <cradek> you're really clever at rebuilding stuff
[18:39:51] <cradek> well except maybe computers :-)
[18:42:57] <andypugh> I am astonished how well the planer worked out.
[18:44:52] <mozmck> metal planer?
[18:48:18] <andypugh> Yes. A hand metal planer :-)
[18:48:34] <andypugh> http://bodgesoc.blogspot.co.uk/2015/08/rivett-lathe-slideway-refurb-as.html
[18:50:10] <mozmck> neat!
[18:53:15] <mozmck> I have an old metal planer - a 3' pratt and whitney
[19:00:10] <andypugh> That would have been exactly 1” too short for my job
[20:35:49] <skunkworks> PID USER PR NI VIRT RES SHR S PU %MEM TIME+ COMMAND
[20:35:51] <skunkworks> 19675 skunkwo+ 20 0 1161644 749496 26016 S 76.9 18.6 200:06.70 axis
[21:03:26] <cradek> what the heck
[21:12:08] <skunkworks> big prigram
[21:12:51] <cradek> oh it's working how you expect?
[21:17:19] <skunkworks> i think so ;)
[21:17:47] <skunkworks> 78000inhes
[21:17:54] <skunkworks> inches
[21:18:03] <cradek> jeez
[21:19:24] <Tom_itx> is that with rob's recent fix?
[21:31:49] <cradek> this kind of thing is a really good test:
https://www.youtube.com/watch?v=d8IgJFfTqME
[21:33:26] <Tom_itx> that or a 3d surface with lots of short moves
[21:35:14] <Tom_itx> that looks like mostly planar moves
[21:35:24] <Tom_itx> or 'waterline'
[21:36:59] <Tom_itx> still probably alot of shorter moves..
