Back
[00:11:28] <memfrob> just a matter of trimming down the git diff now, all clean-up is done. commit should be done in a few days. lots and lots of changes. i hope these fix my super bad latency spikes..
[03:27:46] <memfrob> ah yes and i also need to test it before the push
[03:27:54] <memfrob> night all
[04:30:34] <skunkworks> cradek: question - why did that not show up in the inch config?
[07:59:07] <cradek> skunkworks: you got the defaults of vel 1 unit/sec and acc 1 unit/sec2 for the missing axis
[07:59:23] <skunkworks> ah - ok
[07:59:48] <cradek> yeah and 1 inch is big enough that you didn't notice it
[08:00:53] <skunkworks> yes the testing was less than 60in/min.
[08:02:20] <skunkworks> morning!
[08:02:57] <cradek> it's sooo early
[08:40:58] <skunkworks> cradek, changed g2 to g3 and the program ran at expected speeds.. ;)
[08:41:42] <skunkworks> It is funny - i was thinking to myself when i did the mass change of y to z that I thought with i and k notation I had to change a sign...
[08:41:57] <skunkworks> or something..
[08:42:11] <skunkworks> but it was the G command I changed
[08:42:39] <skunkworks> heh
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/146948
[08:45:27] <cradek> did mach not already have probing?
[08:46:01] <skunkworks> yes but it sounds like it wasn't that flexable
[08:46:06] * skunkworks hugs linuxcnc
[08:47:40] <cradek> skunkworks: it's what it is partly because of you; thanks for all your work
[08:59:33] <skunkworks> Thanks
[09:07:15] <mozmck> c_morley: If I set the theme in .gscreen_preferences, after running gscreen it sets itself back to "Follow System Theme"
[09:18:56] <mozmck> Hmm, I wonder if it's because I am trying to use a theme in ~/.themes instead of /usr/share/themes
[09:23:12] <mozmck> Looks like that is it.
[09:33:47] <cpresser> hi. i was wondering if it is possible to initialize "motion.analog-out-NN" pins with values other than 0
[09:34:05] <cpresser> looking at lines 575ff
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/motion/motion.c;h=d403afa62881ac8117bcaa09d5dce058da5c4d58;hb=HEAD this doesnt seem to be possible
[09:34:47] <cpresser> for me, that would be a usefull feature. so I am considering writing a patch
[09:34:59] <skunkworks> what are you trying to do? Could it be done in hal?
[09:35:22] <cpresser> skunkworks: yes, could be done in hal. with a mux
[09:36:08] <seb_kuzminsky> cpresser: M68 in the startup gcodes?
[09:36:33] <cpresser> seb_kuzminsky: can i have more than on M68 in the startup-code?
[09:37:34] <cpresser> i want to set 4 outputs during startup
[09:37:51] <cpresser> so i was thinking of adding more parameters to motion
[09:38:12] <seb_kuzminsky> you can only have one, good point
[09:38:44] <seb_kuzminsky> can you call an o-word sub in the startup gcodes? that'd let you have as many M68 calls as you want
[09:39:13] <cpresser> i am not sure if o-words work in startup-code. afaik only modal codes work. but ill try
[09:39:44] <cpresser> that would be a way easier solution than patching motion. besides, i might be the only person on earth which wants that feature
[09:42:46] <seb_kuzminsky> your hardware has to be robust against unexpected aout voltages before linuxcnc starts up, so it seems strange to be in a rush to set them once linuxcnc starts
[09:44:05] <cradek> yeah this feels like you're not taking the right approach, but I don't know what the big picture is, so it's hard to guess what to suggest
[09:44:35] <cpresser> true for real analog-out. but i use those values only inside HAL as parameters for some components.
[09:47:28] <seb_kuzminsky> you have some hal components with pins that get netted to motion.analog-out-*?
[09:48:28] <cradek> what are you doing? (not how are you doing it)
[09:50:47] <cpresser> cradek: its complicated.. its a tensile-strenght-testing machine. with optical tracking (i did that in opencv). everything is wired together in HAL. I am using the analog-out pins, so the user can enter parameters as gcode. but it would be good to have them already set at startup
[09:52:05] <cradek> woo that is complicated
[09:52:08] <cpresser> i could use a mux which switched between a default-vaule und motion.analog-out-NN; and switch this mux as soon as 'sane' value apper on the input
[09:52:25] <cradek> yeah I was thinking about that too
[09:52:42] <cpresser> but the HAL files already look really complicated; thats why i am searching for other solutions
[09:52:52] <cradek> could something the user does trigger that mux? should it trigger at start of program run or something?
[09:53:28] <cpresser> yes, i could trigger it with halui.programm-is-running (or similar pins)
[09:53:52] <cradek> that sounds like a useful approach
[09:58:39] <skunkworks> I hope rob's head hasn't exploded.. I sent him a dozen emails yestarday and in the end it was - chris fixed the lathe issue and the arc-spiral issue was my mistake..
[10:03:43] <cradek> poor rob :-)
[10:05:27] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 b39bdb3 06linuxcnc 10src/emc/tp/tp.c tp: possible fix for non-zero current velocity when stopped * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b39bdb3
[10:05:27] <KGB-linuxcnc> 03Robert W. Ellenberg 052.7 ff5b780 06linuxcnc 10src/emc/tp/blendmath.c 10src/emc/tp/tc.c 10src/emc/tp/tc.h tp: refactor blending segment consumption check to ensure that syncedIO is not disrupted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff5b780
[10:08:45] <seb_kuzminsky> cradek: can you elaborate on 8dca131ab "Fix blending regression"? what was teh regression?
[10:10:42] <cradek> instead of working, blending didn't work
[10:10:47] <cradek> at all
[10:10:59] <cradek> not even a little bit
[10:11:54] <skunkworks> I swear he is like peter and watches this list...
[10:13:42] <seb_kuzminsky> skunkworks: those commits were a pull request from github that i just merged
[10:13:52] <seb_kuzminsky> cradek: ouch
[10:13:53] <skunkworks> ah - ok
[10:14:09] <seb_kuzminsky> hm, was that a regression that was introduced since 2.7.0~pre4?
[10:14:35] <skunkworks> zlog,
[10:15:36] <skunkworks> [17:16:24] <skunkworks> 14e9153c7d0c6d1086c9582a1ab97287401bebf7 is the first bad commit
[10:15:36] <skunkworks> [17:16:25] <skunkworks> commit 14e9153c7d0c6d1086c9582a1ab97287401bebf7
[10:15:36] <skunkworks> [17:16:27] <skunkworks> Author: Robert W. Ellenberg <rwe24g@gmail.com>
[10:15:36] <skunkworks> [17:16:28] <skunkworks> Date: Mon Mar 2 22:17:50 2015 -0500
[10:15:56] <cradek> seb_kuzminsky: yes, "tp: polish and tweaks for low queue fix"
[10:16:57] <seb_kuzminsky> cradek: thanks, then i wont bother mentioning it in the changelog
[10:17:58] <cradek> I think it was a "polish" that broke it. he rewrote some conditionals to use variable names (to be clearer) but made a mistake.
[10:18:48] <cradek> yeah I'd not mention it, since it was broken then fixed since the last one
[10:24:36] <seb_kuzminsky> oh yeah, the stepconf doublestep fix
[10:24:56] <seb_kuzminsky> there's been a lot of improvements in the 3 weeks since 2.7.0~pre4
[10:28:10] <cradek> awesome
[10:36:10] <KGB-linuxcnc> 03Dewey Garrett 052.7 9288501 06linuxcnc 10docs/man/man1/xhc-hb04.1 xhc-hb04 manpage: fix missing output pin .sleeping * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9288501
[10:40:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 2b215a4 06linuxcnc 03v2.7.0-pre5 LinuxCNC v2.7.0~pre5 (tagged commit: 04ff882) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b215a4
[10:40:35] <seb_kuzminsky> err oops
[10:40:42] <seb_kuzminsky> i missed dgarr's push
[10:40:43] <seb_kuzminsky> darn
[10:41:08] <KGB-linuxcnc> 05tags 2b215a4 06linuxcnc 04v2.7.0-pre5 tag deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b215a4
[10:42:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 536fb69 06linuxcnc 10VERSION 10debian/changelog LinuxCNC 2.7.0~pre5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=536fb69
[10:42:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags c709566 06linuxcnc 03v2.7.0-pre5 LinuxCNC v2.7.0~pre5 (tagged commit: 536fb69) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c709566
[10:42:46] <seb_kuzminsky> that's better
[10:43:14] <seb_kuzminsky> good thing the buildbot was busy building dgarr's manpage fix and didn't get to build an incorrect 2.7.0~pre5 tag
[10:43:50] <seb_kuzminsky> assuming this goes smoothly i'll upload the debs & send out an announcement tonight
[10:55:24] <cradek> yay!
[10:59:25] <skunkworks> Awesome!
[11:47:29] <skunkworks> wow - cool
https://picasaweb.google.com/108164504656404380542/CNCUnsorted?noredirect=1#6076505779370891058
[12:13:46] <cradek> slick
[13:40:14] <pcw_home> Quite a few bugs fixed for 2.7-pre5
[13:41:10] <pcw_home> The bogus velocity bug is still there but less apparent
[13:41:59] <seb_kuzminsky> even after b39bdb34? (ie, even in 2.7.0~pre5?)
[13:44:21] <pcw_home> yes, but only
[13:44:23] <pcw_home> 1. when first starting linuxcnc
[13:44:24] <pcw_home> 2. for about 1/4 second when starting a job
[13:44:39] <seb_kuzminsky> huh, ok
[13:44:47] <seb_kuzminsky> rob thought he might have fixed it
[13:45:08] <pcw_home> its changed and less apparent
[13:45:47] <pcw_home> oops is still there every time you start a job (but dont blink)
[13:46:53] <pcw_home> I think I'm wrong, its OK
[13:47:31] <seb_kuzminsky> oh! that's a good kind of wrong to be :-)
[13:47:53] <pcw_home> theres a short move right when you start then a long pause
[13:48:07] <pcw_home> the velocity blink is that short move
[13:50:04] <pcw_home> its the z retract
[16:01:43] <skunkworks> well this decides it.. linuxcnc is the best..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/146963
[16:06:12] <cradek> have we ever recorded ours with all four parts playing? it's much better than 3.
[16:06:39] <skunkworks> I don't think I have run across it.. lots of 2 part...
[16:06:43] <skunkworks> *3 part
[16:09:44] <cradek> it was written during one of the eras where max had 4 trivkins axes
[16:36:32] <mozmck> c_morley: I modified gscreen to look for themes in the ~/.themes directory as well as /usr/share/themes, and it also filters out directories without a gtk-2.0 theme
[16:44:17] <mozmck> patch here:
http://pastebin.com/DjWyT6zP
[16:46:22] <mozmck> I'm not a python expert (yet :) ) - there may be some better way to do this.
[18:13:27] <andypugh> I am trying to draw a polygon in a gtk drawable. But it keeps saying “sequence members must be 2-tuples”. However if I print my point sequence it looks like ((10,20), (30,40), (10, 50)) which I think is a 2-tuple? I wish I understood Python.
[18:16:06] <seb_kuzminsky> i think those are lists, not tuples
[18:16:22] <andypugh> What would a tuple look like?
[18:16:24] <seb_kuzminsky> lists are immutable and displayed with ( ), tuples are mutable and displayed with [ ]
[18:16:39] * seb_kuzminsky also does not know python
[18:17:14] <andypugh> http://www.tutorialspoint.com/python/python_tuples.htm
[18:17:20] <andypugh> Suggests the reverse....
[18:17:47] <seb_kuzminsky> >>> type((1, 2))
[18:17:47] <seb_kuzminsky> <type 'tuple'>
[18:17:47] <seb_kuzminsky> >>> type([1, 2])
[18:17:47] <seb_kuzminsky> <type 'list'>
[18:17:54] <seb_kuzminsky> yep, ignore me, heh
[18:48:21] <andypugh> It seems that the problem is not that my tuples are not tuples, but that they are not _integer_ tuples. I tried some sample code, changes a number to non-int and then got the same (confusing) error message
[23:23:29] <KGB-linuxcnc> 03Chris Morley 052.7 1156758 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -check the user directory for GTK2 themes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1156758