Back
[02:57:30] <KGB-linuxcnc> 03seb 05master a8f3946 06linuxcnc 10src/hal/user_comps/gs2_vfd.c * gs2: no need for a third copy of the usage info
[02:57:30] <KGB-linuxcnc> 03seb 05master 64f09cd 06linuxcnc 10docs/man/man1/gs2.1 10src/hal/user_comps/gs2_vfd.c * gs2: split --verbose and --debug again
[02:57:33] <KGB-linuxcnc> 03seb 05master 3b8d3f1 06linuxcnc 10docs/man/man1/gs2.1 10src/hal/user_comps/gs2_vfd.c * gs2: let the user specify accel/decel config on command line
[03:22:59] <seb_kuzminsky> what's the correct "Copyright (C) $YEAR $AUTHOR" string to use when lots of people have hacked on a file over the years?
[03:28:54] <memleak> a bunch of them right after each other on seperate lines
[03:31:41] <memleak> https://github.com/ShabbyX/RTAI/blob/master/base/arch/x86/hal/hal_x86.c
[03:32:15] <seb_kuzminsky> thanks!
[03:33:53] <memleak> you don't need to break up sections though based on what the author(s) wrote
[03:35:03] <memleak> for example you don't need to have the original re-write section, then a porting to x86_64 architecture section. it can be all together as well.
[03:36:50] <KGB-linuxcnc> 03seb 05master 9617d2a 06linuxcnc 10src/hal/user_comps/gs2_vfd.c * gs2: update copyright
[03:36:55] <seb_kuzminsky> there! good night!
[03:39:11] <memleak> for example:
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbmem.h
[03:39:57] <memleak> good night :)
[08:04:23] <jepler> memleak: did you see the discussion of gpl-incompatible sources in rtai? we will need to make sure to remove those sources for anything we ship from linuxcnc.org.
[08:06:28] <jepler> based on a communication via mah, upstream may be keeping the files in question, under a gpl-incompatible license (apfl or something like that)
[08:11:26] <CaptHindsight> jepler: I skimmed over that discussion. Were there only a few of those files that are actually used out of the whole math section?
[08:15:40] <CaptHindsight> a possible fix "create a linuxcnc_math module which builds both for RTAI and xenomai-kernel and uses license-clean source code"
[09:49:14] <jepler> CaptHindsight: right now it looks like the affected files didn't provide any APIs we actually call
[09:49:46] <jepler> CaptHindsight: I see that mah deleted the affected files in the ub branch, and while I haven't been able to test it appears we can just remove them from the version of rtai we ship to our lucid users
[09:49:54] <CaptHindsight> that makes it easy :)
[09:50:48] <jepler> CaptHindsight: well the pain in the a-- is that we have to remember to delete the gpl-incompatible files from any rtai distribution we package for linuxcnc.org.
[09:51:49] <CaptHindsight> someone should probably write this down somewhere
[09:52:30] <CaptHindsight> more to maintain
[09:52:59] <archivist> add to a makefile
[09:55:49] <skunkworks> cradek, how did you setup linuxcnc for velocity/acceleration testing? Is there a config setup?
[09:57:15] <cradek> just a bunch of comparators. there is a check-constraints.hal or some name close to that.
[09:57:35] <skunkworks> thanks
[09:59:16] <skunkworks> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=configs/sim/axis/check_constraints.hal;h=c2a432078ec776484c82c16a269e776f0e1263f0;hb=HEAD
[10:00:34] <skunkworks> so - you just watch constraints-ok it looks. (after setting all the max/mins)
[10:00:52] <cradek> yeah it's nice to trigger scope on it
[10:06:47] <jepler> CaptHindsight: well, if we track rtai in git then it should be enough to nuke those files once
[10:16:57] <skunkworks> hmnm - halscope triggers but I don't see a blip
[10:24:24] <skunkworks> hmm - I wonder if you trigger on a float in halscope - then change the trigger source to a bit and you have some trigger level set - halscope gets confused..
[10:31:49] <skunkworks> uh-oh
[10:31:51] <skunkworks> http://imagebin.org/275865
[10:36:43] <skunkworks> wow - is that right?
[10:37:04] <skunkworks> http://imagebin.org/275867
[10:45:28] <cradek> nopes
[10:45:50] <cradek> accel violations?
[10:47:04] <skunkworks> shoud be max of 30 and it is doing 454?
[10:48:23] <cradek> cool, you've got my halscope ddt patch
[10:48:39] <skunkworks> heh - i saw that..
[10:48:55] <skunkworks> so I could look at the velocity and see the acelleration?
[10:49:09] <cradek> yes
[10:49:58] <cradek> you're not comparing XYvel to anything are you? it may be high by sqrt2 of course
[10:51:08] <skunkworks> no
[10:51:31] <skunkworks> If I look at the x velocity - it does seem to match (high acelleration)
[10:53:54] <skunkworks> http://imagebin.org/275868
[10:55:01] <jepler> the sawtooth velocity profile is weird
[10:55:44] <skunkworks> well - this is an issue with the short line segments maybe... (arcs are too short of the trajectory planner at 1khz) (talking out of my ass)
[11:06:09] <jepler> it's important that gcode with small primitives work better, that's the point of the work...
[11:09:56] <skunkworks> right
[11:11:11] <cradek> I wonder if rellenberg knows how to use this kind of thing for testing
[11:11:24] <jepler> It wouldn't hurt to tell him
[11:11:31] <cradek> ah skunkworks just did
[11:11:42] <skunkworks> I was hoping showing him would help.. :)
[11:28:11] <skunkworks> well - that sucks
[11:28:37] <skunkworks> as jepler said - that was the whole point..
[13:06:58] <jgnoss> can someone tell me what's wrong if I get
[13:07:01] <jgnoss> Can not find -sec MOT -var MOT -num 1
[13:07:03] <jgnoss> Can not find -sec IO -var IO -num 1
[13:07:05] <jgnoss> Can not find -sec LINUXCNC -var NML_FILE -num 1
[13:07:07] <jgnoss> Can not find -sec EMC -var NML_FILE -num 1
[13:07:11] <jgnoss> in ~/linuxcnc_debug.txt
[13:07:28] <seb_kuzminsky> jgnoss: those are annoying but harmless
[13:08:02] <jgnoss> but linuxcnc doesn't start
[13:08:05] <jgnoss> :q
[13:08:23] <seb_kuzminsky> then something else is wrong
[13:08:31] <seb_kuzminsky> look in your linuxcnc_print.txt and dmesg output
[13:08:38] <jgnoss> sorry, that was meant for vi
[13:08:55] <seb_kuzminsky> heh
[13:09:05] <seb_kuzminsky> could have been worse, could have been a password meant for ssh ;-)
[13:09:53] <skunkworks> cradek, if I up the servo thread to 5khz
[13:10:57] <skunkworks> http://imagebin.org/275882
[13:12:49] <cradek> hm 20 megainches/sec2 is probably an incorrect accel
[13:13:54] <skunkworks> probably
[13:13:56] <jgnoss> seb: you're here, that's good,
[13:13:59] <jgnoss> on my e-mail to the mailinglist you mentioned that a update will be enough.
[13:14:01] <jgnoss> after the update all ubutu stuff was updated, but lcnc stuff seems to be the same
[13:14:04] <skunkworks> it is worse if you up it to 10khz
[13:14:26] <skunkworks> I must not have understood - I thought it would get better at a higher servo period
[13:15:04] <skunkworks> it definatly took me a second to find that trace... ;)
[13:15:10] <cradek> well it's just not working right
[13:17:16] <seb_kuzminsky> jgnoss: ah, that's you from the list, hi!
[13:17:52] <seb_kuzminsky> you might not have your linuxcnc buildbot apt sources set up the right way (i had assumed you did, but i didnt really have a reason to think that, i guess)
[13:18:06] <jgnoss> yes, that's me, sorry
[13:18:11] <seb_kuzminsky> look on the buildbot.linuxcnc.org website, it says what to put where to get new buildbot debs
[13:20:02] <jgnoss> sounds strange, but he shows me the source to buildbot debs, and the update seems to have the sourcelist changed too.
[13:20:30] <jgnoss> but let me have a look at that, I'm sitting on another machine right now
[13:23:45] <skunkworks> cradek, that seems to be the inital moves.. the rest of the motion looks the same. (slight constraint violations)
[13:24:41] <seb_kuzminsky> bbl, lunch!
[13:43:52] <skunkworks> cradek, ok - this shows it. there doesn't seem to be much difference between 1 and 10khz
[13:44:06] <skunkworks> 1khz
http://imagebin.org/275886
[13:44:19] <skunkworks> 10khz
http://imagebin.org/275885
[14:13:19] <jgnoss> seb: update,
[14:13:22] <jgnoss> problem was, the installation I had still referred to emc2
[14:13:24] <jgnoss> so I had to apt-get install linuxcnc
[14:13:26] <jgnoss> now I've to go over the config files to see machine is working as expected.
[14:14:01] <seb_kuzminsky> jgnoss: great that you got it upgraded :-)
[14:14:33] <jgnoss> it's your work that let me do it, thanks
[14:17:02] <jgnoss> btw , I compiled 2.6 on the same machine,
[14:17:04] <jgnoss> build run completed without errors. after I'll go to test 2.6
[14:17:06] <jgnoss> right now I'm fiddling with some embedded systems to get RTAI running
[16:19:33] <andypugh> How does run-from-line work in Touchy? I only seem to be able to hop between the start and end points of the program.
[17:39:31] <jepler> andypugh: I think it will stop at lines with N-words too
[17:40:06] <andypugh> Ah, so it isn't meant to work with G-code without line numbers?
[17:44:33] <jepler> you don't have to put the N-words on all the lines, just the lines that are also sensible restart points
[17:46:50] <Tom_itx> they don't hurt anything. i leave them in anyway
[17:48:46] <andypugh> My code doesn't have any at all, though. The CAM program didn't add them (it's an EMC2 post, and presumably believed our docs when they say that LinuxCNC ignores line numbers)
[17:49:20] <Tom_itx> for the most part it probably does
[17:49:48] <Tom_itx> my cad cam editor will add them if you need one done
[17:51:00] <andypugh> I can't help feling that perhaps that quirk might have been usefully documented...
[17:52:41] <andypugh> The cutter started walking out about an hour into the program.
[17:53:23] <kwallace_shop> Before I go looking, does anyone know off-hand how to get .ini parameters into g-code? I would like to use the [AXIS_x] MAX and MIN LIMIT in a g-code file.
[17:53:47] <andypugh> Might be easier just to edit the G-code to remove the completed paths.
[17:53:59] <Tom_itx> i've done that before too
[17:54:16] <Tom_itx> or cut air if i'm being lazy
[17:54:52] <kwallace_shop> Don't forget the '/'.
[17:55:37] <andypugh> kwallace_shop:
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_named_parameters_and_inifile_variables_a_id_remap_referto_inifile_variables_a
[17:56:40] <kwallace_shop> Looking.
[17:56:40] <andypugh> (You need to turn on the feature, as described in secion 18)
[18:01:36] <kwallace_shop> That looks just like what I'm looking for, but won't I need a custom branch to get it?
[18:05:04] <seb_kuzminsky> kwallace_shop: it's in master
[18:05:18] <seb_kuzminsky> aka 2.6~pre
[18:07:00] <kwallace_shop> Cool. Thank you.
[18:07:44] <seb_kuzminsky> every time i see our super ugly doc anchor urls i throw up in my mouth a little
[18:11:54] <andypugh> Users ask for the strangest things. A chap in the forum wants an automatic move to Z0.8 when he touches-off. I wonder why he thinks he wants that?
[18:22:33] <Tom_itx> you can do that
[18:23:24] <Tom_itx> i had a button for x and y that offset .1 for the wiggler but i'm not using it right now
[18:24:35] <Tom_itx> i generally offset off the same end of the vise for most things so it would be handy
[18:31:54] <memleak> removing math support in RTAI is pretty straight forward. just delete the math folders and modify configure.ac and corresponding kconfig and makefiles
[18:32:39] <memleak> RTAI doesn't need math to compile anyway, it will use the built-in library that is included with glibc (libm)
[18:33:06] <jepler> for user-mode sure
[18:33:51] <memleak> https://github.com/ShabbyX/RTAI/commit/9d9e8084f6a5828ab58ad55f071cc58107ed180c for a rough idea
[21:03:47] <jepler> I sure never saw C++ work in rtai kernel space
[21:22:47] <memleak> must have missed it when RTAI first started supporting 2.4 kernels :P