Back
[02:21:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd 67dd6a5 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: fix the commanded freq calculation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=67dd6a5
[02:21:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd bd2e99e 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_modbus.c hy-vfd: improved communications error handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bd2e99e
[02:21:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd c2b543f 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: retry the initial read if it fails * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2b543f
[02:21:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd 3f31ef6 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: allow abort while waiting for communications to come up * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f31ef6
[02:25:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 905b456 06linuxcnc 03src/hal/components/differential.comp add a differential kinematics comp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=905b456
[02:25:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 d553870 06linuxcnc 10(5 files in 2 dirs) scorbot: use differential kins for the wrist * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d553870
[02:32:43] * archivist spots the differential comp
[02:34:24] <archivist> needed for a full hobbing implementation :)
[02:41:57] <seb_kuzminsky> i hobbe it helps
[02:42:34] <archivist> it is the elechant in the middle
http://www.collection.archivist.info/hobbing.html
[02:42:42] <archivist> of the diagram
[02:43:50] <seb_kuzminsky> i dont think so
[02:43:58] <seb_kuzminsky> it's the diff at the top of this pic:
http://highlab.com/~seb/linuxcnc/scorbot-er-3/0302152207.jpg
[02:44:27] <seb_kuzminsky> also visible here:
http://highlab.com/~seb/linuxcnc/scorbot-er-3/1024131507a.jpg
[02:45:31] <archivist> same sort as in the diagram just used differently
[02:45:42] <seb_kuzminsky> yeha
[02:46:06] <seb_kuzminsky> the differential component takes roll and pitch commands, and returns motor0 and motor1 position commands
[02:46:38] <seb_kuzminsky> it was kind of neat seeing two motors cooperate to home roll, then cooperate again to home pitch
[02:48:05] <archivist> in the hobbing machine it feeds distance back to rotate the table to match feed distance for helical gears
[02:51:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 67e9dc0 06linuxcnc 10debian/configure packaging: add support for building on newer Ubuntus * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=67e9dc0
[03:21:13] <seb_kuzminsky> show
[03:22:37] <seb_kuzminsky> oops heh, it looks fine, i'll push it
[03:22:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 62ce1bb 06linuxcnc 10debian/configure Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62ce1bb
[03:24:07] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 8df0f68 06linuxcnc 10docs/src/Submakefile Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8df0f68
[06:35:24] <skunkworks> zlog
[07:54:35] <skunkworks> I got a reply from rob. 'Awesome, that makes things easier. I've been getting behind here because of an approaching deadline at work, but I will try to get to this soon.'
[07:54:51] <skunkworks> I sent him the shorter gcode program and cradek's branch
[07:57:37] <skunkworks> I told him we needed it right now and this should take priority over any day job... ;)
[07:57:46] <skunkworks> or fiancee
[08:00:34] <skunkworks> zlog
[08:01:25] <skunkworks> <rogge> Seb - did Rob ever talk to you about state tags?
[09:13:44] <linuxcnc-build> build #1390 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1390 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Moses McKnight <moses@texband.net>, John Thornton <bjt128@gmail.com>
[09:16:12] <seb_kuzminsky> skunkworks: we talked briefly about it, but i was distracted by something else at the time, the arc tolerance thing i think
[09:16:32] <skunkworks> I am sure the closer they get their system to linuxcnc - the less work they need to do.
[09:16:39] <seb_kuzminsky> i remember cradek was in favor of it, but i haven't looked at it closely enough myself to form an opinion
[09:16:56] <skunkworks> I think there was questions on how to handle certain things.
[09:17:53] <seb_kuzminsky> iirc it lets the interpreter annotate outgoing motion commands so that motion can report where in the program it is more effectively?
[09:18:58] <seb_kuzminsky> something like that should be considered for master, not for 2.7
[09:19:09] <seb_kuzminsky> we need to get 2.7 fixed & released
[09:19:41] <seb_kuzminsky> speaking of which, i'm going to go look at the build failure from last night
[09:28:09] <linuxcnc-build> build #3240 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3240 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>, Moses McKnight <moses@texband.net>, John Thornton <bjt128@gmail.com>
[09:33:31] <cradek> I'm absolutely in favor of the annotations
[09:34:17] <cradek> however I'm wary about the running of gcodes at abort time to try to manipulate the gcode state backward from readahead state to runtime-equivalent state
[09:34:35] <cradek> when I looked at it, those two changes were together
[09:37:33] <cradek> I intended to study it more but then didn't :-/
[09:38:50] <cradek> skunkworks: yeah, for all the things we agree on, it's absolutely best for everyone if they push them up to us
[09:39:27] <skunkworks> sure
[09:42:21] <skunkworks> (I would hope they keep using linuxcnc as the base...)
[09:48:57] <jepler> for ethernet latency, these folks found userspace busy polling with recvmsg(MSG_DONTWAIT) to be better than kernel busy polling or blocking readmsg.
[09:49:00] <jepler> https://blog.cloudflare.com/how-to-achieve-low-latency/#userspacebusypolling
[09:49:33] <AndroUser> Hello everyone
[09:50:23] <REEEN> I have a question to you guys, what is the pin limit in Hal ?
[09:50:49] <jepler> REEEN: the total number of pins is limited by the size of the HAL shared memory area
[09:50:52] <cradek> REEEN: number of pins is limited by the hal shared memory size, which you can adjust by rebuilding
[09:51:05] <jepler> REEEN: I don't know the specific number you can get with the current default, and as cradek says you can change this limit with a recompile
[09:51:08] <cradek> REEEN: I think the actual limit depends on things such as the length of pin names
[09:51:20] <jepler> in hal_priv.h
[09:51:21] <jepler> #define HAL_SIZE (75*4096)
[09:51:44] <REEEN> Is this the default value ?
[09:52:03] <REEEN> 75*4096 ?
[09:52:47] <cradek> do you have a problem you're trying to fix? if so what is it?
[09:54:09] <REEEN> Iam currently converting a machine which uses 100 io pins + 5 axes and i have a lot of comps with a lot of inputs, I don't want to get into trouble
[09:55:10] <jepler> halcmd status shows you information about the usage of the hal shared memory area
[09:55:14] <jepler> HAL memory status
[09:55:14] <jepler> used/total shared memory: 312/307200
[09:55:35] <cradek> ah I was just looking for that
[09:55:43] <REEEN> Okay very good !
[09:56:08] <REEEN> And if I run out of memory, I can adjust it ?
[09:56:46] <jepler> by changing HAL_SIZE and rebuilding linuxcnc.
[09:57:07] <REEEN> Okay, that sounds good
[09:57:31] <REEEN> One laat thing, you said it depends on pin names length ?
[09:57:50] <REEEN> Really ? Pin names length decreases memory ?
[09:58:00] <jepler> incidentally, a test component which does nothing but create float pins creates 3195 before running out of memory
[09:58:48] <REEEN> Okay :D over 3000 with the defualt ?
[09:58:55] <jepler> in my test, using "tmp.%d" as the name template I get the same number of pins as using the template "tmp.xxxxxx.%d"
[09:59:36] <REEEN> Sorry I didn't get it :/
[09:59:56] <jepler> for determining the number of pins that can be created, the name of the pin doesn't matter.
[10:00:11] <jepler> the length of the name of the pin doesn't matter
[10:00:27] <jepler> a pin called "x" takes the same amount of memory as a pin called "this-is-a-long-descriptive-name"
[10:02:49] <mozmck> Isn't the only thing in shared memory the pin data - not the name?
[10:03:12] <jepler> mozmck: the pin structure, hal_pin_t, is entirely in the shared memory area
[10:03:24] <mozmck> I see.
[10:03:25] <jepler> and that includes the place the name is stored, 'char name[HAL_NAME_LEN + 1];'
[10:03:55] <reeeeeen67> Sorry I lost my connection :/
[10:04:13] <cradek> jthornton: I can't find the updating instructions for 2.5->2.6 and 2.6->2.7 (the latter might not exist yet) and this also led me to finding that at
http://www.linuxcnc.org/docs/2.7/html/ when I open "Getting Started" and click "Updating LinuxCNC" it's a broken link.
[10:04:24] <mozmck> Seems like I remember the ulimits having an effect on the HAL size?
[10:04:29] <pcw_home> we have customers using >200 I/O without an issue
[10:04:30] <pcw_home> I think the default shared memory size has bumped up a number of times
[10:04:33] <jepler> reeeeeen67: log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-07-01.html
[10:04:47] <jepler> pcw_home: we seem to double it every couple of releases
[10:05:01] <jepler> 300kB is tiny on almost any system where you'd run linuxcnc
[10:05:24] <pcw_home> yeah but a lot of pins...
[10:05:34] <jepler> looks like the last increase was in 2014 by me, so that would be in 2.7 and not in 2.6.
[10:06:03] <jepler> increases in 2014, 2009, 2006
[10:06:28] <reeeeeen67> Okay that sounds good thank you
[10:06:49] <reeeeeen67> Does the ha memory depend on the threads period ?
[10:06:50] <jepler> increases in 2014, 2009, 2006. the 2014 increase was intended to be approximately proportional to the increase in name length, which went from 41 to 47
[10:06:55] <jepler> reeeeeen67: no
[10:07:34] <reeeeeen67> Is it good to use a slower thread for pins that don't need a fast one ?
[10:08:31] <reeeeeen67> or doesn't this affect performancein any way ?
[10:08:44] <jepler> if you mean "slower than the servo cycle", probably not
[10:08:53] <reeeeeen67> Yes slower
[10:09:22] <reeeeeen67> Okay, so using the servo cycle is enough ?
[10:09:55] <jepler> look at the .time and .tmax (parameters) of the functions you use to read and write your I/Os. If it's large relative to a typical 1 to 2kHz servo period, then yes you may need to use a slower thread
[10:11:16] <jepler> (I forget, are time/tmax in CPU cycles or in nanoseconds?)
[10:11:27] <reeeeeen67> Nano
[10:11:44] <pcw_home> CPU cycles
[10:11:49] <reeeeeen67> Iam using mesa boards for my input
[10:11:58] <reeeeeen67> Sorry you are right
[10:12:26] <Roguish> cradek: just put the gmocappy issue on the forum. maybe cmorley or norbert will respond.
[10:12:46] <cradek> did you reproduce the problem while watching top?
[10:13:46] <reeeeeen67> Thank you all !
[10:15:24] <Roguish> cradek: not yet. i'm not milling now. maybe later this afternoon. is there a handy dandy little 'performance monitor' in debian?
[10:16:32] <cradek> top
[10:16:32] <cradek> use top
[10:16:36] <cradek> top is the thing to use
[10:17:07] <archivist> I always have an instance of top running
[10:18:55] <Roguish> I will look for 'top' thanks.
[10:27:24] <skunkworks> I use top
[10:27:28] <skunkworks> ;)
[10:32:44] <seb_kuzminsky> cradek: the 2.6->2.7 updating instructions are written & were available, but got lost in the recent docs reorg
[13:00:12] <JT-Shop> I fixed that but need to either stash what I'm working on now or finish so I can push
[13:13:05] <seb_kuzminsky> JT-Shop: do you have a working directory with several unrelated changes, some finished and some still in progress? there's a git command for that!
[13:20:09] <JT-Shop> yes I do
[13:20:18] <JT-Shop> git stash or something like that
[13:20:45] <seb_kuzminsky> you can do that, and sometimes that's the easiest way
[13:21:27] <seb_kuzminsky> but often i prefer to use "git gui" to select the files (or parts of files) that i want to commit, and leave the rest of the changes behind in the working tree
[13:22:22] <JT-Shop> I already commited the fix but have uncommited changes left over
[13:22:38] <JT-Shop> I think you can't push unless you have everything commited
[13:22:58] <seb_kuzminsky> that's not true, you can push at any time
[13:23:17] <seb_kuzminsky> you generally can't switch branches if you have a dirty working tree
[13:23:33] <JT-Shop> ah, I knew it was something or other
[13:23:49] <JT-Shop> let me get these parts in the powder coat oven and go see
[13:23:55] <seb_kuzminsky> cool
[13:32:34] <kwallace> Since we are on git, I deleted a file. We I pushed, git status showed the file as deleted. I did a git add on the rest of the files and pushed. Now git status says:
[13:32:37] <kwallace> kwallace@jupiter:~/repos/tormach_linuxcnc$ git status
[13:32:37] <kwallace> # On branch develop
[13:32:38] <kwallace> # Your branch is up-to-date with 'origin/develop'.
[13:32:38] <kwallace> #
[13:32:38] <kwallace> # Changes to be committed:
[13:32:38] <kwallace> # (use "git reset HEAD <file>..." to unstage)
[13:32:38] <kwallace> #
[13:32:39] <kwallace> # deleted: configs/tormach_lathe/python/stdglue.py
[13:32:39] <kwallace> #
[13:33:16] <kwallace> I can't seem to git rid of the non-existent file.
[13:34:33] <kwallace> s We/then
[13:36:18] <kwallace> Oops. strike "We I pushed"
[13:36:42] <seb_kuzminsky> kwallace: you need "git rm $FILE"
[13:37:21] <seb_kuzminsky> by using the non-git rm, you removed the file from your working directory but did not inform git that you want to also remove it from the repo
[13:37:43] <kwallace> kwallace@jupiter:~/repos/tormach_linuxcnc$ git rm configs/tormach_lathe/python/stdglue.py
[13:37:43] <kwallace> fatal: pathspec 'configs/tormach_lathe/python/stdglue.py' did not match any files
[13:38:01] <seb_kuzminsky> i think it's "git rm -f" when it's after the fact
[13:38:12] <kwallace> Hmm...
[13:38:43] <kwallace> same result.
[13:38:44] <seb_kuzminsky> or you're in the wrong directory - you give "git rm" relative paths from where you are, just like with regular shell rm
[13:38:49] <seb_kuzminsky> pwd?
[13:39:00] <KGB-linuxcnc> 03John Thornton 052.7 7365f2d 06linuxcnc 10docs/src/index.tmpl Docs: fix typo in link * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7365f2d
[13:39:08] <seb_kuzminsky> yay thanks JT-Shop
[13:39:18] <kwallace> I just copy what git status lists.
[13:39:57] <seb_kuzminsky> kwallace: oh wait, your paste shows that the file has already been removed from the index
[13:39:59] <jthornton> ok it won't let you git pull --rebase I knew it was something like that
[13:40:10] <seb_kuzminsky> it's listed under "changes to be committed"
[13:40:22] <seb_kuzminsky> so you should be able to say "git commit" now and it will make a commit removing that file from the repo
[13:40:45] <kwallace> Duhhh.
[13:40:53] <seb_kuzminsky> maybe i should actually read what the problem is before offering suggestions on how to fix it....
[13:42:41] <jthornton> what led me to that error was that the documents have 3 naming styles, humpy back, lower case, and some use - and some use _ to separate words.
[13:42:42] <kwallace> Yay, commit fixed it. Thank you.
[13:42:52] <seb_kuzminsky> kwallace: oh good :-)
[13:43:13] <seb_kuzminsky> jthornton: yeah, that's annoying and error-prone
[13:43:24] <seb_kuzminsky> thanks for fixing it
[13:43:27] <jthornton> I'm in favor of document-title.txt which is easier to type than Document_Title.txt
[13:43:43] <seb_kuzminsky> seconded
[13:43:48] <jthornton> done
[13:43:58] <seb_kuzminsky> the ayes have it
[13:44:01] <seb_kuzminsky> bbl
[13:44:07] <jthornton> YEA!
[13:47:19] <kwallace> ay yai yai
[18:59:45] <kwallace> Hello. I'm trying to install linuxcnc-dev . I'm using the wiki instructions and did the git get here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Getting_the_source_with_git which worked fine.
[19:00:25] <kwallace> I did the dependency bit:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Resolving_outstanding_build_dependencies
[19:01:03] <kwallace> Next:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Building_LinuxCNC_realtime
[19:02:05] <kwallace> but "make" returns:
[19:02:08] <kwallace> kwallace@jupiter:~/linuxcnc-dev/src$ make
[19:02:09] <kwallace> Makefile:71: Makefile.inc: No such file or directory
[19:02:09] <kwallace> Makefile:82: *** Makefile.inc must specify RTPREFIX and other variables. Stop.
[19:02:09] <kwallace> kwallace@jupiter:~/linuxcnc-dev/src$
[19:03:16] <kwallace> ls shows a Makefile.inc.in
[19:07:56] <kwallace> I AssUMed the file should be Makefile.inc so I renamed it. But now I get:
[19:08:09] <kwallace> kwallace@jupiter:~/linuxcnc-dev/src$ make
[19:08:09] <kwallace> Reading 0/174 dependency files
[19:08:09] <kwallace> Done reading dependencies
[19:08:09] <kwallace> if [ -f config.status ]; then ./config.status --recheck; else \
[19:08:09] <kwallace> echo 1>&2 "*** linuxcnc is not configured. Run './configure' with appropriate flags."; \
[19:08:10] <kwallace> exit 1; \
[19:08:10] <kwallace> fi
[19:08:11] <kwallace> *** linuxcnc is not configured. Run './configure' with appropriate flags.
[19:08:11] <kwallace> make: *** [config.status] Error 1
[19:08:12] <kwallace> kwallace@jupiter:~/linuxcnc-dev/src$
[19:08:36] <kwallace> I'm at a loss now.
[19:10:00] <kwallace> Crud, going back in the output shows configure didn't finish.
[19:11:06] <kwallace> configure: error: Tclx not found!
[19:11:06] <kwallace> install with "sudo apt-get install tclx"
[19:16:54] <kwallace> Yay, it worked. Never mind.
[19:23:36] <kwallace> Any ideas on making it easier for the next guy/gal?
[19:39:11] <mozmck> hmm, tclx should be a dependency of the runtime package I think
[19:40:28] <mozmck> What version are you working with?
[20:17:57] <mozmck> Is there a way in python to connect to a hal pin 'value-changed' signal if the pin was not created in python?
[20:29:47] <kwallace> mozmck, I used "git clone git://git.linuxcnc.org/git/linuxcnc.git linuxcnc-dev" so I assume it's the current master.
[20:32:01] <kwallace> I also did "dpkg-checkbuilddeps", which didn't complain about tclx being mia.
[20:33:14] <kwallace> Just a note on the webpage to check for tclx would do.
[20:34:48] <mozmck> kwallace: well, it is a dependency of the runtime package, so it would not be picked up by dpkg-checkbuilddeps
[20:35:02] <kwallace> Just as is this page has been a big help, thanks to those who maintain it.
[20:35:28] <mozmck> Maybe it should be a build dependency though? I don't know.
[20:35:51] <kwallace> I know less.
[21:19:24] <kwallace> What is the new name for comp?
[21:20:02] <kwallace> halcompile
[21:40:35] <seb_kuzminsky> mozmck: no, tclx is not used by the build process anywhere, so it should not be a build dependency
[21:41:01] <seb_kuzminsky> it is used by some of the programs (latency-histogram and friends, i think?), so it should be (and is) a runtime dependency
[21:42:00] <seb_kuzminsky> i keep meaning to turn the Installing_LinuxCNC wiki page into an asciidoc file to be built with the rest of our real, maintained docs
[21:42:27] <seb_kuzminsky> in the Developer's Manual somewhere
[22:10:08] <kwallace> So which is it, comp or halcompile? The current master has a man page for halcompile but can't find the program. I installed linuxcnc-dev with Synaptic and now man comp and comp --install work.
[22:13:56] <mozmck> seb_kuzminsky: Looks like that page could use a lot of updates...
[22:31:23] <cmorley> mozmck: 'value-changed' - no only pins that hal_glib.py knows about are polled for gobject signals
[22:31:58] <mozmck> cmorley: thanks. The hal_glib code is hard to understand.
[22:32:19] <mozmck> I see a getpin function, but I tried following it back and can't figure out what it does
[22:33:20] <mozmck> Is there a way to disable the message about the probe input closing while jogging?
[22:33:30] <cmorley> yes. Pavel is very smart.
[22:35:14] <cmorley> I believe that is a 'linuxcnc proper' error, nothing to do with gladevcp..got go... phone call
[22:35:24] <mozmck> ok
[22:44:36] <seb_kuzminsky> kwallace: in 2.6 and earlier it's called comp, in 2.7 and later it's halcompile
[22:45:26] <seb_kuzminsky> kwallace: what version of linuxcnc-dev do you have? i bet it's 2.6 or older
[22:45:57] <mozmck> seb_kuzminsky: do you know if there is a way to disable the "probe input tripped while jogging" message?
[22:46:44] <mozmck> That is something that will happen commonly for our setups
[22:47:50] <seb_kuzminsky> mozmck: debounce your probe input?
[22:48:36] <seb_kuzminsky> what i mean is: that sounds like a hardware problem
[22:48:43] <mozmck> No, the probe input is tied to the ohmic sensor on a plasma torch tip.
[22:49:03] <mozmck> For setup, it is common to run the tip down until it touches the metal and zero it.
[22:50:41] <mozmck> manually that is. So I'm jogging down until the input switches on purpose.
[22:53:36] <seb_kuzminsky> hmm
[22:54:20] <seb_kuzminsky> what if the motion.probe-input pin got "probe-gpio.in AND NOT torch-on"?
[22:55:08] <mozmck> Hmm, so if the torch is not on the probe-input would never go active?
[22:55:45] <seb_kuzminsky> right
[22:55:53] <seb_kuzminsky> no wait
[22:55:59] <mozmck> No, we only do a probing move when the torch is off.
[22:56:26] <seb_kuzminsky> the probe input to motion would only see True when the mesa probe pin goes true *and* the torch is *not* on
[22:56:45] <mozmck> In gcode after stopping a cut we will do a probe before starting the next cut to see where the metal really is now.
[22:57:02] <seb_kuzminsky> but you do the probe with the torch off, right?
[22:57:15] <mozmck> Yes, but we also jog with the torch off.
[22:57:30] <seb_kuzminsky> when do you see phantom probe trips?
[22:57:46] <mozmck> It's not phantom, it's when I jog the tip down to touch the metal :)
[22:58:01] <seb_kuzminsky> isnt that what you want?
[22:58:20] <mozmck> Yes, but I don't want linuxcnc to pop up a warning about it.
[22:58:42] <seb_kuzminsky> ah
[22:58:58] <seb_kuzminsky> i had assumed you used a probe move, not a jog, to go down and touch the torch to the metal
[22:59:30] <mozmck> We do when running gcode, but it's common to just manually jog down when setting up.
[22:59:50] <seb_kuzminsky> i'd add a pyvcp button to do a probe move down to the work
[23:00:43] <mozmck> Well, I can do that, but when a user jogs down and touches the metal even accidentally I'd like to inhibit that message if I can.
[23:01:13] <mozmck> Except it will be gladevcp since my gui is a custom Gscreen based one :)
[23:01:23] <seb_kuzminsky> what is the exact message? i dont see the one you said
[23:01:54] <mozmck> I don't remember exactly, I'll have to look again tomorrow when I go out to the shop.
[23:02:44] <mozmck> Thinking of the GUI, I have a new gladevcp widget HAL_LightButton, that it would be nice to get in 2.7 if you think it's alright.
[23:03:17] <mozmck> pasteboard
[23:03:19] <mozmck> oops
[23:04:22] <mozmck> Here's a shot of the gui with some lighted buttons.
http://pasteboard.co/1BSphh90.png
[23:08:04] <seb_kuzminsky> "Probe tripped during a jog"
[23:08:37] <seb_kuzminsky> there's currently no way to torn that off
[23:08:51] <mozmck> hmm, ok.
[23:09:41] <seb_kuzminsky> and i still think disabling the report of that condition is the wrong approach
[23:09:56] <seb_kuzminsky> most of the time you *want* to know when that hardware problem happens
[23:10:44] <mozmck> Yes, except on a plasma cutter (I think)
[23:11:17] <seb_kuzminsky> that looks nice
[23:11:40] <mozmck> thanks!
[23:11:43] <seb_kuzminsky> in general i think stand-alone things like new widgets and comps and drivers are fine to add almost any time
[23:12:10] <mozmck> I was thinking that might be the case. It won't affect anything existing already.
[23:12:25] <seb_kuzminsky> right, the risk to users is really low
[23:13:40] <seb_kuzminsky> i've never run a plasma machine (or even seen one live), but i imagine i'd want a "touch off to the work" button prominently on the gui, and it would use a probe move, and everything would be fine
[23:13:57] <seb_kuzminsky> and, i like commas
[23:15:04] <mozmck> heh!
[23:15:40] <mozmck> Looks like looking in control.c that it will abort the jog? That might actually be handy.
[23:16:15] <seb_kuzminsky> heh:
[23:16:16] <seb_kuzminsky> // not probing, but we have a rising edge on the probe.
[23:16:16] <seb_kuzminsky> // this could be expensive if we don't stop.
[23:16:24] <mozmck> yeah :)
[23:17:04] <seb_kuzminsky> i often get this warm fuzzy feeling when i worry about something in linuxcnc and go look at the source code and see that someone thought about this problem like 10 years ago
[23:17:35] <mozmck> yeah. They were thinking through things in detail.
[23:18:22] <mozmck> Or they destroyed a $10,000 piece of work :)
[23:18:56] <seb_kuzminsky> heh
[23:19:40] <seb_kuzminsky> looks like this behavior was added by alex joni and chris radek back in 2007
[23:20:01] <seb_kuzminsky> about that time i was excited i could get a servo motor to move
[23:20:53] <mozmck> I could probably add a INI setting to disable that message, but we may play with it and decide we like it.
[23:21:30] * seb_kuzminsky stage whispers: train your users to click the "probe to the work" button
[23:21:36] <mozmck> I haven't played with servos yet, other than ones driven with step/dir drives.
[23:22:23] <seb_kuzminsky> the servos on my bridgeport saved my bacon the other night
[23:22:54] <seb_kuzminsky> the fan that keeps the X amp cool died (i'm guessing it was installed in 1989 when the machine was built)
[23:23:12] <seb_kuzminsky> the amp stopped running, but the encoder was still working (it gets power from the mesa board)
[23:23:27] <seb_kuzminsky> linuxcnc e-stopped before the work was ruined
[23:23:36] <mozmck> Nice!
[23:23:38] <seb_kuzminsky> didn't even lose zero
[23:23:46] <seb_kuzminsky> i let the amp cool down, then finished the part
[23:23:54] <seb_kuzminsky> (and ordered new fans on amazon)
[23:24:28] <mozmck> I'd like to get a cnc mill sometime, but I don't know if I had time to use it.
[23:24:35] <seb_kuzminsky> heh yeah
[23:26:20] <mozmck> Hmm, I may have to implement your idea of "probe-gpio.in AND NOT torch-on", because the ohmic input gets noise on it while the torch is running.
[23:26:30] <cradek> I don't have a spare stylus for my probe - never have. So I think about things like this...
[23:26:58] <cradek> 2007 was like a year or two ago, right?
[23:27:30] <mozmck> seems like!
[23:30:58] <seb_kuzminsky> it was back when we were young
[23:31:56] <cradek> hey, I'm still young [when compared to the right people]
[23:32:35] <cradek> I never intended jogging the probe into something on purpose to be something people did
[23:32:58] <mozmck> heh!
[23:33:00] <cradek> for one thing you'll end up past the trigger point by some distance that depends on how fast you were going
[23:33:14] <cradek> that can't really be a good way to touch off something
[23:33:31] <mozmck> Well, for this you don't have to be real accurate.
[23:34:31] <seb_kuzminsky> https://www.youtube.com/watch?v=C8Ij3TDk3ug
[23:34:39] <mozmck> The main reason I do it actually is so that I'm close to the right place before doing a probe move (or homing move as it was in mach)
[23:36:02] <mozmck> If your Z thinks it is at 0 when it is 4" above the work, then starting a probe move at slow speed up there takes forever.
[23:36:21] <cradek> so probe as fast as the jog?
[23:36:47] <mozmck> I guess that's possible.
[23:36:49] <seb_kuzminsky> that would not be worse in any way
[23:37:17] <cradek> it's better because you get the real trip point stored, and you don't get an error
[23:37:24] <mozmck> I normally don't try to touch the metal when joggin down, but just get close to zero the axis.
[23:37:32] <cradek> ah
[23:37:45] <mozmck> But touching happens often enough.
[23:39:05] <mozmck> We'll probably use it like this and see how it works for us for now.
