Back
[00:43:11] <linuxcnc-build> build #127 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/127 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[02:06:27] <KGB-linuxcnc> 03Chris Morley 052.6 a65435c 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -add 5i25 to internal board data * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a65435c
[02:06:27] <KGB-linuxcnc> 03Chris Morley 052.6 038de8d 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -tweak live tests and remove trace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=038de8d
[02:10:02] <KGB-linuxcnc> 03Chris Morley 05master df265fe 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df265fe
[03:23:09] <linuxcnc-build> build #128 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/128 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[05:07:28] <linuxcnc-build> build #129 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/129 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Chris Morley <chrisinnanaimo@hotmail.com>, gmoccapy <nieson@web.de>
[09:01:12] <cradek> cmorley: yay does that mean you can configure a 5i25 without getting stuff from the forum?
[09:27:46] <alex_jon1> seb_kuzm1nsky: so no 2.6 for the BBB?
[09:27:58] <alex_jon1> e.g. for Xenomai kernels?
[09:29:14] <alex_joni> howdy y'all
[09:43:33] <seb_kuzminsky> alex_joni: yeah, not for 2.6, sorry
[09:44:14] <seb_kuzminsky> i'm planning to keep working on it for 2.7, which should hopefully be much sooner than 2.6 was
[09:45:01] <cradek> I suspect 2.7 can be ready in about the same amount of time as it would have taken to have a bigger 2.6 ready, except we have useful releases meanwhile
[09:45:26] <seb_kuzminsky> that sounds about right
[09:53:23] <skunkworks> well - we have forked
[09:55:55] <cradek> that's great! I wish all the best for both projects.
[10:00:17] <pcw_home> Thanks for all the work on 2.6 Seb
[10:00:26] <seb_kuzminsky> heh
[10:00:54] <seb_kuzminsky> sure thing :-)
[10:00:56] <pcw_home> skunkworks did you manage to boot ubuntu on the Gigabyte?
[10:01:00] <skunkworks> yes
[10:01:24] <skunkworks> I turned off (set to legacy) the uifd (or whatever it was)
[10:01:30] <skunkworks> but aslo updated the bios
[10:01:45] <pcw_home> I had lots of trouble until i upgraded the BIOS
[10:02:03] <skunkworks> running updates now and going to install rtai and play for a bit.
[10:02:16] <pcw_home> or whatever you call it ( UFIOS? )
[10:02:26] <skunkworks> right
[10:02:44] <skunkworks> it was under a wierd menu item..
[10:02:47] <skunkworks> in the bios
[10:02:55] <skunkworks> missed it the first 12 times I looked
[10:03:28] <pcw_home> on thing that's nice is it boots really fast with the right options
[10:04:18] <skunkworks> I have not paid attention yet..
[10:04:22] <skunkworks> but cool
[10:04:25] <pcw_home> (doesnt sit around picking it's nose for 20 seconds or so like some of the Intel MBs)
[10:04:34] <skunkworks> heh
[10:05:46] <pcw_home> DOS prompt in a couple seconds
[10:06:09] <skunkworks> what do you use to boot to dos?
[10:06:20] <skunkworks> (I made a bootable usb..)
[10:06:44] <skunkworks> (although I don't remember how - it has been a while)
[10:07:08] <pcw_home> I used a CF card
[10:07:16] <pcw_home> (in SATA adapter)
[10:07:36] <pcw_home> but usb should work
[10:08:03] <skunkworks> neatr
[10:08:04] <skunkworks> neat
[10:08:17] <skunkworks> how is the rt_preemt latency?
[10:08:22] <pcw_home> used it for upgrading the UFIOS
[10:08:31] <pcw_home> not great
[10:08:39] <pcw_home> ~100 usec
[10:09:10] <pcw_home> RTAI is great but not Preemt_RT no idea why
[10:09:13] <skunkworks> have you tried the idle=poll kernel config line?
[10:09:28] <pcw_home> no
[10:09:37] <skunkworks> worth a shot
[10:16:31] <skunkworks> pcw_home, what did you say about video and kernel version?
[10:16:56] <skunkworks> 3.8 does about 1fps in glxgears :)
[10:17:09] <skunkworks> (12.04)
[10:19:02] <alex_joni> skunkworks: UEFI?
[10:19:47] <skunkworks> alex_joni, right
[10:35:05] <pcw_home> 3.11 or >
[10:36:31] <pcw_home> so preemt_rt 3.12 no RTAI with fast video until RTAI gets to 3.12
[10:43:43] <skunkworks> ah
[10:45:03] <pcw_home> I suspect it wont be too long since RTAI works on 3.10 now
[10:56:11] <mozmck> So that was a fork announcement? Clear as mud...
[11:05:03] <skunkworks> ah - so 3.11 is higher than 3.8.. duh
[11:08:29] <pcw_home> I think the default (non RT) 12.04 kernel is3.11 (and 3.13 for 14.04)
[11:09:07] <skunkworks> hmm - my install says 3.8
[11:09:18] <skunkworks> 12.04
[11:09:26] <pcw_home> so they both work well with Baytrail video
[11:09:28] <pcw_home> No sure why the kernel matters
[11:16:08] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/configs_fixes 44f6bd5 06linuxcnc 10(97 files in 8 dirs) configs/sim/python_demo: move configs to * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=44f6bd5
[11:51:17] <pcw_home> seb_kuzminsky: finally got 7I54 boards so if there are not any major screwups I will send you on to try on your robot
[11:59:13] <seb_kuzminsky> pcw_home: is that the 6 channel 100 W servo daughter board? neat!
[12:01:05] <pcw_home> Yeah
[12:01:36] <pcw_home> with terminal blocks instead of those weird connectors
[12:02:02] <archivist> when will the 9 channel be ready :)
[12:02:12] <pcw_home> buy 1.5
[12:06:56] <linuxcnc-build_> build #382 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/382 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:08:24] <seb_kuzminsky> i like a lot of the "C4" collaboration protocol that the machinekit project linked to
[12:09:57] <MrHindsight> we added some features like SD-card and usb camera support to the preempt_rt kernel we were using and we started getting latency spikes up from <40uS to 53uS
[12:11:29] <MrHindsight> I bumped the stepper base freq up to 120uS and it ran overnight without issue
[12:13:28] <MrHindsight> we need to start keeping track of what kernel options have effects on latency and why
[12:16:04] <pcw_home> i guess with preempt_rt you could possibly trace the causes
[12:17:34] <MrHindsight> we ran that same hardware for weeks and never had >40uS, we add the usb camera and few other options and I'm getting real time errors within an hour
[12:25:49] <MrHindsight> I imagine if we took a hard look at the scheduler we could tweak it, but I can't imagine acceptance of that into mainline
[12:26:41] <MrHindsight> I used to work with QNX, vxworks and psos in another life
[12:28:18] <MrHindsight> but it's not going to be of much benefit for a giant supports everything kernel
[12:28:59] <pcw_home> probably best to just avoid the latency inducing hardware (and/or use more latency tolerant machine hardware interfaces)
[12:30:18] <MrHindsight> we also are using this now with a LPT port vs the 6i25
[12:32:05] <MrHindsight> with RTAI we get <8uS, it was just an attempt to see what happens with preempt_rt
[12:33:32] <pcw_home> There are still some things we can do with the FPGA and driver to make control loops more jitter tolerant
[12:34:44] <pcw_home> (a start of that is in the Fanuc/SSI/BISS interfaces tha use a DPLL to set the encoder data request time before linuxCNCs servo thread)
[12:36:15] <pcw_home> we intend to add this feature to the stepgen, quadrature encoder counters and sserial
[12:38:27] <pcw_home> and perhaps add Endat and Fanuc II to the absolute encoder list
[13:02:10] <MrHindsight> pcw_home: how may the 7i80's be used on a network? how many cards per host? how many 7i80/per switch?
[13:02:34] <pcw_home> currently just one
[13:03:01] <pcw_home> and switches are not suggested (they add latency)
[13:03:33] <MrHindsight> how about multiple nic's on the mainboard/host? Can you have multiple 7i80's?
[13:03:48] <pcw_home> well you can use ans many 7I80s/switches as you like if you are not concerned with RT performance
[13:04:48] <pcw_home> sure multiple NICs should work, though not sure if the driver supports multiple cards yet though
[13:05:15] <MrHindsight> was thinking about 1:1 nic's to 7i80's
[13:07:11] <MrHindsight> http://aggregate.org/FNN/ this worked well for fast cheap clusters 10+ years ago
[13:18:00] <dgarr> seb_kuzminsky: is this a buildbot config problem? the precise/scratch-sim/binary-i386 built ok but the scratch-rt equivalent failed:
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/382/steps/apt-get-update/logs/stdio
[13:25:11] <seb_kuzminsky> i'll look
[13:26:28] <seb_kuzminsky> yeah, looks like a buildbot problem
[13:26:46] <dgarr> ok -- thanks
[13:28:20] <dgarr> is there a way to resubmit the commit that failed when the buildbot problem is fixed?
[13:28:33] <seb_kuzminsky> yeah, i'll show you how after i fix it, hold on a sec
[13:28:50] <seb_kuzminsky> it looks like all the precise buildslaves got corrupted package files from ubuntu.com
[13:29:09] <dgarr> no rush -- thanks when you get to it
[13:31:48] <seb_kuzminsky> dgarr: here's the commands you can give the buildbot:
[13:31:56] <seb_kuzminsky> err, just another sec...
[13:33:08] <seb_kuzminsky> dgarr: here:
[13:33:12] <seb_kuzminsky> linuxcnc-build: help
[13:33:13] <linuxcnc-build> Get help on what? (try 'help <foo>', or 'commands' for a command list)
[13:33:15] <seb_kuzminsky> err
[13:33:18] <seb_kuzminsky> linuxcnc-build: commands
[13:33:18] <linuxcnc-build> buildbot commands: commands, dance, destroy, force, hello, help, last, list, mute, notify, source, status, stop, unmute, version, watch
[13:33:25] <seb_kuzminsky> linuxcnc-build: help force
[13:33:26] <linuxcnc-build> Usage: force build [--branch=branch] [--revision=revision] [--props=prop1=val1,prop2=val2...] <which> <reason> - Force a build
[13:34:10] <seb_kuzminsky> after i fix the precise buildslaves we'll tell the buildmaster to force a build of your branch
[13:53:26] <cradek> I'm surprised to learn that people expected to see the new TP in 2.6. I don't think even Robert expected that.
[13:53:47] <Tom_itx> it would be a nice feature
[13:54:15] <cradek> I can understand this decision seems like a big deal considering releases have been so far apart lately. I would like to see that time reduced a lot for 2.7, whatever it will be
[13:55:08] <Tom_itx> seems 2.6 is targeted to more os flavors than 2.5 ever was
[13:55:25] <Tom_itx> that's quite a leap
[13:55:39] <skunkworks> cradek, that was suprising too.. I know of only a hand full of people that have tested it.. It needs a lot more testing
[13:56:06] <Tom_itx> skunkworks, you seem to be doing most of the hard work on it...
[13:56:17] <cradek> yes I sure appreciate your work testing
[13:56:19] <Tom_itx> dunno what Robert is doing for testing
[13:56:20] <skunkworks> Tom_itx, no... I am doing the fun testing..
[13:56:36] <cradek> Tom_itx: there are great new things in 2.6, it's just that they've been languishing so long people have forgotten
[13:56:57] <skunkworks> robert has been building a test suite of programs
[13:57:08] <Tom_itx> is there a 'new feature' list somewhere?
[13:57:13] <cradek> I think the decision to stop getting bogged down adding things and release it, and then move right on, is the right one
[13:57:18] <Tom_itx> other than changelogs
[13:57:47] <cradek> I don't think there is yet. putting that together is a RM job that can be a big job.
[13:58:03] <skunkworks> cradek, do you remembe how long before your tp improvemenst made it into the released version?
[13:58:08] <skunkworks> that was so long ago..
[13:59:10] <cradek> not really
[13:59:21] <cradek> I don't think the situations compare very well anyway
[13:59:23] <cradek> like you say, long ago
[14:01:35] <skunkworks> I remember helping test that also.. (Although not as good for sure)
[14:01:55] <skunkworks> I was pretty green then..
[14:11:04] <CaptHindsight-sh> does anyone have a copy of camview for linuxcnc?
[14:11:56] <CaptHindsight-sh> also i cant find much information about it due to poorly written and incomplete wiki pages, is camview a modified tree of linuxcnc, a patch set, only available as a precompiled .deb?
[14:12:38] <CaptHindsight-sh> i still do not know exactly what form factors it comes in, psha are you around?
[14:13:35] <CaptHindsight-sh> can camview work just by creating a .axisrc file in the root of your home directory? i cant imagine so.
[14:39:32] <seb_kuzminsky> i'll publish a digested changelog with the 2.6.0~pre1 release
[14:42:39] <skunkworks> in your spare time?
[14:43:34] <seb_kuzminsky> heh
[14:43:47] <seb_kuzminsky> as part of my rm duties, which (contrary to popular opinion) i take seriously
[14:44:31] <skunkworks> when you're not going out of your way to delay, prevaricate and dreaming up excused why you shouldn't instead of should..
[14:44:40] <cradek> you're in a huge "can't win" situation and I think you're making the best of it
[14:45:00] <skunkworks> Agreed - I may have said F-it..
[14:46:35] <pcw_home> skunkworks: the world is a better place if SBs emails are simply not read
[14:46:55] <cradek> oh does that work?
[14:47:45] <skunkworks> heh
[14:48:20] <skunkworks> lets not put in any effort in to the project - but complain about it.
[14:49:00] <cradek> threatening to stop using it over and over is the same as helping improve it, right?
[14:51:08] <cradek> you wouldn't think "I know let's release what is ready and then get on with what isn't!" would cause so much distress
[14:52:01] <cradek> it's already been two years, I mean come on
[14:52:30] <seb_kuzminsky> yeah, that's too long
[14:52:48] <skunkworks> pcw_home, so - with 10.04 - did the usb ports work?
[14:52:53] <seb_kuzminsky> i think the 6-month cadence of ubuntu seems about right, with occasional lts releases
[14:53:42] <cradek> "wait let me get one more thing in" is just so hard to resist
[14:54:11] <cradek> interesting that maybe a fixed schedule fixes that
[14:55:18] <seb_kuzminsky> the linux kernel has something similar, yet different
[14:55:45] <seb_kuzminsky> the release cycle start with a short "merge window", during which time ready features are merged, then the window closes
[14:55:59] <seb_kuzminsky> and there is a period of stabilization, with release candidates
[14:56:24] <seb_kuzminsky> when they get to a release candidate that works, they release it as the next stable version, and open the merge window for the next cycle
[14:57:09] <seb_kuzminsky> dgarr: are you around? i think i finished fixing the precise buildslaves
[14:57:26] <dgarr> for a few minutes -- yes
[14:58:18] <seb_kuzminsky> tell linuxcnc-build this: "force build --branch=dgarr/configs_fixes 0000.checkin'
[14:58:41] <seb_kuzminsky> that'll kick off a build of that branch
[14:58:58] <dgarr> linuxcnc-build force build --branch=dgarr/configs_fixes 0000.checkin
[14:59:26] <cradek> try with a : ?
[14:59:48] <seb_kuzminsky> yeah, like this:
[14:59:52] <seb_kuzminsky> linuxcnc-build: hey there
[15:00:14] <seb_kuzminsky> linuxcnc-build: version
[15:00:14] <linuxcnc-build> buildbot-0.8.6p1 at your service
[15:00:48] <dgarr> linuxcnc-build: force build --branch=dgarr/configs_fixes 0000.checkin
[15:00:49] <linuxcnc-build> build #1991 forced
[15:00:49] <linuxcnc-build> I'll give a shout when the build finishes
[15:01:15] <seb_kuzminsky> cool, i'll keep an eye on it and see if it's still broken
[15:01:21] <dgarr> seb_kuzminsky: thanks -- i will check the deb later this afternoon
[15:30:44] <andypugh> seb_kuzminsky: I don’t doubt that you take RM seriously. My feeling is that perhaps you take it too seriously, and are insisting on a perfection that can’t be achieved.
[15:33:46] <seb_kuzminsky> hmm, yeah i see what you mean
[15:37:23] <andypugh> Some of the outstanding issues are things that I would have expected to see shake out during the 2.6-pre… releases
[15:59:07] <CaptHindsight-sh> any talk of another fest this summer?
[16:03:30] <cradek> I haven't heard of anything, but I'd probably go if it's in the middle of the US somewhere again
[16:04:35] <Connor> So, what's the deal with the TP?
[16:04:50] <Connor> What does the new one do , or do better than the old one ?
[16:04:57] <archivist> thinking of shows MACH14 at the NEC Birmingham in a week or so
[16:05:17] <cradek> it runs some kinds of programs much faster
[16:08:48] <linuxcnc-build> Hey! build 0000.checkin #1991 is complete: Success [3build successful]
[16:08:48] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1991
[16:12:19] <Connor> So, remap and spindle orientation make it into 2.6 release ?
[16:12:29] <cradek> yes
[16:12:42] <cradek> everything that's currently in master
[16:12:48] <Connor> okay. Cool.
[16:13:25] <Connor> I'm going to release this Carousel o-word based remap script at some point. (simulator).. I think it might be good enough to include as a example.
[16:13:49] <cradek> that would be great. a lot of people have tool changers like that.
[16:14:02] <cradek> is it an umbrella style?
[16:14:08] <Connor> yes. non-random
[16:14:13] <Connor> with Z-movement.
[16:14:29] <cradek> ah right. a vismach simulation with a sim config would be a very cool sample
[16:14:52] <Connor> vismach simulation ?
[16:15:07] <cradek> moving 3d model of the machine and tool changer
[16:15:13] <cradek> have you not seen vismach?
[16:15:15] <linuxcnc-build> build #131 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/131
[16:15:17] <Connor> Ah. No.
[16:16:29] <cradek> it's cool. you can link the motion of parts of the model to hal pins
[16:17:15] <Connor> Looks interesting.
[16:17:18] <cradek> ah here's a model of the tripod I hope to make:
http://timeguy.com/cradek-files/emc/upside-down.png
[16:17:39] <cradek> the pink line is the result of jogging around the limits
[16:18:15] <Connor> Does it open up in separate window or something ?
[16:18:18] <cradek> yes
[16:18:27] <cradek> vismach is awesome for working on kinematics etc
[16:18:43] <andypugh> Connor: Start up LinuxCNC and look in (I think) sim-Vismach
[16:19:43] <archivist> in my dreams vismach becomes part of axis one day
[16:20:10] <cradek> can't you already embed it?
[16:20:14] <cradek> on a tab
[16:20:59] <archivist> never tried, I am a python free zone
[16:21:10] <Connor> Found it. Cool.
[16:21:22] <cradek> haha
[16:25:07] <Connor> I have a question... I found that I needed to use a OR component in the simulator... only issue was..I had to go and add it in in the sim_core.hal because OR was already being used..
[16:25:13] <Connor> any way around that ?
[16:28:35] <dgarr> Connor: you can use twopass processing
http://www.linuxcnc.org/docs/devel/html/config/ini_config.html
[16:29:18] <Connor> okay.
[16:29:37] <Connor> so. I can do that.. and it'll override what the core_sim.hal file uses.. cool
[16:30:41] <dgarr> it doesn't override - - just does two passes one to accumulate references, one to execute loadrts
[16:30:52] <Connor> Would THAT have to go into the core_sim.hal ?
[16:33:09] <andypugh> You might find it helps to use “names=“ in your loadrt lines.
[16:33:10] <dgarr> http://www.linuxcnc.org/docs/devel/html/common/starting-emc.html#_twopass
[16:33:40] <Connor> andypugh: I do now. but, in this case.. the sim already had a loadrt or2 statement
[16:33:54] <Connor> and I need a extra one.
[16:35:15] <andypugh> That’s the point of “twopass” It keeps count of how many you asked for.
[16:35:48] <Connor> okay. I'll give that a try in my sim and see how it does.
[16:46:58] <skunkworks> logger[mah]_:
[16:46:58] <logger[mah]_> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-04-03.html
[16:54:57] <Connor> doesn't work with mixed or2.. sim core has it as count=1 and using names= doesnt play nice
[16:57:04] <dgarr> the docs explicitly say that -- count= and names= are mutually exclusive -- just convert to one form or the other, names= is more readable
[16:57:34] <Connor> dgarr: It is. I just didn't want to mess with the stuff in sim_core.hal since it was being used by other things.
[16:57:42] <Connor> so, I'll just use the count version for it.
[16:58:19] <dgarr> in master, core_sim.hal uses names=
[17:00:09] <Connor> must have been updated.. I must have a OLD version then.
[17:00:33] <Connor> I'll nuke out my sim directory and re-install from the current head before releasing.
[17:01:51] <dgarr> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=configs/common/core_sim.hal;h=eecf66ab8d3bcd3599ad47a01f8a9a7d536a6b6f;hb=HEAD
[17:02:56] <Connor> that version doesn't even have a loadrt or2 in it.
[17:03:00] <Connor> so, you I'm out of date
[17:03:52] <Connor> fun part is going to be installing this on the production machine. :)
[17:08:07] <dgarr> names= has been in core sim since:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=3c2c9c236df0bbcef3dab8b25f44ab8b2ff18e8f
[17:08:20] <dgarr> it is even in the v2.5_branch
[17:08:30] <Connor> Yea, who knows how long this config has been on my machine. :)
[17:10:00] <Connor> any known examples of using the orient component ?
[17:10:18] <Connor> that's the LAST thing I need to do
[17:11:42] <dgarr> in master it is wrongly located in configs/sim/python_demo/orient.ini, it will soon be relocated to configs/sim/axis/spindle_orient, the fix is in the scratch branch dgarr/config_fixes
[17:32:16] <Connor> Wow.. Not following this...
[17:34:18] <seb_kuzminsky> dgarr: looks like the debs of your branch built ok this time
[17:35:00] <seb_kuzminsky> Connor: dgarr's been leading the effort to organize our sample configs, it's a work in progress currently
[17:35:08] <dgarr> seb_kuzminsky: yes --thanks again, i just tested a sim and an rt deb on precise and think that branch could (should) be merged to "2.6"
[17:36:19] <Connor> yea, no big deal. Sometimes stuff in simulator is hard to follow...
[17:36:42] <Connor> I think I can play with this on my machine since i have a encoder on the spindle..
[17:37:28] <seb_kuzminsky> wow dgarr, that's a serious commit message you made there!
[17:38:04] <dgarr> just to clarify some configs don't work but they haven't for a long time and i am reluctant to delete them
[17:39:16] <seb_kuzminsky> they don't work in 2.5.3 either? that's a bummer :-/
[17:40:09] <seb_kuzminsky> i wish we had a tool like 'lint' to automatically test our configs and see if they at least load
[17:41:32] <dgarr> seb_kuzminsky: if you merge that branch for me, i will have a few more doc fixes separately later
[17:45:27] <Connor> I don't think that orient example works.. I don't even see it loading the rt module...
[17:46:09] <dgarr> seb_kuzminsky: "they don't work in 2.5.3 either>" -- i don't know about that one way or the other, my tests were with a commit 1c688d, git branch --contains 1c688d doesn't show any v2.5_*
[17:46:23] <seb_kuzminsky> ah, i see, thanks for clarifying
[17:47:39] <seb_kuzminsky> that commit went into master back in december
[17:48:05] <seb_kuzminsky> so things in dgarr/configs_fixes are strictly better than they were in master back in december, is that right?
[17:48:19] <dgarr> hope so
[17:48:39] <dgarr> or maybe better to say no worse than
[17:49:04] <seb_kuzminsky> heh
[17:49:05] <seb_kuzminsky> ok thanks
[17:49:31] <seb_kuzminsky> i'll merge it tonight
[17:50:03] <dgarr> thanks as always for that and all your work
[17:51:38] <seb_kuzminsky> sure! and thank you :-)
[18:38:57] <Connor_mill> playing with orient, but.. not working..
[18:39:03] <Connor_mill> someone look at my hal file?
[18:39:04] <Connor_mill> http://pastebin.com/01KAFXNg
[18:42:55] <seb_kuzminsky> Connor_mill: in what way is it not working?
[18:43:08] <Connor> Well.. it never stops. :)
[18:43:24] <seb_kuzminsky> you tell it to orient the spindle and the spindle just keeps turning?
[18:43:28] <Connor> When is it suppose to ? on the M19 R45 P1 command ?
[18:43:36] <Connor> or S500 M3
[18:43:44] <Connor> correct.
[18:44:24] <Connor> i'm doing some stuff PID stuff with the spindle for speed control.. I might need to remove that.. it might be causing issues.. not sure.
[18:44:56] <seb_kuzminsky> i've never played with spindle orient...
[18:45:17] <seb_kuzminsky> i think there's a sim config that's supposed to demonstrate how it's supposed to work, do you know anything about that?
[18:45:28] <Connor> Me either. *I* don't even need it.. but wanted to test it out.. Need it for Pete's Arrow 500 tool changer
[18:45:43] <Connor> I looked at it.. was clear as mud.
[18:45:57] <seb_kuzminsky> aha
[18:46:10] <seb_kuzminsky> i think you're right, it's supposed to orient when you run M19
[18:46:26] <seb_kuzminsky> i dont know if you need to run M5 first
[18:46:54] <Connor> I did, M19, M5, M19 R45 P1 and then S500 M3
[18:47:27] <seb_kuzminsky> in the hal file you pasted, i dont see anything connected to motion.spindle-is-oriented
[18:48:07] <Connor> I didn't see anything in any of the man page or the sim about that..
[18:48:15] <Connor> except the sim had it linked to a LED
[18:48:44] <seb_kuzminsky> i'm looking at the description of M19, here:
http://www.linuxcnc.org/docs/devel/html/gcode/m-code.html#sec:M19
[18:48:54] <dgarr> the orient.ini file: start,f1,f2, home,f5 (mdi), issue m19 r2, then press the motion.spindle-is-oriented butt - - works for me
[18:49:28] <seb_kuzminsky> cool dgarr
[18:50:02] <seb_kuzminsky> except, dont press the butt ;-)
[18:50:08] <Connor> let me go back out to the machine.
[18:50:14] <Connor> brb
[18:50:29] <seb_kuzminsky> bbl, dinner
[18:52:34] <Connor_mill> is-oriented never trips.
[18:52:52] <Connor_mill> and spindle never moves.
[18:53:02] <Connor_mill> i can turned it manually and it never tripped either..
[18:53:09] <Connor_mill> watching the pins in hal config
[18:53:43] <Connor_mill> maybe the encoder has to be setup a special way ?
[22:59:24] <cmorley> cradek : yes as long as you use the firmware I have samples of - the basics 7i77, 7i76, 7i77_7i76 and prob_rfx2
[23:14:57] <cmorley> I have an updated version of pncconf, but have not tested enough for inclusion and now am too late i think, so I pushed that 5i25 firmware fix to help in the mean time :)
[23:16:59] <seb_kuzminsky> depending on *how* it's better, and how it's different, it's maybe not too late
