Back
[00:06:21] <KGB-linuxcnc> 03Jeff Epler 05ja4-onto-cba4 a30d344 06linuxcnc 10src/emc/usr_intf/halui.cc Fix pin_new already-initialized errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a30d344
[00:06:22] <KGB-linuxcnc> 03Andy Pugh 05ja4-onto-cba4 31b7573 06linuxcnc 03scripts/update_ini Add a script to convert configurations to the joints_axes format. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=31b7573
[00:06:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja4-onto-cba4 54bf0c0 06linuxcnc 10configs/sim/axis/vismach/puma/puma560.ini 10configs/sim/axis/vismach/puma/puma560_sim_6.hal puma560: make the config load under ja * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=54bf0c0
[00:06:24] <KGB-linuxcnc> 03Andy Pugh 05ja4-onto-cba4 0e4b353 06linuxcnc 10scripts/update_ini Add dialog and force options to the update_ini script to make it more suited * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e4b353
[00:06:28] <KGB-linuxcnc> 03andypugh 05ja4-onto-cba4 5df4cf3 06linuxcnc 10scripts/linuxcnc.in 10scripts/update_ini Arrange for the linuxcnc launch script to prompt to auto-convert non JA configs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5df4cf3
[00:06:52] <cradek> sorry andy, fixed
[00:07:28] <cradek> looks like the runtests will need a bit of a massage so they don't try to pop up the dialog
[00:07:42] <cradek> but that's for tomorrow.
[00:07:45] <cradek> goodnight
[00:19:17] <linuxcnc-build> build #257 of 1401.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/257 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:19:56] <linuxcnc-build> build #256 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/256 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:34:59] <linuxcnc-build> build #2101 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2101 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:35:15] <linuxcnc-build> build #2099 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2099 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:35:32] <linuxcnc-build> build #2100 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2100 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:36:16] <linuxcnc-build> build #2101 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2101 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:36:23] <linuxcnc-build> build #1303 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1303 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:40:08] <linuxcnc-build> build #2102 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2102 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[00:40:08] <linuxcnc-build> build #2103 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2103 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, andypugh <andy@bodgesoc.org>, Andy Pugh <andy@bodgesoc.org>
[09:27:58] <skunkworks_> cradek: with the new script from andy - the config converted and worked! Yay thanks
[09:52:21] <skunkworks_> cradek:
http://electronicsam.com/images/KandT/testing/ja4-cba4/Screenshot%20from%202014-05-24%2009:32:04.png
[09:53:30] <cradek> awesome. does the tp work right?
[09:54:33] <skunkworks_> hmm - no.. z axis has a velocity limit of 8.3333
[09:55:09] <cradek> hmm
[09:55:30] <cradek> I'm leaving for a few hours but will help troubleshoot later
[09:56:09] <cradek> is the 8.333 in the axis or joint ini section?
[09:56:53] <cradek> you might want it in both?? not sure how it works, maybe andy would know better
[10:26:19] <skunkworks_> logger[psha]:
[10:26:20] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-24.html
[10:28:50] <skunkworks_> I said and it was lost
[10:28:55] <skunkworks_> yes - it seems to be the homing velocity isn't constrained by the joint limits...
[10:28:59] <skunkworks_> HOME_SEARCH_VEL = 8.330HOME_LATCH_VEL = 8.330
[10:29:06] <skunkworks_> fixed it.. That probably needs to be looked at
[10:29:08] <skunkworks_> maybe
[11:24:14] <skunkworks_> cradek: looks good
http://electronicsam.com/images/KandT/testing/ja4-cba4/Screenshot%20from%202014-05-24%2011:05:30.png
[12:25:24] <skunkworks_> feature by design? :)
[13:12:15] <cradek> skunkworks_: that is really terrific
[13:15:02] <skunkworks_> would there be a situation that you would want to home faster than the joint allows?
[13:15:09] <cradek> doubt it
[13:15:32] <cradek> just a bug I bet
[13:16:00] <cradek> if we want to get serious about merging this maybe we should have a bug tracker category
[13:16:20] <cradek> hm, or maybe just merge it as-is and use the regular categories
[13:16:36] <cradek> I'm working on fixing the runtests now
[13:16:37] <skunkworks_> yes yes - oh god yes!! :)
[13:16:41] <cradek> it looks easy
[13:17:17] <skunkworks_> there will be some freaking out.. but other than that...
[13:18:17] <cradek> skunkworks_: would you verify that joint vel/acc limits work for continuous and incremental jogs in joint mode, and axis vel/acc limits work for continuous and incremental jogs in world mode
[13:19:08] <skunkworks_> let me see
[13:33:21] <skunkworks_> cradek: 9axis sim all seems correct in world mode. (no kins so I will have to make a config that works with something like rdelta)
[13:33:38] <skunkworks_> with the velocity/acc readouts
[13:33:58] <cradek> rdelta is the only nontrivial one I've personally run
[13:35:14] <skunkworks_> I probably won't happen today..
[13:35:54] <cradek> no problem, thanks for helping
[13:36:04] <cradek> we already have a halui-jogging runtest - maybe that could automate the test
[13:36:12] <cradek> I'm not sure if halui can switch between joint and world mode
[13:36:51] <skunkworks_> this looks good though
[13:36:53] <skunkworks_> http://electronicsam.com/images/KandT/testing/ja4-cba4/Screenshot%20from%202014-05-24%2013:17:36.png
[13:37:16] <skunkworks_> the only issue so far with andys script is it doesn't seem to convert locking pins.
[13:37:26] <cradek> this is jogging with trivkins?
[13:37:31] <skunkworks_> right
[13:37:56] <skunkworks_> so joints = axis I assume
[13:37:57] <cradek> did you set max vel/acc in both the joints and axes sections?
[13:38:04] <skunkworks_> yes
[13:38:07] <cradek> I wonder which it uses...
[13:38:15] <skunkworks_> (well - andys script seems to do that)
[13:38:30] <skunkworks_> good question
[13:38:50] <cradek> I guess that feels right for a trivkins machine
[13:39:19] <cradek> we could be smarter about reading the ini, if trivkins, and not require duplicate settings
[13:39:55] <skunkworks_> trivkins uses joint....
[13:40:19] <skunkworks_> (I changed the [axis_x] section and it used the joint limits
[13:40:39] <cradek> for jogging?
[13:41:05] <cradek> I guess that's expected because trivkins jogs in free mode
[13:44:05] <skunkworks_> hmm - then does it use axis for running gcode?
[13:45:12] <skunkworks_> it does. interesting
[13:46:09] <skunkworks_> so - joints limits for jogging - axis limits for gcode.
[13:46:13] <skunkworks_> for trivkins
[13:46:32] <cradek> that is totally correct, but might not be what people expect
[13:46:38] <skunkworks_> right
[13:46:50] <skunkworks_> but for most people - joint=axis... \
[13:47:03] <cradek> we could easily change it to load one set of values into both places, if trivkins
[13:47:04] <skunkworks_> * a lot of people
[13:48:47] <KGB-linuxcnc> 03Chris Radek 05ja4-onto-cba4 36a1269 06linuxcnc 10(10 files in 10 dirs) These were manually converted; avoid the autoconvert which requires $DISPLAY * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=36a1269
[13:49:05] <cradek> that oughta fix the runtests
[13:53:30] <skunkworks_> it doesn't seem that much more confusing.. :)
[14:11:22] <cradek> yay, runtests are passing
[14:45:38] <agwn> anyone successfully using hm2 doing read operations in two different threads (high speed and low)?
[14:46:37] <agwn> i am running a 2kHz servo thread that is doing read/write and a 25hz thread that should be doing uart i/o
[14:47:46] <agwn> if i addf the device *.read and the *.uart.0.recieve both i get stack smashing
[14:48:04] <cradek> what do you see?
[14:51:13] <agwn> either machine grinds to a halt and ui is non responsive or "stack smashing detected" followed by backtrace and mem dump
[14:52:05] <cradek> pastebin your output?
[15:03:16] <agwn> http://pastebin.com/krRnu2nV
[15:05:27] <cradek> what platform, kernel, and source is this?
[15:07:26] <seb_kuzminsky> agwn: calling the same function from multiple threads is an unusual use case, and any functions used that way need to be written specially, carefully to support it
[15:07:35] <seb_kuzminsky> hm2 functions are not written that way
[15:08:06] <seb_kuzminsky> since you're using a 2 kHz servo thread i assume you're using one of the pci anyio boards, is that right?
[15:08:17] <agwn> i guessed that. looked into both components and saw calls to llio->read.
[15:08:21] <agwn> ethernet anyio
[15:08:35] <seb_kuzminsky> if so, there's a couple of extra functions available, read_gpio and write_gpio
[15:09:06] <seb_kuzminsky> if all you need is twiddling gpio bits, those may work for you (they can be run in a separate thread from the regular .read and .write functions)
[15:09:09] <agwn> looking at the calls nothing to make them reentrant.
[15:09:24] <seb_kuzminsky> yeah, they're not reentrant
[15:10:18] <agwn> the slow component is a derivative of mesa_uart. it is not reading the values if not added to a thread.
[15:10:26] <seb_kuzminsky> i'm not familiar with the ethernet hm2 stuff
[15:12:07] <seb_kuzminsky> the llio driver for the ethernet anyio board (hm2_eth?) should set the llio.threadsafe flag True or False when it calls hm2_register
[15:12:27] <cradek> can't you just run everything in the fast thread, but have your uart component do nothing for 79/80ths of its invocations?
[15:13:01] <cradek> (2000/25)
[15:13:37] <agwn> have been looking at that. am going through different configs and just isolated the problem to enabling both read operations
[15:14:19] <agwn> started in single thread. then split when having problems. though it might be overloading the system with "slow" uart operations in the fast thread
[15:15:01] <agwn> now that i have a better handle on what is happening will try all in fast thread again.
[15:15:43] <seb_kuzminsky> if the llio driver sets llio.threadsafe to True, that means the llio author believes you can do reads and writes frm multiple threads
[15:16:47] <seb_kuzminsky> you can see if you're overwhelming your threads with 'halcmd show thread'
[15:16:48] <agwn> doesnt look like it is being set. see it for hm2_pci and hm2_test but no others...
[15:17:06] <seb_kuzminsky> if the max-time is near your thread period you're in trouble
[15:17:14] <seb_kuzminsky> the max-time should be much smaller than the period
[15:17:28] <seb_kuzminsky> was it micges that wrote hm2_eth?
[15:18:17] <agwn> yep
[15:19:23] <seb_kuzminsky> which branch/repo is it in?
[15:22:14] <agwn> i am branched from ubc3-7i80 from git.linuxcnc.org
[15:23:09] <agwn> in working branch minor changes no dev on core components
[15:26:14] <agwn> stripped my hal file down to minimal and moved it back to the high speed thread. seems to be running now to add back in the other functionality.
[15:27:18] <agwn> think i went to two threads trying to solve another problem, fixed it but introduced another. back in one thread with original issue fixed and system is happier.
[15:27:32] <seb_kuzminsky> great
[15:27:47] <seb_kuzminsky> ok cool, i'm out of here for a bit
[15:27:52] <agwn> thanks!
[15:35:16] <micges> agwn: hm2_eth is not supporting separate read_gpio/write_gpio atm
