#linuxcnc-devel | Logs for 2016-09-18

Back
[00:53:17] <linuxcnc-build_> Hey! build 0000.checkin #4525 is complete: Success [3build successful]
[00:53:17] <linuxcnc-build_> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4525
[00:57:23] <linuxcnc-build_> build #598 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/598
[01:23:39] <linuxcnc-build_> build #25 of 4025.deb-jessie-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4025.deb-jessie-armhf/builds/25
[12:32:51] <KGB-linuxcnc> 03Jeff Epler 052.7 d190b9b 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d190b9b
[13:33:49] <Roguish> hey all. I'm working on a slight customization of Touchy. I would like to change the jog increments and can not seem to find where they are set. In touchy.glade there is a signal and all, but where it goes to or comes from I can not find.
[13:33:50] <Roguish> I see reference to a touchy comp, but cannot find that either. There is some python behind touchy, but cannot find touchy.py in a normal install. It is included with the source after I have done a git pull of the current master source, and I see how the jog increment is set. cool.
[13:33:52] <Roguish> I just don't get it in a normal install. Aren't both glade and python interpreted? so shouldn't the files all be present somewhere?
[13:33:54] <Roguish> If I copy and modify the touchy.py in the git source, where should put it in the normal install directories to get it to be used?
[13:33:55] <Roguish> Little help please. Particularly cradek, and maybe jmkasunich or jepler or who ever else knows this gui stuff.
[14:49:29] <JT-Shop> Roguish: gscreen might be easier to modify
[15:22:33] <KGB-linuxcnc> 03Jeff Epler 05master d860b30 06linuxcnc 10debian/changelog 10docs/src/config/python-interface.txt 10tests/interp/compile/use-rs274.cc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d860b30
[15:24:56] <andypugh> Sometimes I do wish Gene would keep out of threads.
[15:25:14] <andypugh> Not often, but sometimes
[15:27:10] <andypugh> (And currently, I am wishing that other people would come in). I am fairly sure that a LinuxCNC-derived analog velocity channel adds nothing to the control loop, but I would value a second (infprmed) opinion.
[15:40:58] <jepler> I haven't read the thread in detail
[15:41:34] <jepler> but it seems like some people have had success using encoder voltage to simulate tach feedback on an old velocity-mode servo amp, which I think is where the thread started..
[15:45:26] <jepler> Roguish: touchy was not designed to be modified by end-users or integrators the way gscreen is. I don't know much more about it than that.
[15:46:36] <Roguish> jepler: thanks for the reply. I understand that, but can you give me a brief understanding of the files with glade and python, etc ??
[15:48:00] <Roguish> like, where the heck does the python code behind touchy exist?
[15:48:21] <Roguish> tghere is some in pyshared. but not a touchy.py
[15:48:23] <jepler> Roguish: looks like src/emc/usr_intf/touchy ?
[15:48:26] <andypugh> jepler: No doubt that it can work. It seems that cradek has done exactly that. But my thesis is that such a solution is degenerate to torque-mode.
[15:49:06] <jepler> > $ git ls-files '**/*touchy*'
[15:49:20] <jepler> here's how I found the answer to that question ^^ hunch + commandline = hopefully an answer
[15:50:43] <jepler> the fact that it's in src/ is a clue that after changing the files, you would run "make" again before the changes are effective
[15:51:12] <andypugh> Isn’t it all Python?
[15:51:14] <cradek> andypugh: I don't know anything you don't, except I have hooked up a spare dac to replace a broken tachometer on my vmc, and it worked, I think even with the same tuning. I think I had to change something [??] on the amp to compensate for having +-10 feedback instead of +-100 or whatever it was.
[15:51:59] <cradek> andypugh: it does seem like the first thing the amp does is subtract the two signals...
[15:52:28] <andypugh> cradek: I think that (if drives work like I think they do) that shorting the velocity input to zero and doing the subtraction in HAL would work the same.
[15:52:39] <cradek> I suspect you're right
[15:53:05] <cradek> but then I don't know why commercial machines use this setup
[15:53:39] <cradek> it might be slightly safer
[15:53:43] <andypugh> Because the actual tacho is much faster than the servo thread
[15:53:49] <Roguish> cradek: did you see my questions from earlier concerning touchy?
[15:54:34] <cradek> Roguish: if you want to run a customized linuxcnc, change the source and build, and then either use RIP or build a package and install it
[15:55:20] <Roguish> cradek: it's compilinng now. if I modify touchy.py, do i need to recompile each time I change something?
[15:55:21] <cradek> but much better than either of those options would be to contribute a patch that lets you set touchy to have non-default increments in the ini file
[15:55:27] <cradek> yes
[15:56:47] <Roguish> i am not a coder. just muddling through. I will see if I can make sense of it all, but no guarentees at all.
[15:57:07] <cradek> andypugh: my amps have a knob you set to just over the expected tach voltage at rapid, and if that's detected on the tach channel the amp faults
[15:57:13] <Roguish> so, again. Is touchy.py part of the linuxcnc compilation?
[15:58:17] <cradek> I can imagine some obscure cases where that could stop a runaway that is missed with your scheme, even if works identically when everything is working right (which I still can't decide whether it does)
[15:58:39] <andypugh> I have changed axis.py and glcanon.py and seen instant changes with no recompiling many times.
[15:59:33] <andypugh> Roguish: Try it and see. Just change some obvious text.
[15:59:35] <cradek> Roguish: I guess I don't know if you have to rebuild every time. Try it and let us know.
[16:00:05] <Roguish> andypugh and cradek. I will try and see what happens.
[16:01:01] <cradek> andypugh: I can also imagine a stupid chain of events where they wanted to use up some old amps without changing them, or send non-tachometer motors to customers with older setups, and adding a dac channel was the easiest way to do that, and it stuck because of dumb reasons
[16:01:13] <cradek> andypugh: but in summary, I have no idea
[16:02:09] <cradek> http://timeguy.com/cradek-files/emc/real-vs-generated-tach.jpg
[16:02:09] <cradek> http://timeguy.com/cradek-files/emc/real-vs-generated-tach-upclose.jpg
[16:02:13] <cradek> ^^ from my testing
[16:02:45] <cradek> you can see the servo cycle of course, but also I think you can sorta see the one-cycle lag in the -upclose
[16:03:32] <andypugh> Aye, it’s not _quite_ as good, is it? But it seems to work well enough
[16:03:59] <cradek> it sure works better than my tach, which has a dead spot
[16:04:14] <andypugh> And it’s an easy fix, rather than going off on a punt into the unknown based on a hunch about information theory
[16:04:18] <cradek> it would go BANG BANG BANG during jogs, one BANG per turn of the screw
[16:04:52] <andypugh> sounds like an easy fix, probably a commutator segment.
[16:04:58] <andypugh> :-)
[16:05:05] <cradek> heh yeah it's a simple mechanism
[16:05:22] <cradek> just a zillion turns of pixie hair in a package the size of my thumb
[16:06:01] <cradek> unfortunately the scope trace of the tach at steady speed is lost to time
[16:06:27] <cradek> iirc, I pulled it out and spun it with the drill press
[16:06:43] <andypugh> I was very relieved that I managed to fix my potted-solid electromagnetic clutch by poking a wire back into the hole and fllowing it up with solder….
[16:07:10] <cradek> wow, don't let that wire jiggle
[16:08:19] <andypugh> Well, I guess that the wire that pulled out left behind the tinned end of a coil that was otherwise enamelled copper, so it’s probably actually fixed properly. And lucily.
[16:08:44] <andypugh> (luckily). Lucily would be something to do with Peanuts, I thing.
[16:09:50] <Roguish> hey, while you guys are around. is the 'calibrate' thing in axis available outside of axis? it is just so good for tuning, etc.
[16:10:19] <cradek> yes I think it's not specific to AXIS. it just runs it.
[16:10:45] <Roguish> it's not mentioned in the docs, like halscope, etc.
[16:11:01] <Roguish> clue as to how to run it?
[16:11:40] <andypugh> halcmd loadusr whatver-the-file-is-called
[16:12:06] <andypugh> (works for halmeter, halscope, halshow)
[16:12:36] <Roguish> ok. cool, so, what is the file named? (and no, i have looked into the guts of axis to see....)
[16:13:20] <andypugh> I thought you might ask that :-)
[16:14:41] <andypugh> emctuning look likely
[16:15:22] <andypugh> No. I don’t think it is
[16:15:38] <andypugh> What the heck _is_ emctuning.py?
[16:16:03] <andypugh> Err, I mean emctuning.tcl
[16:16:31] <Roguish> there is an autotuning comp somewhere....
[16:18:52] <andypugh> that’s something else
[16:18:52] <cradek> I've never seen it work
[16:18:58] <cradek> at_pid
[16:19:21] <cradek> also, it's a fork of pid, so it's probably missing important bug fixes
[16:19:41] <andypugh> Looks like the file you want is emccalib. But I tried “halcmd loadusr emccalib” and it seems to expect arguments
[16:20:49] <cradek> % git grep emccalib
[16:20:52] <cradek> [...]
[16:20:53] <cradek> share/axis/tcl/axis.tcl: -command {exec $env(LINUXCNC_TCL_DIR)/bin/emccalib.tcl -- -ini $emcini &}
[16:21:26] <cradek> src/emc/usr_intf/gscreen/gscreen.py: p = os.popen("tclsh %s/bin/emccalib.tcl -- -ini %s > /dev/null &" % (TCLPATH,self.inipath),"w")
[16:21:37] <cradek> so, um, there are at least two different ways to start it...
[16:21:54] <cradek> but -- -ini inifilename.ini is probably what you're missing
[16:43:03] <JT-Shop> I tried for a short bit to get emccalib to run before I left the other day
[17:01:10] <JT-Shop> pcw_home: any thoughts on this 7i77 encoder problem? http://paste.ubuntu.com/23200143/
[17:09:07] <JT-Shop> Roguish: grep -irl 'emccalib' * returns a short list and looking in gscreen.py I see p = os.popen("tclsh %s/bin/emccalib.tcl -- -ini %s > /dev/null &" % (TCLPATH,self.inipath),"w")
[17:10:01] <cradek> if you get the same answer from two people, do you think it's 2x as likely to be right, or 4x?
[17:10:29] <JT-Shop> I think it is exponential...
[17:23:53] <pcw_home> JT-Shop: Maybe wrong config, wrong IEEE1284 cable, or too long IEEE1284 cable
[17:25:11] <JT-Shop> I shipped the png kit with a cable... I could have put the wrong config in
[17:25:41] <pcw_home> IEEE1284 cable?
[17:26:04] <pcw_home> (a generic DB25 cable will not work)
[17:26:36] <JT-Shop> same cable you have, you gave the supplier and number a while back
[17:26:51] <JT-Shop> yep IEEE1284
[17:27:54] <JT-Shop> can't say at this point that they didn't use another cable
[17:28:53] <pcw_home> also 7I77 jumpering (and check differential encoders by measuring _across_ A,/A B,/B Z,/Z
[17:29:17] <JT-Shop> thanks
[17:30:28] <Roguish> JT-Shop: did you ever get the calibration thing running? outside of axis?
[17:30:45] <pcw_home> something may be marginal (so check differential voltages)
[17:30:56] <JT-Shop> I just spend some time trying and no luck, can't even find it in gscreen
[17:33:08] <cradek> Roguish: it seems like you keep missing people's answers to you. do you read back carefully when you're away for a bit and come back?
[17:34:27] <Roguish> no. just busy. yes, i do read back and see answers. my setup is compiling now and I can't touch it.
[17:34:59] <Roguish> I also copy all the text here and keep it for reference..... and know where zlog stores it.
[17:35:29] <Roguish> and most of all, appreciate ALL help and assistance.
[17:43:47] <JT-Shop> my problem may be linked to this configure error configure: error: tcl lib not found
[17:50:05] <JT-Shop> switched to 2.7 and down to this error config.status: error: cannot find input file: `../scripts/halcmd_twopass.in'
[17:55:04] <JT-Shop> well don't switch branches in mid build process and you won't get funny errors
[17:58:26] <JT-Shop> Roguish: from emccalib.tcl # EMC parameter setting application # Needs emcsh to run
[18:10:40] <skunkworks> someone to ask about the simulated tach output would be pcw_home :)