Back
[00:38:43] <KGB-linuxcnc> 03Dewey Garrett 05master 9d80455 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py restore wrongly removed set_teleop_mode() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d80455
[01:38:15] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc commented on issue #103: I pulled the latest commits and the bug is gone for most non-identity configs: hexapod-sim, max5kins, lineardeltakins... 02
https://github.com/LinuxCNC/linuxcnc/issues/103#issuecomment-230137638
[02:05:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc opened issue #104: Ctrl-Space clears axis selection in AXIS for non-identity configs after homing 02
https://github.com/LinuxCNC/linuxcnc/issues/104
[05:22:47] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 33da23a 06linuxcnc 10lib/python/gladevcp/speedcontrol.py GladeVCP - SpeedControl - set the increment to default after setting a new adjustment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=33da23a
[05:22:47] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 0681968 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_4_axis.ini 10src/emc/usr_intf/gmoccapy/getiniinfo.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_JA_master - jog speed control not initialized with the correct increment value * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0681968
[05:28:49] <KGB-linuxcnc> 03Norbert Schechner 052.7 cd91a98 06linuxcnc 10lib/python/gladevcp/speedcontrol.py GladeVCP - SpeedControl - set default increment after setting a new adjustment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd91a98
[05:37:25] <KGB-linuxcnc> 03Norbert Schechner 052.7 755235e 06linuxcnc 10docs/src/gui/gladevcp.txt DOCS - GladeVCP - SpeedControl - updated and corrected * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=755235e
[05:38:17] <KGB-linuxcnc> 03Norbert Schechner 05master a9f2113 06linuxcnc 10docs/src/gui/gladevcp.txt Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a9f2113
[05:39:22] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master c359535 06linuxcnc Merge branch 'master' into gmoccapy_JA_based_on_master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c359535
[06:17:24] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 83b1036 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_XYZAB.ini 10configs/sim/gmoccapy/gmoccapy_lathe.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_JA-master - differnt DRO size adjustment * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83b1036
[08:35:48] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 3f71864 06linuxcnc 10(5 files in 2 dirs) gmoccapy_JA_master - bug in units handling jog vel slider * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f71864
[08:58:38] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master fc22b50 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_JA_master - updated debug server * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc22b50
[09:23:57] <linuxcnc-build> build #3518 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/3518 blamelist: Norbert Schechner <nieson@web.de>
[10:12:19] <linuxcnc-build> build #4322 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4322 blamelist: Norbert Schechner <nieson@web.de>
[10:48:47] <skunkworks> pcw_home:
http://pastebin.ca/3654791
[10:48:56] <skunkworks> unless I am doing something wrong...
[10:49:27] <skunkworks> that is turning the jog wheel clockwise
[10:52:55] <pcw_home> Thats expected (counts are raw counts from the 7I73)
[10:53:19] <pcw_home> if you want scaled data, use position
[10:54:52] <skunkworks> oh - that makes sense.
[10:55:41] <pcw_home> maybe should have been named rawcounts to match standard encoders
[10:55:49] <skunkworks> it also has a raw counts pin - so that isn't intuative
[10:56:22] <pcw_home> Yes I see that, thats a bit odd
[10:57:59] <pcw_home> not really sure what the difference is
[11:00:43] <pcw_home> I think Andy discovered a bug with the encoder also
[11:00:44] <pcw_home> I think it makes using rawcounts or counts a bit dangerous
[11:00:45] <pcw_home> since they are not zeroed on linuxcnc startup
[11:01:40] <pcw_home> (unless the 7I73 is powered down)
[11:08:55] <pcw_home> maybe raw counts is not reset at startup or by the reset pin
[11:10:14] <pcw_home> Yeah, thats the difference
[11:28:32] <skunkworks> for a jog wheel I don't think it matters..
[11:29:52] <skunkworks> huh - ok - yes. If you start using the counts and it is negative - the MV is zero
[11:30:12] <skunkworks> So I should use position
[11:31:01] <skunkworks> let me try that. I remember axis coming up with the override being zero and I thought that was odd
[11:32:38] <skunkworks> postion desn't seem to be reset either..
[11:33:57] <skunkworks> so - I need to poke the reset for the encoder before linuxcnc comes up?
[11:36:05] <skunkworks> aww - postion won't work without a convertion from float to int
[11:39:02] <pcw_home> if you want to get really obscure you can reverse the count by changing the 7I73s count mode
[11:39:24] <skunkworks> but that is a mute point as the positon count doesn't get reset eithere
[11:39:53] <pcw_home> I think thats a legitimate bug
[11:40:14] <skunkworks> at what point does the gui become active - like I wonder if I can do a reset in hal
[11:41:15] <pcw_home> maybe just machine-on or some such
[11:42:33] <skunkworks> by then the slider is already reflecting the count
[11:43:12] <pcw_home> but it wont change...
[11:44:43] <pcw_home> (assuming reset is level triggered)
[11:49:12] <pcw_home> yeah its level triggered so the count/position will be forced to 0 until reset is released
[11:49:13] <pcw_home> (and then start counting from 0)
[11:49:50] <pcw_home> (but rawcounts is unaffected)
[11:53:02] <pcw_home> One reason you might need to swap A/B pins is to get the point that the counter counts in 1x mode to be between detents
[11:53:44] <skunkworks> well - I was going to oneshot it but reset is i/o and oneshot output is a bit. Looking
[11:54:57] <pcw_home> why not just hold in reset until machine is enabled?
[11:56:06] <skunkworks> hmm I don't know how I would do that with i/o pin
[11:56:07] <skunkworks> yet
[11:58:10] <pcw_home> hmmm thats odd, why would reset be a I/O pin
[12:00:54] <skunkworks> probably similar code to the index
[12:01:48] <pcw_home> I vaguely remember a comp that can do this
[12:02:42] <pcw_home> IMHO I/O hal pins are a bug
[12:04:14] <pcw_home> there are only a few important ones and they always cause suffering
[12:08:51] <skunkworks> http://pastebin.ca/3654849
[12:09:05] <skunkworks> that seems to work
[12:13:31] <pcw_home> Yeah, that's the comp I was thinking of
[12:14:14] <pcw_home> I think I would just hold it reset until ready though (no need for oneshot)
[12:15:24] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #102: Is this PR for 2.7 or master? 02
https://github.com/LinuxCNC/linuxcnc/pull/102#issuecomment-230162813
[12:39:08] <skunkworks> instead of i/o would you use 2 pins for handshaking?
[12:47:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #96: This bug can be reproduced with the sim/axis/gantry config by reducing [JOINT_3]MAX_LIMIT from 50 to 40, then homing and jogging towards the Y maximum. 02
https://github.com/LinuxCNC/linuxcnc/issues/96#issuecomment-230164379
[13:45:02] <pcw_home> Yeah I would use 2 pins
[14:52:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #102: I intended this PR to be for 2.7. I already pushed it to master so this is effectively a cherry pick. The bug would affect 2.6 but I don't think that tree will build on a new enough platform to be actually affected. 02
https://github.com/LinuxCNC/linuxcnc/pull/102#issuecomment-230170574
[15:35:05] <skunkworks_> zlog
[16:35:14] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #104: What appears to be happening is, a non-visible radiobutton widget for some joint has keyboard focus. control-space activates that radiobutton, and also clears messages. Normally this effect goes unnoticed.... 02
https://github.com/LinuxCNC/linuxcnc/issues/104#issuecomment-230175447
[16:49:18] <KGB-linuxcnc> 03Dewey Garrett 05master b6dac59 06linuxcnc 10share/axis/tcl/axis.tcl axis.py work on #104 "Ctrl-Space clears axis ... * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b6dac59
[17:48:36] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15pkmcnc closed issue #104: Ctrl-Space clears axis selection in AXIS for non-identity configs after homing 02
https://github.com/LinuxCNC/linuxcnc/issues/104
[17:49:03] <DLPeterson> good afternoon! I'm trying to compile the tip of master and am running into a configure error:
[17:49:39] <DLPeterson> http://pastebin.com/BtzrT0p1
[17:50:33] <DLPeterson> i am on gentoo and have python-2.7.11 and python-3.4.4 available; the latter is my system default; I tried the --with-python configure flag but it made no difference
[17:51:46] <memleak> what does python --version say?
[17:52:16] <DLPeterson> Python 3.4.4
[17:52:51] <memleak> temporarily try changing to python 2 via eselect python set X (run list first) then env-update && source /etc/profile
[17:53:35] <memleak> then remove python options on the ./configure line
[17:53:47] <DLPeterson> memleak, actually i just tried --with-python=python2 and now i'm seeing a different error that looks more solvable
[17:53:55] <DLPeterson> checking for boost::python shared library...
[17:53:57] <DLPeterson> configure: error: boost::python is required to build LinuxCNC
[17:54:55] <memleak> yes for that set the boost-python=boost_python-2.7 in ./configure
[17:55:45] <DLPeterson> via commandline flag?
[17:55:48] <memleak> ls /usr/lib | grep boost_python-2.7
[17:56:13] <memleak> there's a --with-boost-python or a --boost-python option in ./configure --help in linuxcnc
[17:56:18] <memleak> i forget which one it is off hand
[17:57:27] <memleak> USE flags for dev-libs/boost and dev-util/boost-build need to be at least +python +python_targets_python2_7
[17:58:46] <DLPeterson> ok, using this worked: --with-python=python2 --with-boost-python=boost_python-2.7
[17:58:50] <memleak> woo!
[17:58:53] <DLPeterson> :)
[17:58:54] <DLPeterson> thanks
[17:58:59] <memleak> make sure you have bwidget, tcl, tk and modbus installed
[17:58:59] <DLPeterson> now to see if it compiles :)
[17:59:16] <DLPeterson> oh yeah, those got installed earlier as i was running configure
[18:00:42] <DLPeterson> ok, looks like i'm getting a modbus related compilation error:
[18:00:49] <DLPeterson> http://pastebin.com/G1dnmt01
[18:01:39] <DLPeterson> i have modbus 3.1.2 installed
[18:03:34] <memleak> what branch of linuxcnc are you building?
[18:04:27] <DLPeterson> master
[18:05:10] <DLPeterson> i don't need to build master, should I build something else?
[18:05:42] <DLPeterson> i'll give the 2.7 branch a try
[18:05:58] <memleak> it's the same line of code i just checked
[18:07:17] <DLPeterson> should I file an issue on github?
[18:08:14] <memleak> i just looked at the source of libmodbus 3.0.6
[18:08:24] <memleak> might fix your problem, number of arguments are off
[18:08:53] <memleak> 3.0.6 defines modbus_set_response_timeout with (modbus_t *ctx, const struct timeval *timeout);
[18:09:08] <memleak> 3.1.2 is int modbus_set_response_timeout(modbus_t *ctx, uint32_t to_sec, uint32_t to_usec);
[18:10:00] <memleak> 3.1.2 expects 3 arguments, 3.0.6 will accept the two that linuxcnc provides, which is this: (this_mb_link->modbus, &timeout);
[18:10:38] <memleak> emerge -v =dev-libs/libmodbus-3.0.6 :)
[18:10:43] <DLPeterson> :)
[18:11:36] <DLPeterson> i presume 3.1.1 requires the same as 3.1.2
[18:13:29] <DLPeterson> gentoo is just too advanced :)
[18:13:59] <memleak> I'd have to look at the source code of 3.1.1 to verify
[18:15:37] <DLPeterson> yeah
[18:15:41] <DLPeterson> don't bother
[18:16:00] <DLPeterson> I just added =dev-libs/libmodbus-3.1.0 to /etc/portage/package.mask/libmodbus
[18:16:12] <memleak> >=
[18:16:17] <DLPeterson> yeah
[18:16:23] <DLPeterson> bad copy
[18:16:31] <memleak> making sure!
[18:19:04] <memleak> This means the linuxcnc devs need to patch configure to check for libmodbus version and ifdef modbus_set_response_timeout args
[18:21:37] <memleak> I've gotten lazy a few times and just tagged a ",1" to it (probably broke something)
[18:22:17] <memleak> "well he said 3!"
[18:30:14] <DLPeterson> ok, compilation is proceeding and seems good so far
[18:31:23] <DLPeterson> spoke too soon:
[18:31:26] <DLPeterson> http://pastebin.com/BsEmmutN
[18:33:05] <memleak> its probably calling python 3 again
[18:38:04] <memleak> python 3 uses print as a function (needs parenthesis)
[18:42:43] <memleak> replace it with print (quote.os.path.normpath(fn))
[18:44:40] <memleak> last line of po/fixpaths.py
[18:45:24] <memleak> or replace the "python" at the top of the file with python2.7
[18:46:24] <memleak> #!/usr/bin/env python2.7
[18:46:52] <memleak> that is IF the file is called by "./" and not "python" directly
[18:47:34] <memleak> otherwise just convert it to python 3 :)
[18:57:38] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15hazelnusse opened issue #105: compiling against libmodbus version 3.1.0 or greater fails due to API changes 02
https://github.com/LinuxCNC/linuxcnc/issues/105
[18:58:53] <DLPeterson> memleak, ok, that fix seems to do the trick
[18:58:58] <memleak> awesome!
[18:59:10] <DLPeterson> i filed an issue related to the modbus API change:
[18:59:13] <DLPeterson> https://github.com/LinuxCNC/linuxcnc/issues/105
[18:59:42] <memleak> yes it showed up in the channel, one more bug. --with-python= isn't consistent with fixpaths.py
[19:00:31] <DLPeterson> oh, cool
[19:00:44] <memleak> i thought so too!
[19:02:14] <DLPeterson> looks like adding some ifdefs would be pretty straightforward to check for LIBMODBUS_VERSION_{MAJOR,MINOR,MICRO}
[19:02:23] <DLPeterson> would that be the right way to fix it?
[19:02:38] <memleak> you got it!
[19:03:05] <DLPeterson> i'll try to bang that out
[19:26:38] <DLPeterson> memleak, in the case of modbus 3.1.0 or higher, do you think the call to modbus_set_response_timeout should be:
[19:26:41] <DLPeterson> modbus_set_response_timeout(this_mb_link->modbus, timeout.tv_sec, timeout.tv_usec);
[19:30:33] <memleak> That's what I would do but I'm also not the best C coder.
[19:44:58] <memleak> what's actually the practice anyways for calling __vdso_gettimeofday(2) via tv to avoid using the vsyscall ASLR backdoor?
[19:46:47] <memleak> ah timespec not timeval
[19:46:50] <DLPeterson> memleak, i pushed a commit to my Issue105 branch:
[19:46:51] <skunkworks_> chris saves the day.. :)
http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/309384-cnc-5.html#post1907090
[19:46:53] <DLPeterson> https://github.com/hazelnusse/linuxcnc/commit/29d22f2088ec12710974a6c544e02473999c5a0d
[19:47:13] <DLPeterson> who can sign this off?
[19:48:29] <DLPeterson> i compiled it on my machine while 3.1.2 is installed and it compiles fine, i don't know if there any way to really test it though
[19:52:42] <memleak> Hey just out of curiosity are you on 64 or 32-bit? And what RT system? RTAI, preempt-rt?
[19:54:16] <memleak> is that the only change you made? How does the compiler know what LIBMODBUS_VERSION_CHECK is?
[19:54:54] <memleak> Generally that's in autotools but I just grepped configure.in and it wasn't there.
[19:57:18] <DLPeterson> memleak, 64 bit laptop. no rt system yet, was just getting familiarized with LinuxCNC and trying to see if I could build it on my machine
[19:57:29] <DLPeterson> after some reading I think I'll be giving preempt-rt a try
[19:58:14] <DLPeterson> LIBMODBUS_VERSION_CHECK is supplied by the modbus-version.h file which is included by modbus.h
[20:01:52] <memleak> ahh
[20:02:05] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15hazelnusse opened pull request #106: Add libmodbus version checks (06master...06Issue105) 02
https://github.com/LinuxCNC/linuxcnc/pull/106
[20:03:13] <memleak> Shouldn't there be an >= sign as well?
[20:04:26] <memleak> or when == isn't supplied, then it doesn't need it and the compiler automatically assumes >=
[20:04:37] <DLPeterson> https://github.com/stephane/libmodbus/blob/master/src/modbus-version.h.in#L43
[20:05:07] <DLPeterson> I think their comment isn't quite accurate since the micro version number is a >=
[20:05:37] <DLPeterson> so i believe the way i've written it, it will be true for anything that is >= 3.1.0
[20:06:20] <memleak> modbus-version.h.in is really freakin ugly.. @_@
[20:07:09] <memleak> Props to your decoding skills! Job well done!
[20:07:22] <DLPeterson> thanks :)
[20:07:23] <memleak> That file gives me a headache
[20:08:33] <memleak> I'd have MAJOR, MINOR and MICRO defined in autotools then pulled in by .h not that nonsense that they did
[20:08:36] <memleak> afk for awhile bbl
[20:14:01] <DLPeterson> meh, its a template header that gets populated by autotools, it basically does what you are describing
[21:57:04] <memleak> DLPeterson glad I could help you today. Take care everybody!