Back
[07:12:52] <maximilian_h> hello, I cannot post to emc-developers
[07:13:03] <maximilian_h> I get my email back with this msg on top
[07:13:07] <maximilian_h> You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at emc-developers-owner@lists.sourceforge.net.
[07:13:35] <maximilian_h> I would like to give a patch to somebody who can apply it to the git repository
[07:15:50] <archivist> morning for most
[08:32:43] <cradek> maximilian_h: I answered your devel-owner email
[08:32:58] <cradek> maximilian_h: separately, I have feedback about the patch: first, thank you for working on it
[08:33:11] <cradek> your patch says 4/4 implying there are 3 more parts you did not include - is this right?
[08:33:21] <maximilian_h> yes
[08:33:39] <maximilian_h> got a couple more things I need to change myself to make my machine work
[08:34:38] <maximilian_h> reading your email
[08:34:50] <cradek> ok, if you regenerate it with git format-patch and specify just the change you want, it won't write the confusing 4/4
[08:35:09] <maximilian_h> yes, that is most probably the reason why the posting to the devel mailing list does not work
[08:36:01] <maximilian_h> k, I will just include the change
[08:36:27] <maximilian_h> Shall I send then to emc-developers again, is this the right place to post it ?
[08:37:05] <cradek> also please use your full first and last name in the commit, and use git commit -s to "sign off" your changes (#6 and #7 in
http://www.linuxcnc.org/docs/html/code/Contributing-to-LinuxCNC.html )
[08:37:36] <cradek> yes that's a perfectly good way to submit a patch
[08:37:51] <cradek> thank you for working on this
[08:38:31] <maximilian_h> I do not want to use my last name, I once got a crazy person stalking me, since then I am taking precautions not to be found on google with my laast name
[08:38:41] <maximilian_h> no need to thank me at all
[08:39:29] <maximilian_h> will Maximilian H. not be enough ?
[08:40:44] <cradek> hm, I'm not sure how to handle anonymous contributions. it is sometimes very important to know who submitted changes, because in our project the authors retain copyright on code they submit
[08:41:42] <maximilian_h> 100mil Chinese are called Wang, the last name is not always much of a distinction, and I happily put my email address, I got no problem with that
[08:42:23] <cradek> it's true - it can be hard to find authors even when they intend that you can find them
[08:42:36] <cradek> we have had this problem
[08:42:52] <maximilian_h> I can imagine
[08:44:09] <cradek> aha, we already have some commits with that name, so this will make it no worse
[08:44:38] <maximilian_h> Well I will post my patches to emc-developers again, and then you can decide what to do with them regarding the name matter. I do not care if I get credit or not. I just do not want to touch the same problems in a year or two with the next version.
[08:44:59] <cradek> I think it will be fine
[08:45:01] <cradek> thank you
[08:45:23] <maximilian_h> k
[08:45:34] <maximilian_h> till later
[09:03:19] <pcw_home> are meters ever uses in gcode scaling
[09:03:27] <pcw_home> used
[09:11:49] <archivist> a meter for measuring or a metre the distance
[09:15:36] <cradek> jthornton: on these (day job) machines I just install nvidia-glx package
[09:15:59] <cradek> "using info from the web" is really not very specific
[09:16:45] <cradek> then in xorg.conf change "vesa" to "nvidia"
[09:17:03] <mozmck> does xorg.conf exist?
[09:17:50] <cradek> yeah
[09:18:02] <cradek> maybe the nvidia package generates it
[09:18:51] <cradek> (insert nvidia rant here)
[09:19:19] <mozmck> I'm using nvidia here on linuxmint 17.1, and I don't see an xorg.conf
[09:19:47] <mozmck> I used to have to play with that file often, mainly because X would not properly auto-detect my CRT monitors
[09:20:24] <cradek> is mint downstream of ubuntu? they may be in bed with nvidia in ways that debian isn't
[09:20:40] <cradek> ... so it might be different
[09:20:41] <mozmck> they quit using it long ago, but you could still create one and tweak values, and that was still in debian.
[09:20:53] <mozmck> yes, downstream of ubuntu.
[09:21:00] <mozmck> could be - I don't know.
[09:21:52] <mozmck> There is a button in the Nvidia settings dialog to "Save to X Configuration File"...
[09:22:31] <cradek> yeah that'll definitely write one out
[09:23:39] <mozmck> I don't see an xorg.conf in my wheezy VM (no nvidia)
[09:24:23] <pcw_home> metre. I guess the guys HSM sample on the forum must be in inches (so quite tiny) but he must have rather large accels if he is actually getting the IPM he claims
[09:25:11] <skunkworks> it is tiny..
[09:26:08] <cradek> he should configure sim according to the machine specs and try it
[09:28:01] <pcw_home> I get 26 seconds at 1200 IPM/3G new TP but of course even at 3G it cannot approach his IPM
[09:29:17] <cradek> 3G meaning 1200 in/sec2?
[09:29:25] <pcw_home> y
[09:29:40] <cradek> that would be quite the machine
[09:30:24] <skunkworks> I am running at 22 seconds with G64P.005Q.001 40in/sec^2
[09:35:04] <pcw_home> i get about 100 IPM max when machining
[09:37:49] <jthornton> cradek, I installed nvidia-glx first and that would not boot up much past the kernel selection screen
[09:38:35] <jthornton> actually when I create an xorg.conf file is when it locks up while booting
[09:38:59] <cradek> does the nvidia-glx package install create a xorg.conf?
[09:39:10] <jthornton> yes
[09:39:13] <skunkworks> I found something wonkey in master... If you hit the estop - then refresh the file - linuxcnc hangs for 10's of seconds.. Or if you try to load another program..
[09:39:23] <cradek> and you change vesa to nvidia and then it won't boot?
[09:39:32] <jthornton> correct
[09:39:44] <cradek> hmmm
[09:39:57] <cradek> are you using debian's kernel or ours?
[09:40:01] <jthornton> there is no xorg.conf file when you first install wheezy
[09:40:08] <cradek> yeah
[09:40:53] <skunkworks_> *estop while a program is running
[09:43:15] <jthornton> according to this page I should be using nvidia-legacy-304xx-driver
[09:43:21] <jthornton> https://packages.debian.org/sid/nvidia-legacy-304xx-driver
[09:43:42] <cradek> oh is your card oldish?
[09:43:43] <jthornton> I have a GeForce 6150SE nForce 430 video
[09:43:59] <jthornton> might be 5 years old
[09:44:24] <jthornton> nvidia-detect says I should use nvidia-glx
[09:45:17] <jthornton> when I try and install the legacy drivers synaptic says the package is broken and won't install it
[09:45:34] <cradek> GeForce 6150SE nForce 430 0x03D0 -
[09:45:49] <jthornton> yep
[09:46:09] <cradek> ii nvidia-glx 304.125-1
[09:46:18] <cradek> this is what nvidia-glx on my wheezy system gave me
[09:46:33] <cradek> and that's listed in the supported cards in the package's docs
[09:49:50] <jthornton> downloading nvidia-glx
[09:50:11] <jthornton> I mean installing via synaptic
[09:50:47] <pcw_home> ahh the accels are limited by funny feed rate manipulation in the file, thats why my high accel test doesn't make it any faster
[09:51:33] <jthornton> The Nvidia driver is not yet configured; it needs to be enabled in xorg.conf before it can be used.
[09:51:33] <jthornton> Please see the package documentation for instructions.
[09:51:46] <cradek> yeah that's normal
[09:52:20] <cradek> I think changing vesa to nvidia is the only change I make on these machines (I scripted it long ago, y'know)
[09:53:27] <cradek> er no!
[09:53:33] <cradek> Xorg -configure
[09:53:33] <cradek> mv /xorg.conf.new /etc/X11/xorg.conf
[09:53:36] <cradek> sed -i s/vesa/nvidia/ /etc/X11/xorg.conf
[09:58:00] <jthornton> john@zotac:~$ Xorg -configure
[09:58:01] <jthornton> Fatal server error:
[09:58:01] <jthornton> Server is already active for display 0
[09:58:01] <jthornton> If this server is no longer running, remove /tmp/.X0-lock
[09:58:01] <jthornton> and start again.
[09:58:14] <cradek> you can't be in X when you do that
[09:58:25] <jthornton> lol
[10:01:15] <pcw_home> ok so if the accel is limited to 1G but the feed rate is not limited I get 8 seconds
[10:02:01] <skunkworks> heh
[10:02:49] <pcw_home> the TP goes wonky at really high accels but then so do the mechanics
[10:03:23] <skunkworks> pcw_home, do you get a 'line can't have zero length' at those acc's?
[10:04:58] <skunkworks> that is 400in/s^2?
[10:06:43] <jthornton> Mick has responded with some instructions for me
[10:06:58] <jthornton> be back in a bit
[10:07:39] <skunkworks> heh - I don't think the screen refresh is fast enough to draw that.. ;)
[10:08:17] <pcw_home> no, havent seen that error for a while but i'm running at 4 KHz servo thread
[10:08:26] <skunkworks> ah - ok
[10:10:20] <seb_kuzminsky> cradek: is the patch that maximilian sent you a fix for the pyvcp regression in 2.6?
[10:10:20] <pcw_home> ~3 seconds at 10G :-)
[10:11:35] <cradek> seb_kuzminsky: yes I think so. he said he's going to repost on -devel but I don't see it yet.
[10:11:41] <seb_kuzminsky> ok cool
[10:12:00] <seb_kuzminsky> i just repro'd his issue, so a fix would be welcome
[10:14:36] <seb_kuzminsky> the sf lists have been kinda flaky for me lately
[10:15:22] <skunkworks> pcw_home, do you get the 'already splitting...' though?
[10:16:09] <skunkworks> Does someone have master available to test the above issue?
[10:16:32] <skunkworks> (estop while program is running - then try to reload the file)
[10:16:56] <pcw_home> no I dont get any warnings
[10:17:12] <skunkworks> huh. ok
[10:17:20] <pcw_home> at a least on the HSM sample file
[10:17:30] <pcw_home> just tried at 1 KHz
[10:17:58] <skunkworks> maybe a differnce between sim/realtime.. I will have to play with it more.
[10:18:40] <pcw_home> yeah this is real time
[10:30:15] <pcw_home> the feed rates in the sample file s limit accels to ~ .1G
[10:47:49] <skunkworks> that makes sense.
[12:33:05] <KGB-linuxcnc> 03Norbert Schechner 052.6 b778709 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_1_4 - bug because I missed two self. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b778709
[12:33:35] <KGB-linuxcnc> 03Norbert Schechner 052.7 d58cf2b 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d58cf2b
[12:34:21] <KGB-linuxcnc> 03Norbert Schechner 05master 1e71868 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1e71868
[12:40:43] <pcw_home> skunkworks: I do see that hang occasionally when you hit estop
[12:40:45] <pcw_home> and the "line cant have zero length" error sporadically in master
[12:43:39] <pcw_home> once its in the state that file reload hangs the GUI, reloading again hangs again
[12:51:31] <pcw_home> and estop is not needed, machine off does the same
[12:52:10] <zeeshan|2> http://pastebin.com/miSMiUcv
[12:52:17] <zeeshan|2> why does stack smashing occur?
[12:52:31] <zeeshan|2> am i trying to add an additional element to a an array that's already full somewhere inmy code?
[13:43:39] <skunkworks> pcw_home, great (well you know) so I isn't just me..
[13:44:21] <pcw_home> I wonder if 2.7 behaves the same
[13:44:56] <skunkworks> well robs feature branch which is based on 2.7 does it.
[13:47:59] <pcw_home> this is preemt-rt, not that it matters
[14:07:50] <cradek> maximilian_h: cool, thanks
[14:37:56] <seb_kuzminsky> zeeshan|2: we're going to need more information to help you
[14:38:17] <seb_kuzminsky> what is hf430rtu?
[14:38:22] <zeeshan|2> seb_kuzminsky: it was my fault
[14:38:41] <zeeshan|2> i was trying to add stuff beyond the array's index
[14:38:44] <zeeshan|2> seemed to fix it
[14:39:09] <zeeshan|2> userspace comp
[14:42:53] <seb_kuzminsky> ok
[16:09:15] <linuxcnc-build> build #1260 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1260 blamelist: Norbert Schechner <nieson@web.de>
[16:26:00] <linuxcnc-build> build #2922 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2922 blamelist: Norbert Schechner <nieson@web.de>
[17:24:32] <KGB-linuxcnc> 05dgarr/use_hallib 010cc96 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=010cc96
[17:25:02] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/halcheck 225eb0e 06linuxcnc 10docs/src/config/ini_config.txt 03lib/hallib/halcheck.tcl 10tcl/twopass.tcl halcheck: library halfile to check common errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=225eb0e
[17:53:38] <linuxcnc-build> build #1100 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1100 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:01:30] <linuxcnc-build> build #2923 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2923 blamelist: Dewey Garrett <dgarrett@panix.com>
[18:35:52] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/halcheck 24725c5 06linuxcnc 10docs/src/config/ini_config.txt 10lib/hallib/README 03lib/hallib/halcheck.tcl 10tcl/twopass.tcl halcheck: library halfile to check common errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24725c5
[19:15:47] <mozmck> I notice that in a python program, there is a hal-pin-changed signal - can something like this be done in C as well?
[19:57:55] <KGB-linuxcnc> 03Dewey Garrett 052.7 a8bef41 06linuxcnc 10docs/src/config/ini_config.txt 10lib/hallib/README 03lib/hallib/halcheck.tcl 10tcl/twopass.tcl halcheck: library halfile to check common errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a8bef41
[19:58:48] <KGB-linuxcnc> 05dgarr/halcheck 24725c5 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24725c5
[22:58:23] <KGB-linuxcnc> 03Dewey Garrett 052.7 bad7066 06linuxcnc 10docs/src/config/ini_config.txt 10lib/hallib/halcheck.tcl halcheck: suppress gui if no errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bad7066