Back
[02:01:39] <CaptHindsight> http://www.asrock.com/mb/overview.asp?Model=E350M1 12.04 RTAI with EFI is also ~9k max jitter
[06:35:41] <memleak> i know we have some ARM users here like people running the beaglebone black with linuxcnc but is anyone here interested in heavily optimized ARM toolchains? i'm a crosstool-ng dev now and i'll be working on the ARM side of things for awhile in case anyone is interested in that sort of thing.
[10:28:24] <skunkworks> cradek, did you see... current
http://electronicsam.com/images/KandT/testing/screenshots/Screenshot%20from%202014-01-26%2014:42:11.png
[10:28:43] <skunkworks> New
http://electronicsam.com/images/KandT/testing/screenshots/Screenshot%20from%202014-01-26%2014:34:21.png
[10:29:20] <skunkworks> for this simple program
http://electronicsam.com/images/KandT/testing/screenshots/Screenshot%20from%202014-01-26%2014:53:00.png
[10:30:38] <skunkworks> notice the parabolic blends on the entry/exit.. (As I understand it the entry is because at that point he has not done any readahead yet - the last is because he doesn't know if it is the end of the program)
[10:44:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 688f47a 06linuxcnc 10debian/rules.in deb/rules: remove unused python_version * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=688f47a
[10:44:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 16c3ca7 06linuxcnc 10debian/rules.in deb/rules: dont need to care about BUILD_SYS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=16c3ca7
[10:44:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb d823f6c 06linuxcnc 10debian/.gitignore deb: dont ignore package-dirs we no longer build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d823f6c
[10:44:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 26c0e99 06linuxcnc 10(16 files) deb: new debian/configure and debian/control* * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=26c0e99
[10:44:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 5bb9d79 06linuxcnc 10debian/configure 10debian/rules.in deb: fix the debian/{control/rules} remaking rules * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bb9d79
[10:44:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 6f69003 06linuxcnc 10(6 files in 2 dirs) add a linuxcnc-test.deb, with all the tests in it * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6f69003
[10:44:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb fb04ca2 06linuxcnc 10debian/configure deb/conf: accept -a to mean -r * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb04ca2
[10:44:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 2f29c1d 06linuxcnc 10debian/control.in deb/control: get rid of ancient Provides in control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f29c1d
[10:44:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 023ad2b 06linuxcnc 10debian/control.posix.in 10debian/control.rtai.in 10debian/control.rtpreempt.in deb/control: relax the Conflicts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=023ad2b
[10:44:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 1845f37 06linuxcnc 10debian/rules.in deb/rules: dont use cpio when cp will do * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1845f37
[10:44:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 464aca9 06linuxcnc 10debian/linuxcnc.files.in 10src/Makefile install rsyslogd.conf file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=464aca9
[10:44:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb a707037 06linuxcnc 10src/configure.in 10src/rtapi/ulapi_autoload.c give dlopen the path to the ulapi library * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a707037
[10:45:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 9d45fc8 06linuxcnc 10src/Makefile 10src/rtapi/Submakefile put ulapi-$flavor.so straight into rtlib/, not lib, so the dlopen can look in EMC2_RTLIB_DIR * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d45fc8
[11:56:34] <linuxcnc-build> build #31 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/31 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[11:56:39] <linuxcnc-build> build #31 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/31 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[12:14:14] <seb_kuzminsky> i'm looking at 2.6 todo item #3.1,
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6
[12:14:21] <seb_kuzminsky> "which realtime kernels should we ship/support"
[12:14:54] <CaptHindsight> other than ones that work well?
[12:15:44] <seb_kuzminsky> i'm currently thinking: rtai (32 bit) on precise and wheezy, xenomai (32 and 64 bit) on precise and wheezy, and rt-preempt (32 and 64 bit) on wheezy (because debian's done that work for us)
[12:16:19] <seb_kuzminsky> i'm also thinking we might want to re-publish the debian.org rt-preempt debs in our precise deb archive
[12:16:27] <seb_kuzminsky> does that sound like a reasonable set?
[12:16:53] <seb_kuzminsky> CaptHindsight: i only want to ship/support kernels that work well ;-)
[12:17:37] <CaptHindsight> memleak was getting the GPU hardware accel driver working on the E350M1, after that we can test any RTAI, xenomai and preempt-rt kernels
[12:18:14] <seb_kuzminsky> that's great
[12:18:16] <CaptHindsight> Precise installed fglrx or something slow
[12:19:27] <CaptHindsight> I need hardware video and >4GB of memory, not sure if anyone else does
[12:19:49] <seb_kuzminsky> those both sound like good things to have ;-)
[12:20:19] <CaptHindsight> seb_kuzminsky: we can add debian to the test board here, any suggestions on which version or versions to test?
[12:20:57] <seb_kuzminsky> wheezy (debian 7) is the current stable release, that's what i'd suggest
[12:21:16] <seb_kuzminsky> i recently added a wheezy rt-preempt buildslave, but then the vm host lost its power supply :-(
[12:21:22] <seb_kuzminsky> hoping to have it back up later this week
[12:21:39] <CaptHindsight> does the installer work? I only ask because one recent attempt had a broken installer, I forget the version
[12:21:46] <seb_kuzminsky> worked fine for me
[12:22:09] <seb_kuzminsky> i guess we should also support wheezy/xenomai/armhf, for the beaglebone black
[12:23:44] <CaptHindsight> seb_kuzminsky: wheezy i386 or ia64? or should we install both for help with testing?
[12:24:13] <seb_kuzminsky> not ia64
[12:24:27] <seb_kuzminsky> use amd64 instead
[12:24:48] <seb_kuzminsky> sure, it would be great if you could test both, thank you!
[12:25:50] <CaptHindsight> seb_kuzminsky: we should have the cubieboard (dual core arm cortex-a7 + mali400) working shortly, preempt-rt was ~80uS
[12:26:39] <CaptHindsight> not sure what your timing is for the next release
[12:28:03] <seb_kuzminsky> me neither :-/
[12:28:35] <seb_kuzminsky> the main blocker right now is getting ubc merged, and the closer we look at it the more work it looks like it needs :-/
[12:28:58] <seb_kuzminsky> cradek and zultron and i are working on it, but i dont have an eta date
[12:30:13] <CaptHindsight> we are building from scratch since all the ISO's had broken distro's and the tool chains were full of magic
[12:31:04] <seb_kuzminsky> for the cubieboard you mean? yeah the arm world is not as mature/settled as x86, that's for sure
[12:31:32] <CaptHindsight> yes, the cubieboard, getting Gentoo + preempt-rt and RTAI with EMC on the board now
[12:31:59] <CaptHindsight> someone could take that and get Debian working on it
[12:32:03] <seb_kuzminsky> whaaa? rtai on arm, really? that's awesome
[12:33:10] <CaptHindsight> someone could probably get xenomai going as well
[12:33:48] <seb_kuzminsky> xenomai already runs on arm (bbb) so it should(?) be a small leap
[12:34:15] <CaptHindsight> seb_kuzminsky: I forget how much space EMC takes in memory
[12:34:32] <CaptHindsight> and I'm too lazy to walk into the other room and find out :)
[12:34:44] <seb_kuzminsky> bbl
[12:35:32] <CaptHindsight> we can get Linux and BIOS in flash and go from power-on to desktop in ~2 sec
[12:35:53] <CaptHindsight> if we can fit linuxcnc into flash it might be 3 sec
[12:36:50] <linuxcnc-build> build #31 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/31 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[12:55:05] <linuxcnc-build> build #1330 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1330 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[14:01:07] <memleak> "getting the GPU hardware accel driver working on the E350M1" and ended up breaking KDE for.. unknown reasons...
[14:05:31] <CaptHindsight> this is why we don't like wasting time on Ubuntu
[14:07:20] <memleak> kde4[1559]: segfault at <address> error 4 in ld-2.15.so [address] and kcminit_startup[1564]: seg fault at <address> error 4 in ld-2.15.so[address]
[14:08:52] <memleak> switching X drivers should never cause a seg fault in anything except the driver itself
[14:17:09] <CaptHindsight> do we waste time installing a different desktop or try debian?
[14:18:50] <CaptHindsight> every time we mess with Ubuntu we find some mystery magic to make it work just because they wanted to build differently or just randomly rename things
[17:24:35] <cradek> often, broken opengl makes every gl thing crashy
[17:24:47] <cradek> I think kde4 might be a gl thing (crazily)
[17:29:47] <seb_kuzminsky> but! wobbly windows!
[17:29:53] <seb_kuzminsky> you old curmudgeon
[17:30:02] <cradek> that stuff...
[17:30:10] <cradek> I just can't even
[17:30:24] * cradek madly types into irssi
[17:36:08] <seb_kuzminsky> cradek's like, dafuq.png
[17:41:16] <cradek> jellovision
[17:50:25] <mozmck> if half the work put into flashy graphics were put into actual usability, open source software would be worlds ahead...
[18:01:51] <memleak> mozmck, compiz is the future of linux :P
[18:02:34] <mozmck> as long as it works and they quit removing features - I don't care!
[18:03:21] <mozmck> I thought compiz was already mostly abandoned for something else now?
[18:03:53] <memleak> meh i wouldn't know, i run openbox
[18:04:18] <memleak> i used ratpoison a little bit but i really like lxde and openbox
[18:07:36] <memleak> my favorite is still /dev/ttyS0
[18:11:23] <mozmck> I almost went to lxde - I like it pretty well
[18:12:16] <mozmck> xfce is nice, but I'm using Cinnamon now - mainly because I like rabbitVCS integration in Nemo and a couple other Nemo features.
[18:43:39] <seb_kuzminsky> dgarr: in the bug you just opened, #353, the g2 center doesnt make sense to me
[18:44:14] <seb_kuzminsky> oh wait, are you using relative arc centers?
[18:51:19] <seb_kuzminsky> looks like a real bug
[18:51:30] <cradek> I'm still trying to understand the path
[18:51:41] <seb_kuzminsky> if you do the cutter comp entry move before the g2, the g2 works fine
[18:54:57] <cradek> man that's weird gcode
[18:55:33] <cradek> I think if it's allowed, the entry arc will turn into a different arc with an astronomical radius
[18:55:54] <seb_kuzminsky> i now think it's not a bug and things are working as intendend
[18:56:09] <cradek> did you know relative arc centers are the default?
[18:56:58] <seb_kuzminsky> notice it's g21, and the arc is bigger by just .0005 *mm*, which is below the tolerance threeshold for arcs,
http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#_center_format_arcs
[18:57:17] <cradek> I think this poison is better than the other poison we'd get if we allowed them to be even closer
[18:57:18] <seb_kuzminsky> no, i did not know that, i complained needlessly :-/
[18:57:48] <seb_kuzminsky> bbl, bus stop
[18:59:06] <cradek> if we want to allow the entry arc and the tool to be exactly the same radius, that would currently make a degenerate arc, and there would need to be special case code for changing the entry into a line instead.
[19:02:10] <Tom_itx> fwiw i think even in my cad cam it has to be a minimal difference
[19:05:37] <cradek> currently the largest arc I can get it to generate (by changing 5.0005 to 5.0006) is 15600 mm radius
[19:06:09] <cradek> considering that, I think it would be asking for trouble to relax this check
[19:06:37] <Tom_itx> boss5 would do that
[19:06:52] <Tom_itx> they would cut all screwy in a similar case
[19:07:34] <cradek> the 15600mm radius arc runs fine, AXIS preview and motion both get it right
[19:09:22] <cradek> I think I agree with seb that everything is working as designed, but I also agree that the error message is not strictly correct because the one radius IS less than the other radius
[19:12:20] <cradek> a separate check for this case that gives an error like "Arc entry move is degenerate because arc and tool radii are nearly the same", or a special case that lets it decay into a line, would be the two possible fixes I can picture
[20:34:25] <cradek> I wonder who TomP meant to send that to...
[20:40:03] <PCW> I tried but failed at understanding it in a CNC context
[20:42:26] <Tom_itx> PCW i was gonna ask if you had further info on bit files i could include on that tut page
[20:42:39] <Tom_itx> that could be useful to a noob
[20:43:33] <PCW> Not off hand, looks pretty complete
[20:45:53] <PCW> There's some funkyness about sserial stuff on 5I20/4I65
[20:45:55] <PCW> (you need to use a different ucf file) that might be added
[20:45:56] <PCW> This is due to limitations in ISE prior to about V 11
[20:53:05] <PCW> (use 5i20ss.ucf or 4I65ss.ucf for sserial configs)
[20:58:36] <Tom_itx> do you switch that in the TOP file?
[20:58:47] <Tom_itx> like you do the boards
[21:02:57] <PCW> It needs to be in the .ise file (so there should be one for ss builds and one for non ss builds
[21:03:33] <Tom_itx> ahh ok
[21:04:21] <Tom_itx> is that bundled in the zip on your site?
[21:04:28] <PCW> Ill try and make a set if if get a chance
[21:04:34] <Tom_itx> ok
[21:04:49] <Tom_itx> probably won't come up soon anyway
[21:05:29] <PCW> doing a bunch of stuff for the 7I90 and 5I24 so ill add that before I rebundle everything
[21:14:02] <micges> PCW: hi
[21:14:56] <micges> PCW: remind me under what dos version your utils from zips works?
[21:15:22] <PCW> any >3.3 probably
[21:17:18] <micges> ok
[21:18:24] <PCW> theres a util for flashing the 7I90 over epp
[21:19:29] <PCW> I am in the process of making the dist image for the 7I90 which will include this
[21:19:56] <micges> send me please sources and compiled
[21:20:39] <micges> still fighting with 7i90, not always connecting via epp
[21:20:49] <PCW> the serislhm2 stuff all works but iI have not tried programming one over serial yet
[21:21:46] <PCW> Hmm seems stable to me (we are using EPP for loopback test and initialization)
[21:23:45] <PCW> i will send nmflash and source from home, bbl
[21:24:11] <atom1> PCW, does this look reasonable under the 'Bit on Bitfiles' section:
http://tom-itx.dyndns.org:81/~webpage/emc/xilinx/xilinx92_install_index.php
[21:53:05] <atom1> mmm i think i figured it out
[21:54:37] <atom1> remove the 5i20.ucf from the 'work' library add 5i20ss.ucf to it and save the project as fivei20ss.ise
