Back
[07:16:42] <skunkworks> zlog
[08:18:48] <skunkworks> cmorley, Did you see the conversation mozmck was having on some added fuctionaliity?
[08:19:23] <cmorley> no. I am away working... I will try to look back
[08:22:36] <mozmck> cmorley: it's pretty trivial IMO. I needed a way to make the HAL_Sourceview widget not reset the line number to 0 when you hit stop.
[08:22:44] <mozmck> cmorley: (05:18:44 PM) mozmck: I created a property to allow the sourceview to keep the highlighting after an abort. The default is the old behavior. Does this look reasonable?
http://pastie.org/10424589
[08:31:22] <cmorley> I wonder if a user would mistake the highlight as the place linuxcnc would restart at if you pressed cycle start?
[08:31:52] <cmorley> besides that thought looks good to me..and its optional anyways
[08:32:22] <cmorley> off to bed after a 15 hour shift :)
[08:33:46] <mozmck> Ouch!
[08:34:12] <mozmck> In my GUI, it IS a place to restart if you press "Run From Line"
[08:34:40] <mozmck> But cycle start "Run" always starts from the beginning.
[08:35:53] <archivist> change the button to run from start/beginning or similar
[08:36:55] <skunkworks> mozmck, do you have a new screenshot of your gui?
[08:40:39] <mozmck> Not much has changed I don't think, but here is the current screenshot:
http://pasteboard.co/HWhEHxt.png
[08:49:21] <KGB-linuxcnc> 03Moses McKnight 052.7 c14c1c5 06linuxcnc 10lib/python/gladevcp/hal_sourceview.py Add option to disable line number reset in hal_sourceview when idle. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c14c1c5
[09:10:27] <JT-Shop> how do you enable that option?
[09:11:02] <JT-Shop> mozmck, that's looking good
[09:11:26] <JT-Shop> I get my volts preset from G code now
[09:22:28] <mozmck> JT-Shop: you can enable the option in glade, or in python by setting EMC_SourceView::idle_line_reset to False
[09:22:44] <mozmck> How are you doing volts preset from G code?
[09:28:27] <JT-Shop> M68 E0 Q79 then in hal I connect the input to my component volts in
[09:29:07] <mozmck> Ah, yes, that basically what I'm doing.
[09:29:38] <mozmck> I can send a lot more settings, so I use Q number ranges for different things.
[09:41:45] <JT-Shop> what all are you sending?
[09:42:03] <JT-Shop> and is your GUI shared?
[09:53:36] <mozmck> we send current and air pressure to a hypertherm cutter, and several other values our THC uses.
[10:01:03] <JT-Shop> neat
[10:04:08] <JT-Shop> I'm guessing your hypertherm is a bit more advanced than my 1250
[10:05:41] <mozmck> Yes, the newer ones have an optional rs485 card for external control. I think the powermax 65, 85, and 105 - maybe more.
[10:06:12] <JT-Shop> yea, mine is an old powermax 1250
[10:06:23] <mozmck> The GUI will be shared at some point - it is mostly a Gscreen skin and some python to make it behave like we want :)
[10:06:40] <mozmck> I think we have one of those - or used to anyhow.
[10:06:41] <JT-Shop> cool, it looks much better than most
[10:06:46] <JT-Shop> clean and simple
[10:06:50] <mozmck> Thanks!
[10:07:08] <JT-Shop> most look way to gaudy like a mark screen
[10:08:14] <pcw_home> angry fruit salad
[10:08:19] <mozmck> Simple is how we need it. Our shop manager who also does a lot of cutting on the side, said "I love this Linux CNC, its very easy to use" :)
[10:09:02] <mozmck> haha! Our Mach screens have been pretty "colorful" Tom likes colors ;)
[10:10:23] <seb_kuzminsky> i think most ease of use comes from the gui, not from the motion control core, so a lot of the credit for the compliment should go to you and cmorley
[10:20:05] <JT-Shop> is EMC_SourceView::idle_line_reset part of gscreen?
[10:22:08] <mozmck> :: is probably not the right terminology for python ;) (the more I use python, the more I like c++)
[10:22:36] <mozmck> The gcode window is an object of type EMC_SourceView
[10:23:53] <mozmck> So with my change, you can set that variable in either the glade file, or in an init function you should be able to do something like: gcode_view.idle_line_reset = False
[10:27:04] <JT-Shop> ok, thanks
[10:27:19] <JT-Shop> I like python but I'm learning C++
[12:02:18] <KGB-linuxcnc> 03Norbert Schechner 052.6 e242b0e 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_1_5_5_1 - solved bug step by step * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e242b0e
[12:02:19] <KGB-linuxcnc> 03Norbert Schechner 052.6 9b924c7 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b924c7
[12:21:32] <norbert__> Hallo, I just solved a bug in gmoccapy and pushed the changes to origin/2.6 I tried to merge that branch into origin/2.7, but I get a conflict in tp.c -- Could someone help to solve the conflict?
[12:34:12] <cradek> working on it
[12:34:45] <norbert__> Thanks!
[12:37:34] <KGB-linuxcnc> 03Chris Radek 052.7 69fc2dd 06linuxcnc 03src/emc/tp/tp.c 10src/emc/usr_intf/gmoccapy/gmoccapy.py Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=69fc2dd
[13:33:40] <skunkworks> cradek, whay so much added?
[13:49:20] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis 721e862 06linuxcnc Merge branch '2.7' into gmoccapy_5_axis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=721e862
[13:49:21] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis 4c92e78 06linuxcnc Merge branch '2.7' into gmoccapy_5_axis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4c92e78
[13:49:21] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis 943875d 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py Merge branch '2.7' into gmoccapy_5_axis * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=943875d
[13:49:22] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis e39dfbe 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_XYZAB.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_5_axis - jog and home buttons working * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e39dfbe
[13:49:28] <cradek> skunkworks: rob moved files around, which makes things tricky. Seb put a bugfix in tp.c in 2.6, which rob moved to a new location, so the change didn't merge very easily. I think I did it right, although gitweb's output does look wonky to me too
[13:49:43] <cradek> skunkworks: it was actually just a one line change
[13:50:09] <skunkworks> ok
[13:58:53] <skunkworks> hmm - did I just dream it or did seb talk to be about a fix for the axis delay.
[13:59:08] <mozmck> He did...
[13:59:28] <skunkworks> I don't see it in the logs
[13:59:37] <mozmck> 09:23:03 PM) KGB-linuxcnc: Sebastian Kuzminsky 2.6 3f95264 linuxcnc src/emc/kinematics/tp.c Motion: set the "In Position" emcmot status flag when aborting *
http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f95264
[13:59:37] <mozmck> (09:23:51 PM) seb_kuzminsky: skunkworks: can you confirm that fixes the "Axis snooze after estop" problem you reported?
[13:59:37] <mozmck> (09:45:37 PM) skunksleep: Oh cool. I will test tomorrow
[13:59:49] <skunkworks> logger[mah],
[13:59:50] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2015-09-17.html
[13:59:52] <mozmck> Is it tomorrow yet? :)
[14:00:46] <mozmck> That looks like it was on 9-15
[14:01:08] <skunkworks> oh wow - I lost a day
[14:01:17] <mozmck> looks like pidgin doesn't tell me a date on posts - just the time.
[14:01:39] <mozmck> I can tell the date by looking at skunkworks' periodic log requests ;)
[14:03:06] <skunkworks> hmm was that commit master then. wow - I think I need more sleep
[14:05:40] <mozmck> :)
[14:05:53] <mozmck> How's the baby?
[14:06:14] <mozmck> sleep all day and rarin' to go all night?
[14:06:27] <skunkworks> Good - sleeping at night - smiley and giggley
[14:06:35] <mozmck> great!
[14:10:07] <skunkworks> how is your 2
[14:10:11] <skunkworks> 2?
[14:11:25] <skunkworks> So - in axis when you hit the X it asks you if you want to exit linuxcnc.. If you go file ->quit - it just exits.
[14:12:26] <skunkworks> seb_kuzminsky, great job! that fixes the pause
[14:12:38] <skunkworks> How in the world did you find that?
[14:13:21] <mozmck> 3
[14:13:33] <mozmck> They are doing quite well!
[14:13:52] <skunkworks> great
[14:14:44] <mozmck> My boy is 2 now and all over "tools" He knows his are vastly inferior to mine, so he's always trying to sneak off with mine :)
[14:15:36] <skunkworks> Heh - stella just turned 3 and will pretend to fix things with random screwdrivers and such
[14:15:49] <mozmck> Another year and everything on the place held together with screws or bolts will be all in pieces (I better not let him watch me with the cutting torch!)
[14:16:51] <mozmck> Yeah, Ruth is about 3.5 and can wield a screwdriver quite well. I'm amazed at how she turns the screws the correct way first time every time.
[14:17:57] <skunkworks> heh - I noticed that with bottles. She can unscrew them quicker than you can stop her
[14:18:27] <mozmck> Yeah, ask her if you can't get the child-proof lids off of stuff.
[14:39:08] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_5_axis af07894 06linuxcnc 10(8 files in 2 dirs) gmoccapy_5_axis - added touch off button * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=af07894
[14:44:51] <linuxcnc-build> build #37 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/37 blamelist: Norbert Schechner <nieson@web.de>, Sebastian Kuzminsky <seb@highlab.com>, Chris Radek <chris@timeguy.com>
[14:45:06] <linuxcnc-build> build #28 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/28 blamelist: Norbert Schechner <nieson@web.de>, Sebastian Kuzminsky <seb@highlab.com>, Chris Radek <chris@timeguy.com>
[14:47:13] <cradek> uhh
[14:47:18] <cradek> I don't know what that means
[14:56:36] <jepler> looks like a network error
[15:17:12] <seb_kuzminsky> skunkworks: i found it the stupid way - by adding prints around everything suspicious looking in Axis' file reading code, looking for the thing that was slow, and chasing the bug down the stack from there
[15:17:48] <seb_kuzminsky> cradek, jepler: yeah, my home network has been all kinds of crappy lately :-(
[15:17:55] <seb_kuzminsky> i'd switch ISPs but they all suck
[15:19:34] <linuxcnc-build> build #76 of 1502.rip-jessie-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/76 blamelist: bebro <bebro@users.noreply.github.com>, andypugh <andy@bodgesoc.org>, Norbert Schechner <nieson@web.de>, Chris Radek <chris@timeguy.com>, Chris Morley
[15:19:34] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Andy Pugh <andy@bodgesoc.org>, Jeff Epler <jepler@unpythonic.net>, Moses McKnight <moses@texband.net>, Benjamin Brockhaus <burning@burning-world.de>, Florian Kerle <flo.kerle@gmx.at>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Robert W. Ellenberg <rwe24g@gmail.com>, Dewey Garrett
[15:19:34] <linuxcnc-build> <dgarrett@panix.com>
[15:22:33] <andypugh> It’s my fault _twice_ it seems
[16:03:15] <seb_kuzminsky> jepler: it's that hm2-idrom failure again, and again only on jessie
[16:32:25] <linuxcnc-build> build #3462 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3462 blamelist: bebro <bebro@users.noreply.github.com>, andypugh <andy@bodgesoc.org>, Norbert Schechner <nieson@web.de>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Andy Pugh
[16:32:25] <linuxcnc-build> <andy@bodgesoc.org>, Jeff Epler <jepler@unpythonic.net>, Moses McKnight <moses@texband.net>, Benjamin Brockhaus <burning@burning-world.de>, Florian Kerle <flo.kerle@gmx.at>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Robert W. Ellenberg <rwe24g@gmail.com>, Dewey Garrett <dgarrett@panix.com>
[17:00:37] <jepler> seb_kuzminsky: I don't think I ever deployed that fix-that-shouldnt-be-a-fix
[17:20:19] <seb_kuzminsky> jepler: thanks for that, i think
[18:24:34] <jepler> announcing a new web service: "Is It Dark Or Not" isitdarkornot.github.io/
[18:30:56] <jepler> https://isitdarkornot.github.io/
[18:34:46] <jepler> version for pluto not available.
http://www.nasa.gov/feature/pluto-wows-in-spectacular-new-backlit-panorama/ http://www.nasa.gov/sites/default/files/thumbnails/image/nh-apluto-wide-9-17-15-final_0.png
[18:52:49] <cradek> jepler: I love it
[18:54:39] <cradek> wow those pluto images are stunning
[19:12:34] <jepler> hanks
[19:12:35] <jepler> thanks
[19:15:24] <andypugh> Looks like a planet to me :-)
[20:55:24] <skunkworks> mozmck:
[20:55:28] <skunkworks> I think what's happening is that NCD is combining segments together if there is no M67, but it can't do that if there is. If you make Q 0.0, the effect disappears (in that you see the blip regardless).
[20:55:30] <skunkworks> It's the age-old problem of telling the motion side that the program is done, or that we've hit a queue buster and to assume that the last segment will be exact stop. Since there isn't a clean way to do this now, the workaround is to have a lead-out move of some sort (for example, a rapid down to the work and back up after the cut). If the last segment is not cutting, then the little blip...
[20:55:31] <skunkworks> ...won't affect the part.
[20:59:22] <jepler> of course you can also determine whether it's dark or not with this watch
http://www.bloomberg.com/news/articles/2015-09-17/vacheron-constantin-unveils-the-most-complicated-watch-ever-made
[21:21:49] <cradek> not nearly as easily
[21:22:22] <mozmck> skunkworks: I'm not sure...
[21:27:54] <mozmck> If M67 is supposed to be a non-queue buster, then it should be a non-queue buster at any point. Didn't you say it did not have the blip in 2.6? Wasn't NCD in 2.6 as well?
[21:29:31] <mozmck> I don't think I can do a rapid up after a cut - but I'll have to look at it a bit more.
[22:41:30] <skunksleep> mozmck: I don't think it is the m67. It is not knowing that it is the last segment
[22:41:56] <mozmck> not sure what you mean?
[22:42:08] <mozmck> I can take the M67 out and there is no dip in velocity
[22:42:52] <mozmck> I also changed some of the codes to M62/M63 and it does the same thing.
[22:44:37] <mozmck> I just tried adding another move of .001" after the last move after the last Mxx code, and the velocity dip vanishes. If I make that last move longer - like .5" then the dip is still there.
[22:46:53] <skunksleep> I looked into that before, and I'm not sure there's a good answer. We effectively need a way to tell motion to do an exact stop at the end of the queue. One way might be a special motion command that says that we're done sending moves for now (i.e. queue buster or end-of-program). Then, we could override the stop condition of the last move (make it exact stop), and re-run the optimization to remove the blip. Th
[22:48:09] <mozmck> This is with NCD turned off now - hmm, interesting - if I turn NCD back on ( Q0.001 ), the dip is back even with the extra .001 move
[22:49:09] <mozmck> I don't understand why motion would not know to do an exact stop at the end of the queue?
[22:50:08] <mozmck> And why would inserting a non queue-buster command make any difference if that is the problem?
[22:51:19] <skunksleep> I don't think I understand it either. Are you doing a g0 .001 move?
[22:51:35] <mozmck> No, it was still a g1
[22:52:00] <skunksleep> I think you want a g0 move
[22:52:20] <mozmck> The thing is, I have an M5 already which is a queue buster.
[22:52:57] <skunksleep> (But it is late and things are fuzzy)
[22:53:27] <mozmck> ja, richtig
[22:59:26] <skunksleep> The dip is back with the extra move because the ncd combines it into one segment again
[23:00:22] <mozmck> Ok, so why does the dip happen at all? If I remove the M code the dip goes away, or if it is far enough away from the end of the line.
[23:00:34] <skunksleep> So I think ether add the extra g1 move with no ncd or use a g0 with
[23:02:27] <skunksleep> I don't know?
[23:03:16] <mozmck> The G0 with a .001 move makes the dip much smaller and down at the end of decel
[23:08:52] <mozmck> It does not work to put the G0 move after the M5 either.
[23:10:05] <skunksleep> What is m5 used for?
[23:10:13] <mozmck> I can just see telling our customers - "If you don't want it to burp before the end of each cut, just put a bogus G0 move of .001" before the M5!"
[23:10:22] <mozmck> turning the torch off
[23:11:11] <skunksleep> Isn't there going to be rapids between each cut?
[23:11:21] <mozmck> Only after the torch is off!
[23:11:49] <mozmck> But putting a rapid after turning the torch off does not help
[23:14:25] <skunksleep> You don't have issues with m3/5? I thought that was iocontrol and not realtime
[23:15:01] <skunksleep> Maybe I am wrong
[23:16:21] <mozmck> When you turn the torch on motion.motion-inhibit is asserted until the torch actually fires, and on torch off it happens after the last segment of a cut.
[23:16:50] <mozmck> So it doesn't need to be realtime
[23:18:05] <skunksleep> Ah . would using digital I/o help? Instead of spindle on/off?
[23:18:28] <mozmck> They are queue busters, so motion waits for those commands to execute before starting motion again.
[23:18:32] <skunksleep> Synced I/o
[23:18:57] <mozmck> I don't see why it would - they don't need to be synced - in fact that would probably be bad.
[23:19:56] <mozmck> For torch on, we hold motion until we have a valid arc, then we move from pierce height down ~ .060" to cut height to pierce through the metal and then start X/Y motion
[23:21:09] <mozmck> For thicker metal there may also be a pierce delay.
[23:25:08] <skunksleep> Remap m6 to add a g0 move?...
[23:25:20] <skunksleep> Before
[23:25:37] <skunksleep> sorry. Grasping
[23:26:55] <skunksleep> M5 I mean
[23:28:28] <mozmck> heh! don't know about that! I better quit for tonight - thanks for thinking about it with me.
[23:31:12] <skunksleep> No problem
