Back
[01:58:55] <memleak> tree works fine now:
https://github.com/shabbyx/rtai/tree/linuxcnc
[02:14:24] <memleak> now that RTAI is back to life, time to finish that live cd
[03:23:48] <memleak> i opened up #rtai just now btw
[04:18:56] <memleak> well this is new..
[04:19:14] <memleak> isolcpus=1,2,3 must be set otherwise i get latency results in the billions
[04:33:28] <memleak> looks like hal and base scheduler need some rewriting because its broken upstream too
[04:33:46] <memleak> somewhere between 3.9.2 and 4.0 final release
[04:35:51] <memleak> with isolcpus its fine but the old code worked just fine and didnt need that
[05:12:12] <memleak> just to ensure that this isnt happening only on my system, could someone compile the linuxcnc rtai branch and see if latencytest works ok?
[05:12:30] <memleak> (ideally if you have a multicore machine)
[05:13:10] <memleak> no rush just curious. thanks!
[05:15:52] <micges> memleak: remember me link for your github
[05:16:16] <memleak> https://github.com/shabbyx/rtai/tree/linuxcnc
[05:17:30] <memleak> ./autogen.sh ; make menuconfig, change number of cores in Kconfig to your CPU accordingly, make sure math support is enabled, save compile and install
[05:18:12] <memleak> all you have to do then is recompile linuxcnc
[05:18:46] <memleak> (ill automate the rtai configuration stuff soon)
[05:26:56] <micges> can it be on kernel 3.4.55 ?
[05:27:15] <memleak> yes
[09:10:34] <JT-Shop> in 2.5.3 net spindle-enable <= motion.motion-enabled => and2.1.in0 => and2.2.in0 works as expected but net spindle-enable and2.1.in0 <= and2.2.in0 <= motion.motion-enabled and motion.motion-enabled does not change the signal
[09:11:38] * JT-Shop upgrades to 2.4 to see if it is fixed
[09:11:42] <JT-Shop> 2.5.4
[09:13:51] <cradek> are you talking about something stepconf generated? 2.5.4 has a changelog entry "Stepconf: fix spindle-at-speed connection"
[09:13:51] <JT-Shop> hmm works in 2.5.4
[09:14:01] <JT-Shop> no, hand coded
[09:14:18] <cradek> I don't understand what you're reporting
[09:15:12] <JT-Shop> in 2.5.3 the line net spindle-enable and2.1.in0 <= and2.2.in0 <= motion.motion-enabled the motion.motion-enabled does not get connected to the signal spindle-enable
[09:15:56] <JT-Shop> if I used net spindle-enable <= motion.motion-enabled => and2.1.in0 => and2.2.in0 then motion.motion-enabled shows is connected to the signal
[09:16:05] <JT-Shop> in 2.5.4 either line works
[09:16:59] <cradek> I don't know of any change that would affect that. Are you sure you didn't make a mistake?
[09:17:16] <JT-Shop> no, I'm not sure at this point
[09:17:32] <cradek> I know that feeling well
[09:18:19] <JT-Shop> oh wait this is what I first had net spindle-enable and2.1.in0 <= and2.2.in0 <=motion.motion-enabled note no space between <= and motion. and that one does not work
[09:19:04] <MrHindsight> what to do with RTAI? The maintainer of the official branch doesn't have the time to keep up or even test his code.
[09:19:05] <cradek> oh yeah I bet not
[09:20:00] <MrHindsight> the official branch will only be functional for short periods of time throughout the year
[09:20:21] <pcw_home> the parser drops the complete token is it starts with <= or => ?
[09:20:27] <pcw_home> if it
[09:20:54] <cradek> yeah I'd expect an error that the name doesn't exist
[09:21:09] <cradek> but apparently it just drops it
[09:21:42] <MrHindsight> what is the preference here work with a fork of RTAI or put up with whatever happens at rtai.org?
[09:21:55] <pcw_home> either complain or parse correctly would be good
[09:23:03] <pcw_home> are = and < > legal in pin/net/param names?
[09:23:46] <cradek> unfortunately the documentation is written in C
[09:23:57] <pcw_home> :-)
[09:24:46] <cradek> MrHindsight: I don't feel like I have the information to answer that in a smart way, except for what I've said earlier about how avoiding forks/divergence is best, when possible
[09:25:00] <MrHindsight> yeah that was tried
[09:25:32] <MrHindsight> but the RTAI "keymaster" doesn't want to share his powers
[09:26:12] <MrHindsight> and he updates the current fork from shabby/memleak and then adds his broken code and disappears for 4 months
[09:28:09] <MrHindsight> the majority of RTAI devs work only with the shabby/memleak repos and not RTAI.org
[09:32:58] <cradek> if(argv[s][0] == '<' || argv[s][0] == '=') { continue;
[09:33:14] <cradek> so, yes I think it discards the whole word
[09:35:10] <pcw_home> thats sure can lead to subtle bugs with bad typists
[09:35:55] <cradek> I haven't yet found whether there's a restriction on what characters can be in a pin name
[09:36:20] <pcw_home> probably better to have <= and => as tokens and drop them
[09:36:47] <cradek> yes they could be "words" whose handler function does nothing
[09:37:56] <pcw_home> then <=somename would just be an error
[09:38:19] <cradek> yes because it would be a pin that doesn't exist
[09:45:50] <cradek> currently someone can write ===> but that would become an error
[09:46:09] <cradek> but man halcmd only allows for three particular errors
[09:46:12] <cradek> arrows
[09:47:30] <cradek> MrHindsight: considering that, do you think the situation is evolving naturally to work around the problems?
[09:49:05] <mozmck> even at rtai there are several repositories, and I think we used magma - the development branch once or twice.
[09:49:50] <memleak> mozmck, magma is the most broken repo atm
[09:50:13] <mozmck> memleak: but several years ago it was not
[09:50:45] <MrHindsight> so "use what works" is what has been done
[09:50:50] <memleak> 3.x kernels broke that
[09:51:12] <mozmck> the point is, we were not using the latest "stable" release as far as I know, someone else may know better than me though.
[09:51:30] <MrHindsight> so linuxcnc will use whatever branch works best whenever it gets to the point of a new release
[09:51:47] <cradek> sure
[09:51:54] <cradek> we always have done that
[09:51:58] <memleak> you dont need the latest release if you're using 2.6 kernels :)
[09:52:14] <cradek> it has always been kind of hard to get a combination of kernel and rtai that works right
[09:52:20] <memleak> indeed..
[09:52:46] <cradek> in the past we've been able to stick with a version for a few years at least
[09:52:51] <mozmck> :) back then that was the latest kernel! We needed magma to support the kernel we wanted to use at the time.
[09:52:54] <cradek> that seems to be less and less true as hardware becomes weirder
[09:52:57] <seb_kuzminsky> i'm rsyncing 2.6.0~pre2 debs to wlo now
[09:53:00] <memleak> even more difficult now with 50 other kernels to decide from :)
[09:53:04] <cradek> seb_kuzminsky: yay!
[09:53:53] <MrHindsight> but now back to another current problem....
[09:54:15] <cradek> // special case: sig = newvalue
[09:54:16] <cradek> if(argc == 3 && strcmp(argv[1], "=")) {
[09:54:25] <cradek> well I guess this has never worked...
[09:54:29] <cradek> funny
[09:56:06] <mozmck> off topic: for the last few days I'm getting "Received CTCP 'VERSION' (to mozmck) from ParaDMON" every 30 minutes or so - and idea why?
[09:56:23] <cradek> did you ask ParaDMON?
[09:56:27] <MrHindsight> 10.04 doesn't automagically install FGLRX on a new AMD board, 12.04 does however, how do we install Linuxcnc on new hardware without the Ubuntu installer using FGLRX?
[09:57:30] <MrHindsight> once FGLRX is in place it's been impossible so far to remove it and install the open hardware drivers
[09:57:58] <mozmck> cradek: I don't know how - It's a bot I'm pretty sure.
[09:58:39] <MrHindsight> the problem with using 10.04 is the old kernel that doesn't support the new hardware
[09:59:14] <cradek> MrHindsight: sometimes hidden in the boot screen there's a "use only free software" option you can turn on...?
[10:00:20] <cradek> [freenode] -!- There is no such nick ParaDMON
[10:00:22] <cradek> hm
[10:00:36] <cradek> then I don't know, sorry
[10:01:35] <mozmck> thanks, probably another irc server I'm connected to then.
[10:01:43] <cradek> yeah
[10:01:51] <cradek> you can /query the nick and talk to him/her/it
[10:05:07] <archivist> or talk to a staffer and get them to kline it
[10:16:19] <seb_kuzminsky> MrHindsight, memleak, cradek: i'm trying to understand what's going on with rtai
[10:16:48] <seb_kuzminsky> sounds like there are 3 major forks in play currently: paolo's (aka the real rtai), shabby's (aka the active rtai), and memleak's (aka the linuxcnc rtai)
[10:16:51] <seb_kuzminsky> is that right?
[10:17:12] <memleak> yes the rest are small little forks like avalanche :P
[10:17:19] <seb_kuzminsky> i dont know what avalanche is
[10:17:44] <memleak> https://github.com/shabbyx/rtai/tree/avalanche
[10:17:50] <memleak> but yeah basically
[10:18:00] <seb_kuzminsky> ah, avalanche is a branch in shabby's fork
[10:18:06] <memleak> yes
[10:18:21] <memleak> its the most stable 2.6 kernel RTAI branch
[10:19:26] <seb_kuzminsky> memleak: and you think shabby's fork is no good because he merges with paolo's, which breaks things for us, is that right?
[10:19:50] <memleak> yes all shabby branches are hosed IIRC
[10:20:18] <memleak> except avalanche :/
[10:20:50] <seb_kuzminsky> and shabby's branches are hosed because of things he merged from paolo?
[10:21:25] <memleak> yes, the sections of rtai that shabby and i wrote are fine
[10:22:50] <memleak> i handle all the autotools stuff, scheduler and kernel patches, shabby takes care of kconfig and misc bugs that i dont have
[10:24:07] <memleak> hes a genius at kconfig btw. i dont know how he updated the ancient kconfig code to the kconfig code found in kernel 3.9
[10:24:26] <memleak> i spent about 3 days trying to do that with absolutely no success
[10:24:52] <seb_kuzminsky> how is it that paolo's (and by merge, shabby's) rtai forks fail to work with linuxcnc? is it internal apis that have evolved, and maybe we should evolve along with them? or is it just legit bugs in rtai that dont get addressed?
[10:25:33] <memleak> the answer to that question depends on which bug we're talking about
[10:26:26] <memleak> sometimes the answer is "i dont know if its broken within linuxcnc or RTAI"
[10:27:57] <memleak> it really all depends. ive seen bugs that clearly could have been fixed with appropriate changes to linuxcnc's rtapi, and ive seen legit bugs within RTAI, then there are times where ive been utterly confused why something isnt working
[10:29:05] <seb_kuzminsky> bugs are one thing - i expect there to be bugs when code is developed, and especially when code is integrated between two projects like rtai and linuxcnc
[10:30:03] <memleak> bugs / catastrophic failure
[10:31:29] <seb_kuzminsky> sure
[10:32:37] <seb_kuzminsky> ideally that's why projects have a stable branch and a development branch
[10:32:48] <memleak> magma doesnt even compile with linuxcnc
[10:33:29] <seb_kuzminsky> magma's the development branch, right? it doesn't surprise me or worry me if they've changed something so that our use is no longer current
[10:33:44] <seb_kuzminsky> bbl, switching busses...
[11:41:32] <KGB-linuxcnc> 03Francis Tisserant 052.6 647162f 06linuxcnc 10docs/src/config/linuxcnc2hal_fr.txt French doc: add descriptions for new spindle orientation HAL pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=647162f
[11:53:37] <cradek> seb_kuzminsky: do you want this on 2.6?:
http://timeguy.com/cradek-files/emc/0001-halcmd-Better-detection-of-some-arrow-related-typos.patch
[12:06:08] <seb_kuzminsky> cradek: yes please
[12:07:15] <seb_kuzminsky> it'd be good if we could detect the invalid multi-equal-sign arrows and complain about them, but since the docs say "one equal sign" i think it's fine
[12:08:40] <KGB-linuxcnc> 03Chris Radek 052.6 e08f9c0 06linuxcnc 10src/hal/utils/halcmd.c Fix "pin = value" and "param = value" hal commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e08f9c0
[12:08:40] <KGB-linuxcnc> 03Chris Radek 052.6 934296f 06linuxcnc 10src/hal/utils/halcmd.c halcmd: Better detection of some arrow-related typos * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=934296f
[12:08:40] <KGB-linuxcnc> 03Chris Radek 05master 90e4834 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=90e4834
[12:08:45] <cradek> I have no evidence people have written those invalid arrows
[12:09:55] <cradek> what does buildbot build when I push two branches at once?
[12:11:16] <seb_kuzminsky> it builds first one then the other
[12:11:25] <cradek> ah, poor thing
[12:11:36] <seb_kuzminsky> thanks for the halcmd fixes
[12:11:41] <cradek> welcome
[12:14:13] <cradek> it's odd that an 11-year-old feature has never worked and nobody ever noticed
[12:14:18] <seb_kuzminsky> heh
[12:14:27] <cradek> that might mean I should've removed it instead
[12:14:57] <seb_kuzminsky> makes me think people stop reading when they come to the setp part of the manpage, and don't notice the paragraphs after
[12:15:30] <seb_kuzminsky> i assume you tested that it works after your change, so then i think it's fine ot leave in
[12:15:39] <cradek> yes I even tried it
[12:16:00] <cradek> completion doesn't work for that format, but that's to be expected
[12:16:05] <cradek> I couldn't find any other problem
[12:17:47] <seb_kuzminsky> bueno
[13:08:52] <seb_kuzminsky> huh, andypugh reports that the machinekit folks are publishing an rtai fork too
[13:14:45] <jthornton> yea! I won't be able to make the same dumb mistake again...
[13:26:46] <KGB-linuxcnc> 03John Thornton 05v2.5_branch 5c09139 06linuxcnc 10docs/src/hal/basic_hal.txt Docs: add info about the direction arrow requirements * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c09139
[13:31:31] <pcw_home> minor spell-o: separate
[13:31:50] <pcw_home> (instead of seperate)
[13:32:06] <jthornton> dang finge3rs
[13:33:44] <KGB-linuxcnc> 03John Thornton 05v2.5_branch cd7f7d6 06linuxcnc 10docs/src/hal/basic_hal.txt Docs: fix spello * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd7f7d6
[13:34:18] <jthornton> it's Chris's fault he makes me work without a safety net and have the auto spell checker turned off LOL
[13:39:46] <pcw_home> thats pretty harsh
[13:47:48] <cradek> who me?
[13:55:13] <cradek> micges: before you try merging artek's jerk limiting, be sure to test and see if it works. last I knew (last he communicated on our lists), it absolutely did not work
[14:02:19] <andypugh> Was it seb_kuzminsky or cradek who was experimenting with a model gantry at Wichita?
[14:03:02] <andypugh> Someone on the forum (after a bit of a prod) is xperimenting with having the loints wait for each other:
http://linuxcnc.org/index.php/english/forum/49-basic-configuration/27724-homing-a-dual-motor-for-one-axis-gantry-machine#45970
[14:03:39] <cradek> micges:
http://thread.gmane.org/gmane.linux.distributions.emc.devel/6364
[14:03:46] <andypugh> However, he is deliberately not worrying about encoder index as he only wants to solve his own problem.
[14:03:49] <cradek> andypugh: that was me
[14:04:43] <andypugh> It will be interesting to see how it works out.
[14:04:48] <cradek> andypugh: waiting at each homing stage for all the others who share the same home sequence seems like a fine way to do it
[14:05:18] <cradek> andypugh: my only problem was I couldn't manage to get the code right - but that doesn't mean it's hard for someone else, heh.
[14:05:45] <cradek> there's nothing special about index step, it's just some more stages
[14:05:59] <andypugh> More likely you saw what might break, and he hasn’t spotted the problems.
[14:06:24] <andypugh> Index gets more complicated if the indexes don’t line up.
[14:06:46] <andypugh> (but that seems a fairly pathalogical way to build a gantry)
[14:06:55] <cradek> well I don't care about that - they should line up.
[14:07:13] <pcw_home> Yeah fix your friggin index
[14:07:36] <cradek> no reason to make the problem as hard as possible right at the start... :-/
[14:07:50] <cradek> andypugh: what happened to your ' ?
[14:08:31] <cradek> has anyone (here) tried to merge ja4 and cba-rc3?
[14:09:46] <andypugh> cba?
[14:10:02] <cradek> andypugh: circular-blend-whatever
[14:10:17] <cradek> andypugh: my aborted attempt from fest:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/synchronized-homing
[14:10:52] <andypugh> I think that someone somewhere else has merged the two.
[14:10:57] <cradek> if nothing else, 2e3764aea might be useful to him (reading config-file boilerplate)
[14:12:45] <cradek> the actual synchronization code is probably just the wrong approach - I was trying to make it minimally-invasive (not put a bunch of crap in each state)
[14:15:40] <andypugh> Minimally-invasive doesn’t always mean “better”, though it does make testing easier, I reckon.
[14:16:15] <andypugh> I haven’t looked at how he did it. When he is happy with it, perhaps it could be a feature branch.
[14:30:43] <cradek> oh did he succeed already? that's great
[14:31:12] <cradek> I'd love to have that incorporated and would be happy to review (and maybe help improve) it
[14:32:08] <andypugh> He has a log of it working in sim, but I don’t know how complte it is.
[14:32:40] <cradek> I wonder if we could simulate all of index homing
[14:33:01] <cradek> we do/did have sim servos
[14:36:44] <micges> cradek: I've tested branch from git and it works very well
[14:37:11] <cradek> that's great
[14:37:17] <cradek> I'm glad to hear he finished it
[14:38:31] <micges> hard to tell which commit is last of jerk work but I'll figure it out
[14:41:14] <micges> pcw_home: about 7i76e: can I set led pointer to communication error flag?
[14:41:36] <MrHindsight> whats the install procedure for 14.04? do the 12.04 repos work as is on 14.04?
[14:42:12] <MrHindsight> pcw_home: how did you try it out on the new Intel boards?
[14:47:18] <pcw_home> micges yes
[14:48:28] <pcw_home> MrHindsight: theres some Tk tomfoolery needed for 14.04 that I think was recently added to master
[14:48:29] <micges> pcw_home: it could be 8 leds for testing ;)
[14:48:47] <pcw_home> I think there are only 4 :-(
[14:49:20] <pcw_home> Ill try and find the address
[14:54:20] <MrHindsight> the 12.04 livecd won't even load on the E350M1
[14:54:52] <MrHindsight> going to try updating the 10.04 install to 12.04
[14:55:01] <pcw_home> 12.04 works fine for me with RTAI and Preemt-RT on J1800 MB
[14:55:29] <micges> pcw_home: no need, I found it
[14:55:33] <pcw_home> though i only tried the 2.6.32 RTAI kernel
[14:56:06] <MrHindsight> we need the 3.4 kernel or newer to get the new drivers to work
[14:56:58] <pcw_home> 3.12 and 3.14 preemt-RT kernels work also
[15:01:52] <pcw_home> micges: its in the manual I think
[15:01:53] <pcw_home> I also have some debug code to allows use of one hostmot2 port as a 24 bit debug I/O
[15:02:26] <pcw_home> leddbgptr is space 6 only
[15:03:31] <pcw_home> lwi mem6
[15:03:32] <pcw_home> sta temp0
[15:03:34] <pcw_home> lwi 01Fh
[15:03:35] <pcw_home> and leddebugptr
[15:03:37] <pcw_home> ashr
[15:03:38] <pcw_home> add temp0
[15:03:40] <pcw_home> sta t
[15:06:35] <MrHindsight> 12.04 upgrade in progress
[15:07:26] <MrHindsight> I'll try a fresh 14.04 install after this succeeds or fails
[16:30:50] <KGB-linuxcnc> 03Francis Tisserant 052.6 58b53b1 06linuxcnc 10docs/src/config/ini_config_fr.txt 10docs/src/config/linuxcnc2hal_fr.txt 10docs/src/gcode/m-code_fr.txt 10docs/src/gcode/overview_fr.txt French doc: add missing descriptions around M19 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58b53b1
[17:28:52] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 951ad51 06linuxcnc 10docs/src/hal/basic_hal.txt 10docs/src/hal/basic_hal_fr.txt French doc: add info about the direction arrow requirements * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=951ad51
[18:30:03] <memleak> mhaberler is getting his feet wet with RTAI now