#linuxcnc-devel | Logs for 2013-11-08

Back
[00:35:34] <cmorley> IchGuckLive: PNCconf supports backlash compensation. It's on the axis configuration page. Select the checkbox and set the value. Have you done that and it did not work?
[09:55:08] <seb_kuzminsky> marius alksnys reports on emc-developers that 5-axis tlo doesnt work, but i thought it did? looks like motion at least contains a full EmcPose for tool offset
[09:57:38] <cradek> people can mean different things when they talk about that
[09:58:01] <cradek> you're right that there can be a tool offset on any axis
[09:58:21] <cradek> but what people often want is a tool offset that points in the direction of the tool (which on a 5 axis machine isn't always along Z)
[09:58:51] <cradek> I've done that by using kins to put a virtual W axis along the tool vector, and putting the TLO along the W axis
[10:04:56] <KGB-linuxcnc> 03seb 05master 7f29445 06linuxcnc 10docs/ 10(7 files in 5 dirs) * docs: rebrand wiki links
[10:04:56] <KGB-linuxcnc> 03seb 05master 0201b15 06linuxcnc 10docs/ 10src/config/ini_config.txt 10src/gcode/gcode.txt 10src/gui/gladevcp.txt * Merge branch 'v2.5_branch'
[10:04:59] <KGB-linuxcnc> 03seb 05v2.5_branch 7f29445 06linuxcnc 10docs/ 10(7 files in 5 dirs) * docs: rebrand wiki links
[10:05:47] <seb_kuzminsky> i think i understand that, thanks
[10:16:00] <linuxcnc-build> build #1467 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1467 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:17:51] <linuxcnc-build> build #1467 of hardy-i386-sim is complete: Failure [4failed git] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1467 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:43:08] <seb_kuzminsky> ffs
[10:49:20] <seb_kuzminsky> those buildslaves took more than 10 minutes to copy the git repo from one local dir on the buildslave VM to another, so it timed out :-/
[10:49:59] <linuxcnc-build> build #1469 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1469 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:52:05] <seb_kuzminsky> i'll bump it up to 20 minutes
[10:52:26] <seb_kuzminsky> the real fix is probably to give all the buildslaves more ram, and do the builds on ramdisks
[10:52:37] <seb_kuzminsky> but i've already maxed out the vm host
[10:58:01] <cradek> I wish you could use something like chroot instead of VMs. they're so wasteful and horrible to maintain
[10:58:09] <jepler> can you explain to buildbot that the buildslaves are actually VMs on the same host and to not use so much of the apparently parallelism?
[11:00:16] <linuxcnc-build> build #1468 of hardy-i386-sim is complete: Failure [4failed git] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1468 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:32:19] <micges> seb_kuzminsky: hi
[11:32:58] <micges> seb_kuzminsky: any fixes or improves should go to ja4 or ja3 branch?
[11:33:28] <skunkworks> micges, any progress on the 7i80
[11:34:07] <micges> not really
[11:34:25] <skunkworks> heh
[11:34:41] <micges> but I managed to understand sserial code and I know how to make sserial over eth work
[11:34:50] <skunkworks> cool
[11:36:30] <skunkworks> micges, this is from sebs email
[11:36:30] <skunkworks> I just pushed joints_axes4. Please stop using joints_axes3, use
[11:36:31] <skunkworks> joints_axes4 instead. Please don't merge anything into joints_axes4.
[11:38:01] <micges> skunkworks: is this mail list mail?
[11:38:10] <skunkworks> yes
[11:38:15] <micges> ok
[11:39:22] <linuxcnc-build> build #1470 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1470 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:40:15] <skunkworks> micges, http://article.gmane.org/gmane.linux.distributions.emc.devel/11266/match=joints_axes4
[11:40:53] <micges> thanks, got it
[12:40:29] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch checkin
[12:40:30] <linuxcnc-build> build #1471 forced
[12:40:31] <linuxcnc-build> I'll give a shout when the build finishes
[12:41:02] <seb_kuzminsky> micges: i rebased ja3 onto the tip of master a little while ago, i called the new rebased branch 'joints_axes4', please do any future work on that branch instead of ja3
[12:41:28] <micges> ok
[12:41:37] <seb_kuzminsky> there was a bug report on emc-developers recently about accel not being handled right
[12:42:16] <seb_kuzminsky> also, jogwheel support is still missing i think
[12:42:41] <seb_kuzminsky> there's a list of ja issues on the wiki, item 4: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6
[12:43:45] <micges> seb_kuzminsky: I've got another bug report that gentrivkins doesn't work in ja4
[12:44:20] <micges> but it should, all my machines on ja3 runs with it
[12:46:07] <seb_kuzminsky> strange
[12:46:08] <micges> and I've reproduce it
[12:46:37] <seb_kuzminsky> you've reproduced the bug that gentrivkins doesnt work in ja4, but you know it works in ja3?
[12:47:02] <seb_kuzminsky> if so, maybe i broke something during the rebase, but i tried to be careful and check the result for differences, and i didnt see anything like that
[12:47:20] <seb_kuzminsky> bbl, thanks for your work on ja*!
[13:02:11] <micges> it worked on ja3 two years ago but doesn't work now on ja3
[13:02:24] <micges> i'm testing ja4 now
[13:20:43] <jthornton> test this axis in the stepconf wizard has a default test area of +-15" for an inch configuration and +-0.5mm for a millimeter configuration.
[13:21:45] <jthornton> a safer default for the inch configuration could be +-0.5" for inch and +-15mm for metric
[13:22:05] <jthornton> so I think they are reversed somehow...
[13:27:33] <jthornton> perhaps line 2231 and 2245 are reversed in stepconf.py?
[14:00:37] <linuxcnc-build> Hey! build checkin #1471 is complete: Success [3build successful]
[14:00:37] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1471
[14:03:51] <cradek> jthornton: if they're obviously wrong just fix 'em
[14:52:19] <seb_kuzminsky> linuxcnc-build: force build --branch=master checkin
[14:52:20] <linuxcnc-build> build forced [ETA 1h20m06s]
[14:52:20] <linuxcnc-build> I'll give a shout when the build finishes
[15:31:14] <kwallace> Hello. I have a python probing routine that puts out mdi commands. This works well except the commands fill the buffer then proceed to the python code that reads the status register for the probed location, but the probing is still in process. To fix this, I added a loop that polls the status of the 'probing' register which loops until the probing is TRUE, then again until it goes FALSE. Then I read the location.
[15:32:27] <kwallace> This works for the hardware configuration, but not for the sim. The sim version won't let me switch screens or trigger the probe with my button.
[15:33:07] <kwallace> Is there a better way to wait for G38 to finish before reading the location?
[15:35:03] <micges> if you have in sim button that works like probe input with hardware, then it should work
[15:35:35] <micges> can you see motion.probe-input changing in sim while you hitting button?
[15:39:14] <kwallace> I also have a routine that probes a corner and sets the origin with G10. This doesn't need to return a value, so there is no looping. This routine works both ways, so I'm pretty sure the probe button works.
[15:40:12] <kwallace> Here is the code so far: http://wallacecompany.com/tmp/find_x_plus.py
[15:41:09] <kwallace> The loops seem to block everything until the count runs out.
[15:57:24] <linuxcnc-build> Hey! build checkin #1472 is complete: Success [3build successful]
[15:57:24] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1472
[17:28:41] <memleak> Are there any plans to use python 3 as the default for linuxcnc? python 3.2 is pretty stable now.
[22:20:01] <KGB-linuxcnc> 03micges 05master c45d05f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c * hm2: reads from hostmot2 area should be always 32 bit