Back
[08:55:29] <skunkworks_> zlog
[09:05:33] <seb_kuzminsky> zlog
[09:08:05] <KGB-linuxcnc> 03Jeff Epler 052.6 3b84b1c 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc interp: don't return potentially stacked data * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3b84b1c
[09:08:40] <seb_kuzminsky> jepler: just cherrypicking your c++ stacked return fix from 2.7 to 2.6, thanks
[09:13:48] <jepler> seb_kuzminsky: yay
[09:58:54] <KGB-linuxcnc> 03Norbert Schechner 05master 28370b8 06linuxcnc 10lib/python/gladevcp/hal_gremlin.py 10src/emc/usr_intf/gremlin/gremlin.py GladeVCP - gremlin - corrected mouse button 6 behavior * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=28370b8
[10:47:49] <linuxcnc-build> build #355 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/355 blamelist: Jeff Epler <jepler@unpythonic.net>
[11:22:51] <KGB-linuxcnc> 03John Morris 05zultron/remap-dup-oword 130bfcd 06linuxcnc 10(7 files) `nested-remaps-oword` test: Do what `README` says * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=130bfcd
[11:22:51] <KGB-linuxcnc> 03John Morris 05zultron/remap-dup-oword a91ab3f 06linuxcnc 10(7 files) Unit test demonstrating a remap bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a91ab3f
[11:22:51] <KGB-linuxcnc> 03John Morris 05zultron/remap-dup-oword 2af880c 06linuxcnc 10src/emc/rs274ngc/rs274ngc_pre.cc Fix incorrect `_setup.sequence_number` after remaps * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2af880c
[11:29:26] <seb_kuzminsky> sweet
[11:56:21] <JT-Shop> in Axis if you press Run with no file loaded you get a blank error message
[11:57:57] <cradek> how can you get there to be no file loaded?
[12:03:03] <Tom_itx> esp
[12:03:06] <JT-Shop> OPEN_FILE = /full/path/to/file.ngc - The file to show in the preview plot when AXIS starts. Use a blank string "" and no file will be loaded at start up.
[12:03:16] <JT-Shop> http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_display_section
[12:10:24] <seb_kuzminsky> blank error message are not the most helpful
[12:10:34] <seb_kuzminsky> JT-Shop: can you open a github issue for that?
[12:14:37] <cradek> heh, it's funny - in the long ago, we made the splash screen because things were wonky when no file was loaded, and what's the point in worrying about the behavior when no file is loaded? but now, we have that ability again.
[12:20:00] <mozmck> I figured out that hal_glib is given the filename of external file subroutines while running. This does not cause problems except if you stop while running code - probably within a certain time after executing an external file sub. Then since the filename is different than the old one, it causes gremlin and the gcode view to reload the file, which often causes the code to rewind to the beginning.
[12:22:04] <mozmck> what I need I think is a way to tell (in hal_glib.py) if the code is executing an external sub, and not store the file name if so.
[12:23:31] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton opened issue #63: Blank Error Message 02
https://github.com/LinuxCNC/linuxcnc/issues/63
[12:23:34] <mozmck> It appears that interp.call_level() > 0 indicates it is in a sub.
[12:23:38] <JT-Shop> there you go seb_kuzminsky
[12:23:43] <seb_kuzminsky> thanks!
[12:23:59] <seb_kuzminsky> that'll make me 7% less likely to forget it
[12:24:02] <JT-Shop> mmmm this sauerkraut n carrots is good
[12:24:28] <JT-Shop> I forget what I was supposed to do to remember...
[12:36:02] <mozmck> so I'm thinking the best thing would be to get the interp.call_level() value into python, but I'm not sure how to do that.
[12:37:39] <mozmck> Looks like I might be able to add it to the EMC_TASK_STAT class and then add an item to Stat_members[] in emcmodule.cc?
[13:14:52] <mozmck> Looks like there is an interp python module with a class that has the call_level in it. Anyone know if I can use that in hal_glib?
[13:15:09] <seb_kuzminsky> no idea, sorry
[13:16:34] <mozmck> does anything use the python interp module? what is it for?
[13:26:12] <seb_kuzminsky> i think maybe for writing remapped gcode in python
[13:32:11] <seb_kuzminsky> actually i dont know
[13:32:13] * PCW needs to barter for some sauerkraut n carrots
[13:38:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 07d9662 06linuxcnc 10docs/src/config/python-interface.txt docs: fix typo in config/python-interface.txt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=07d9662
[13:41:40] <mozmck> 8ß0 - looks like a german keyboard was used for that typo ;-)
[13:45:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 219663a 06linuxcnc 10docs/src/config/python-interface.txt docs: clarify the intro to the python-interface documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=219663a
[13:45:24] <seb_kuzminsky> yeah
[13:45:55] <KGB-linuxcnc> 03John Morris 05zultron/remap-io-lcnc ffac896 06linuxcnc 10(18 files in 2 dirs) Enable remap of M62-M66 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ffac896
[13:46:09] <seb_kuzminsky> JT-Shop: the document at docs/src/config/python-interface.txt doesn't seem like it belongs there - it describes a python interface to linuxcnc, for writing guis and things, nothing to do with configuring linuxcnc
[13:46:37] <seb_kuzminsky> maybe it should go in docs/src/code? i'm not sure where it fits best
[13:46:47] <mozmck> I think I'm going to add callLevel to the EMC_TASK_STAT class. This will allow me to check the call level and ignore file name changes and line number changes while executing a subroutine.
[13:47:21] <mozmck> It should fix problems in everything that uses hal_glib - gcodeview and gremlin being the ones I'm affected by.
[15:51:56] <mozmck> Norbert fixed the issue I asked him about with mouse mode 6 in gremlin, but he did it on master. What is the best way to get that on 2.7?
[15:52:55] <cradek> best way? time machine. second best way: cherry pick it
[15:53:25] <mozmck> :-) So cherry picking it will not cause a conflict when someone merges 2.7 into master again?
[15:53:58] <cradek> no, and you can even do the merge if you want. the merge will do nothing, since the change is already on both sides.
[15:54:09] <mozmck> ok, good.
[15:57:26] <KGB-linuxcnc> 03Norbert Schechner 052.7 a3f4f2e 06linuxcnc 10lib/python/gladevcp/hal_gremlin.py 10src/emc/usr_intf/gremlin/gremlin.py GladeVCP - gremlin - corrected mouse button 6 behavior * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3f4f2e
[15:59:24] <KGB-linuxcnc> 03Moses McKnight 05master 5cdaa52 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5cdaa52
[16:00:12] <mozmck> interesting, so it shows the commit in master twice now.
[16:01:32] <cradek> yep, once on each side of the merge
[16:01:48] <cradek> looks right
[16:02:00] <mozmck> good
[16:05:40] <andypugh> Would it be usual for a CNC machine to power up the servo drives when e-stop is disabled?
[16:06:56] <cradek> pretty sure every machine I've seen has a button for enable that you poke after popping out (all) the estop knob(s)
[16:07:28] <andypugh> Currently my startup-sequence is that nothing much happens when e-stop is reset, but when I turn the machine “on” the main contactor closes, the VFD is powered up, and the servo PSU soft-start sequence is enabled. Unfortunately it is a fair few seconds from mahine-on to being able to move any joints. In fact long enough to twiddle jog knobs and get an f-error
[16:08:12] <cradek> hm, estop has a loopback thing so it can take a while, but machine-on doesn't
[16:08:30] <andypugh> I was wondering if I was missing something.
[16:08:32] <cradek> my vmc probably takes 5 seconds to come out of estop (a ladder happens)
[16:08:34] <JT-Shop> seems like a blur between configuration and writing a gui... all part of the process imho
[16:09:26] <andypugh> I quite like to power-down my machines when they are not running, to get rid of the VFD whine and the fan noise.
[16:09:38] <cradek> yeah, me too, I just hit estop
[16:09:39] <andypugh> But I don’t really want to do that with e-stop.
[16:09:53] <cradek> it stops the cooling fans and everything
[16:10:20] <andypugh> Maybe I should use e-stop then. But that rather begs the question about what machine on/off is actually for
[16:11:26] * cradek shrugs
[16:11:50] <cradek> it's true the state where everything's powered but limp isn't one you need to use very often
[16:12:10] <cradek> I guess if the machine had cranks on it you might use that state a lot?
[16:12:34] <andypugh> Maybe.
[16:12:55] <andypugh> Also odd, while I am poking about, is that the external e-stop input is a halui pin.
[16:13:17] <andypugh> Is there nothing to poke in realtime to toggle e-stop?
[16:13:18] <cradek> no, everything you need is on iocontrol
[16:13:47] <mozmck> which is not realtime either is it?
[16:13:50] <cradek> but yes, it's not realtime
[16:14:05] <mozmck> I think the estop input is simply to inform the software that estop happened.
[16:14:13] <cradek> I agree with that
[16:14:25] <andypugh> Yes that’s what I want it for. But I also want it to be told that _reliably_
[16:14:27] <cradek> it doesn't really matter how soon it responds
[16:14:59] <mozmck> I think iocontrol is reliable, but just not realtime.
[16:16:25] <andypugh> The reason is that one of my e-stops is a momentary button. I don’t want the contactor to drop back in immediately when I release it, I want to have to go through the startup sequence again.
[16:16:25] <cradek> andypugh: sim/axis/classicladder/demo_sim_cl (top rung) shows how the estop loopback works
[16:17:37] <cradek> I think you should consider replacing your estop button, and then you don't have to trust that the software is alive and working right.
[16:17:42] <mozmck> maybe that's one reason the large e-stop buttons are not momentary - I had not thought of that.
[16:18:19] <cradek> or use a mechanical relay?
[16:18:33] <mozmck> I've used momentary e-stop buttons, but our power supply has to be manually turned on for safety reasons.
[16:18:35] <andypugh> cradek: The same objection applies to any e-stop. When I twist it to release it, I don’t want the machine to immediately wake back up.
[16:19:07] <cradek> that's true, but in that case you have time to see what's up
[16:19:39] <cradek> you probably wouldn't go ahead and pull the button back out if the software was gone or being wonky
[16:20:04] <cradek> I'm sure you know this - I won't lecture you
[16:20:18] <andypugh> Anyway, you said there was an iocontrol button to toggle an e-stop?
[16:20:32] <cradek> yeah, check out that ladder sim
[16:21:27] <cradek> there's a "user requested to come out of estop" strobey signal, and iocontrol gets feedback to say it's now fully out of estop
[16:21:27] <cradek> and I have to look at that ladder each time to figure out how it works
[16:21:47] <seb_kuzminsky> there's a realtime hal pin called motion.enable that lets you go from Machine On to Machine Off
[16:22:05] <seb_kuzminsky> but nothing to go to the Estop state
[16:22:32] <seb_kuzminsky> i think that's either a bug, or a strong argument that in Machine Off the spindle and joint motors should really be powered off
[16:22:42] <seb_kuzminsky> bbl
[16:23:04] <mozmck> aren't the enable pins disabled in machine off?
[16:23:59] <andypugh> I _want_ the motors to be off in machine-off. In fact I want them to remain off until some time after I pressed the machine-on button.
[16:24:49] <mozmck> there are axis.x.amp-enable-out pins, that I think are off in machine-off
[16:25:34] <andypugh> I think I am looking for a pin that says to the system “OK, everything is powered up and ready now, you can start PID loops and amps and try to move stuff"
[16:25:50] <mozmck> I assumed they were to connect to the motor drive enable inputs - is that not what you want? Or do they not work like that.
[16:26:33] <andypugh> They are the right pins, except they go true instantly, without waiting for the power supplies to report power-good
[16:27:34] <andypugh> So it looks like I have to power on/off the VFD and amps with the e-stop loop, then enble the amps / pid etc with machine-on
[16:27:35] <mozmck> I see - maybe you can connect the power supplies power-good pins to motion.enable?
[16:28:15] <andypugh> Let me experiment with that pin.
[16:33:16] <andypugh> Hmm, that might be workable. It only lets me disable the “machine on” button, so I would have to keep poking the button until the system decided it was allowed to work.
[16:34:18] <mozmck> Interesting. Is this for the lathe you are working on?
[16:34:22] <andypugh> Yes
[16:34:45] <cradek> it would probably be nice if machine on was also a loopback
[16:34:46] <mozmck> That is very nice looking. It almost looks like the spot where the keyboard is was made for that.
[16:35:07] <andypugh> The servo PSU has a soft-start and dishcharge. Get the sequence wrong and I need to shop for new relays.
[16:35:13] <mozmck> Or is that a custom piece you made for it?
[16:35:30] <andypugh> No, it’s original. DId you see the video?
[16:35:36] <mozmck> no
[16:35:46] <mozmck> just some pictures you posted here.
[16:35:46] <andypugh> I put the keyboard exactly where the threading chart was.
[16:35:53] <mozmck> neat!
[16:36:24] <andypugh> mozmck:
https://www.youtube.com/watch?v=woU927Tqoo8
[16:42:59] <linuxcnc-build> build #3384 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3384 blamelist: John Morris <john@zultron.com>
[16:58:12] <linuxcnc-build> build #4175 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4175 blamelist: John Morris <john@zultron.com>
[17:27:27] <linuxcnc-build> build #4187 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4187 blamelist: John Morris <john@zultron.com>
[18:18:29] <mozmck> Ok, the behavior I thought was a bug in my S-RFL was not - readahead adds stuff to the queue before it actually gets executed. So I was expecting an output to turn on but readahead found a problem after that line but before the output actually turned on and canceled everything.
[18:26:49] <mozmck> It does look like my fix for the file name keeps gremlin and sourceview from reloading the file now if aborting shortly after an external subroutine was run.
[22:31:35] <mozmck> Here is my fix for the file-loaded event from hal_glib
https://github.com/mozmck/linuxcnc-mirror/commit/8cec4d3ec3fa51e7691e7f639ddd942ec4736451
[22:32:50] <mozmck> If someone can think of a better way to do this, or sees a problem with the way I did it, please let me know. If it looks good, should it go on 2.7 as a bugfix?