Back
[00:49:14] <linuxcnc-build> build #1324 of deb-hardy-rt-binary-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-rt-binary-i386/builds/1324 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[06:44:00] <KGB-linuxcnc> 03Norbert Schechner 05master 7f2e356 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_6 - solved show tooledit bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f2e356
[07:16:13] <KGB-linuxcnc> 03Norbert Schechner 05master 344e9af 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy.glade 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_7 - highlight gcode line by grafics click * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=344e9af
[08:13:13] <KGB-linuxcnc> 03Norbert Schechner 05master c7b39cf 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_8 - corrected hardware switch behavior * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c7b39cf
[12:48:14] <KGB-linuxcnc> 03Norbert Schechner 05master fecada9 06linuxcnc 10lib/python/gladevcp/hal_actions.py gladevcp - hal_action - toogleaction_run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fecada9
[14:06:07] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise I just tried this howto and you end up with a UID error
[14:40:11] <zultron> WOO HOO! FreeCAD can finally be included in Fedora!
https://lists.fedoraproject.org/pipermail/legal/2013-December/002345.html
[14:40:37] <zultron> And awallin's CAM libs, too.
[14:41:54] <CaptHindsight> Total download size: 116 M
[14:42:07] <CaptHindsight> Install 1 Package (+23 Dependent packages)
[14:42:41] <CaptHindsight> needs all the OCE stuff
[14:43:21] <zultron> Yep. I already package RPMs in RPMFusion. Now they can go into Fedora.
[14:43:58] <zultron> Plus there is work on a promising-looking CAM module that would benefit greatly from awallin's TPGs.
[14:47:07] <CaptHindsight> zultron: do you use EMC on Fedora?
[14:49:54] <zultron> Yes
[14:50:18] <zultron> Building packages, too.
[14:58:07] <KGB-linuxcnc> 03Frederic Rible 05xhc-hb04 4a6f649 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: Fix stepsize management in simulation mode Put back HAL pins creation before pendant detection Put some vars in xhc_t structure to prepare future multi-pendant support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a6f649
[14:58:07] <KGB-linuxcnc> 03Frederic Rible 05xhc-hb04 449f0d8 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: Add -x cmdline option to call hal_ready() only after pendant detection * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=449f0d8
[14:58:07] <KGB-linuxcnc> 03Frederic Rible 05xhc-hb04 6576c1f 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: Add xhc-hb04.connected ping to report if the pendant is connected or not Remove tiemout in USB connection loop when "-x" cmdline flag is not present * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6576c1f
[14:58:12] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 471259b 06linuxcnc 10configs/sim/axis/xhc-hb04/README 10configs/sim/axis/xhc-hb04/xhc-hb04-layout1.ini 10configs/sim/axis/xhc-hb04/xhc-hb04-layout2.ini 10configs/sim/axis/xhc-hb04/xhc-hb04.tcl xhc-hb04: support multiple ini jogmodes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=471259b
[14:58:17] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 3fc151f 06linuxcnc 10(8 files in 2 dirs) xhc-hb04: monitor pendant connect/disconnect * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3fc151f
[16:37:06] <pcw_home> cmorley: re brunos problem, is it possible pncconf uses the same ferror values on a mm machine as on a inch machine?
[16:37:30] <cmorley> yes
[16:37:46] <cmorley> but he should see that on the axis page
[16:38:57] <cmorley> he should also update to 2.5.3 - i wish we updated the live cd ....
[16:40:40] <pcw_home> it might be that the mm defaults should be scaled up by 25.4 incase they are not touched
[16:41:21] <cmorley> yes mm conversions are on my todo list for 2.6 refactor
[16:41:46] <pcw_home> Thats may be all thats really wrong with his setup
[16:43:10] <cmorley> well seems like he had step driver timing wrong , possibly following error too tight and backlash too big...?
[16:44:31] <cmorley> but I agree the metric following error would be easy to miss
[16:44:57] <pcw_home> took me twice to see it (used to inch configs)
[16:45:36] <cmorley> but i'm not sure why following error on a stepper system would trip without something else drastically wrong
[16:46:51] <pcw_home> you can always trip the following error by setting it too tight (if only do to time jitter in the postion read)
[16:47:02] <pcw_home> due to
[16:48:37] <cmorley> ok. well i will fix that in the refactor. It should be ready relatively soon. thanks for the heads up on that issue.
[16:49:11] <pcw_home> imagine moving at 10 ips (10 mill per 1 Khz servo thread) If the read in the servo thread is 50 usec late, thats .5 mils apparent error
[16:49:44] <cmorley> wow ok i see that now
[16:51:06] <cmorley> I guess this is why latency is so important - eg step gens assume the periodic rate is steady.
[16:51:48] <pcw_home> the driver stepgen is particulary sensitive to jitter and tends to go off the deep end
[16:51:59] <pcw_home> hm2 drivers
[16:52:34] <cmorley> oh yes I think i read that u tested stepgens with PID and it worked better - is that related?
[16:52:46] <pcw_home> yes if you have a lot of jitter its actuall better to close the stepgen loop with a PID comp
[16:53:20] <cmorley> better to the point pncconf should allow that option?
[16:53:29] <pcw_home> this also eliminated the need to set stepgen_maxaccel (which was just a work-around)
[16:53:53] <cmorley> i see. interesting
[16:53:59] <pcw_home> yes but I think only for 2.6
[16:54:30] <pcw_home> (the PID comp needs the error_prev__target set)
[16:54:30] <cmorley> well i will get back to you when i am ready to work on that then.
[16:55:04] <cmorley> oh yes another observation you had right :)
[16:55:17] <cmorley> prev-target I mean
[16:55:21] <pcw_home> its kind of nice because a stepgen/encoder config is only trivially different
[16:55:52] <pcw_home> so all configs are just servo configs of one type or the other
[16:56:05] <cmorley> yes and pncconf has code for that....not tested really though
[16:56:23] <pcw_home> (with the stepgen having simple fixed tuning)
[16:56:25] <cmorley> I guess tuning is the only pain
[16:57:05] <pcw_home> stepgen tuning is trivial (FF1 = 1.0000 , P = 50)
[16:57:20] <cmorley> that _always_ works? cool
[16:57:21] <skunkworks> you could probably set defaults that will work for almost all..
[16:57:45] <cmorley> what does p compensate for in the stepper system?
[16:57:58] <pcw_home> time base errors
[16:58:02] <cmorley> ahh
[16:58:23] <pcw_home> (and direction change delays)
[16:58:56] <cmorley> have you logged some time of configs like this?
[16:59:03] <pcw_home> the other trick is setting the PIDs maxerror to some small amount so big delay spikes get clipped
[16:59:08] <pcw_home> Yes
[16:59:21] <cmorley> excellent
[16:59:47] <cmorley> sounds very interesting - but i have to finish the refactor first ....:)
[17:00:21] <pcw_home> I'll send you a sample config if you wish
[17:00:34] <cmorley> sure that would be great.
[17:01:19] <pcw_home> really just a servo config with feedback from stepgen position instead of an encoder
[17:01:21] <pcw_home> (and stepgen set into velocity mode)
[17:01:47] <cmorley> what lead you down that path to try it?
[17:02:22] <pcw_home> the 7I80 and the current 100 uSec or worse jitter it has
[17:02:45] <cmorley> yes very bad jitter
[17:03:35] <cmorley> interestingly I think emc1 used steppers with pid and it was a tuning hassle (I read at one time) but i don't know the details
[17:04:25] <cmorley> It seems there is little one can't due with linuxcnc given time and someone interested
[17:04:49] <pcw_home> not useable with the hm2 position mode stepgen but if you consider that the stepgens
[17:04:51] <pcw_home> digital oscillator is very accurate so should be trusted more than the position sample
[17:04:52] <pcw_home> (that is only trust linuxcnc for slow long term corrections)
[17:05:42] <cmorley> that does make some sense :)
[17:06:19] <pcw_home> the stepgen in the driver tries to "fix" the position in the next sample so cause wild bogus adjustments
[17:06:30] <pcw_home> causes
[17:06:35] <cmorley> got ya
[17:06:59] <cmorley> the fact it works as well as it does is surprising then
[17:07:26] <cmorley> the better the latency the better they work
[17:07:37] <cmorley> because the adjustment is smaller
[17:07:43] <pcw_home> Yes
[17:08:32] <pcw_home> but theres no reason you could not tolerate even 500 usec of jitter as long as you just correct based on the average
[17:08:57] <cmorley> maybe this is how MACH 3 does it?
[17:09:59] <cmorley> then does this mean servos are less latency sensitive because of the PID too
[17:10:20] <pcw_home> on the current stepgen, setting stepgen_maxaccel limits how wild the corrections are
[17:10:58] <pcw_home> Yes the same setting can help with jitter on servos
[17:13:01] <pcw_home> but stepgen_maxaccel needs to be big enough to accomodate the highest machine acceleration
[17:13:03] <pcw_home> so still allows too large adjustments
[17:15:06] <pcw_home> the PID method lets you separate the feedforward part (anything the TP tells me goes)
[17:15:07] <pcw_home> from the feedback part (only do slow corrections to filter out jitter)
[17:23:25] <cmorley> I think i get understand. seems we need to fix our docs up - it still recommends setting maxvel / accel to 0
[17:23:46] <cmorley> anyways back to coding work....
[17:25:30] <pcw_home> The hm2 driver should probably be fixed but using PID is a easy workaround
[17:26:02] <pcw_home> and consistent across systems
[18:34:14] <KGB-linuxcnc> 03Chris Morley 05master 359c726 06linuxcnc 10configs/sim/gscreen/gscreen_custom/README 03configs/sim/gscreen/gscreen_custom/tester.ini 03configs/sim/gscreen/gscreen_custom/tester_handler.py gscreen config -add 'tester' config to aid in testing custom screens * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=359c726
[18:49:15] <KGB-linuxcnc> 03Chris Morley 05master 11d0494 06linuxcnc 10lib/python/gladevcp/hal_filechooser.py gladevcp -make action_open sensitive to a running machine * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11d0494
[19:36:24] <KGB-linuxcnc> 03Chris Morley 05master 73f1240 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -fix launch of halshow * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=73f1240
[19:54:36] <KGB-linuxcnc> 03Dewey Garrett 05master 9f6c219 06linuxcnc 10share/axis/tcl/axis.tcl 10tcl/bin/halshow.tcl 10tcl/mini.tcl 10tcl/tklinuxcnc.tcl halshow: eliminate unused ref to a -ini option * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f6c219
[21:04:26] <CaptHindsight> HexChat: 2.9.5 ** OS: Linux 3.12.9-201.fc19.x86_64 x86_64 ** Distro: Fedora release 19 (Schrödinger’s Cat) ** CPU: 6 x AMD Phenom(tm) II X6 1090T Processor (AuthenticAMD) @ 3.62GHz ** RAM: Physical: 15.2GB, 92.9% free ** Disk: Total: 32.6GB, 36.3% free ** VGA: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] ** Sound: HDA-Intel - HDA ATI SB1: HDA-Int
[21:04:27] <CaptHindsight> el - HDA ATI HDMI ** Ethernet: Realtek Semiconductor Co., Ltd. CIe Gigabit Ethernet ** Uptime: 6m 51s **
[21:05:04] <CaptHindsight> 12.05 with emc 2.5 and RTAI 3.4 latency ~8KuS
[21:05:41] <pcw_home> pretty good (assuming thats 8k ns)
[21:05:52] <CaptHindsight> heh, yeah
[21:06:10] <CaptHindsight> 8uS
[21:06:57] <CaptHindsight> with factory Award BIOS
[21:08:31] <CaptHindsight> all the AMD boards seem to run around 8K with ubuntu and rtai 3.4
[21:08:55] <pcw_home> launching flash videos in firefox is usually a latency stressor
[21:09:14] <CaptHindsight> with memleaks tweaked kernels on gentoo it gets down to ~5uS
[21:09:29] <CaptHindsight> yeah flash and firefox does it every time
[21:10:00] <CaptHindsight> has more impact than running stress with 8GB of memory being used
[21:10:58] <CaptHindsight> and this is with integrated graphics
[21:11:32] <pcw_home> not sure if its saturated disk IO or video drivers oer something else
[21:12:02] <CaptHindsight> we'll find out as we get more time
[21:12:51] <pcw_home> That always seems to get the worst times
[21:13:09] <CaptHindsight> this board sits around 5us until I load firefox
[21:14:13] <CaptHindsight> cool and quite and support c1e has to be off
[21:14:25] <CaptHindsight> support for C1E
[21:15:05] <pcw_home> I had to turn that off on my AMD test machine
[21:15:46] <CaptHindsight> virtualization should also be OFF
[21:16:53] <pcw_home> Now if I could figure why Preemt_RT is unstable on AMD...
[21:17:14] <CaptHindsight> it's stable here
[21:17:34] <pcw_home> maybe just the kernel I have
[21:17:34] <CaptHindsight> we have it running on an Asrock e350m1
[21:17:55] <CaptHindsight> could be it's been running for ~2 weeks at <70Us
[21:18:02] <CaptHindsight> let me check...
[21:18:12] <pcw_home> hmm simimilar hardware I think (ASUS pro-e 350)
[21:22:55] <CaptHindsight> 48uS
[21:23:34] <CaptHindsight> someone borrowed the HDMI cable, was running monitorless for the past few days
[21:24:04] <pcw_home> thats good fo preemt_rt
[21:24:48] <CaptHindsight> he had it running ~20uS but it wasn't stable, forgot what it was
[21:25:13] <pcw_home> what kernel version?
[21:26:24] <CaptHindsight> 3.10.28
[21:26:38] <CaptHindsight> is the stable one at 48uS
[21:27:02] <CaptHindsight> I think he posted the configs the other day
[21:27:18] <CaptHindsight> check the logs
[21:28:19] <pcw_home> I will. Im using a pre built kernel from mah but its seems unstable on some hardware
[21:28:46] <CaptHindsight> http://pastebin.com/zgRt1p2E
[21:29:09] <pcw_home> rock stable on intel Atom flakey on core Duo and AMD
[21:30:36] <pcw_home> Thanks!
[21:31:43] <CaptHindsight> fast enough for me
[21:32:13] <CaptHindsight> just controlling 2 steppers with a 12mm travel ea
[21:32:42] <pcw_home> thats not very far...
[21:33:03] <CaptHindsight> only 8K total steps
[21:33:12] <CaptHindsight> 80 tpi screw
[21:33:43] <pcw_home> sounds like a microscope stage
[21:34:12] <CaptHindsight> small format printer
[21:34:30] <pcw_home> thats pretty small
[21:34:37] <CaptHindsight> 12 x 12mm
[21:35:50] <CaptHindsight> but it's high viscosity fluid otherwise it would be a simple inkjet
[21:36:18] <CaptHindsight> it's like printing with honey
[21:37:10] <pcw_home> with a hypo and a blue LED you could make a teenie wenie reprap
[21:38:51] <CaptHindsight> this is similar only it uses a solenoid valve vs a hypo
[21:39:36] <CaptHindsight> fuel injector for honey/thick oil
[21:46:01] <pcw_home> interesting
[21:47:09] <pcw_home> thick stuff allows some really tough filled plastics
[21:51:01] <pcw_home> might erode a fuel injector though
[22:01:30] <CaptHindsight> it's not an actual injector, just similar
[22:44:07] <CaptHindsight> pcw_home:
http://imagebin.org/289623