Back
[00:13:38] <memleak> hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[10:04:23] <jepler> seb_kuzminsky: we're switched over to buildbot-build docs on www.l.o? that's great.
[10:28:47] <seb_kuzminsky> yeah the switch is done
[10:28:52] <seb_kuzminsky> jepler: ^^^
[10:29:08] <seb_kuzminsky> your suggestion to move the $HOME/docs symlink worked, as far as i can tell
[11:00:55] <jepler> OK.
[11:01:00] <jepler> I admit to having forgotten how it fits together
[15:00:54] <kwallace> Hello, I'm still trying to find what makes my probing routines pause randomly. I've looked through the LinuxCNC debug messages and brought up the system monitor to see if any processes are hogging resources, but everything is idle except python at around 4%.
[15:01:21] <kwallace> This makes me think that something is waiting for input or for some event to happen, but why would it be random, and affected by mouse or key activity?
[15:02:11] <kwallace> I am sending MDI commands through the LinuxCNC python interface.
[15:05:30] <cradek> andypugh: thanks for fixing U canned cycles. funny that maybe nobody has ever used one...
[15:06:16] <cradek> andypugh: I agree about not knowing what changing planes while in cycle mode should do. perhaps we should just disallow it if it's unclear.
[15:09:22] <andypugh> Does making a plane-changes also issue a G80 (or equivalent) solve the problem?
[15:10:36] <kwallace> andypugh: Did you drive a train today?
[15:10:56] <andypugh> A fire engine
[15:11:24] <kwallace> Oops, just as good.
[15:11:52] <cradek> andypugh: perhaps
[15:12:37] <cradek> andypugh: I'd (slightly) rather cause an existing maybe-mistaken-but-surely-weird program to error than to change its motion
[15:13:08] <andypugh> Yes, I guess that is more conservative
[15:13:14] <cradek> andypugh: that nobody runs into this tells me that nobody has ever really done it on purpose with expectations
[15:14:00] <andypugh> Yeah, I guess folk may have tried it, thought "that's unusual" and decided to put a G80 on there.
[15:14:16] <cradek> yes maybe so
[15:14:41] <cradek> running cycles in different planes consecutively without even a rapid in between is a situation I have trouble imagining
[15:15:22] <andypugh> Yes, it is a pretty odd thing to do. I only did it because I was testing a change, and wanted to make sure I had fixed every plane.
[15:17:08] <cradek> that makes you awesome
[15:19:30] <kwallace> Are there any issues with sending MDI commands batch style rather than being throttled by human typing?
[15:19:44] <andypugh> Not especially, there is a separate switch-case for every plane.
[15:20:16] <andypugh> (That was a reply to cradek not kwallace )
[15:20:22] <cradek> kwallace: that's certainly unusual, so it would take some hubris to answer no
[15:21:08] <cradek> andypugh: and to my embarrassment, I screwed one of them up years back, which you found after I was discouraging you from refactoring it
[15:21:17] <cradek> which is pretty funny, actually
[15:22:00] <andypugh> Claim is was an Easter-egg to see if anyone ever used that plane.
[15:23:46] <andypugh> kwallace: I caught a bit of the edge of some discussions about remote MDI and GUI commands fighting each other.
[15:24:54] <andypugh> Someone on the forum had an analogue input pin that was sending a new spindle-override setting every time the LSB twiddled, and that was causing funny delays.
[15:26:10] <kwallace> Should that show up on the system monitor as a resource hog?
[15:27:42] <andypugh> Maybe.
http://linuxcnc.org/lucid/emc2/index.php/italian/forum/38-general-linuxcnc-questions/27113-bridgeport-retrofit-keyboard-input-delays-noted?start=60
[15:28:03] <andypugh> (Solved at around 40178)
[15:29:42] <cradek> no, it showed up in the task-issue debug messages
[15:33:05] <kwallace> From what I could tell from my Task debug logs, the logs look the same whether there is a pause or not.
[15:44:38] <cradek> andypugh: can you close
http://sourceforge.net/p/emc/bugs/337/ now?
[15:46:35] <andypugh> It looks like I can. Interesting, last time I tried, i couldn't.
[15:46:44] <andypugh> (Not that issue, a different one)
[15:47:00] <cradek> awesome
[15:49:28] <kwallace> Could there be a problem with having the probing done in another python thread?
[15:50:14] <andypugh> I will just say now that I am not ignoring your questions, I just have no clue.
[15:51:37] <cradek> the symptoms you report [that you are issuing commands with python and therefore it can't be a gui problem BUT it responds to wiggling the mouse] are so bizarre and unlikely that I don't know what to suggest except to be careful that you are not blinded by trees to some forest
[15:52:21] <kwallace> I understand, but if I don't put the questions out... well.
[15:53:18] <cradek> what would someone have to do to see the problem?
[15:55:37] <kwallace> Another bizarre event was using our file screen to drag a bunch of .ngc files to a subdirectory. I changed to the main screen and a half minute latter the file icons pop up on top and drag themselves around.
[16:00:55] <kwallace> cradek: I think it has to do with our UI so there really isn't a way to reproduce the problem on another machine. I'm just out of my depth, but giving it a try anyway.
[16:01:17] <cradek> so if you use another gui the problem goes away?
[16:04:41] <kwallace> The MDI calls are in our GUI. I don't think any other GUI does this, maybe GScreen but I haven't looked.
[16:04:52] <andypugh> kwallace: Can you remind me who the "we" is here?
[16:05:50] <andypugh> Not that it matters, I guess.
[16:06:00] <kwallace> (tor--ch)
[16:06:23] <andypugh> Yeah, that was my guess.
[16:06:57] <andypugh> I am rather concerned about the tool-change patch too, it's bugging SRT
[16:10:12] <cradek> what's SRT?
[16:11:29] <cradek> kwallace: perhaps dodge the whole problem by writing a file and using O-call for "macro" type stuff. that's how touchy does macros.
[16:11:44] <cradek> or just open and run the file like normal
[16:12:09] <cradek> I suspect MDI o-call is well used, since people do it with halui
[16:13:15] <kwallace> That sounds better.
[16:16:21] <kwallace> Plus, I can stop stressing over it.
[16:18:36] <andypugh> SRT is "Superior Roll and Tool". They have quite a lot of LinuxCNC lathe installations doing real industrial stuff. There is a very interesting perspective.
[16:19:45] <andypugh> (Sorry, name wrong:
http://www.superiorroll.com/index.html
[16:20:16] <andypugh> (They aren't great with HTML)
[16:24:10] <kwallace> When I got started with HTML, I recall W3 was fighting to keep HTML as a content manager and claimed it was not for layout. That didn't work out too well for them.
[16:24:10] <cradek> http://www.superiorroll.com/products/1.jpg
[16:24:24] <cradek> I get the impression surface finish is important for that stuff
[16:25:23] <cradek> they retrofit Turks Heads and Scarfing Units!
[16:27:14] <kwallace> I was wondering where I could have that done -- now I know.
[16:41:15] <andypugh> If you have seen Rick Lair pop up on the mailing list or forum, I think he works there.
[16:42:11] <andypugh> It's intersting that the machinists resist conversion to LinuxCNC. We have work to do there to see what the problem is. (reguarly corrupted tool tables won't help)
[16:45:16] <cradek> yes FUD is bad enough - but when it actually works badly that is worse
[16:45:46] <cradek> I wish we had a sane way to do wear offsets
[16:46:05] <Tom_itx> those look similar to some roll forms we made for our neighbor shop
[16:46:19] <cradek> it seems like such an easy problem
[16:46:49] <andypugh> cradek: It is something I am actively working on. But is a project that has grown in scope.
[16:47:54] <andypugh> For example, you end up looking at iocontrol.c and thinking "Do I really want to bodge this again, or do it all a different way"
[16:48:11] <cradek> heh do you mean iocontrol or iocontrol_v2?
[16:48:21] <andypugh> Both
[16:48:49] <andypugh> iocontrol_v2 is also looking like a dead end to me.
[16:49:05] <andypugh> Nearly all of that should be loadable HAL modules.
[16:49:06] <cradek> sure both of them are dead ends
[16:50:02] <andypugh> Not wanting to put words into his mouth, but I think mah sees iocontrol_v2 as a wrong turn.
[16:50:51] <cradek> I forget what the differences are
[16:52:12] <andypugh> I have some aspects of a) an infinite tool table b) an infintie tool table with Fanuc-styl offsets and c) A factory-wide tool table with offsets, alternatives and current location sort-of working.
[16:53:14] <andypugh> But, I have no tool editor, the GUI's don't see the data, and tool changers are unaware.
[16:54:46] <andypugh> I actually had all that by the end of Wichita, but it is a long way from release ready and might actually want to wait for the prophesised "Death of NML" even.
[16:56:02] <andypugh> I probably ought to have created a preview branch by now, I am beginning to think.
[16:56:26] <andypugh> But it still feels too far from useful.
[16:56:43] <cradek> that's a tough stage
[16:57:05] <cradek> you want to share it to get help and input, but you sure don't want users trying to give you feedback
[16:57:55] <andypugh> Especially not "your branch trashed my mill"
[16:58:07] <Tom_itx> heh
[16:58:36] <cradek> Especially not "how do I compile!?!?"
[17:00:27] <andypugh> It's taken a bit of a back seat to the new toy (Rivett) and the easy hm2 stuff (SSI, BISS, Fanuc encoders) for the last few months. Largely becasue the SSI etc stuff just kept growing
[17:04:27] <cradek> it's not your fault that there's only one of you.
[17:05:31] <andypugh> it's probbaly a good thing there is only one of me :-)
[17:06:47] <andypugh> But I do feel a bit guilty that I announced "OK, I got this" a year or so ago and haven't actually produced.
[17:08:45] <cradek> well a year isn't very long, and you're a volunteer.
[17:11:22] <andypugh> I was raised as a Catholic. If we can't find something to feel guilty of, then we are guilty of Pride.
[17:13:25] <andypugh> On a different tack. Is dfg2gcode part of the standard install?
http://www.linuxcnc.org/index.php/english/forum/36-using-this-forum-questions/27172-dxf2gcode#40521
[17:14:27] <cradek> no
[17:14:46] <andypugh> That explains it then.
[17:14:58] <cradek> they followed instructions from ... somewhere
[17:16:27] <andypugh> Probably the Forum, or the Wiki, or some other un-checked source.
[17:20:59] <andypugh> I feel an urge to buy Laurent some proper hold-down clamps.
http://www.linuxcnc.org/index.php/english/forum/20-g-code/27161-cnc-g-code-basics-explained-part-2#40444
[17:36:20] <cradek> the 10m manual doesn't say whether you can switch planes in canned cycle mode
[17:38:49] <cradek> oh yes it does!
[19:50:24] <jepler> kwallace: you mentioned threads in passing. i doubt it is ok to use the same nml object from two threads.
[19:52:36] <jepler> though if it's all driven from python without allow_threads that may be ok
[20:38:00] <kwallace> jepler: Thank you, I'll look into it.
[21:15:13] <cradek> seb_kuzm1nsky:
https://sourceforge.net/p/emc/bugs/319/ seems like another 2.6?
[21:17:41] <cradek> arrgh now whenever I edit a bug it gets assigned a milestone -- there is no "none" option.
[21:29:52] <KGB-linuxcnc> 03ben 05master 67bb7b9 06linuxcnc 10src/hal/components/blend.comp * blend: Make the docs match the component behavior
[21:32:31] <seb_kuzm1nsky> cradek: yes, thanks
[21:32:39] <seb_kuzmisnky> whoops
[21:32:49] <cradek> the sf bugtracker comments display extra backslashes. they probably have incorrect quoting in their sql.
[21:33:39] <seb_kuzminsky> at some point i want to look at each of our 330+ bugs and figure out which ones to close/fix/postpone
[21:34:08] <seb_kuzminsky> i made a "2.next" milestone to mean "at some point later"
[21:34:09] <cradek> I've closed a few tonight (and unwittingly assigned them the 2.6 milestone)
[21:34:15] <seb_kuzminsky> thanks
[21:34:52] <cradek> I guess if they're closed they'll be in 2.6 and that's kind of a little bit appropriate sorta
[21:36:52] <seb_kuzminsky> i can make that make sense in my head
[23:13:01] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 27c22c7 06linuxcnc 10Bug/ 10(26 files in 2 dirs) * config files from Alan (the OP)
[23:13:01] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 40d64a7 06linuxcnc 10Bug/crp4848-probekins/ 10custom.hal 10custom_postgui.hal 10custompanel.xml * cleanup OP's config: remove execute permissions
[23:13:06] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 585d9c3 06linuxcnc 10Bug/crp4848-probekins/ 10(25 files in 2 dirs) * cleanup OP's config: move subs to a subdir
[23:13:12] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi bba1492 06linuxcnc 10Bug/crp4848-probekins/ 10crp4848.hal 10custom_postgui.hal * tweaks to make it break a little less
[23:13:19] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 051245d 06linuxcnc 10Bug/crp4848-probekins/ 10custom.hal 10custom_postgui.hal * comment out everything that prevents linuxcnc from starting up
[23:13:27] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 3b4930e 06linuxcnc 10Bug/crp4848-probekins/custom_postgui.hal * fix dos-style line endings
[23:13:33] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 601a673 06linuxcnc 10Bug/crp4848-probekins/subs/ 10(7 files) * fix perms
[23:13:40] <KGB-linuxcnc> 03seb 052.5.1-halui-probe-mdi 2215be1 06linuxcnc 03Bug/README * debugging notes
[23:13:46] <KGB-linuxcnc> 03seb 05contributor-docs-1 7e91f24 06linuxcnc 10docs/src/code/Using-git.txt * add quotes around external document name
[23:13:52] <KGB-linuxcnc> 03seb 05contributor-docs-1 21a7dab 06linuxcnc 10docs/src/code/Using-git.txt * add missing line breaks
[23:13:58] <KGB-linuxcnc> 03seb 05contributor-docs-1 897182f 06linuxcnc 10docs/src/code/Using-git.txt * using git updates
[23:14:04] <KGB-linuxcnc> 03seb 05contributor-docs-1 3128b81 06linuxcnc 10docs/src/code/Contributing-to-LinuxCNC.txt * add git tutorial to contributing doc
[23:14:11] <KGB-linuxcnc> 03seb 05v2.5_branch 887da22 06linuxcnc 10docs/src/config/stepconf.txt * rebranding stepconf docs
[23:14:17] <KGB-linuxcnc> 03seb 05vfd-b 060a43d 06linuxcnc 10src/hal/user_comps/vfdb_vfd/vfdb_vfd.c * vfd-b: finish rename from "vfs11"
[23:14:23] <KGB-linuxcnc> 03seb 05vfd-b ef4766c 06linuxcnc 03docs/man/man1/vfdb_vfd.1 * vfd-b: add a manpage
[23:14:29] <KGB-linuxcnc> 03seb 05vfd-b e92c383 06linuxcnc 10src/hal/user_comps/vfdb_vfd/vfdb_vfd.c * vfd-b: remove VF-S11 comments etc
[23:14:35] <KGB-linuxcnc> 03seb 05vfd-b 768cb26 06linuxcnc 10docs/man/man1/vfs11_vfd.1 * docs: rebrand emc2 to linuxcnc in vfs11_vfd manpage
[23:14:42] <KGB-linuxcnc> 03seb 05vfd-b-2 fbc7cc4 06linuxcnc 10docs/man/man1/vfdb_vfd.1
[23:14:44] <KGB-linuxcnc> vfd-b manpage: document DEBUG and MODBUS_DEBUG (and TYPE, though it should go away)
[23:15:23] <seb_kuzminsky> hrm, didnt mean to push all those temporary branches :-/
[23:17:08] <seb_kuzminsky> the 2.5 push was all i meant to do
[23:17:14] <seb_kuzminsky> that might mean its time for bed...
