Back
[00:50:16] <seb_kuzminsky> sse was a bad idea and it should never have been invented
[00:50:21] <seb_kuzminsky> and we should all be using i386 still
[00:50:22] <seb_kuzminsky> the end
[02:27:15] <KGB-linuxcnc> 03Norbert Schechner 052.6 865f2bb 06linuxcnc 10lib/python/gladevcp/iconview.py gladevcp - iconview could create exception in some circumstances * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=865f2bb
[02:33:30] <KGB-linuxcnc> 03Norbert Schechner 052.6 96bb83c 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_5_4 - stay syncronized with iconview widget button states * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96bb83c
[02:34:07] <KGB-linuxcnc> 03Norbert Schechner 052.7 0e702bd 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e702bd
[02:34:56] <KGB-linuxcnc> 03Norbert Schechner 05master 9d7bb46 06linuxcnc 10docs/src/Submakefile Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d7bb46
[05:21:15] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja10 8a2f69d 06linuxcnc 10docs/man/man1/halui.1 halui.1 man page remove merge markers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a2f69d
[07:02:56] <skunkworks> seb_kuzminsky, ran over night 12598 ma
[07:02:58] <skunkworks> x
[07:59:26] <automata_> skunkworks: that is latency figures on servo thread in ns for the new 3.16.0 kernel
[07:59:58] <skunkworks> that is running the latency test from the rtai suite
[08:05:03] <jepler> seb_kuzminsky: I'd rather we'd always had amd64-style sse, with 16 flat registers for FP and SIMD ops, but I appreciate your frustration.
[08:45:15] <cradek> mozmck: never trust a comment. they only exist to trick you.
[08:47:06] <jepler> /* never trust a comment. they only exist to trick you */
[08:47:43] <cradek> perfect
[08:48:58] <mozmck> heh, I've figured that out! They were obviously put in while people were trying to learn the code at times.
[08:59:43] <mozmck> Here is a new diff against 2.7 that uses an ini setting for probe error inhibit.
[08:59:45] <mozmck> http://pastie.org/10618425
[09:11:20] <skunkworks> /* fix me */
[09:24:29] <cradek> mozmck: that looks great. Is there a spot where the default inside emcmotConfig should be set? I'm imagining the situation where no EMCMOT_SET_PROBE_ERR_INHIBIT at all is sent to motion (like with standalone-motion in the runtests), and the correct default should be set in that situation too
[09:29:06] <JT-Shop> I wish we had an ini option for do you really want to quit...
[09:30:42] <cradek> you mean for AXIS?
[09:31:03] <JT-Shop> yes
[09:31:34] <cradek> yeah I'd be happy to see that option too. the new question still takes me by surprise and never seems to benefit me
[09:32:09] <jepler> I know it was added with good intentions
[09:32:11] <cradek> I don't feel that way about all confirmations: the one about the axis already being homed is good, I think
[09:32:26] <jepler> at some point I saw a .axisrc snippet to paste in to make it stop
[09:32:26] <cradek> yes of course it was
[09:32:37] <JT-Shop> root_window.tk.call("wm","protocol",".","WM_DELETE_WINDOW","destroy .")
[09:32:47] <jepler> I should just put that in
[09:32:59] <jepler> since I usually run the sim config direct from git, I'd never have the inifile setting
[09:33:39] <jepler> JT-Shop: thanks
[09:33:53] <JT-Shop> thanks to dgarr who told me about it
[09:36:05] <cradek> mozmck: is JH in the variable name a typo?
[09:38:57] <JT-Shop> for me the do you really want to close should be optional and enabled in the ini
[09:39:03] <JT-Shop> off to town
[10:39:02] <cradek> wow, a touchscreen bounce caused part of andy's mill to explode. then he fixed it in hal.
[10:39:34] <skunkworks> ummm?
[10:39:47] <cradek> well not the exploded part. I assume he replaced that.
[10:39:52] <cradek> http://bodgesoc.blogspot.com/
[10:43:03] <skunkworks> Neat!
[11:16:21] <jepler> ugh all input devices suck
[11:16:26] <jepler> we should learn to do without them
[11:36:35] <jepler> so I'm trying to install fedora to check this guy's weird problem
[11:36:38] <jepler> configure is failing
[11:36:38] <jepler> configure:8229: g++ -o conftest -g -O2 -std=c++11 -I/usr/include/python2.7 conftest.cpp -lXinerama -lpython2.7 -lboost_python >&5
[11:36:42] <jepler> g++: internal compiler error: Killed (program cc1plus)
[11:37:00] <cradek> ouch
[11:41:32] <jepler> oh
[11:41:32] <jepler> [ 1035.098019] Out of memory: Kill process 6200 (cc1plus) score 844 or sacrifice child
[11:41:38] <jepler> virtual machine without enough memory
[11:45:57] <skunkworks> even a direct memory connection wouldn't work well for a machine interface.. My mind would wonder and I would crash the machine
[11:51:56] <jepler> hal/drivers/serport.comp: In function ‘read’:
[11:51:57] <jepler> hal/drivers/serport.comp:108:31: warning: comparison of constant ‘128’ with boolean expression is always false [-Wbool-compare]
[11:52:00] <jepler> pin_1_in_not = !(i & DCD) == DCD;
[11:52:01] <jepler> ooh this compiler diagnostic sure looks right
[11:52:04] <jepler> ^
[11:52:06] <jepler> hal/drivers/serport.comp:108:31: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
[11:52:11] <jepler> somebody should fix it
[12:05:06] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch 2914e95 06linuxcnc 10src/hal/drivers/serport.comp Fix pin-1-in-not * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2914e95
[12:05:06] <KGB-linuxcnc> 03Chris Radek 052.6 508ae41 06linuxcnc Merge branch 'v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=508ae41
[12:05:06] <KGB-linuxcnc> 03Chris Radek 052.7 6f1195e 06linuxcnc 10src/hal/drivers/serport.comp Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6f1195e
[12:05:07] <KGB-linuxcnc> 03Chris Radek 05master 00581f6 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=00581f6
[12:46:10] <mozmck> cradek: it might be good to set a default on the variable in emcmotConfig
[12:46:51] <mozmck> cradek: I put the JH in to indicate it only inhibits Jog and Home errors
[12:49:09] <cradek> oh right, I see
[12:49:48] <mozmck> Looks like it works well too.
[12:52:48] <cradek> I was wondering if people would want different combinations of inhibits (I recall people disliking these errors over the years), but I don't see that in the bugs or feature requests
[12:53:16] <mozmck> Yeah, so there is room for other ini settings if desired.
[12:53:51] <mozmck> There is a way to suppress the main errors already - I saw it in the code, but didn't follow to see how to activate that.
[12:54:16] <cradek> yeah I was wondering if each inhibit should be separate
[12:54:27] <cradek> the main errors are controlled by which probing gcode you use
[12:55:27] <mozmck> if (emcmotStatus->probe_type & 1), then there will be no probing error if the probe move finished without tripping
[12:55:38] <cradek> yeah that's based on the gcode
[12:55:45] <mozmck> oh, ok
[12:56:15] <cradek> http://www.linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38
[12:56:37] <mozmck> So you are thinking the jog err and home err inhibit should be separate ini settings?
[12:58:45] <cradek> I hate to expand your project, but I think that would future-proof your change, because it would be sad if we would end up with _JH_ and other combinations. what do you think?
[13:02:16] <cradek> or -- if you make the ini entry more generic-sounding, we just could add mask types 2 and 3 later if it comes up
[13:02:21] * cradek shrugs
[13:08:56] <ssi> https://www.groupon.com/deals/gg-hp-chromebox-pc-with-intel-celeron-2955u-cpu?utm_source=fac&utm_medium=cpc&utm_campaign=US_DT_SOM_FAC_TIM_TTT_RS_CBP_CH1_NBR_x%2Afb6035826474588
[13:09:09] <ssi> I wonder how those'd do running linuxcnc with an ethernet mesa card on the hardware port and a usb ethernet for lan
[13:18:50] <mozmck> cradek: I could have NO_PROBE_JOG_ERROR and NO_PROBE_HOMING_ERROR without much extra work. The only other error currently is probe tripped during MDI move.
[13:20:36] <cradek> I would be very happy with that
[13:44:03] <jepler> cradek: thank you for fixing that serport bug
[13:44:53] <jepler> ssi: a chromebox will be an increment more difficult to install a regular OS on
[13:45:02] <ssi> I don't really know anything about them
[13:46:42] <jepler> the default bootloader is a secure-boot type arrangement. you *can* enable a (more) standard bootloader though. The first resource I found is pertaining to arch linux, but anything up until you reach the bootloader will be the same.
https://wiki.archlinux.org/index.php/Chrome_OS_devices
[13:47:28] <jepler> I don't know how to determine whether a particular chromebook/chromebox has the "SeaBIOS"
[13:47:48] <jepler> > The legacy boot mode is provided by the SeaBIOS payload of Coreboot, which is the firmware for the Intel based Chrome OS devices (with the exception of the first generation of Chromebooks)
[13:47:50] <ssi> sounds like more trouble than it's worth
[13:47:58] <jepler> I would tend to think so
[13:52:27] <skunkworks> I thought peter had one of those little hp boxes running linuxcnc
[13:53:17] <jepler> skunkworks: some of them come in windows and chromeos versions
[13:53:22] <jepler> I assume he has the windows version
[13:54:53] <skunkworks> yes - probably windows
[13:56:20] <skunkworks> seb_kuzminsky, did you get the modules working? (could I build linuxcnc and try the latency test?)
[14:02:35] <mozmck> cradek: emcmotStruct gets memset to 0 in init_comm_buffers() when created, which would set the defaults in emcmotConfig correctly.
[14:02:42] <cradek> sweet
[14:02:46] <cradek> thanks for checking that
[14:02:50] <mozmck> np
[14:19:35] <seb_kuzminsky> skunkworks: no, i can't get the rtai math code to build right on amd64
[14:21:53] <skunkworks> yeck
[14:30:29] <jepler> I'm glad 50% of the bugs I found building linuxcnc on fedora weren't ours :-P
[14:44:58] <mozmck> Run from line is definitely not working correctly. We found that if there is a rapid to the start position of an arc, we get an arc error when we try to run from any line past that arc.
[14:45:40] <mozmck> But if we add a G1 move to the start position of the arc - even if there was a previous G0 to the same spot, it works fine.
[14:46:12] <jepler> that is weird and possibly also good information for further work on the problem
[14:46:17] <mozmck> I looks like run-from-line scans the code to set context or something, but does not do it the same as when actually running the code.
[14:46:47] <jepler> do you think this is a recent (e.g., not in 2.6) regression in RFL?
[14:46:55] <mozmck> We are still working on it. Changing our sheetcam post now to see if we can work around it.
[14:47:42] <mozmck> I don't know, because I haven't tried 2.6 with any of this. I need to get a good sample gcode file that exhibits the error and is not too large...
[15:39:13] <jepler> Either I didn't understand the how-to-reproduce steps, or I am not encountering the problem myself (tip-ish of master)
https://emergent.unpythonic.net/files/sandbox/rfl-arc.ngc
[15:39:27] <jepler> I have a G0 move followed by a G2 arc and then a couple of G1 moves
[15:39:38] <jepler> I can right-click run from line 10 and I don't encounter a problem
[16:02:18] <mozmck> jepler: I need to look and see how axis does run from here. Tried your code and I get "G0 Z1 exceeds -X limit"
[16:06:29] <mozmck> If I change your second G0 to G1 X2 Y2 Z0, then my run from line works fine. I'm using 2.7.3, and my gui is based on gscreen.
[16:14:08] <jepler> that's quite curious.
[16:14:12] <jepler> configs/sim/axis/axis.ini here of course
[16:14:27] <jepler> but the message you cite would be coming from task so not sure why UI would make a difference
[16:15:20] <mozmck> It looks like it is using the current position of the tool instead of the position from the last G0 move to me.
[16:15:47] <cradek> is it starting at an off-by-one line?
[16:16:06] <cradek> do I understand right that AXIS works right?
[16:16:06] <mozmck> Looks like my run from here is essentially the same as the one in axis
[16:17:10] <mozmck> I don't think that's the problem, because I can do it on any line after the G0 -> G2/G3 with similar problems.
[16:23:23] <jepler> at the tip of 2.7 I get the same diagnostic
[16:24:33] <jepler> .. once
[16:24:33] <mozmck> same error I reported?
[16:24:44] <jepler> not quite
[16:24:50] <jepler> "G0 Z1 exceeds +Z limit"
[16:24:58] <mozmck> heh... I tried it in axis, and did not get it.
[16:24:59] <jepler> oh, no, that's totally different
[16:25:07] <jepler> after I touched off it works now
[16:25:16] <mozmck> ah, that's because the default axis.ini has a limit of 0.12
[16:26:25] <mozmck> My Z limits were set to -10000 and +10000 because they are not critical for our use, and there is really no need to home the Z if you don't want to.
[16:26:44] <jepler> anyway here's what my debug log looks like
http://paste.ubuntu.com/13836780/
[16:26:51] <mozmck> So I set them to -10.000 and +10.000 and now I'm not seeing that error in my gui either :-/
[16:28:13] <mozmck> how do you get that debug log?
[16:28:36] <jepler> in axis.ini
[16:28:37] <jepler> -DEBUG = 0
[16:28:37] <jepler> +DEBUG = 0x950
[16:29:02] <cradek> maybe I missed it - have you said what the error is, or pastebinned your gcode?
[16:30:02] <mozmck> I've had various error messages now, but the most recent is with jeplers test code, "G0 Z1 exceeds -X limit"
[16:30:36] <cradek> if you're outside (or against??) a limit, you can get that for any move
[16:30:56] <mozmck> my Z limits were -10000 and 10000
[16:31:02] <jepler> mozmck: were you running this in a situation where the whole program is within the bounds?
[16:31:09] <mozmck> yes
[16:31:56] <jepler> because I got a deceptively-similar error, and that occurred when the whole program would have hit a limit
[16:33:21] <mozmck> Well, I can do more testing and see. The errors we are seeing in the shop are with the arc end not matching the start...
[16:33:35] <jepler> make sure we can reproduce it with a config we have ...
[16:34:41] <mozmck> I'll work on that.
[16:50:10] <mozmck> Here's a diff against the tip of 2.7 with separate probe inhibit ini settings - tested and working here.
[16:50:11] <mozmck> http://paste.ubuntu.com/13837440/
[16:51:39] <cradek> great, I like it
[16:51:49] <jepler> + trajInifile->Find(&j_inhibit, "NO_PROBE_JOG_ERROR", "TRAJ");
[16:52:02] <jepler> I think you guys covered this before, but if the inifile item is not there then the variable is unmodified?
[16:52:11] <jepler> (and an error indicator is returned but ignored)
[16:52:25] <jepler> -MIN_LIMIT = -8.0
[16:52:26] <jepler> +MIN_LIMIT = -10000
[16:52:28] <cradek> was line 81 a bug?
[16:52:37] <cradek> (yeah it has a bit of extra stuff in it)
[16:52:43] <jepler> please don't commit these config file changes
[16:54:01] <mozmck> hmm, not sure I understand all of that.
[16:54:09] <cradek> hm I'm not understanding the process_probe_inputs chunk and I have to run - I'll look again later
[16:54:27] <cradek> he just means the first chunk wasn't intended for this change
[16:54:54] <cradek> bbl (sorry)
[16:55:32] <jepler> these two changes seem to modify the behavior you'll get if you don't enable either of the new settings:
[16:55:35] <jepler> - if(joint->free_tp_enable == 1) {
[16:55:39] <jepler> + if((joint->free_tp_enable == 1) && !GET_JOINT_HOMING_FLAG(joint)) {
[16:55:48] <jepler> (changes the condition under which free_tp_enable is reset back to 0)
[16:55:54] <jepler> - if(!aborted) aborted=2;
[16:55:57] <jepler> + aborted=2;
[16:56:03] <jepler> (changes the condition under which aborted gets set to 2)
[16:56:20] <mozmck> ahh, I didn't see that - I didn't commit that, but this diff is against 2.7 branch.
[16:56:29] <mozmck> the MIN_LIMIT stuff that is.
[16:57:08] <jepler> I think that's what cradek was saying about pastebin line 81
[16:57:45] <mozmck> jepler: with the current code, the check for free_tp_enable will be true if homing.
[16:58:39] <mozmck> so, free_tp_enable was always set to 0 and the if(!aborted) check was to give the correct error. My change makes the two checks independent of each other.
[16:59:31] <jepler> give that a moment to sink in for me
[17:00:16] <mozmck> clearing free_tp_enable when aborting homing should not be needed because that is done when homing.c sees the HOME_ABORT, but I put it there to match the old behaviour.
[17:01:56] <jepler> so the addition at pastebin line 81 clears free_tp_enable if they have NO_PROBE_JOG_ERROR but don't have NO_PROBE_HOME_ERROR
[17:03:14] <mozmck> yes, but the extra check on line 91 makes sure that block does not get run when homing at all.
[17:04:01] <jepler> OK, I am starting to see what you're saying. At first it was a surprise to me that anything inside those blocks had to change but I get the gist of your argument
[17:04:16] <mozmck> I had to separate the two to make the separate inhibits work properly. If I inhibited home errors only, I would still get a jog error when homing.
[17:04:40] <mozmck> because homing uses the free_tp planner.
[17:13:05] <jepler> I see that now. Thanks for taking the time to walk me through it.
[17:20:51] <mozmck> you're welcome!
[17:37:33] <linuxcnc-build> build #1520 of 1102.rip-hardy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1102.rip-hardy-amd64/builds/1520 blamelist: Chris Radek <chris@timeguy.com>
[18:37:20] <linuxcnc-build> build #3742 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3742 blamelist: Chris Radek <chris@timeguy.com>
[20:20:00] <mozmck> Here is sample gcode that give the error we are seeing in axis. The only change needed is to increase the positive Z limit to more than .75
http://paste.ubuntu.com/13843261/
[20:20:48] <jepler> mozmck: if I "touch off" instead, does the problem not occur?
[20:21:06] <mozmck> instead of what?
[20:23:19] <mozmck> To see the error, I'm just starting axis, power on, home all, load code, select line 25 (M5) and run from here in the right click menu
[20:23:34] <jepler> instead of changing the Z limit
[20:23:51] <mozmck> Oh, I don't know - that might work
[20:24:28] <jepler> can you put that somewhere that I can download it as text? the link forces sign-in to ubuntu to continue
[20:25:53] <jepler> oh I'll copy&paste it, sorry for b----complaining
[20:26:53] <mozmck> http://www.mcknight-instruments.com/files/CircleSquare_expanded_2.ngc
[20:27:07] <mozmck> :-)
[20:29:10] <jepler> thanks
[20:29:39] <mozmck> I'm trying to use a touchoff instead of changing the axis Z limit, but I'm not sure which way to go.
[20:31:03] <jepler> jog to the top (machine z=0), press Z, END, then enter the value you want the Z coordinate to be (e.g., .75 or 1.0)
[20:31:56] <mozmck> ok, I got that to work, and it looks like I still get the error.
[20:33:33] <jepler> and the error you get in this case is about the limit?
[20:33:57] <mozmck> no it's Radius to end of arc differs from radius to start
[20:37:03] <jepler> OK
[20:37:06] <jepler> I can get that error too
[20:37:15] <jepler> Radius to end of arc differs from radius to start: start=(X0.0000,Y0.0000) center=(X-0.1280,Y0.0000) end=(X8.7170,Y0.2470) r1=0.1280 r2=8.8484 abs_err=8.72 rel_err=98.5534%
[20:37:45] <jepler> I didn't get it at first because I changed the G38.2 to G0
[20:37:59] <mozmck> interesting
[20:38:12] <jepler> I did that because the first thing I wanted to do was run the program from the start, but I got an error about my probe move finishing without probe tripped (of course)
[20:38:19] <mozmck> Ah, yes.
[20:40:14] <mozmck> Now if you copy the XY move from line 11 into th G1 move on line 19, you can then "run from here" at line 25 and it will work.
[20:41:59] <mozmck> But, when I put the G38.2 move in an O subroutine (separate file), then the above fix stops the arc radius error, but instead I get a G38.2 probe move in an ARC! It will gradually arc down to the metal but will usually error out first.
[20:42:12] <jepler> what I *suspect* is happening is that even though it's supposed to be skipped, a part of G38.2 is still happening:
[20:42:32] <jepler> the part where the X,Y,Z of the interpreter become equal to the X,Y,Z of the machine after the probe move is done
[20:43:12] <jepler> in the case of this pre-running of the code because of RFL, maybe that needs to not happen
[20:43:29] <jepler> but instead the X,Y,Z endpoint of the probe move should be used instead? I'm not sure what number can safely be used.
[20:43:55] <mozmck> For our use case anyhow, it should not need to pre-run the code.
[20:44:00] <jepler> for instance, if you do that then every probe would move the coordinates down 0.50"
[20:44:31] <jepler> I don't know the history of the addition of that code. I can predict it was done by somebody who believed it made rfl work better, but that's the end of my prediction :-P
[20:45:00] <mozmck> :-)
[20:45:08] <jepler> You had said you thought G1 vs G0 might be relevant, but in my testing just now it seems like adding G0 X- Y- or G1 X- Y- has the same effect
[20:45:53] <mozmck> In another software we have used, it had both run from here that pre-ran the code, and a "Set next line" that simply ran from the line selected.
[20:45:56] <jepler> anyway, I'm not sure where it leaves you looking for a resolution to the problem, but that's my guess about what's going on...
[20:46:39] <jepler> I can double my level of guess by noting that if I jog out to some random X,Y coordinates, those are the ones shown in the arc error
[20:46:47] <mozmck> hmm, well I was suspecting the G38.2 had something to do with it, and the pre-running of the code.
[20:46:50] <jepler> Radius to end of arc differs from radius to start: start=(X20.5835,Y11.4804) center=(X20.4555,Y11.4804) end=(X8.7170,Y0.2470) r1=0.1280 r2=16.2475 abs_err=16.12 rel_err=99.2122%
[20:47:24] <mozmck> Yes, I had noticed that. It seems to use the current location for the start if there is not an XY move after the G38.2
[20:49:42] <jepler> hm that code looks to date back to the dawn of emc2
[20:49:59] <jepler> though it has been touched some since then
[20:51:15] <jepler> .. sometimes by me :-/
[20:51:18] <jepler> .. in 2009
[20:52:52] <jepler> I don't have anything constructive to offer. I've long been a pessimist about the general shape of our run-from-line code, and I don't feel like we're just a few bugfixes from having it right.
[20:53:39] <jepler> afk
[20:53:50] <mozmck> Well, thanks for looking at it!