Back
[00:04:15] <KGB-linuxcnc> 03Fernand Veilleux 05features_preview_2 787b94d 06linuxcnc 10lib/python/gladevcp/features.py Correct some file path and name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=787b94d
[00:11:44] <KGB-linuxcnc> 03Fernand Veilleux 05features_preview_2 004b93f 06linuxcnc 10lib/python/gladevcp/features.py Added standalone debugging capability * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=004b93f
[00:15:42] <linuxcnc-build> build #3661 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3661 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:16:52] <linuxcnc-build> build #3663 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3663 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:17:14] <linuxcnc-build> build #3662 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3662 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:18:46] <linuxcnc-build> build #3662 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3662 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:19:45] <linuxcnc-build> build #1821 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1821 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:19:58] <linuxcnc-build> build #1822 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1822 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:20:08] <linuxcnc-build> build #2870 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2870 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:20:40] <linuxcnc-build> build #2013 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/2013 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:20:45] <linuxcnc-build> build #1332 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/1332 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:21:16] <linuxcnc-build> build #289 of 1500.rip-jessie-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/289 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:21:21] <linuxcnc-build> build #289 of 1502.rip-jessie-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/289 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:21:46] <linuxcnc-build> build #289 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/289 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:21:51] <linuxcnc-build> build #289 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/289 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:22:48] <linuxcnc-build> build #1487 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1487 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:24:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 d231cf7 06linuxcnc 10scripts/realtime.in 10src/configure.in realtime script: when loading, wait for udev to finish * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d231cf7
[00:24:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 17c51b5 06linuxcnc 10scripts/realtime.in realtime script: remove broken CheckLoaded function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17c51b5
[00:24:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 1c678f2 06linuxcnc 10debian/configure debian/configure: accept the 3.16.0-9-rtai linux/rtai kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c678f2
[00:24:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 f539678 06linuxcnc 10src/Makefile.inc.in 10src/configure.in RTNAME is not used anywhere * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f539678
[00:24:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 2d22a86 06linuxcnc 10src/Makefile.inc.in 10src/configure.in 10src/hal/Submakefile handle building under RTAI 4.1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d22a86
[00:24:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 1132232 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ioport.c hm2: fix uninitialized variable warning in ioport * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1132232
[00:24:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 a439918 06linuxcnc 10src/rtapi/rtai_rtapi.c rtapi: teach rtai_rtapi about renamed RTAI constant * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a439918
[00:24:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 4a4b043 06linuxcnc 10src/Makefile 10src/Makefile.modinc.in build system: all versions of RTAI need -msse for math * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a4b043
[00:24:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 51331af 06linuxcnc 10scripts/rtapi.conf.in 10src/configure.in 10src/rtapi/rtai_rtapi.c teach build system & rtapi about RTAI 5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=51331af
[00:24:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 f7f3f7f 06linuxcnc 10tests/symbols.0/test_define.comp 10tests/symbols.0/test_use.comp tests: fix a compiler warning that fails this test on Jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f7f3f7f
[00:25:52] <seb_kuzminsky> rob ellenberg's branch failed the motion-logger test because Task asked Motion to go faster than it used to :-)
[00:26:27] <seb_kuzminsky> ok that's it for me tonight
[00:26:49] <seb_kuzminsky> all those builds will keep my house nice and warm tonight
[00:29:29] <linuxcnc-build> build #1854 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1854 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:32:18] <seb_kuzminsky> i'm thinking those first two realtime-script commits might should go in 2.6
[00:32:57] <linuxcnc-build> build #3665 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3665 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[00:32:58] <linuxcnc-build> build #3675 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3675 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[08:46:54] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates ee8b535 06linuxcnc 10src/emc/usr_intf/stepconf/build_HAL.py 10src/emc/usr_intf/stepconf/build_INI.py stepconf: update for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee8b535
[08:49:14] <jepler> I looked, and there doesn't seem to be any sort of "audit trail" for moderation actions done on the forum.
[08:52:10] <jepler> I just made a judgement call to delete a video post by a new user, which seems to just show clicking in a bunch of commercial windows cam software without context; the blog which was shown in a banner during much of the video seems to be text copied from wikipedia and other websites. Feels like spam to me, even if it is vaguely CNC-related spam
[09:04:04] <JT-Shop> I usually delete any videos not related to CNC when I see them
[09:05:48] <JT-Shop> the message will have the name of the last person to edit it but that is the only place I know of that shows that
[09:22:16] <jepler> I *wish* there were a page in /administrator/ that just gave a list of all the moderator actions
[09:22:29] <jepler> oh well
[09:24:59] <seb_kuzminsky> overnight latency-histogram on 3.16/5.0-test1:
http://highlab.com/~seb/linuxcnc/seb-25Nov2015-20090.png
[09:26:05] <seb_kuzminsky> wow, dewey's on fire
[09:26:54] <jepler> seb_kuzminsky: nice latency
[09:27:06] <jepler> do you have comparison figures on same hardware older os/kernel?
[09:28:00] <jepler> and why is servo thread latency consistently lower than base thread latency on rtai systems? do we have something regarding priority backwards, or some other cause?
[09:31:26] <seb_kuzminsky> jepler: that machine always had pretty good latency, but i dont remember the actual numbers
[09:31:39] <seb_kuzminsky> i'll reboot it into wheezy tonight and make another plot
[09:31:53] <seb_kuzminsky> i'm just excited it didnt crash overnight!
[09:32:34] <jepler> that is good too
[09:40:51] <jepler> may be an interesting thread for people (like us) who publish debian-derived installers / isos:
http://article.gmane.org/gmane.linux.debian.devel.general/205801
[09:42:25] <jepler> istr that the live-build tools can build source images but it doens't look like we actually upload those to wlo
[09:46:39] <linuxcnc-build> build #860 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/860 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>, Jeff Epler
[09:46:39] <linuxcnc-build> <jepler@unpythonic.net>
[09:48:39] <seb_kuzminsky> jepler: where do our rtai rt modules get math things like pow()? they dont seem to be in rtlib/rtapi.ko or in the loaded rtai modules
[09:49:49] <linuxcnc-build> build #1529 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/1529 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>, Jeff Epler <jepler@unpythonic.net>
[09:51:17] <linuxcnc-build> build #898 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/898 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>, Jeff Epler
[09:51:17] <linuxcnc-build> <jepler@unpythonic.net>
[09:51:32] <linuxcnc-build> build #1527 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/1527 blamelist: Bernhard M. Wiedemann <bwiedemann@suse.de>, dummy, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>, Jeff Epler <jepler@unpythonic.net>
[10:04:43] <skunkworks> seb_kuzminsky: wow - very exciting!
[10:05:36] <skunkworks> 0-ppppppppppppppppppppdddddddddddddddddddddddddddddddddddddddddneeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[10:07:31] <skunkworks> heh - kitten says nice work!
[10:07:56] <lair82_> Question Gentleman, using Halscope should I be able to see the encoder.xxxx.xxxx.index-enable signal for a given encoder?
[10:10:07] <jepler> lair82_: I don't know why not. I've frequently scoped and triggered on a soft encoder's index-enable, as in this halscope plot
https://media.unpythonic.net/emergent-files/sandbox/thread-glitch-reproduced.png
[10:10:09] <skunkworks> lair82_: I think if you set the index-enable to true - you should be able to see it tranistion to false with the index is found.
[10:10:41] <skunkworks> iirc how the index works
[10:11:30] <jepler> right, for instance if you're scoping your spindle's index-enable you'll see it transition to TRUE when motion sets it at the start of a spindle synch move, and then to FALSE when the encoder actually encounters its next index pulse and resets its counts & position to 0
[10:11:45] <lair82_> Ok, I can't see anything on either of the encoders that I have connected to my 7i52 in regards to an index-enable signal.
[10:12:22] <jepler> Are you trying to see the actual "phase Z" AKA "index pulse" of the encoder? That is not what the index-enable pin means.
[10:12:30] <lair82_> I figure I should see a blip on the scope???
[10:12:56] <lair82_> Yes, jepler, trying to sort out my encoder signals
[10:13:21] <jepler> OK, "index-enable" is *NOT* the same as "phase Z" or "index pulse". If you just scope index-enable and spin your encoder, it will never "blip"
[10:13:38] <lair82_> But that signal is fired off of the index pulse isn't it?
[10:13:56] <jepler> "index-enable" controls how the encoder component behaves *when there is a rising edge of the index pulse*
[10:14:04] <jepler> encoder.N.index-enable bit i/o
[10:14:04] <jepler> When true, counts and position are reset to zero on the next
[10:14:07] <jepler> rising edge of Phase-Z. At the same time, index-enable is reset
[10:14:10] <jepler> to zero to indicate that the rising edge has occurred.
[10:14:33] <lair82_> Ok, so do a sets .index-enable true, and rotate to turn it off/
[10:14:41] <lair82_> in halshow
[10:14:46] <jepler> that should work
[10:15:08] <jepler> are you working with software encoder component, or hardware (e.g., hostmot2)?
[10:15:45] <lair82_> OK, I try not to bother you guys on this channel, but I have been all over the mailing list, and the linuxcnc irc channel, with no responses
[10:16:08] <lair82_> I am using a hardware encoder in my 7i52
[10:16:25] <jepler> I see now that you said 7i52 already once, thanks for repeating yourself
[10:16:59] <jepler> so yes, try setting index-enable to TRUE manually, then run the encoder through a full revolution
[10:17:08] <jepler> it may help if you use halscope to trigger on the *falling* edge of index-enable
[10:17:56] <lair82_> jepler, can you take a look at my mail thread, "Trouble with 4th axis", just to see what your thoughts are, please.
[10:18:39] <jepler> jas
[10:18:50] <JT-Shop> lair82_:
http://gnipsel.com/linuxcnc/tuning/encoder.html
[10:19:43] <Roguish> jepler: could you take a quick look at this (from PCW). is it specific to a 32bit build? or 64bit? if 32bit, what changes are needed for 64bit?
http://freeby.mesanet.com/makert4.1.13
[10:19:53] <Roguish> thanks
[10:20:15] <lair82_> No problem jepler, very nice JT-Shop, heading back to the machine now
[10:20:20] <jepler> > FERROR = 10000
[10:20:29] <jepler> so you have your FERROR set quite high
[10:20:45] <jepler> .. continues reading
[10:21:47] <seb_kuzminsky> jepler: answering my own question, pow comes from rtai_math.ko, which is disabled for my 5.0-test1 build :-(
[10:22:00] <seb_kuzminsky> so things that use pow(), like genserkins, don't load
[10:23:14] <seb_kuzminsky> we supply some math as inlines in rtapi_math.h, but not pow
[10:23:35] <seb_kuzminsky> this puts a damper on things
[10:23:43] <seb_kuzminsky> well, off to work for me now
[10:24:40] <jepler> lair82_: I don't have any killer suggestions for you
[10:26:48] <jepler> seb_kuzminsky: it's possible to implement pow badly in terms of exp and log, but we don't have implementations of those either
[10:27:14] <jepler> I hate the future where we (linuxcnc) end up maintainers of a math library :-/
[10:28:29] <jepler> exp and log at least have x87 instructions implementing them [with range caveats, I think]
[10:28:33] <jepler> >>> def po(x,y): return exp(log(x)*y)
[10:28:34] <jepler> >>> po(3,2)
[10:28:34] <jepler> 9.000000000000002
[10:28:34] <jepler> >>> pow(3,2)
[10:28:34] <jepler> 9.0
[10:30:30] <jepler> lair82_: if the motor stops but linuxcnc thinks your ferror is in the hundreds, your servo tuning seems quite wrong and/or your feedback is wrong. I would try to eliminate the homing procedure and index for now and work first on accurate feedback and then basic tuning.
[10:32:08] <jepler> lair82_: so change your inifile homing options to whatever does no motion and just takes the current feedback position as home. having done that, you can turn amps off and rotate the shaft by hand.
[10:32:23] <jepler> see if +1 rev and -1 rev both give the expected number of counts
[10:32:39] <jepler> problems like the one you discovered, where you'd matched A and B/ (?) at one differential encoder input should show up there
[10:32:57] <jepler> next do PID tuning and tighten up your ferror, and do home-to-index last.
[10:33:05] <jepler> that is my advice at any rate
[10:34:12] <lair82_> I have the motor installed in the rotary, and the feedback direction and scale are correct now for the commanded motion ( forward rotation-reverse rotation )
[10:36:12] <jepler> it's driving a worm gear or something in the rotary so you can't turn it manually?
[10:36:37] <lair82_> I'm going to go change the homing routine and work from there, see what comes of it. Yes, with a 1:360 reduction
[10:37:14] <lair82_> I can't move it even with a 36" prybar in one of the t-slots on the table
[10:37:14] <jepler> that means you'll get 360 index pulses per 1 revolution of the rotary?
[10:37:39] <lair82_> Yep, the index is working, properly also
[10:37:47] <lair82_> just checked it
[10:38:01] <Roguish> lair82: worm gears won't (cannot) back drive if they are over about 40:1
[10:38:22] <Roguish> frictional physics.
[10:38:23] <lair82_> Yep, figured that one out the hard way
[10:38:38] <jepler> I bet the lesson will stay with you!
[10:38:50] <lair82_> after I almost launched the rotary off of the table
[10:39:04] <lair82_> Yeah, lol
[10:39:37] <lair82_> Ok, bbl
[10:39:51] <Roguish> incidentally, worm gears are just about the most inefficient type of gearing. but if you don't need efficiency, they do cool things.
[10:40:03] <Roguish> and work really well.
[10:40:29] <Roguish> just be sure they are well lubricated.
[10:43:46] <jepler> lair82_: capture a plot of axis.#.motor-pos-cmd and axis.#.home-state during the home procedure. It'll look something like this:
https://emergent.unpythonic.net/files/sandbox/home-seq.png
[10:44:09] <jepler> if home-state is stuck at a number besides 0 when it should be "done" with homing, that may be an interesting piece of troubleshooting info.
[10:44:28] <jepler> if so, report the specific number
[10:48:08] <Roguish__> jepler: i think i answered my own question of a few minutes ago. anyway. i was trying to build a rt kernel for 64bit Mint. I got some errors, but a kernel was built.
http://pastebin.com/qm3drjTQ
[10:48:36] <Roguish__> are these errors mortal? like the kernel is not good?
[10:51:41] <jepler> Roguish__: I'm not familiar with doing "sudo make install" for kernels on Debian.
[10:52:10] <jepler> Roguish__: just based on a quick glance, it looks like the kernel drivers "ndiswrapper" and "virtualbox-guest" are not going to be available in the new kernel.
[10:52:41] <Roguish> ok. there were some errors along the way.
[10:53:45] <Roguish> when i just looked thru the pcw script, it should be ok for 32 and 64. but I had goofed around with the system before and maybe polluted things.
[10:54:00] <jepler> nothing in the script looked specific to 32 bit kernels
[10:54:06] <jepler> afk
[10:54:42] <Roguish> my goal is to use Mint 64bit, with RT-preempt. sound feasible?
[10:55:33] <Roguish> I know JT and others are using Mint32.
[10:56:08] <Roguish> i figured out all my partitioning problems and dont
[10:56:39] <Roguish> don't have a problem reinstalling Mint from the beginning. multiple timessssss
[10:57:29] <seb_kuzminsky> jepler: the rtai folks (or at least paolo) dont want to maintain a math library either, though they said they'd welcome committed volunteers to do so:
http://article.gmane.org/gmane.linux.real-time.rtai/27217
[10:57:40] <Roguish> anyway. thanks. i'll keep plugging along at it.................
[11:22:34] <Roguish__> Jepler: ok, hopefully last question today. I think it's working.
[11:22:54] <Roguish__> noel@ultra-plus ~ $ uname -a
[11:23:04] <Roguish__> Linux ultra-plus 4.1.13-rt15 #1 SMP Tue Nov 24 20:55:01 PST 2015 x86_64 x86_64 x86_64 GNU/Linux
[11:23:53] <Roguish__> what da ya think?
[11:25:09] <lair82_> jepler, I'm trying to capture a shot, but having troubles, I did see that after it hits the home switch zeros the dro and makes it's move to the "home position" it says 21 for the home-state, even though the home position is "0" and when I finally hit the estop it was already over 200 on the readout
[11:29:04] <lair82_> And I get a ' Your connection is not private" error looking at your link, is that due to me using XP/chrome?
[11:33:36] <seb_kuzminsky> lair82_: home state 21 is "final move wait", which means, umm...
[11:34:43] <seb_kuzminsky> which means it's done dancing with the home switch and it's in transit to the final Home position
[11:37:44] <seb_kuzminsky> it should get to the home location, do the optional locking steps, then go to the state HOME_IDLE, which is 0
[11:39:23] <lair82_> But that is the problem, the dro resets to 0 when it gets off of the home switch, so technically at the same time it should change that 0 to whatever my home offset value is, then move to my "home" 0 position.
[11:39:53] <seb_kuzminsky> did you post your ini somewhere?
[11:42:04] <lair82_> But it is going fast enough, even though it is slow, I cant see it setting the offset value, but when it is making it's move to the final home position, it blows past whatever I put down for a home position, and will stop at some random position 20 degrees, 1500 degrees, 555 degrees, never at the programmed " HOME " value.
[11:42:29] <lair82_> And it never stops at the same value
[11:43:28] <skunkworks> where is the index in relation to the actual rotory axis?>
[11:43:53] <skunkworks> Is it connected directly to the servo - or is it on the actual rotary?
[11:44:07] <lair82_> http://pastebin.com/WT8fMkvY here is what I have for my config
[11:44:28] <lair82_> it is off of the actual rotary table
[11:46:59] <lair82_> And, I changed up the homing routine to use the HOME_USE_INDEX so as to use the index from the encoder, that doesn't work either
[11:49:42] <seb_kuzminsky> lair82_: looks like you're missing a connection from axis.3.index-enable to you a-index-enable net
[11:50:31] <seb_kuzminsky> though if you have HOME_USE_INDEX=no, it shouldnt matter
[11:51:25] <seb_kuzminsky> why is HOME commented out? that's where the axis should after locating the home switch (which lives at HOME_OFFSET)
[11:52:54] <lair82_> I do have HOME_USE_INDEX=no, and I am not sure why it is like that, I know for sure that on the machine it is not like that though
[11:54:45] <lair82_> The few lines about "TYPE = ANGULAR, WRAPPED_ROTARY = 1, #LOCKING_INDEXER = 1" are all that are required to differentiate between an angular "rotary"and a linear axis correct?
[11:57:11] <seb_kuzminsky> TYPE=ANGULAR does that
[11:57:55] <seb_kuzminsky> it's hard to debug stuff like this remotely when we can't see the actual config that's driving the machine
[11:58:03] <lair82_> thats what I thought, so anything referencing dimensions would be in degrees correct?
[11:58:24] <seb_kuzminsky> yep
[11:58:54] <lair82_> I will go out and grab what is in the machine right now and post it. what is the best way to send the entire hal and INI, pastebin/
[11:59:27] <seb_kuzminsky> you can change the angular units with [TRAJ]ANGULAR_UNITS,
http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_traj_section
[12:01:06] <lair82_> I have degree, does this look correct to move the a axis 10 degrees, "G01 A 10 F10" ?
[12:02:16] <seb_kuzminsky> yeah, that should move in the positive direction to the 10 degree location
[12:02:31] <lair82_> Because that command moved it 300 degrees
[12:02:37] <seb_kuzminsky> assuming you're in absolute position mode
[12:02:59] <seb_kuzminsky> the distance travelled may be longer than 10 degrees, depending on where you start
[12:03:22] <seb_kuzminsky> if you're a A=11 and run that, i think it should move 359 degrees in the positive direction, how i understand it
[12:03:29] <seb_kuzminsky> (i've never used a rotary axis myself)
[12:04:07] <lair82_> it was at +310.xxxx and it went to +610.xxxx when I ran that command
[12:04:09] <seb_kuzminsky> this understanding is based on my reading of WRAPPED_ROTARY here:
http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_axis__lt_num_gt_section
[12:07:57] <seb_kuzminsky> so it sounds like basic motion is not working right on this axis, you should fix that before trying to tackle homing
[12:09:26] <lair82_> I agree totally, it acts like the units are wrong, and there is a scale factor applied
[12:09:47] <seb_kuzminsky> is it servo or stepper?
[12:09:51] <lair82_> The craziest thing, is that my mpg hand-wheel, works perfectly
[12:09:56] <lair82_> servo
[12:10:05] <lair82_> brand new drive and motor
[12:10:36] <seb_kuzminsky> do you have your encoder count and gearing all figure out and entered into the ini correctly?
[12:10:36] <lair82_> http://www.automationdirect.com/adc/Shopping/Catalog/Motion_Control/Servo_Systems/Medium_Inertia_(1KW_-_3KW)_Servo_Systems/3KW_Servo_System_(Med_Inertia)/SVA-2300
[12:11:11] <seb_kuzminsky> yikes thats big
[12:11:45] <lair82_> Yep, one full rev of the table shows 360 degrees rotation on the screen, it is going in the proper direction based off of command voltage applied
[12:12:23] <lair82_> 12" diameter rotary table
[12:12:50] <seb_kuzminsky> when you say "shows 360 degrees rotation on the screen", do you mean on the Axis DRO?
[12:12:57] <lair82_> Yes
[12:13:21] <seb_kuzminsky> how do you cause the table to rotate one full rev, in that test?
[12:13:34] <lair82_> using my handwheel
[12:13:59] <seb_kuzminsky> an mpg connected via hal to axis.3.jog-counts?
[12:14:09] <lair82_> I don't beleive there are keyboard shortcuts for A axis jogging
[12:14:16] <lair82_> correct seb
[12:15:12] <seb_kuzminsky> according to this, "[" and "]" should jog the 4th axis:
http://linuxcnc.org/docs/2.7/html/gui/axis.html#_keyboard_controls
[12:15:39] <lair82_> Tried that, I'm using gscreen
[12:15:46] <lair82_> if that affects it
[12:16:07] <seb_kuzminsky> so axis.3.jog-counts gets you to the right place but gcode does not?
[12:16:16] <lair82_> Yep
[12:17:38] <seb_kuzminsky> switch to mdi, use "halcmd show pin axis.3.joint-pos-cmd" to inspect the joint position, then run mdi "g0 a0" and inspect it again, then "g0 a10" and inspect again, what do you see?
[12:17:53] <seb_kuzminsky> (run halcmd in a terminal, not the mdi window, obviously)
[12:18:03] <lair82_> Earlier when I changed it up to just set home at zero with no motion, and I homed the machine, it showed it was homed, with a position of 7.5 degrees
[12:18:17] <lair82_> Ok, heading out there now
[12:28:29] <lair82__> Hey seb, here is a screen shot o the terminal. The highlighted is what things looked like
http://postimg.org/image/ke225reo3/
[12:29:00] <seb_kuzminsky> ok
[12:29:03] <seb_kuzminsky> that looks right
[12:29:08] <seb_kuzminsky> it starts at 0, then moves to 10
[12:29:21] <seb_kuzminsky> was the motion of the hardware not that?
[12:29:24] <lair82__> And it moved to 300.1106 on the dro,
[12:29:35] <lair82__> and the rotary move the same 300
[12:30:49] <seb_kuzminsky> what does axis.3.joint-pos-cmd do when you move about 10 degrees using the handwheel?
[12:31:54] <lair82__> 21 float OUT 10.1563 axis.3.joint-pos-cmd
[12:32:17] <lair82__> That was exactly 10 degrees movement
[12:39:09] <lair82__> http://pastebin.com/mPBA70XG http://pastebin.com/e3bwAwbQ here are my hal and INI files that the machine is currently working with
[12:39:10] <seb_kuzminsky> so the pin went frmo 10 to 10.1563, and the table turned 10 degrees?
[12:39:17] <lair82__> Yep
[12:39:27] <seb_kuzminsky> ok, great! that's your problem
[12:39:33] <seb_kuzminsky> the scaling is wrong
[12:41:21] <lair82__> Which scale? if the encoder scale was wrong, why is it reading correctly?
[12:42:05] <seb_kuzminsky> it's reading wrong
[12:42:24] <seb_kuzminsky> the scale that's wrong is hm2_7i80.0.encoder.01.scale, which is [AXIS_3]ENCODER_SCALE
[12:42:30] <seb_kuzminsky> that's 5000 currently
[12:43:10] <seb_kuzminsky> encoder.position is encoder.counts / encoder.scale
[12:43:43] <seb_kuzminsky> your delta position was 0.1563 (for 10 degrees movement)
[12:44:13] <seb_kuzminsky> 0.1563 = delta_counts / 5000, so delta_counts was 781 (0.1563 * 5000)
[12:44:35] <seb_kuzminsky> so, 781 counts should have a delta_position of 10 degrees
[12:44:46] <seb_kuzminsky> 10 = 781 / scale
[12:44:59] <seb_kuzminsky> scale = 781 / 10 = 78.1
[12:45:02] <seb_kuzminsky> or there abouts
[12:45:13] <seb_kuzminsky> that's rough, but should get you in the ballpark
[12:45:49] <seb_kuzminsky> the real way to compute scale is to trace the drive train from the motor to the actuator, taking into account encoder resolution and transmission ratios of gear boxes and belts and things
[12:53:40] <lair82__> I changed that to 78.1, shut down restarted linuxcnc, tried to home the machine, and this is what i see,
http://postimg.org/image/kfk86bhhh/
[12:54:16] <seb_kuzminsky> let's save homing for after basic motion works right
[12:54:50] <seb_kuzminsky> if you use your mpg to move the table 10 degrees, does the dro (and the axis.3.joint-pos-cmd pin) change by ~10 degrees now?
[12:56:25] <seb_kuzminsky> bbl
[13:31:05] <lair82__> seb_kuzminsky, now no homing just jogging after the startup, the dro reads 620.84 and here is terminal,
http://postimg.org/image/lvvqogked/
[13:31:29] <lair82__> moving 10 degrees on the table itself
[13:51:34] <jepler> is your DRO showing commanded or feedback position?
[13:51:45] <jepler> are motor-pos-cmd and motor-pos-fb about the same, or are they wildly different?
[13:52:28] <jepler> er, joint-pos-fb
[13:52:34] <lair82__> Actual position
[13:53:28] <jepler> OK
[13:53:57] <jepler> you should look at the commanded and feedback positions in HAL
[13:54:06] <jepler> if they are wildly different then you need to return to the issue of motor tuning
[13:54:49] <jepler> otherwise you need to see whether there are offsets or something else that would explain why the numbers seen in the user interface are differing so much from what is seen in hal
[13:55:21] <jepler> you might also want to try a different GUI such as AXIS or tklinuxcnc just in case gscreen gets the display of rotary axes wrong, applying an inappropriate scale or something
[13:56:02] <lair82__> http://postimg.org/image/w783h4c3p/
[13:56:17] <jepler> when changing SCALE, PID tuning parameters will also need to be revised. I mention this since
http://postimg.org/image/kfk86bhhh/ shows a following error message...
[13:56:34] <lair82__> That is with it started and homed
[13:57:41] <jepler> you've got ~58 units of difference between command and feedback positions
[13:58:05] <jepler> with that being the case, trying to have linuxcnc turn by ~10 units and visually verifying the result is not useful
[13:58:10] <lair82__> http://postimg.org/image/viz8y6ddx/ that is with it started up, no commands
[13:59:05] <lair82__> But what would cause that? that is what I am trying to figure out,
[13:59:13] <cradek> I would not trust any GUI except AXIS to display WRAPPED_ROTARY right, without testing for sure
[13:59:21] <lair82__> I have no offsets applied at all
[13:59:40] <cradek> oh it's off
[13:59:44] <cradek> is this the latest ini file?
[14:00:08] <jepler> if motor-pos-cmd and motor-pos-fb are different by 50 then you need to tune your PID
[14:00:42] <lair82__> Yes, other than the scale being at 78.1
[14:01:41] <lair82__> How do I tune it, when as soon as I put anything in the P value, it takes off, aimlessly
[14:02:06] <jepler> and fwiw I don't agree with seb_kuzminsky's advice to empirically determine the SCALE based on joint-pos-cmd
[14:02:19] <cradek> your feedback doesn't work right if P makes it take off forever
[14:02:30] <cradek> you need to back up and troubleshoot very basic things, NOT homing
[14:03:21] <jepler> in a pinch you might empirically tune SCALE based on joint-pos-*FB* but not based on commanded positions when you have lots of following error
[14:03:30] <lair82__> Should I worry about tuning the servo to the drive, it has it's own tuning setup to get them matched, or set everything to zero, and use linuxcnc exclusively?
[14:04:03] <cradek> you should make sure the drive and servo work right before doing anything else
[14:04:38] <jepler> if the servo drive itself has a tuning procedure then yes I advise starting there
[14:04:42] <cradek> then you should make sure the resolver correctly reads the position
[14:04:50] <cradek> probably one of those isn't working at all right
[14:05:21] <cradek> maybe feedback is backwards, or who knows what
[14:05:24] <jepler> for instance, I've watched people like cradek and jmkasunich tune analog-input servo drives and begin by e.g., giving .1V of analog input and verifying that it gives a specific speed (1% of what you'd want to get at the 10V full-scale)
[14:05:56] <cradek> yes that's a great basic first step to take
[14:05:58] <jepler> and when it doesn't, turning trimpots on the analog servo drive
[14:06:31] <jepler> or saying "oh it's going the wrong way!" and standing up in a hurry, hitting head on a corner of the electronics enclosure, and starting to bleed all over the place
[14:06:49] <cradek> if it makes banging noises, or oscillates, or does some other crazy thing when you do that, no point in moving on and adding more layers of stuff on top of that
[14:07:02] <cradek> yes be sure to bleed on it early and often
[14:07:06] <cradek> it's good luck
[14:07:41] <JT-Shop> I must have a lot of good luck as much as I bleed lol
[14:07:51] <jepler> if you don't like bleeding your own blood, but know someone who keeps chickens, well, I don't want to spell it all out for you.
[14:08:30] <jepler> OK, I'm getting silly now, sorry about that
[14:09:50] <jepler> seb_kuzminsky: given that I don't believe we actually have a problem of this kind in any branch *before* I started monkeying with mutexes, do you see a reason to put this in any branch prior to the one where I am tinkering?
https://emergent.unpythonic.net/files/sandbox/0001-tests-add-a-test-of-the-rtapi-mutex-operations.patch
[14:11:11] <jepler> .. I'm happy for anyone else's opinion too
[14:11:47] <cradek> cool, you made sure the test is valid and it also passes
[14:13:28] <cradek> count++ is not atomic because read-modify-write, so if mutex is broken you get a final count that's too ... low?
[14:13:37] <jepler> cradek: typically, yes
[14:14:01] <jepler> when I deliberately broke it I got a number of counts like 100121 or something
[14:14:20] <cradek> oh, too high
[14:14:58] <jepler> count=200000
[14:14:58] <jepler> test passed
[14:15:04] <jepler> vs
[14:15:04] <jepler> count=100892
[14:15:05] <jepler> test: test.cc:29: int main(): Assertion `count == 2*N' failed.
[14:15:05] <jepler> Aborted
[14:15:09] <cradek> oh wait that's low, right
[14:15:14] <jepler> expected is 2*N
[14:15:18] <cradek> I couldn't figure out how it would be too high
[14:15:41] <cradek> "read modify [read modify write] write" easily makes it too low
[14:15:45] <jepler> right
[14:16:20] <jepler> unfortunately, when the test only runs on a single CPU core, the problem triggers much less readily
[14:16:46] <jepler> in this configuration (bad mutex, forced to execute on a single CPU core), 3500 passes and counting
[14:17:06] <cradek> unless the mutex code has changed in the last forever, I don't see any reason to put the test on old branches
[14:17:29] <cradek> maybe change it to read modify delay write
[14:17:38] <jepler> yes
[14:17:39] <jepler> rtapi_mutex_get(&mut);
[14:17:40] <jepler> int c = count;
[14:17:40] <jepler> c++;
[14:17:40] <jepler> sched_yield();
[14:17:42] <jepler> count = c;
[14:17:45] <jepler> rtapi_mutex_give(&mut);
[14:17:52] <cradek> heh
[14:17:55] <cradek> take that
[14:18:14] <jepler> still takes just 1/3s to run
[14:19:03] <jepler> well, 2/3s single-core with correct mutex
[14:19:16] <jepler> but a test that takes .7s is just fine by the standards of our testsuite!
[14:19:20] <cradek> no kidding
[14:19:53] <cradek> slow but readily shows a problem is better than fast but gives lots of false positives
[14:20:46] <cradek> er, false successes
[14:20:53] <cradek> you know what I mean
[14:21:24] <jepler> yes
[14:25:54] <lair82__> The drive had an auto tune, so I ran it, and it sounded good, and ran good, so I connected linux to it, and this is where it stands
[14:28:56] <cradek> ok now find out if giving it commands makes it do reasonable things, and find out if your resolver reports its actual position in a reasonable way
[14:29:47] <jepler> encoder, not resolver, afaik?
[14:29:59] <cradek> give it a small positive velocity command, like 1 degree/second, and see if your eyeballs agree it's moving at 1 degree/second and your resolver's position is increasing by 1/second and resolver velocity shows 1
[14:30:03] <lair82__> Gotta go guys, they are shutting it down for the holiday. I going to start over on the whole dam thing monday from the beginning.
[14:30:11] <cradek> I thought the hal file showed a resolver
[14:30:29] <lair82__> Thanks for all the help though, Happy Thanksgiving
[14:30:47] <jepler> eat well, etc
[14:31:05] <jepler> cradek: oh if so I stand corrected
[14:32:05] <cradek> a previous pastebin shows WRAPPED_ROTARY = 1
[14:32:23] <cradek> gscreen really may not get this right
[14:32:31] <cradek> http://pastebin.com/WT8fMkvY
[14:32:48] <cradek> he may be chasing many tails
[14:33:17] <cradek> is there a mythical creature like a hydra but with many tails instead of heads?
[14:34:01] <cradek> on the list he says it's an encoder
[14:34:43] <seb_kuzminsky> jepler: it's fine with me if you put the mutex test in 2.6 or 2.7, but it's also fine if you dont, as long as it goes in before the real mutex changes
[14:35:44] <jepler> seb_kuzminsky: Ok
[14:35:51] <jepler> I think I'll just put it in my branch then
[14:36:50] <seb_kuzminsky> cool
[14:38:33] <jepler> hm in the inifile pastebin I still have open from earlier, I now see P=0
[14:38:52] <jepler> trying to diagnose this initially as a homing issue was not the right thing to do
[14:38:56] <jepler> http://pastebin.com/WT8fMkvY
[14:39:54] <cradek> it runs away with any P set is a big clue that he might not have realized right away was so big
[14:53:47] <cradek> > Merge branch 'master' into features_preview
[14:54:08] <cradek> hmm, unfortunately this isn't ideal, is it
[14:58:18] <jepler> no it is unfortunate
[14:58:50] <pcw_home> trying to home on (probably incorrect) FF1 alone is not going to work very well
[14:58:52] <jepler> it's not a big deal in the grand sceme of things
[14:58:53] <cradek> I see we have features_preview2 now with a new feature in it; wonder what his overall plan is
[14:59:06] <cradek> er _2
[14:59:23] <jepler> ugh there are more problems and limitations of the rtapi_atomic.h header than I realized
[14:59:54] <jepler> it interacts badly with boost's implementation of C++11 atomics, which I end up colliding with in my test
[15:13:26] <seb_kuzminsky> cradek: features_preview_2 was my attempt at recovering from another merge trainwreck in features_preview
[15:13:44] <seb_kuzminsky> features_preview should be removed, and all future work should be done on _2
[15:56:47] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates ef0f74d 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: if KINEMATICS_IDENTITY, label menu items * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ef0f74d
[15:56:47] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_updates a4bdc92 06linuxcnc 10docs/man/man9/motion.9 motion.9 update man page for joints_axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a4bdc92
[16:01:31] <jepler> argh my new test creates a dependency on a new part of libboost
[16:01:38] <jepler> I guess I'll rewrite it as pthreads
[16:06:18] <seb_kuzminsky> yay dgarr!
[16:46:59] <linuxcnc-build> build #168 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/168 blamelist: Dewey Garrett <dgarrett@panix.com>
[16:48:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-rtmath-test eb33301 06linuxcnc 10(5 files) tests: verify that the exported realtime math functions exist * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb33301
[17:05:40] <jepler> seb_kuzminsky: makes sense
[17:11:42] <seb_kuzminsky> jepler: what, the features_preview thing? or the rtmath-test thing?
[17:13:30] <jepler> seb_kuzminsky: the 2.6-rtmath-test
[17:14:16] <seb_kuzminsky> i just fixed the rtai 5 rtai_math.ko problem, and that test verifies it :-)
[17:15:11] <jepler> by putting implementations in linuxcnc, or by fixing the ones in rtai?
[17:15:11] <seb_kuzminsky> rtai provides a way to say what libm.a to link into rtai_math.ko, and one of the options is newlib, which is a libc/libm implementation intended for embedded systems
[17:15:13] <jepler> I hope the latter
[17:15:28] <jepler> ah newlib should be suitably licensed
[17:15:44] <jepler> as I mentioned recently, one of the problems with the math code in rtai was that some files were not distributable...
[17:15:49] <seb_kuzminsky> so now the rtai.dsc build-depends on newlib-source.deb, compiles it appropriately, and links the result into rtai-modules.deb
[17:15:53] <jepler> ++++
[17:15:56] <jepler> makes sense
[17:16:01] <seb_kuzminsky> yeah, i spot-checked newlib and it seems sane
[17:16:11] <jepler> probably not the most efficient pow() implementation for x86 but so what
[17:16:34] <seb_kuzminsky> idfk at this point
[17:16:39] <jepler> yup
[17:17:36] <seb_kuzminsky> * Copyright (C) 1998, 2002 by Red Hat Inc. All rights reserved.
[17:17:36] <seb_kuzminsky> *
[17:17:36] <seb_kuzminsky> * Permission to use, copy, modify, and distribute this
[17:17:36] <seb_kuzminsky> * software is freely granted, provided that this notice
[17:17:36] <seb_kuzminsky> * is preserved.
[17:19:03] <seb_kuzminsky> [79046.521854] RTAI[math]: loaded, using NEWLIB.
[17:19:29] <seb_kuzminsky> ok, back to 0 known bugs in the rtai5 stuff :-)
[17:21:20] <JT-Shop> yea!
[17:21:54] <JT-Shop> nice flash flood watch for Friday
[17:22:13] <seb_kuzminsky> our friday flash-flood will be frozen
[17:22:30] <seb_kuzminsky> 5-12 inches forecast, temps in the teens
[17:22:31] <JT-Shop> that would be worse for me
[17:22:51] <JT-Shop> ouch
[17:23:02] <seb_kuzminsky> i can't wait to be snowed in
[17:23:16] <seb_kuzminsky> i got firewood and whiskey and boardgames
[17:23:18] <JT-Shop> I'm still trying to finish the siding on the shop/garage before it gets too bad outside
[17:23:29] <seb_kuzminsky> oh yeah, you'll want that
[17:23:34] <JT-Shop> you only need 2 of them
[17:24:58] <jepler> the weather forecast here contained the words "sleet accumulation expected" or similar
[17:25:15] <JT-Shop> we picked up some moonshine in Tenn when we went
[17:26:32] <seb_kuzminsky> haha, i just went to refresh my CVS checkout of RTAI vulcano and the patch included this hilarious addition: rt_task->is_hard
[17:26:38] <seb_kuzminsky> it sure is, little CVS server
[17:26:40] <seb_kuzminsky> it sure is
[17:32:57] <JT-Shop> I added the shop onto the garage in Dec 2012 and the garage is who knows old, it's about time to put siding up and get this puppy done
[17:54:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops 2f76b99 06linuxcnc 03tests/lowlevel/mutex/expected 03tests/lowlevel/mutex/test.c 03tests/lowlevel/mutex/test.sh tests: add a test of the rtapi mutex operations * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f76b99
[17:54:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops e49db4b 06linuxcnc 10src/Makefile rtapi: remove rtapi_common.h from public interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e49db4b
[17:54:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops eced6ad 06linuxcnc 10docs/man/man3/rtapi_mutex.3rtapi docs: fix formatting in rtapi_mutex page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eced6ad
[17:54:24] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops 232d2a8 06linuxcnc 10(18 files in 6 dirs) rtapi: split mutex to new header * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=232d2a8
[17:54:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops d0bf9a5 06linuxcnc 10src/hal/hal_priv.h 10src/rtapi/rtapi_common.h 10src/rtapi/rtapi_mutex.h 10src/rtapi/uspace_common.h rtapi: introduce, use new rtapi_mutex_t type * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0bf9a5
[17:54:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/simplify-bitops 818e432 06linuxcnc 10src/rtapi/rtapi_bitops.h rtapi_bitops: remove unneded asm versions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=818e432
[17:54:55] <KGB-linuxcnc> 05jepler/atomic-mutex 840d689 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=840d689
[17:54:55] <KGB-linuxcnc> 05jepler/atomic-mutex-pt1 99fc07b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=99fc07b
[17:55:58] <jepler> I kept ending up in deeper and deeper water as I tried to use our <rtapi_atomic.h> facility to provide the atomic primitive that a mutex needs
[17:56:19] <jepler> .. then I remembered what I hadn't hadd the courage to do when I was adding arm support: use compiler intrinsics for all arches
[17:56:26] <jepler> s/hadd/had/
[17:56:58] <jepler> which achieves the main goal, getting rid of nearly 300 lines of inscrutable inline asm copied wholesale from the linux kernel source tree
[17:57:02] <jepler> src/rtapi/rtapi_bitops.h | 278 +------------------------------------------------------------------------------------------------------------------------------------------------------------------
[17:57:06] <jepler> 1 file changed, 1 insertion(+), 277 deletions(-)
[18:00:07] <jepler> we are left with 5 inline-asm blocks now
[18:04:58] <seb_kuzminsky> sweet
[18:10:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 b5be557 06linuxcnc 10scripts/rtapi.conf.in rtapi: load rtai_math for RTAI 5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b5be557
[18:14:04] <linuxcnc-build> build #3673 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3673 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:15:39] <seb_kuzminsky> huh, that's a real failure
[18:16:02] <seb_kuzminsky> The 2.6 rtapi_math.h advertises a round() function, but lucid's rtai fails to provide it
[18:16:11] * seb_kuzminsky sweeps that one under the rug
[18:16:27] <jepler> do we use round, or just have a declaration?
[18:19:23] <jepler> looks like we probably don't use it in RT
[18:29:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/intrinsic-rdtsc 78d8f5f 06linuxcnc 10src/configure.in 10src/rtapi/uspace_common.h configure: No supported platforms have userspace asm/msr.h * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=78d8f5f
[18:29:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/intrinsic-rdtsc e2b7725 06linuxcnc 10src/rtapi/uspace_common.h uspace: Use compiler intrinsic for rdtsc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e2b7725
[18:33:56] <seb_kuzminsky> jepler: we must not use it in RT anywhere
[18:39:40] <linuxcnc-build> build #3683 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3683 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:54:12] <seb_kuzminsky> i guess that means i should add the rtmath test to master and not to any older branch (since master doesn't claim to support lucid)
[18:54:43] <seb_kuzminsky> and we should not remove the declaration of round from 2.6 and 2.7, since those branches build on both lucid and wheezy, and wheezy apparently *does* have round
[19:23:17] <KGB-linuxcnc> 052.6-rtmath-test eb33301 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb33301
[19:27:22] <jepler> seb_kuzminsky: we do use rdtsc from <asm/msr.h> in kernel space. the removed test and code is all about userspace.
[19:30:30] <jepler> can I just say how happy I am that buildbot can check all those platforms? I don't know how we'd get by if we had to wait for that one guy who still had a lucid machine to compile-test this or that
[19:30:34] <jepler> .. days or weeks post-push
[19:34:32] <seb_kuzminsky> yeah that wouldn't work at all
[19:34:48] <seb_kuzminsky> i'll check out the intrinsic-rdtsc branch when i get back from the nutcracker
[19:35:08] <jepler> enjoy
[19:35:19] <jepler> .. isn't it a bit early?
[19:35:38] <seb_kuzminsky> it's the cheapo rehersal showing
[19:35:47] <seb_kuzminsky> sssh, dont tell my kids
[19:36:19] <jepler> hah until I saw the domain it was on I thought this was spam that had crept onto a popular link aggregation site:
[19:36:23] <jepler> Aging Star’s Weight Loss Secret Revealed
[19:36:26] <jepler> (eso.org)
[19:36:35] <seb_kuzminsky> heh
[19:42:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master-rtmath-test d07c79d 06linuxcnc 10(5 files) tests: verify that the exported realtime math functions exist * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d07c79d
[19:44:08] <seb_kuzminsky> jepler: is __builtin__ia32 appropriate for amd64 too?
[19:44:51] <KGB-linuxcnc> 03Fernand Veilleux 05features_preview_2 6a8c92b 06linuxcnc 10(6 files in 3 dirs) Give user customizing choices * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6a8c92b
[19:46:45] <jepler> seb_kuzminsky: yes, tested on my amd64 / x86_64 here
[22:11:30] <KGB-linuxcnc> 05dgarr/ja9_configs 5c3b309 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c3b309
[22:11:59] <KGB-linuxcnc> 05features_preview 4a1dc8a 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a1dc8a
[22:26:44] <linuxcnc-build> build #864 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/864 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:30:26] <linuxcnc-build> build #1531 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/1531 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:31:40] <linuxcnc-build> build #1533 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/1533 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:31:43] <linuxcnc-build> build #902 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/902 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:19:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 1ddea81 06linuxcnc 10(5 files) tests: verify that the exported realtime math functions exist * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1ddea81
[23:19:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 9400324 06linuxcnc 10debian/control.in packaging: bdep on udev * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9400324
[23:19:23] <seb_kuzminsky> woops
[23:21:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 576d02f 06linuxcnc 10debian/control.in packaging: bdep on udev * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=576d02f
