Back
[09:56:15] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 285867c 06linuxcnc 10docs/src/gui/gmoccapy.fr.po 10docs/src/gui/gmoccapy_fr.txt French documentation update * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=285867c
[10:49:53] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/spiral-arc-handling-2.7 e004532 06linuxcnc 10src/emc/motion/command.c 10src/emc/tp/tp.c 10src/emc/tp/tp_types.h motion: fix for zero-length line errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e004532
[10:49:53] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/spiral-arc-handling-2.7 e86321f 06linuxcnc 10(5 files) tp: Added optimizations to increase arc tangential acceleration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e86321f
[10:49:53] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/spiral-arc-handling-2.7 7fbff07 06linuxcnc 10src/libnml/posemath/posemath.cc posemath: fixed PM_CARTESIAN cross product * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7fbff07
[10:49:55] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/spiral-arc-handling-2.7 2aaa7d1 06linuxcnc 10src/emc/tp/blendmath.c tp: fix for rare acceleration violation that that Sam found * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2aaa7d1
[10:49:59] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/spiral-arc-handling-2.7 eefa5f7 06linuxcnc 10tests/trajectory-planner/circular-arcs/configs/sim_XYZ.ini 10tests/trajectory-planner/circular-arcs/configs/sim_XYZ_fast.ini tests: increased optimization depth in fast sim config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eefa5f7
[10:51:14] <cradek> awesome
[10:52:09] <seb_kuzminsky> yay!
[10:53:03] <skunkworks> awesome!
[10:53:16] <skunkworks> I just emailed him like 30 minutes ago
[10:53:21] <skunkworks> https://trademarks.justia.com/865/18/pathpilot-86518629.html
[10:55:29] <skunkworks> sounds like tormach is going to be announcing thier new control very soon (for the mill too).
[10:56:16] <pcw_home> big add on CNCzone
[10:56:46] <skunkworks> really? did I miss that?
[10:57:01] <cradek> people see ads?
[10:57:06] <skunkworks> heh
[10:57:53] <pcw_home> http://www.tormach.com/pathpilot?utm_campaign=cnczone_pathpilot&utm_source=cnczone&utm_medium=banner&utm_content=pathpilot_intro
[10:58:48] <skunkworks> cool
[10:58:52] <mozmck> adblock works pretty good :)
[10:59:09] <pcw_home> Yeah had to turn it off :-)
[10:59:52] <cradek> Should I convert my Tormach mill controller to PathPilot? We think the majority of people will want to convert.
[11:00:23] <cradek> > PathPilot is a development of the Tormach.
[11:00:27] <cradek> uh
[11:01:55] <skunkworks> I guess parts of it is...
[11:02:19] <mozmck> They developed the name at least :)
[11:08:46] <mozmck> Is their UI proprietary?
[11:09:09] <pcw_home> Sure sounds like it
[11:09:30] <cradek> so far, we can only guess their intents
[11:18:51] <kwallace2> Yikes, that's not what I expected.
[11:21:03] <skunkworks> has a little bit of smitthy taste.. But smithy moved to siemens
[11:21:46] <kwallace2> I thought they would slip Linux in as a continuation rather than an evolution.
[11:30:56] <kwallace2> My guess is that Smithy didn't apply enough resources to get critical mass, and decided to get something off-the-shelf.
[11:31:51] <kwallace2> Who knows, maybe Siemens is starting to feel threatened, and gave Smithy a good deal.
[11:34:10] <seb_kuzminsky> wow there's a lot of new stuff in 2.7 since ~pre2
[11:35:13] <kwallace2> Oops, the screen shows a soft-limit error.
[11:39:59] <seb_kuzminsky> hm, i didn't appreciate halcheck enough when dgarr wrote it, it's pretty neat
[11:40:54] <mozmck> kwallace2: do you work for tormach?
[11:41:49] <kwallace2> We are 'friendly'.
[11:42:46] <mozmck> oh ok. sounded like you might from some things.
[11:43:53] <kwallace2> Yes, I am not able to give un-biased opinions.
[11:44:22] <mozmck> heh :)
[11:47:00] <kwallace2> Is anyone familiar with this?
http://gcode.ws/
[11:48:36] <seb_kuzminsky> is that a cd-rom drive on the front of the path pilot computer? that's so retro! i bet cradek will love it
[11:51:30] <cradek> funny - I was just facing (to my dismay) installing windows in virtualbox on a real computer here, and it doesn't have a cd, but windows is on a cd
[11:51:42] <cradek> my powers are nearly useless when it comes to the windows world
[11:52:21] <seb_kuzminsky> things are so weird in that world
[11:53:16] <kwallace2> How can you install Windows when it looks at your hardware to see if it is still the PC you bought ten years ago?
[11:54:04] <cradek> kwallace2: who knows - luckily I can just give problems like that to someone else to handle
[11:54:28] <cradek> hey I guess that's my power
[11:54:31] <cradek> yay
[11:54:34] <kwallace2> LOL :)
[12:00:50] <mozmck> Windows XP works well in VirtualBox anyhow. I imagine other versions do if they are not tied to specific hardware.
[12:01:18] <mozmck> They will get tied to the virtual VirtualBox hardware once activated there I guess.
[12:01:25] <skunkworks> 7 is ok alos
[12:01:27] <skunkworks> also
[12:02:19] <cradek> at goodwill they have a new sign that says BECAUSE OF LICENSE ACTIVATION RESTRICTIONS YOU MAY NOT TURN ON THE COMPUTERS BEFORE BUYING THEM
[12:02:40] <mozmck> One nice thing I discovered, is that the virtualbox harddisk image can be easily backed up since it is just one large file.
[12:02:40] <cradek> they are also now around $400 instead of $100 like they used to be
[12:02:56] <cradek> I buy from the other shelf where they have missing hard drives and are $29
[12:03:30] <mozmck> At least with WinXP it is no longer tied to a certain computer either - I can copy the image to another computer with the same virtualbox setup and run it there.
[12:03:51] <cradek> I wouldn't say that too loudly
[12:04:07] <mozmck> wow, you can get a brand new computer for $400
[12:04:20] <cradek> yeah, no joke
[12:04:49] <cradek> I don't know what chain of bad decisions led them to where they are
[12:05:12] <cradek> I assume they started with "I guess we have to be a microsoft certified something or other"
[12:06:02] <mozmck> MS may make them put a new copy of windows on the machines
[12:06:44] <mozmck> or maybe they have to in order to wipe the old data? since you don't get a disk with them now...
[12:07:12] <cradek> I booted debian+rtai from my keychain and tested latency, and bought a very nice machine for my lathe for the $29
[12:07:30] <cradek> core-2-duo with 1GB of ram and two pci slots, everything but the hard disk
[12:07:48] <cradek> in a cute little compact case
[12:08:37] <mozmck> somebody sent a link to these yesterday:
http://www.ebay.com/itm/281497643572
[12:08:59] <mozmck> I should buy one. Or two.
[12:09:37] <cradek> considering free shipping, that looks like a great price
[12:09:56] <mozmck> yes
[12:12:46] <cradek> wow used PCs are cheap
[12:16:57] <pcw_home> Core2 Duos seem to have quite decent latency (at least the 3 or 4 I have do)
[12:17:18] <pcw_home> also good on Preemt-RT
[12:17:19] <cradek> the one I just bought tested well before any tweaking at all, I just booted it
[12:17:51] <cradek> I love booting debian live from usb and just having everything work perfectly
[12:18:11] <cradek> at goodwill they have a monitor and keyboard you can use to test before you buy stuff, took two minutes
[12:19:32] <pcw_home> The wheezy live image runs fine on my cheap laptop I bought to test hm2-eth
[12:19:58] <pcw_home> (crappy latency but probably OK)
[13:00:23] <skunkworks> pcw_home, what laptop?
[13:00:56] <pcw_home> bought a ebay Dell E6420 to try with hm2_eth
[13:01:03] <skunkworks> neat
[13:02:06] <pcw_home> Need to get a ESATA --> SATA cable or HDD caddy to try without wiping windows
[13:02:30] <skunkworks> duel boot!
[13:02:39] <skunkworks> dual
[13:03:02] <pcw_home> I like duel better :-)
[13:04:16] <skunkworks> I just dual booted the asus
[13:04:32] <skunkworks> well - it did have 14.04 on it - now wheezy
[13:06:09] <pcw_home> YOu can apparently get caddies for the dell that let you replace the DVD with a HDD (well SDD in my case)
[13:07:34] <pcw_home> Or I could just test with the ESATA connection but no one seems to have those cables locally
[14:32:05] <skunkworks> pcw_home, money shot..
http://api.viglink.com/api/click?format=go&jsonp=vglnk_142420387899715&key=8fc203c6d53cfcf639464b616dec43af&libId=09459180-6f47-4449-8f3c-6c4e62d50996&loc=http%3A%2F%2Fwww.cnczone.com%2Fforums%2Ftormach-personal-cnc-mill%2F259506-tormach-5.html&v=1&out=http%3A%2F%2Fwww.tormach.com%2Fpathpilot%3Futm_campaign%3Dcnczone_pathpilot%26utm_source%3Dcnczone%26utm_medium%3Dbanner%26utm_content%3Dpathp
[14:32:05] <skunkworks> ilot_intro&ref=http%3A%2F%2Fwww.cnczone.com%2Fforums%2Ftormach-personal-cnc-mill%2F259506-tormach-6.html&title=Just%20In%20Tormach%20News%20-%20Page%205&txt=http%3A%2F%2Fwww.tormach.com%2Fpathpilot%3Futm...athpilot_intro
[14:32:09] <skunkworks> wow
[14:32:11] <skunkworks> sorry
[14:33:52] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/259506-tormach-5.html
[14:34:19] <skunkworks> no..
[14:34:21] <micges> skunkworks: that address is way too short ;)
[14:34:43] <skunkworks> heh
[14:34:45] <skunkworks> ok
http://www.cnczone.com/forums/tormach-personal-cnc-mill/259506-tormach-5.html#post1649534
[14:37:32] <skunkworks> http://www.tormach.com/store/index.php?app=ecom&ns=prodshow&ref=PATHPILOT-BETA
[14:40:06] <skunkworks> they say they have a re-vamped trajectory planner.. hmmm
[14:40:13] <skunkworks> http://www.tormach.com/blog/pathpilot-beta-testing/?utm_source=blog&utm_medium=email&utm_campaign=postnotify&utm_id=5184&utm_title=Introducing+PathPilot%26trade%3B%2C+Tormach%26amp%3B%238217%3Bs+new+machine+controller
[14:42:40] <mozmck> hopefully they've been following all the bug fixes?
[14:57:40] <seb_kuzminsky> i wonder if they're using mk
[14:59:52] <skunkworks> they did have the mk fest their
[15:00:00] <skunkworks> there
[15:04:43] <seb_kuzminsky> some more info here:
http://www.tormach.com/blog/pathpilot-beta-testing/
[15:07:20] <seb_kuzminsky> strange, i can't find the source code download link anywhere
[15:20:30] <seb_kuzminsky> mozmck: i'm looking at your new-deb-conf branch
[15:20:33] <skunkworks> now now..
[15:21:02] <seb_kuzminsky> why did you change the order of the arguments to lsb_release?
[15:22:04] <seb_kuzminsky> looks like you removed build-dependencies on texlive-lang-{french,spanish}
[15:23:08] <seb_kuzminsky> we don't need an explicit dependency on libudev - we have the build-dependency on libudev-dev, and the debian packaging tools will see that we're linked against it and add the runtime dependency for us
[15:23:30] <seb_kuzminsky> otherwise it looks good
[15:25:08] <mozmck> hi seb
[15:25:13] <seb_kuzminsky> hi!
[15:25:38] <mozmck> I didn't remove the dependencies to texlive-lang-french etc I don't think - they were in there twice.
[15:25:45] <seb_kuzminsky> whoops!
[15:26:41] <seb_kuzminsky> yes, i see that you are right
[15:26:45] <seb_kuzminsky> thanks for fixing my mistake!
[15:27:00] <mozmck> That has been the case for a long time I think because the current setup does it as well. They are listed in the EXTRA_BUILD in configure, and in the depends in control
[15:27:20] <seb_kuzminsky> aha, maybe that's where i got it
[15:27:43] <mozmck> I changed the order of arguments to lsb_release to make both calls consistent, which is how the old configure did it too :)
[15:27:51] <seb_kuzminsky> the way we build up the Depends, Build-Depends, etc, is one of the super hairy bits i was hoping to clean up a bit
[15:28:54] <mozmck> For libudev, if all someone gets is a linuxcnc*.deb package, it will have the libudev dependency in it?
[15:28:56] <seb_kuzminsky> oh, yeah is guess that was a bit schizophrenic, and your way is better
[15:29:08] <seb_kuzminsky> it absolutely should, yes
[15:29:21] <mozmck> Well, it was not in the finished control file.
[15:29:43] <seb_kuzminsky> oh, well, i should say, it depends
[15:29:58] <seb_kuzminsky> i bet linuxcnc-uspace depends on libudev, and i bet linuxcnc (the rtai flavor) does not
[15:30:51] <mozmck> linuxcnc-uspace in the current setup depends on libudev-dev - which I don't think is correct.
[15:31:06] <seb_kuzminsky> i agree that's a bug
[15:31:16] <mozmck> in your configure it did not depend on libudev-dev or libudev
[15:31:18] <seb_kuzminsky> are you on 2.7.0~pre2? i think that version has the bug, and i think i fixed it in 2.7 after that
[15:31:55] <seb_kuzminsky> it may be that the libudev-dev build-dependency was added after where the new-deb-configure branch forked off
[15:32:06] <mozmck> I rebased onto the 2.7 branch but I verified that master was the same at the time.
[15:32:23] <mozmck> as far as the configure, control.in, rules.in etc files
[15:32:47] <seb_kuzminsky> it's also very possible i just messed it up
[15:36:30] <seb_kuzminsky> the latest 2.7 rtai deb does not depend on libudev, which is correct
[15:37:03] <mozmck> yes - only the uspace version
[15:37:37] <mozmck> in configure line 154: KERNEL_DEPENDS=libudev-dev
[15:37:39] <seb_kuzminsky> and the latest 2.7 uspace deb depends on both libudev (correct) and libudev-dev (incorrect)
[15:37:44] <seb_kuzminsky> yeah :-/
[15:40:32] <mozmck> I don't see that it depends on libudev, only libudev-dev. If you run configure in the debian dir you can look at the control file and see what it actually outputs.
[15:42:18] <mozmck> or are you looking at the depends in the .deb itself? I bet it has libudev there because libudev-dev depends on it.
[15:42:39] <seb_kuzminsky> no, that's not it
[15:42:48] <mozmck> ok
[15:43:14] <seb_kuzminsky> after you run debian/configure, see that debian/control has a Depends: line that includes ${shlibs:Depends}
[15:43:36] <mozmck> yes
[15:43:47] <seb_kuzminsky> after the source code is compiled and linked and the deb tools are building the .deb package, that gets expanded to the list of all the packages that our binaries got linked against
[15:44:00] <seb_kuzminsky> that's in debian/rules
[15:44:01] <mozmck> ah, I didn't know that.
[15:44:05] <seb_kuzminsky> in the binary-arch target
[15:44:25] <seb_kuzminsky> the dh_shlibdeps command
[15:45:04] <seb_kuzminsky> it's super convenient that we dont have to maintain a list of deb packages providing shared libs that we depend on
[15:45:13] <seb_kuzminsky> debian packaging tools do that for us
[15:45:15] <mozmck> aha, ok.
[15:45:23] <mozmck> yes, that is nice!
[15:45:27] <seb_kuzminsky> we just need to provide the list of libraries/headers we *build* against
[15:46:28] <mozmck> that would explain why most things in the depends are scripting languages and external programs/utilities
[15:46:42] <seb_kuzminsky> yeap
[15:48:04] <mozmck> I still haven't run it on my wheezy machine - I should do that.
[15:48:27] <mozmck> "wheezy" is not a name I would have picked.
[15:48:31] <seb_kuzminsky> heh
[15:48:44] <seb_kuzminsky> i'm running wheezy on my laptop here, and it's working great :-)
[15:49:06] <mozmck> "sick", "barely works", "cough"
[15:49:13] <seb_kuzminsky> i once named a cat after a debian distribution (slink)
[15:49:19] <mozmck> the new_deb_conf is?
[15:49:33] <seb_kuzminsky> we called her slinky, she was a good cat
[15:49:47] <mozmck> that's a bit better name anyhow!
[15:50:34] <seb_kuzminsky> i wonder what they'll do when they run out of toy-story names
[15:50:58] <mozmck> heh, is that where that came from?
[15:51:19] <mozmck> I prefer version numbers myself.
[15:51:23] <seb_kuzminsky> yeah, one of the debian founders worked at pixar when it all got started
[15:51:48] <seb_kuzminsky> that's also why the "unstable" debian distro is called "sid" - he was the mean neighbor kid who broke all the toys
[15:51:58] <mozmck> I see :)
[15:52:21] <seb_kuzminsky> i like version numbers, but i also like names
[15:52:25] <mozmck> I ran unstable for years, and didn't have many problems with it overall
[15:52:25] <seb_kuzminsky> maybe we should have both, too
[15:52:40] <seb_kuzminsky> when i was young and reckless i did too
[15:53:08] <mozmck> I switched to ubuntu, and now am on Mint
[15:53:22] <seb_kuzminsky> i switched to ubuntu, now i'm back on debian ;-)
[15:53:32] <seb_kuzminsky> though i've been meaning to give mint a try, i've heard good things about it
[15:53:42] <mozmck> :) It's too out of date for my main system.
[15:53:51] <seb_kuzminsky> maybe "LinuxCNC 2.7 ChuckSmasher"
[15:54:16] <mozmck> I like mint. Their choice of programs and setup is near perfect for me.
[15:54:28] <seb_kuzminsky> or "Hard Stop"
[15:54:41] <mozmck> heh, BitBreaker
[15:54:46] <seb_kuzminsky> heh
[15:55:05] <mozmck> MetalMelter
[15:55:43] <seb_kuzminsky> elon musk is naming his autonomous rocket-retrieval drone boats after Culture starships
[15:59:24] <KimK_laptop> mozmck: Hi, how are you? Which Mint desktop? I'm using Cinnamon. I tried MATE first (forked Gnome 2), I'd prefer that, but they renamed all the apps to enable dual-desktop installs, drove me crazy, so I picked Cinnamon (not crazy about Gnome 3 though). But now that I've tried XFCE on our Debian ISO, I might take XFCE next time, nice.
[16:00:06] <mozmck> Hi KimK_laptop: I'm doing well, but quite busy here. 3 children now and more work than ever!
[16:00:21] <KimK_laptop> Ha, that'll keep you busy!
[16:00:44] <mozmck> I like Cinnamon pretty well. It does use more system resources, which is noticeable on slower machines.
[16:01:11] <mozmck> One nice thing about Mint is that they keep the look and feel pretty close between the different desktops.
[16:01:44] <mozmck> I use kind of a hybrid right now. I use XFCE, but have Nemo for my default file manager.
[16:02:22] <mozmck> Mint XFCE uses Gedit instead of Mousepad, which is nice - although the latest Mousepad now has syntax highlighting.
[16:03:15] <KimK_laptop> Yes, consistent look, and also their GUI (even when offered to Windows users), does not "frighten the horses".
[16:03:24] <mozmck> Thunar (file manager for XFCE) now has tabs, which I use a *lot*, but I use Nemo for the nemo-terminal which is an embedded terminal window which follows the directory you are in.
[16:04:22] <KimK_laptop> Yes, I like the nemo-terminal too. And I still install the open-in-terminal option besides. Choices are good.
[16:04:42] <mozmck> I have gotten quite used to the search feature on the menu in Cinnamon, and the Whisker menu in XFCE works identically.
[16:05:01] <mozmck> Thunar has the open-in-terminal by default as well.
[16:06:19] <mozmck> I also use rabbitvcs, which shows emblems for git status in Nemo, but does not in Thunar.
[16:07:55] <KimK_laptop> Thanks, rabbitvcs sounds interesting, I'll look at it. I haven't used our new Debian XFCE install too much yet, but I hope to eventually. Right now I'm (on Cinnamon laptop) trying to master the intricacies of gEDA/gaf/pcb for a PCB I need.
[16:09:04] <KimK_laptop> OK, well, you're busy, thanks for chatting. See you again.
[16:09:35] <KimK_laptop> (and Hi Seb)
[16:09:53] <seb_kuzminsky> hi KimK_laptop, how's it going?
[16:11:30] <KimK_laptop> That's kind of a long story, but I've got plenty to do, at least, lol. You wouldn't know if anyone in our group has used gschem/pcb, would you?
[16:11:59] <seb_kuzminsky> i've used it a little bit, but decided i liked kicad better
[16:12:22] <KimK_laptop> Oh, OK, that's interesting, what persuaded you?
[16:13:03] <seb_kuzminsky> oh wait, it was kicad instead of geda
[16:13:23] <KimK_laptop> ?
[16:13:56] <seb_kuzminsky> oh yeah, gschem is part of geda
[16:14:10] <seb_kuzminsky> kicad includes schematic layout through pcb manufacture, just like geda does
[16:14:25] <seb_kuzminsky> i found the kicad interface simpler to learn
[16:14:49] <seb_kuzminsky> i last used a schematic capture to pcb toolchain years ago, and it was eagle
[16:16:11] <seb_kuzminsky> kicad's toolchain seemed more integrated than geda's
[16:16:13] * seb_kuzminsky shrugs
[16:16:17] <KimK_laptop> Yes, those seem to be the big three, gEDA-gaf (gschem/pcb/gerbv, etc), KiCAD, and Eagle. Each has their adherents, I suppose. I had to pick one.
[16:16:51] <seb_kuzminsky> i think you did the right thing to avoid eagle, better to work with the open-source tools
[16:17:37] <KimK_laptop> Yes, gEDA is the oldest, and therefore maybe the clunkiest/cruftiest(?) but you're right, I did want to stick with open source.
[16:18:22] <KimK_laptop> But since they've been around the longest, they've got a big developer group, if that means anything.
[16:18:32] <seb_kuzminsky> that means a lot
[16:19:38] <mozmck> I use kicad here. Lot of work going on in it. CERN is working on it and about to release some new features.
[16:19:50] <seb_kuzminsky> ooh, that's great to hear
[16:19:53] <KimK_laptop> It's pretty good once you learn the "gEDA way", lol. But it's at times not intuitive, so a quick Q to an expert can save a lot of time. Their IRC channel responds pretty fast.
[16:20:00] <seb_kuzminsky> i quite liked it when i fiddled with it for a weekend
[16:20:17] <mozmck> Debian XFCE will probably get some of the new features in about 6 years :)
[16:20:59] <KimK_laptop> That's good to hear about KiCAD, maybe I'll end up learning that too, but I'd rather not right now, now that I'm halfway into it. Maybe on the next board?
[16:21:15] <mozmck> Yes, I did not use gEDA long enough to learn it. Kicad has a push-and-shove router that CERN did, that is very nice.
[16:22:19] <mozmck> http://home.web.cern.ch/about/updates/2015/02/kicad-software-gets-cern-treatment
[16:22:41] <seb_kuzminsky> if you run axis on a non-trivkins machine (for example sim/axis/vismach/hexapod-sim) and you're in joint mode, it chooses jog speeds wrong
[16:23:12] <seb_kuzminsky> joints 0-2 get the linear jog speed, whether they're linear or rotary joints, and joints 3-5 get the angular jog speed
[16:23:32] <seb_kuzminsky> its as if axis thinks joints 0-2 corresponds to x, y, z, and joints 3-5 to a, b, c
[16:23:35] <seb_kuzminsky> silly axis
[16:24:08] <KimK_laptop> I'll keep you guys posted on my alleged progress, lol. I'll be around here for awhile.
[16:26:14] <KimK_laptop> mozmck: Thanks, that's a very impressive KiCAD/CERN article.
[16:30:10] <KimK_laptop> I wonder what CERN calls their Tux-PCB-mascot?
http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages Can't look now, back to work!
[16:55:43] <seb_kuzminsky> axis makes the jog speed decision in get_jog_speed()
[16:56:19] <seb_kuzminsky> that function looks at vars.joint_mode to (i think) guess if we're in joint/free mode or in teleop/world mode, but gets the check backwards because the variable is named wrong
[16:58:01] <seb_kuzminsky> vars.joint_mode is False if the machine is in joint mode, and True if the machine is in teleop mode
[16:58:28] <Tom_itx> heh
[17:01:06] <skunkworks> seb_kuzminsky: what are you looking at?
[17:01:58] <seb_kuzminsky> a jog-speed bug in axis, in joint more, on non-trivkins machines
[17:02:03] <seb_kuzminsky> *joint mode
[17:03:39] <andypugh> I wonder which version of tool offsets Tormach are using? Remap + G43.1 or the original patch?
[17:04:39] <seb_kuzminsky> huh, in the comments of the video that Bruce Layne posted,
http://youtu.be/WqJmBEWnvpk, a tormach spokesperson claims that tormach funded rob ellenberg's trajectory planner. does anyone know if that's true?
[17:05:01] <seb_kuzminsky> that's a pretty significant contribution back to the community, if so
[17:05:57] <PCW> Yep, thats true
[17:07:54] <andypugh> Tormach hosted a Machinkit meetup too.
[17:08:16] <andypugh> Which probably counts
[17:15:12] <seb_kuzminsky> none of rob's commits claim copyright by tormach
[17:15:18] <seb_kuzminsky> some claim copyright by rob
[17:17:13] <seb_kuzminsky> PCW: that's news to me, cool
[17:21:22] <kb1kdw> Anyone: Do components get pre-empted midway through their execution, or do they get to run all of the way through?
[17:21:44] <seb_kuzminsky> kb1kdw: userspace components get interrupted all the time
[17:22:07] <seb_kuzminsky> realtime components get interrupted only by faster (shorter-period) realtime threads
[17:22:56] <kb1kdw> Ok -- I am writing a SPI driver component. It do not plan to classify it as "userspace." It will function sort of like pwmgen.
[17:23:36] <seb_kuzminsky> ok, a realtime component (ie, one which doesn't run as its own process, but exports a function to hal, and the hal file addf's it to a realtime thread)
[17:23:38] <kb1kdw> So they don't all just get called one at a time by the base thread? I
[17:24:13] <seb_kuzminsky> there are often two realtime threads: a fast (short-period) one called "base" and a slow (long-period) one called "servo" (which is a little confusing)
[17:24:32] <kb1kdw> yep -- I would put it into base.
[17:24:45] <seb_kuzminsky> you can addf your realtime comps' functions to either thread
[17:24:49] <andypugh> The SPI driver will need a base-thread function to bit-bang and a servo-thread one to update the HAL pins
[17:24:56] <seb_kuzminsky> if you add your function to the base thread, then it will never get preempted
[17:25:16] <seb_kuzminsky> (unless you do something weird, like go out of your way to create an extra thread with an even shorter period)
[17:25:19] <kb1kdw> That was what I had hoped.
[17:25:23] <seb_kuzminsky> :-)
[17:25:36] <andypugh> You don’t normally do floating point in the Base thread. In fact until a couple of years you simply weren’t allowed to.
[17:26:08] <kb1kdw> I don't plan to use pi() for anything in my spi driver :)
[17:26:18] <seb_kuzminsky> heh
[17:27:26] <kb1kdw> That is really good, because I was going to burn some cycles locking my buffers just in case some clown tried to take over my MCU.
[17:27:54] <kb1kdw> If I don't have to worry about
[17:28:53] <kb1kdw> "times up" servo thread time, forget about finishing this pass, I can pretend my inputs and output won't change until I have exited, right?
[17:29:37] <kb1kdw> I was worried it was like every function got it's own timer generated interrupt.
[17:30:50] <kb1kdw> Is there a base thread "idle time" variable I can plot in halscope to see if I am overloading things?
[17:31:21] <seb_kuzminsky> heh, yeah, dgarr just made that into a pin so you can plot it
[17:31:32] <seb_kuzminsky> each function has a .time pin, that says how long the function took to run last time
[17:32:08] <kb1kdw> I have used that for my function. Is there one for the sum of everything in the base thread & the servo thread.
[17:32:30] <kb1kdw> I wonder if there would be a benefit to making a "slothen" thread that runs every 50ms
[17:32:36] <seb_kuzminsky> hm, thread time as pin i dont think is available
[17:33:00] <seb_kuzminsky> in halcmd you can "show thread", it has the info you want (most recent runtime of the thread, and max-ever runtime)
[17:33:32] <seb_kuzminsky> but it's not available as a pin, so you can't look at it with halscope
[17:35:11] <kb1kdw> Can I also count on each item within the servo thread getting to finish before someone else in the servo thread could mess the state of things up? For example, if two drivers were sharing the spi buffer, one noticed it wasn't busy and decided to pick up the phone, it wouldn't get cut off before it finished writing to the buffers. Is that true?
[17:36:05] <seb_kuzminsky> within a thread, the functions are ordered (the order is shown by 'halcmd show thread')
[17:36:16] <seb_kuzminsky> each function runs to completion before the next one is started
[17:36:31] <seb_kuzminsky> so if you write your driver in a sane way, they can use shared lockless data structures safely
[17:36:41] <seb_kuzminsky> does that answer your question?
[17:37:09] <kb1kdw> Yes.
[17:38:03] <kb1kdw> Is all of this summed up like we have just discussed in a document somewhere, or is it just obvious to people who are more educated than I?
[17:39:52] <kb1kdw> I hate pestering dev's with newb questions, but I haven't had good luck finding answers to these sort of questions that keep me awake at night...
[17:39:56] <andypugh> I can remember when it wasn’t obvious. That would be about the time I was learning C to write the Mesa three-phase PWM driver
[17:40:45] <seb_kuzminsky> kb1kdw: good question...
[17:40:52] <kb1kdw> I see mention of object and C++ goodness in the developer's guide. Is everything C++able, or just C for components.
[17:42:04] <kb1kdw> A friend of mine mentioned overloading would be a good way to solve my wacky state machine I was attempting to code, but at the time I was pretty sure the code base was C only.
[17:42:27] <kb1kdw> Now that I have read more, I'
[17:42:34] <kb1kdw> am not so sure...
[17:43:52] <seb_kuzminsky> the realtime code often gets compiled to run in kernel space under RTAI, so it must be C, not C++
[17:44:42] <kb1kdw> In the developer's guide, I also saw it mention the trajectory planner run "much faster" than the io and other threads. Is the fastest thing going on in the base thread, or are there special, faster threads reserved for more important work?
[17:45:13] <andypugh> A further limitation is that it is only really safe to use functions and libraries defined in the rtapi directory in the LinuxCNC source tree.
[17:46:02] <seb_kuzminsky> kb1kdw: in answer to your first question (docs about the realtime threads & preemption): i think we don't have written docs about that, sadly
[17:46:07] <kb1kdw> I like safe -- The idea of an over-indexed array causing errant motion is scary.
[17:46:08] <seb_kuzminsky> your questions are always welcome here
[17:46:18] <seb_kuzminsky> (and patches that add the missing docs are welcome too!)
[17:47:18] <kb1kdw> I will try to keep transcripts of my burning questions so that I or someone can add them to the docs. You only get to be newb once :)
[17:48:48] <seb_kuzminsky> about the second question, no, there are almost always 1 or 2 threads
[17:48:53] <andypugh> I am actually aware that my answers now are less helpful than they were when I knew less.
[17:48:58] <seb_kuzminsky> there is always a servo thread, and sometimes also a base thread
[17:49:29] <seb_kuzminsky> the trajectory planner runs in the servo thread
[17:50:46] <seb_kuzminsky> maybe the documentation you found is talking about the difference between Motion (which includes the trajectory planner, and runs in the realtime "servo" thread) and the part of linuxcnc called "io", which is a non-realtime, userspace process
[17:51:28] <seb_kuzminsky> we only have a few brain cells left after trying to write docs for users, so writing docs for developers nearly always gets dropped...
[17:51:45] <kb1kdw> andypugh: Would you be willing to email the wiki password to me so I can add things?
[17:56:57] <kwallace2> In case it might be helpful:
http://www.nist.gov/manuscript-publication-search.cfm?pub_id=823374 . the second half and appendices are probably more interesting.
[17:57:36] <kb1kdw> What is the linuxcnc-devel irc log file url again? I just tried the wiki and I think the info is old.
[17:59:14] <kwallace2> Somethong like this?
http://linuxcnc.mah.priv.at/irc/
[17:59:49] <kwallace2> Ha, something
[18:00:56] <kb1kdw> yeah, that's it. Thank you. I wanted to copy out what I learned this evening.
[18:01:42] <kwallace2> There are other links and I think a zlog thing.
[18:03:09] <Tom_itx> there are at least 3 logbots in here
[18:03:11] <kb1kdw> zlog? What's that? Is that the name for that thing that chased me in my dream?
[18:03:23] <Tom_itx> kb1kdw you just figured it out :)
[18:14:20] <kb1kdw> Is there some "traditional" way of signaling a buffer is being read and that a base thread should not modify it at that second?
[18:15:05] <kb1kdw> if I have a servo thread component that is using the buffer?
[18:15:49] <kb1kdw> (like an array of a few uints for example)
[19:13:35] <wortley> I can write code to test this, but does variable create what is essentially a global as far as the functions in a component using the component generator are concerned, or is it static space that is private to only the main function in .comp file?
[19:14:13] <wortley> (meaning FUNCTION(_) )?
[19:14:40] <andypugh> They are normally globals so that the setup code can do things.
[19:15:09] <wortley> Man, Andy--What are you doing up at this hour!! :)
[19:15:30] <wortley> GOOD. That is what I hoped to hear.
[19:15:44] <wortley> Thank you!
[19:16:18] <andypugh> It’s only 1am here today. I was here at 3am last night.
[19:17:17] <wortley> I know they tend to start work a little later in the morning in Europe, but I am definitely not at the top of my game on 5 hours sleep :)
[19:19:42] <wortley> I used grep and wc to count how many .c's and .comps your name was in -- It came up with 54. That's a lot of different pieces of hardware you have worked on.
[19:22:49] <andypugh> That many? I admit to being surprised.
[19:28:23] <wortley> The power of a habbit. I used to record ALL of my notes at work in composition books. I had about 1 filled per year. People would look at the stack I had after 10 years and thought I had some sort of problem.
[19:29:45] <wortley> So it appears that even though a typedef comes AFTER the declarations at the beginning of .comp file, the typedef can be used with variable to declare a fancy type instead of using junk base types.
[19:31:52] <wortley> Wait. Nope. Maybe not...
[19:38:36] <wortley> So if I add a header file and put my typedefs in there, it appears I can use non-native data types for variables. If I put function protoypes in there, will tha work just like a normal C program too?
[19:45:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05mozmck/new-deb-conf 977237a 06linuxcnc 10debian/configure build: don't depend on libudev * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=977237a
[19:51:07] <PCW> so libudev wasn't needed? (seems I always had to add it manually)
[19:52:09] <seb_kuzminsky> libudev is needed to run uspace packages, and the uspace deb depends on it whether or not we explicitly call it out
[19:52:24] <seb_kuzminsky> the tools that build debian packages notice that we link against it, and add the dependency for us
[19:52:52] <seb_kuzminsky> libudev-dev is needed as a build-dependency for building uspace debs, and we need to call that out explicitly, and we do still after that commit
[19:53:48] <PCW> OK
[19:55:06] <seb_kuzminsky> if you install the deb everything should be automatic & awesome, if you build rip you have to manage the dependencies manually
[19:59:12] <PCW> its great the package system does all that
[21:09:37] <wortley> Can I get a volunteer to please explain to me how a variable from my pin definitions gets into a private function for use with a plain old variable name? Is there some sort of C variable aliasing mojo I should know about?
[21:12:06] <wortley> For example, I declared a "variable" with variable int sp; in a .comp file.
[21:12:25] <wortley> It see that it becomes part of the __comp_state data structure.
[21:12:42] <wortley> I see a pointer to it gets passed to every function defined with the FUNCTION macro.
[21:13:06] <wortley> But I don't understand how I can call it "sp" as in sp=10; and actually have something happen.
[21:13:32] <wortley> as far as I can tell "sp" doesn't exist. Just __comp_inst->sp.
[21:14:21] <wortley> nevermind. #define sp _comp_inst->sp
[21:14:24] <wortley> do!
[21:14:44] <wortley> while (1) { smack forhead() };
[21:15:04] <wortley> #define forhead forehead
[22:49:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/axis-jog-speed 87a898a 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: rename joint_mode to teleop_mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87a898a
[22:49:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/axis-jog-speed c86acbc 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: fix teleop jog speeds * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c86acbc
[22:49:28] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/axis-jog-speed 48ee6b0 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis gui: fix jog speed in Free mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48ee6b0
[22:49:42] <seb_kuzminsky> i'd appreciate a review on that branch