#linuxcnc-devel | Logs for 2016-02-15

Back
[05:57:33] <KGB-linuxcnc> 03John Thornton 052.7 13480af 06linuxcnc 10docs/src/config/pncconf.txt Docs: add info about editing a config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13480af
[09:08:30] <skunkworks> I like how he doesn't mention linuxcnc https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150096
[09:09:37] <skunkworks> seb_kuzminsky, deb?
[09:10:09] <archivist> he is very blinkered
[09:11:14] <archivist> its the linux is scary problem
[09:11:26] <skunkworks> yes - he has
[09:11:34] <skunkworks> very very complicated
[09:28:02] <pcw_home> hmm, how many times do I need to ask mister "dead-in-the-water" what OS he's running?
[09:42:18] <skunkworks> pcw_home, sorry...
[09:49:54] <skunkworks> heh
[09:49:55] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150097
[09:52:31] <cradek> Date: Tue Mar 21 02:42:28 2006 +0000
[09:52:44] <cradek> we're coming up fast on our 10 year anniversary of having threading
[09:53:03] <cradek> jeez I've been working on linuxcnc a long time
[09:54:26] <archivist> when was the last threading bug.. 2009 when I had a problem in 2.3, fixed in 2.4
[09:56:42] <cradek> yeah it's sure had some fixes over time
[09:57:18] <skunkworks> it must suck as a motion control mfg to have to come up with your own treading/tapping logic
[09:58:41] <archivist> js was talking about that the other day, seems the delay external to internal is a killer
[09:59:09] <archivist> fscks up the shoulder, has to have a safety groove
[10:00:35] <cradek> there but for the grace of smart predecessors and a good initial design
[10:58:50] <seb_kuzminsky> skunkworks: deb http://highlab.com/~seb/linuxcnc jessie main
[11:00:43] <seb_kuzminsky> there's -rt kernels for amd64 and 686-pae
[11:00:47] <seb_kuzminsky> haven't tried them yet
[11:07:24] <jepler> I had overnight latency of ~300us on my laptop
[11:07:39] <seb_kuzminsky> how does your laptop run with rtai?
[11:07:44] <jepler> I think the 4.1-rt may have been better on that particular hardware but I don't know for sure
[11:07:47] <jepler> I haven't run rtai there
[11:10:32] <jepler> .. I really can't imagine ever using rtai again, for my own needs. I'd much rather debug uspace, and if I never have to do software step generation again I'll be happy.
[11:19:32] * skunkworks agrees.. (except for debugging uspace)
[11:21:00] <pcw_home> I had stability issues with 4.4.1-rt6 so went back to 4.4.1.5
[11:25:12] <jepler> I'm not sure which combination of patches is in this debian packages
[11:25:33] <jepler> it looked like they use a broken up set of patches,so it might not exactly correspond to any specific -rt release
[12:54:04] <CaptHindsight> happy to test any packaged RTAI test kernels on 2.7
[13:26:29] <skunkworks> pcw_home, http://www.cnczone.com/forums/servo-motors-drives/299340-switch-resolver-encoders.html
[14:00:03] <seb_kuzminsky> jepler: 80 us worst case latency after ~1 hr here, on a machine that runs all day with 1/10 of that with rtai
[14:07:22] <skunkworks> sounds like normal rt_preempt.
[14:07:34] <skunkworks> I have not gotten to it yet. Been one of those days.
[14:18:32] <PCW> seb_kuzminsky: what hardware? I get a lot better on fast hardware than slow ( Atoms are terrible with Preempt-RT newer fast Intel are quite good )
[14:24:25] <jepler> mine's a i5-3220M fwiw. I guess
[14:24:29] <jepler> that's not particularly new anymore
[14:24:46] <jepler> launch Q2'12 according to intel
[15:51:50] <JT-Shop> PCW: iirc you have some sample configs for the 5i25?
[15:55:37] <PCW> I have some but they are just 5i2x sample configs with the card name changed in the ini file
[15:56:04] <PCW> pncconf probably makes better sample configs
[15:56:19] <JT-Shop> ok i'll make some up
[16:02:55] <PCW> theres an old one here:
[16:02:56] <PCW> http://freeby.mesanet.com/7i77.zip
[16:08:05] <JT-Shop> thanks
[17:56:56] <skunkworks> The matsuura has a resolver on the spindle motor - cradek you figured out it was not usable? (multi-pole?)
[17:57:34] <skunkworks> (I don't think we would try to use it anyway.. It is still being used for the existing spindle drive.
[18:03:43] <cradek> I think the vfd needed it - mine was not usable - it had like 100 poles and the pico resolver board couldn't come close to driving it
[18:04:13] <skunkworks> That is what I remember. - plus it is on the spindle
[18:04:19] <skunkworks> *spindle motor
[18:04:23] <cradek> it would have made an unreasonable count rate if it had worked
[18:04:28] <cradek> yes on the motor
[18:04:46] <skunkworks> I think we have the a decent solution if we can get the gear tooth counting well.
[18:04:57] <skunkworks> 69 teeth
[18:05:23] <cradek> yeah that should be good enough if your sensors are fast (don't have much hysteresis)
[18:05:55] <cradek> I suppose it couldn't be worse than a half tooth, so it will be fine
[18:06:22] <skunkworks> they say they will count a 60 tooth gear up to 12krpm
[18:06:33] <skunkworks> (this is 6krpm spindle)
[18:06:37] <skunkworks> so time will tell
[18:06:41] <cradek> neat
[18:07:00] <cradek> mine loses count when it goes fast (ttl encoder) but who cares
[18:08:50] <skunkworks> we have been using ttl-dif converters from digikey. (they have 5 pun plug on one end - dif pigtail on the other end
[18:49:43] <skunkworks> http://www.digikey.com/product-detail/en/CUI-102E-10/102-1787-ND/1923401
[20:15:19] <seb_kuzminsky> PCW: mine's old too - it's powered down right now so i dont know the model
[21:24:12] <KGB-linuxcnc> 03Chris Morley 052.7 b800088 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py pncconf: fix spindle display not working with encoder * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b800088
[21:24:12] <KGB-linuxcnc> 03Chris Morley 052.7 629ab6f 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py pncconf: fix spindle feedback signal error - missing components * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=629ab6f
[21:27:05] <KGB-linuxcnc> 03Chris Morley 05master d5ae641 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d5ae641
[21:34:53] <pcw_home> some random Preempt-RT latency histograms:
[21:34:54] <pcw_home> all servo thread only except last
[21:34:56] <pcw_home> old i5 laptop:
[21:34:57] <pcw_home> http://freeby.mesanet.com/e6420.png
[21:34:59] <pcw_home> older Atom:
[21:35:00] <pcw_home> http://freeby.mesanet.com/atom-330-preempt-rt.png
[21:35:02] <pcw_home> newer Celeron:
[21:35:03] <pcw_home> http://freeby.mesanet.com/hp-stream-mini-preemt-rt.png
[21:35:05] <pcw_home> Dell DC7800 with 2.333 GHz Core Duo:
[21:35:06] <pcw_home> http://freeby.mesanet.com/dc7800-preemt-rt.png
[21:35:08] <pcw_home> same with 3.16 Ghz Core Duo:
[21:35:10] <pcw_home> http://freeby.mesanet.com/e8500-4.4.1-rt5.png
[21:35:11] <pcw_home> G3258/H97:
[21:35:13] <pcw_home> http://freeby.mesanet.com/h97-g3258-preemt-rt.png
[21:42:43] <jepler> seb_kuzminsky: the dpkg force suggestion hasn't worked out for me. the next time I wanted to install a package, apt wouldn't continue due to the problem..
[21:46:52] <mozmck> pcw_home: dead-in-the-water is running rtai with his 7i92!
[21:51:00] <skunksleep> Oops.
[21:53:15] <jepler> seb_kuzminsky: so instead I hand-edited /var/lib/dpkg/status and changed the Breaks: line of that kernel image :-/ it'll do while I rebuild the thing
[22:06:56] <skunksleep> Wait... The hm2_eth component isn't available in an rtai build
[22:07:33] <skunksleep> He must have a sim build?
[22:07:45] <skunksleep> Odd
[22:17:00] <mozmck> skunksleep: I think that's why he's having following errors. It will run - just no realtime.