Back
[06:38:06] <skunkworks> stupid question - if I wanted to run the ubc2 and test michaels 7i80 branch// How would I do that..
[06:50:28] <alex_joni> logger[psha]: bookmark
[06:50:29] <logger[psha]> alex_joni: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2013-08-19.html
[06:53:55] <skunkworks> how do I parce this into a git command...
[06:54:04] <skunkworks> https://github.com/mhaberler/linuxcnc/tree/ubc2-7i80-rtnet
[06:54:39] <skunkworks> git clone git://github.com/mhaberler/linuxcnc/tree/ubc2-7i80-rtnet
[06:54:39] <skunkworks> rtnetnew doesn't work :)
[06:55:13] <skunkworks> Hey alex
[06:55:27] <skunkworks> stella 1 year old today
[06:56:28] <skunkworks> mhaberler, hey - stupid question - how do I git your 7i80 branch from github?
[06:57:03] <skunkworks> git clone git://github.com/mhaberler/linuxcnc/tree/ubc2-7i80-rtnet rtnetnew doesn't work :)
[06:57:29] <mhaberler> git remote add github-mah
https://github.com/mhaberler/linuxcnc.git
[06:57:34] <mhaberler> git fetch github-mah
[06:57:54] <mhaberler> git checkout -b ubc2-7i80-rtnet github-mah/ubc2-7i80-rtnet
[06:58:00] <mhaberler> as per manpage ;)
[06:58:08] <skunkworks> heh - thanks
[06:58:15] <mhaberler> NB: untested
[07:00:59] <skunkworks> I am getting 'not a git repository .git
[07:04:48] <skunkworks> http://pastebin.ca/2434163
[07:07:12] <skunkworks> my google foo is failing me
[07:20:55] <mhaberler> you need to be within an existing linuxcnc dir to do that, just cd into it
[07:21:11] <mhaberler> you get a new remote and can check out that branch, the other ones wont be touched
[07:21:19] <mhaberler> so
[07:21:35] <mhaberler> cd linuxcnc-dev # or whatever it's called
[07:21:40] <mhaberler> git remote add github-mah
https://github.com/mhaberler/linuxcnc.git
[07:21:47] <mhaberler> … yadayada..
[07:32:26] <skunkworks> I need to git the ub2 first though - right?
[07:32:40] <mhaberler> no
[07:32:57] <mhaberler> a branch you pull is supposed to contain all you need
[08:57:19] <skunkworks> mhaberler, I think I got things going - but I am getting this error with halrun or halcmd...
http://pastebin.ca/2434193
[08:58:08] <mhaberler> to see debug, start realtime as 'DEBUG=5 realtime start'
[08:58:32] <mhaberler> but anyway I think micges needs to look into this, this is some net access issue, getting something similar here
[08:59:04] <mhaberler> did you configure syslog as per
http://static.mah.priv.at/public/UnifiedBuild.html
[08:59:14] <mhaberler> no point in even trying without that
[09:04:12] <skunkworks> I will prepare the logging
[09:05:03] <mhaberler> again, it is some networking issue, I will wait until micges had a look at it, it needs serious work anyway
[09:07:41] <skunkworks> well - this isn't loading realtime I think - isn't that unrelated to the ethernet stuff?
[09:07:53] <skunkworks> rtapi_app startup failed - aborting
[09:07:58] <mhaberler> 'this' ?
[09:08:20] <skunkworks> git checkout -b ubc2-7i80-rtnet github-mah/ubc2-7i80-rtnet
[09:08:35] <mhaberler> well read the patch, there is a start_net.sh script inserted in linuxcnc but you can run it manually beforehand
[09:09:16] <mhaberler> this is exactly as much documentation as I have ;)
[09:09:20] <mhaberler> bbl
[09:22:28] <skunkworks> I don't think we comunicated very well..
[09:28:38] <mozmck> skunkworks: stella is 1? good deal!
[09:29:05] <skunkworks> Yes - (well as of about 6:00pm today) ;)
[09:30:52] <mozmck> :) Our Ruth is about 18 months now, and we're about to start the clock on another any day. (Internal oscillator's been working great for a while already)
[09:31:12] <skunkworks> http://www.electronicsam.com/images/house/redwagan.JPG
[09:31:31] <skunkworks> heh
[09:35:44] <mozmck> Looks like the wagon shrank!
[09:36:49] * archivist checks the books on the shelf behind
[09:38:14] <skunkworks> this is a comuity center or whatever it is called
[09:38:32] <skunkworks> community \
[09:42:03] <skunkworks> (you can tell by the industrial carpeting..)
[10:07:51] <skunkworks> well - I can build and run the rtos-master-v0 version here (with or without patch) but the second I pull the 7i80 stuff from mhaubler - realtime won't start. (for the 7i80)
[10:08:04] <skunkworks> * here
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mesa7i80_Driver_For_Linuxcnc_On_Xenomai
[10:32:54] <skunkworks> heh - setuid. sorry
[10:33:02] <skunkworks> logging really helps :)
[11:01:42] <skunkworks> mhaberler, I didn't do the setuid.. The logging told me so.. :)
[11:01:53] <mhaberler> ah.
[11:02:18] <skunkworks> It sort of works... Same issue as 10.04 - the config doesn't seem to be set - and I get encoder errors.
[11:02:32] <skunkworks> How do I set the debugging level when running halrun?
[11:02:52] <skunkworks> *halcmd
[11:02:52] <mhaberler> the same way: the DEBUG environment variable.
[11:03:23] <mhaberler> in halcmd, see 'log user <level>' or 'log rt <level>'
[11:03:46] <mhaberler> this applies instance-wide (i.e. all user HAL comps, and all rt comps)
[11:08:33] <pcw_home> encoder errors are probably meaningless in master (especiall with muxed encoders)
[11:12:46] <pcw_home> It is possible that the config parsing got broken ( a "halcmd show pin" should show what got enabled)
[11:18:31] <skunkworks> http://pastebin.ca/2434246
[11:22:12] <skunkworks> the watchdog bites pretty quick - although I don't know why as the thread time is under 1ms - around 600us
[11:24:18] <skunkworks> and the config issue is there - I tell it 0 everything and it still has encoders and such
[11:36:34] <pcw_home> yeah sounds like the config parsing is wrong
[13:08:56] <skunkworks> andypugh, did you see my email to the list?
[13:09:06] <andypugh> I did.
[13:09:34] <andypugh> But I have so far been looking at JA3 velocity limits rather than 7i80
[13:09:42] <skunkworks> heh
[13:11:42] <skunkworks> andypugh, what is your project?
[13:12:48] <cradek> andypugh's project is dealing with a user who keeps insisting that someone should have implemented what he wants by now
[13:12:49] <andypugh> My project is trying to be too helpful on the Forum.
[13:13:07] <skunkworks> ahhhh
[13:14:35] <andypugh> I might not be stressing hard enough that there is a fundamamental limit on his machine, and even with adaptive velocities that limit would be there.
[13:15:34] <andypugh> I think what might work for him would be a feed-override pin output from 5axiskins. But whether that would work for jogging too depends on how he is jogging.
[13:16:39] <archivist> and that last 10% he thinks he is missing out on, may only effect 1% of total runtime.....a waste of effort
[13:18:00] <andypugh> Well, to be fair, I can see his point that having it take minutes to jog C from +180 to -180 will be boring.
[13:18:35] <andypugh> But let's see how he responds to my suggestion of dropping into joint mode for fast jogs.
[13:19:13] <skunkworks> great - so back to the 7i80 then :)
[13:19:35] <andypugh> cradek: On an unrelated note, do you have any guesses why the vismach model of the 5axiskins wouldn't work in JA3?
[13:19:50] <cradek> can you give me anything to go on?
[13:21:12] <andypugh> http://pastebin.com/9WFDYrSM ?
[13:22:16] <cradek> ok yes, the tuple index is out of range
[13:22:45] <andypugh> Ah! Of course! Why didn't I think of that :-)
[13:23:23] <cradek> sorry, the backtrace doesn't mean much to me.
[13:23:23] <jepler> it's my fault; I recently broke it
[13:23:23] <cradek> orly
[13:23:23] <skunkworks> heh. wait - is that sarcasmthe tuple?
[13:23:27] <jepler> vismach.py line 185 apparently should read 'if args and isinstance...'
[13:23:28] <skunkworks> what?
[13:23:32] <andypugh> Ah, so not my config, it is just broken in JA3?
[13:24:14] <jepler> I changed the __init__ of some base classes in vismach recently, I think that is part of what cradek pushed to ja3 with his rotary delta visualization
[13:24:37] <cradek> teamwork!
[13:25:01] <cradek> but to be fair, it still works for me
[13:25:33] <andypugh> the rotarydelta vismach works for me, but not the 5axiskins one.
[13:25:50] <jepler> can one of you test with my suggested change? It's inconvenient for me right now
[13:26:15] <andypugh> I am wondering if it is related to the number of joints or axes (I have no real idea how Vismach interfaces to the rest of the system)
[13:27:06] <jepler> no
[13:27:27] <andypugh> Can you give me a clue where vismach.py lives?
[13:27:32] <jepler> lib/python/vismach.py
[13:27:34] <jepler> not inside src/
[13:31:16] <andypugh> It's like magic!
[13:31:23] <andypugh> Yes, that seems to fix it
[13:31:52] <jepler> great
[13:31:56] <jepler> thanks for testing
[13:32:03] <jepler> now if one of you is kind enough to push it..
[13:32:50] * skunkworks wonders if this is jeplers new programming method...
[13:33:43] <jepler> the change message should basically say that the earlier change to CoordsBase failed to account for subclasses which in fact had no arguments in their constructor
[13:33:57] <andypugh> I am working on a VM on my Mac. (Which has no ssh keys) so it will have to wait until a bit later.
[13:34:04] <jepler> OK
[13:35:03] <skunkworks> pcw_home, is there a way to know why a watchdog bit?
[13:35:22] <jepler> I think I can push it soon
[13:37:57] <jepler> Your branch is behind 'origin/joints_axes3' by 4940 commits, and can be fast-forwarded.
[13:38:04] <jepler> this must be a seriously old clone
[13:41:28] <andypugh> That's more like a crone than a clone!
[13:43:57] * jepler groans
[13:43:57] <jepler> cradek: which is a good inifile to look at? I need to update my axis_rostock.ini for ja3
[13:43:57] <pcw_home> skunkworks: well only the obvious, it wasn't serviced in time
[13:44:01] <memleak> or just reset one too many heads..
[13:44:35] <cradek> I've been using sim/axis/rdelta.ini which has all the needed bits
[13:45:01] <skunkworks> hmm - I am not seeing over 600us for the tmax on the servo thread
[13:45:02] <cradek> I think it's suitably the same in joints_axes3 and upside-down and you can work from either
[13:45:26] <pcw_home> you could set the watchdog to a ridiculous time (say 5 seconds) and if it bites
[13:45:28] <pcw_home> in 5 seconds it was initialized but not being serviced
[13:52:25] <skunkworks> heh - I put this harddrive and nic in a different system for testing and it hard locks after a bit.
[13:52:36] <skunkworks> switching back
[13:56:44] <jepler> hmph, my inifile(?) makes linuxcnc crash
[13:56:52] <jepler> task generates a backtrace but it's not useful
[13:58:03] <andypugh> I think I got that yesterday.
[13:58:37] <andypugh> But I blamed me.
[13:58:46] <cradek> can jepler also blame you?
[13:58:53] <andypugh> Why not?
[14:03:33] <skunkworks> pcw_home, even 5 seconds there is a bite
[14:05:43] <pcw_home> at 5 seconds?
[14:06:02] <skunkworks> 5000000000
[14:06:26] <pcw_home> What i am asking is did it bite at ~5 seconds
[14:08:18] <skunkworks> hmm
[14:08:37] <skunkworks> I think it was random - some times right away some times at 5 seconds
[14:08:43] <skunkworks> I could set it even longer
[14:10:00] <skunkworks> it seems to be pretty instantanious
[14:10:27] <skunkworks> (I set it to 50 seconds and it bits pretty quick
[14:10:46] <pcw_home> Sounds like its not setup
[14:12:35] <skunkworks> ah - so the time out isn't getting set
[14:13:13] <skunkworks> it shows in 'show' that it is set - but maybe not getting to the board?
[14:15:29] <skunkworks> I can toggle a gpio..
[14:15:32] <pcw_home> yes probably not etherized yet
[14:17:08] <pcw_home> Even if all this worked, theres still work to do (find/fix all conditional/polls, change to 2 packet mode, add DPLL timer)
[14:17:35] <skunkworks> minor issues...
[14:17:37] <skunkworks> ;)
[14:18:49] <pcw_home> DPLL will be a big improvement for PCI/EPP configs as well (no polling for done on SSI/FAbs/BISS/SPI interfaces)
[14:19:44] <pcw_home> stepgen and encoder counts captured in hardware
[14:28:31] <pcw_home> with < 100 ns jitter
[14:29:54] <skunkworks> cool
[14:38:20] <KGB-linuxcnc> 03jepler 05joints_axes3 66e0696 06linuxcnc 10lib/python/vismach.py * vismach: Fix HalToolCylinder
[14:38:20] <KGB-linuxcnc> 03jepler 05joints_axes3 a1e5c21 06linuxcnc 10src/rtapi/rtapi_math.h * rtapi_math: ensure that isfinite() is available
[14:38:22] <KGB-linuxcnc> 03jepler 05joints_axes3 aeb2da2 06linuxcnc 10src/emc/motion/command.c * motion: treat a point as out of range when it it is not finite
[14:38:29] <KGB-linuxcnc> 03jepler 05joints_axes3 9922cbc 06linuxcnc 10src/emc/ 10motion/command.c 10motion/control.c * motion: check for kinematicsInverse failures
[14:38:36] <KGB-linuxcnc> 03jepler 05joints_axes3 f2126b2 06linuxcnc 10(6 files in 3 dirs) * kins: Implement linear delta kinematics
[14:38:42] <KGB-linuxcnc> 03jepler 05joints_axes3 ecd64fe 06linuxcnc 10src/hal/ 10user_comps/vismach/Submakefile 03user_comps/vismach/lineardelta.py * vismach: Linear delta visualization
[14:38:49] <KGB-linuxcnc> 03jepler 05joints_axes3 5a9848b 06linuxcnc 10configs/ 03sim/axis/ldelta.ini 03sim/axis/sim_ldelta.hal * sample-configs: sim linear delta configuration
[14:38:54] <jepler> opa!
[14:40:06] <cradek> oh hey
[14:50:50] <jepler> I ended up with a fairly weird little work volume but *shrug*
[14:55:26] <linuxcnc-build> build #1281 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1281 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:56:57] <jepler> doh
[14:56:59] <KGB-linuxcnc> 03jepler 05joints_axes3 6a281a6 06linuxcnc 10src/rtapi/rtapi_math.h * rtapi_math: fix isfinite implementation for pre-4.4 gcc
[15:11:43] <cradek> Linear move on line 0 would exceed Z's positive limit
[15:11:43] <cradek> Linear move on line 0 fails kinematicsInverse
[15:11:49] <cradek> slick
[15:12:41] <cradek> kins support is so much less bad than it ever has been
[15:20:44] <cradek> my kins sure can trigger all of those...
[15:20:55] <KGB-linuxcnc> 03jepler 05upside-down 66e0696 06linuxcnc 10lib/python/vismach.py * vismach: Fix HalToolCylinder
[15:20:55] <KGB-linuxcnc> 03jepler 05upside-down a1e5c21 06linuxcnc 10src/rtapi/rtapi_math.h * rtapi_math: ensure that isfinite() is available
[15:20:57] <KGB-linuxcnc> 03jepler 05upside-down aeb2da2 06linuxcnc 10src/emc/motion/command.c * motion: treat a point as out of range when it it is not finite
[15:21:04] <KGB-linuxcnc> 03jepler 05upside-down 9922cbc 06linuxcnc 10src/emc/ 10motion/command.c 10motion/control.c * motion: check for kinematicsInverse failures
[15:21:11] <KGB-linuxcnc> 03jepler 05upside-down f2126b2 06linuxcnc 10(6 files in 3 dirs) * kins: Implement linear delta kinematics
[15:21:17] <KGB-linuxcnc> 03jepler 05upside-down ecd64fe 06linuxcnc 10src/hal/ 10user_comps/vismach/Submakefile 03user_comps/vismach/lineardelta.py * vismach: Linear delta visualization
[15:21:24] <KGB-linuxcnc> 03jepler 05upside-down 5a9848b 06linuxcnc 10configs/ 03sim/axis/ldelta.ini 03sim/axis/sim_ldelta.hal * sample-configs: sim linear delta configuration
[15:21:24] <cradek> KGB-linuxcnc: I wish you didn't do that
[15:21:31] <KGB-linuxcnc> 03chris 05upside-down 21ec746 06linuxcnc 10configs/sim/axis/rdelta.ini 10configs/sim/axis/sim_rdelta.hal 10src/emc/kinematics/rotarydeltakins-common.h 10src/hal/user_comps/vismach/rotarydelta.py * Upside-down delta configuration
[15:21:39] <KGB-linuxcnc> 03chris 05upside-down 0c1d107 06linuxcnc 10configs/sim/axis/rdelta.ini 10src/hal/user_comps/vismach/rotarydelta.py * Represent rotaries more precisely
[15:21:46] <KGB-linuxcnc> cradek: My master told me to not respond.
[15:32:39] <linuxcnc-build> build #1279 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1279 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:59:15] <memleak> people still use pre 4.4 gcc releases?
[15:59:55] <memleak> even slackware updated.
[16:03:33] <jepler> memleak: the beloved Ubuntu 8.04...
[16:04:05] <jepler> "hard of hearing" or whatever it's called
[16:10:10] <memleak> :)
[17:17:59] <andypugh> Hmm, the ubc2-7i80-rtnet branch doesn't seem to work for a PCI Mesa card either.
[17:20:52] <andypugh> "rtapi_app 1651: caught signal 11 - dumping code"
[17:25:01] <jepler> fun times :-/
[17:29:53] <andypugh> Is "dumping core" (I miss-typed) a bad sign?
[17:30:16] <cradek> not necessarily; it means you're more likely to be able to find the bug
[17:37:53] <jepler> it means somewhere there should be a "core" file, which you can use with a debugger to examine the state of the program when it crashed
[17:38:08] <jepler> stack of active functions, variables (where not hopelessly obscured by the optimizer), etc
[17:38:50] <jepler> e.g., once you find out where 'core' is: gdb rtapi_app core
[17:39:25] <andypugh> sudo apt-get install gdb....
[17:41:01] <linuxcnc-build> build #1283 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1283 blamelist: dummy, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>
[17:41:11] <andypugh> Hmm, no, I can't figure out gdb by the power of intuition.
[17:41:33] <cradek> did you find the core?
[17:41:41] <andypugh> Yes.
[17:41:51] <cradek> go to that directory, then gdb /path/to/rtapi_app core
[17:42:01] <cradek> at the (gdb) prompt type bt
[17:42:35] <andypugh> not telling me very much.
[17:43:20] <cradek> it should be showing the site of the signal 11
[17:43:46] <jepler> you can pastebin it if you like
[17:45:10] <andypugh> I realised that I need to find rtapi_app first
[17:45:22] <andypugh> cd src
[17:46:30] <jepler> I think gdb finds the executable program from the $PATH
[17:48:37] <andypugh> http://pastebin.com/zJdeLfgt
[17:49:09] <andypugh> Possibly a config problem, maybe I built a sim version by mistake?
[17:49:31] <cradek> ok yeah, that's pretty bad
[17:49:52] <cradek> but it says signal 6? are you sure this is the right core?
[17:50:09] <cradek> "core file may not match specified executable" is another bad sign
[17:54:29] <andypugh> Interesting. I have a core and a scripts/core
[17:54:36] <andypugh> Both give the same output
[17:55:31] <andypugh> And they are the same size in bytes
[17:56:39] <cradek> I wonder if your build is inconsistent or something. maybe clean and rebuild?
[17:57:01] <andypugh> Just doing exactly that
[17:57:12] <cradek> sometimes certain kinds of errors do give useless backtraces, if an errant write nukes the stack. but yours looks sorta differently weird.
[17:59:13] <jepler> if you did a 'make' in the meantime that rebuilt rtapi_app that could lead to the non-matching warning
[17:59:54] <jepler> master does call read_strings. the rest is probably in libstdc++ / libc, for which you could install debugging symbols
[18:00:11] <jepler> thread apply all bt
[18:00:33] <jepler> the crash could have been in a different thread, this is only looking at the main thread (maybe)
[18:03:16] <andypugh> make -s is much more interesting, you get to see all sorts of interesting stuff
[18:12:23] <andypugh> OK, a clean make has a similar problem.
[18:12:50] <andypugh> It might not be sensible to get too caught up in this, as this is a strange branch (ubc2-7i80)
[18:14:35] <jepler> fair enough
[18:15:15] <andypugh> It is suspcious to me that the troublesome file is claiming to be sim_rtapi_app.cc
[18:22:07] <linuxcnc-build> build #1281 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1281 blamelist: dummy, Chris Radek <chris@timeguy.com>, Jeff Epler <jepler@unpythonic.net>
[18:43:18] <andypugh> The normal unified-build-candidate-2 works OK with hm2_pci, so it is a peculiarity of the 7i80 branch
[20:22:01] * skunkworks reads back
[20:22:08] <skunkworks> logger[mah]_:
[20:22:08] <logger[mah]_> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-08-20.html
