#linuxcnc-devel | Logs for 2018-11-02
Back
[01:57:02] -!- c-log has quit [Ping timeout: 268 seconds]
[01:58:38] -!- c-log has joined #linuxcnc-devel
[02:00:04] -!- alex_joni has quit [Ping timeout: 264 seconds]
[02:04:34] -!- alex_joni has joined #linuxcnc-devel
[02:04:34] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[02:08:08] -!- c-log has quit [Ping timeout: 268 seconds]
[02:11:48] -!- c-log has joined #linuxcnc-devel
[02:41:55] -!- ve7it has quit [Remote host closed the connection]
[07:23:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15oro06 commented on issue #457: current master version permit only to access device located at... 02 https://github.com/LinuxCNC/linuxcnc/pull/457#issuecomment-435348860
[07:30:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jethornton pushed 1 new commit to 06master: 02 https://github.com/LinuxCNC/linuxcnc/commit/91fa2d939822006a5ba872f455a8ec1c076bde31
[07:30:29] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 1491fa2d9 15jethornton: Docs: fix markup error...
[09:38:47] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15andypugh commented on issue #457: Do the changes require any changes to existing configs? 02 https://github.com/LinuxCNC/linuxcnc/pull/457#issuecomment-435382822
[10:40:29] -!- Roguish has joined #linuxcnc-devel
[13:32:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15c-morley pushed 2 new commits to 06qt5vcp_py2: 02 https://github.com/LinuxCNC/linuxcnc/compare/2b816f5c2d95...6ebd9b3323e0
[13:32:42] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 14b2f0631 15Chris Morley: qtvcp -add option reference geometry from main window...
[13:32:42] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06qt5vcp_py2 146ebd9b3 15Chris Morley: qtvcp -fix designer crash when deleting focus-overlay
[14:43:51] <linuxcnc-build> build #3840 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[14:43:52] <linuxcnc-build> build #5686 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[15:12:27] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15andypugh commented on issue #457: https://travis-ci.org 02 https://github.com/LinuxCNC/linuxcnc/pull/457#issuecomment-435480207
[15:22:53] -!- ve7it has joined #linuxcnc-devel
[16:30:17] <mozmck> It seems that some of the GUIs assume that axes A, B, and C are always rotary - but can't they be set to linear in the INI?
[16:33:21] <seb_kuzminsky> mozmck: yes, i believe they can
[16:33:32] <mozmck> hi seb_kuzminsky!
[16:36:34] <seb_kuzminsky> hi :-)
[16:36:55] <seb_kuzminsky> i think interp also assumes a, b, and c are angular, and x, y, z, u, v, and w are linear
[16:38:22] <seb_kuzminsky> eg https://github.com
[16:46:19] <mozmck> What I'm looking at is that DROs for ABC do not switch units when switching from inch to metric etc, and I'm thinking they should if those axes are linear.
[16:46:39] <mozmck> Is there a reason this is not a good idea that you can think of?
[16:47:35] <seb_kuzminsky> given that interp has abc hardcoded as angular, i think it would be misleading for the UIs to represent them as anything but angular
[16:49:15] <mozmck> hmm, I think I understand. In that case however - shouldn't it be an error to set those axes to linear in the INI file?
[16:49:16] <seb_kuzminsky> i think abc moves in degrees (or whatever angular units are set in the ini), independent of the g20/g21 setting
[16:49:26] <seb_kuzminsky> yes, it probably should
[16:49:29] <seb_kuzminsky> is it not?
[16:49:42] <seb_kuzminsky> (note: it's also possible my 5-minute reading of the code is missing something here)
[16:49:46] <mozmck> It does not give any error!
[16:50:02] <seb_kuzminsky> what happens when you try to run the machine that way?
[16:50:03] <mozmck> I think we have people using A as linear in any case.
[16:50:58] <mozmck> I guess I should set one up and try it. It works fine for jogging motors on the bench, but I have not tried changing units.
[16:52:45] <KimK> Yes, and maybe A as plastic extruder, so neither linear (unless "toothpase" length?) or rotary (extruder screw). However, I think you are right, ABC must be rotary due to positioning transforms, etc., but could be degrees, radians, grads, other(?)
[16:53:47] <KimK> s/"toothpase"/"toothpaste"/
[16:55:18] <KimK> Degrees being the external standard for gcode of course, never saw any other there.
[16:59:25] <mozmck> So from that function in interp_convert it looks like it at least assumes that coordinate system offsets are degrees for those axes.
[17:00:56] <jepler> "linear" vs "rotary" for *axes* is probably a leftover bug from when axes and joints were thoroughly muddled together in the inifile
[17:01:22] <jepler> now, axes have their nature defined by the gcode spec, but joints should specify angular/linear
[17:01:28] <jepler> </result of thinking about this for all of 15 seconds>
[17:01:50] <jepler> counterpoint: glue gun cnc machines use a/b as linear
[17:02:00] <mozmck> I should also say that that I failed to mention I'm using 2.7
[17:03:37] <seb_kuzminsky> my 3d printer runs master, and uses A for the extruder, but pretends that the units are mm instead of degrees
[17:03:55] <seb_kuzminsky> err
[17:04:27] <seb_kuzminsky> it doesn't specify angular or linear for AXIS_A, but set [JOINT_3]TYPE=ANGULAR
[17:05:51] <mozmck> We actually use a rotary axis as linear to cut pipe joints. Our software flattens out the joints to make them work in 2D cam. So the gcode is moving in inches or mm, but it is actually a rotary axis.
[17:14:59] <KimK> mozmck: That's an interesting one. Is the gcode executing in linear? Maybe it doesn't care?
[17:16:55] <mozmck> Yes, executing in linear, but I think it doesn't care. It knows the scale per unit (steps-per-inch etc), and moves the appropriate amount. I bet it works as long as no unit conversion is needed. I'll have to think through that more.
[17:18:44] -!- andypugh has joined #linuxcnc-devel
[17:55:42] <rene_dev_> jepler there are still units hardcoded in many places...
[18:03:49] <andypugh> Interesting question on the main forum.
[18:04:18] <andypugh> How _do_ you tell if a probe has completed sucessfully from the Python interface?
[18:05:03] <andypugh> It would be handy to be able to read #5070. But then it would be useful to be able to read all the params, but I don’t know of a way outside of a remap.
[18:10:41] <jthornton> how does G code read the params?
[18:12:24] <rene_dev_> they are exposed as variables
[18:12:31] <rene_dev_> or parameters
[18:15:20] <rene_dev_> the probescreen calls gcode macros, but I have no idea how it checks if it was successful
[18:15:50] <rene_dev_> https://github.com
[18:17:11] <jthornton> ah that uses remap and stdglue and toplevel might be something in there
[18:18:13] <rene_dev_> https://github.com
[18:18:25] <rene_dev_> probed_position=list(self.stat.probed_position)
[18:19:04] <rene_dev_> I think thats only to measure on m6
[18:31:34] <andypugh> rene-dev: Were you chasing this? https://forum.linuxcnc.org
[18:31:53] <andypugh> (spiral to arc blend or something like that)
[18:31:57] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15oro06 commented on issue #457: sorry, this last commit was not supposed to come to you now, ... 02 https://github.com/LinuxCNC/linuxcnc/pull/457#issuecomment-435528279
[18:35:42] <seb_kuzminsky> the python stat struct has .probing, .probe_tripped, and .probe_val, do any of those help?
[18:36:47] <seb_kuzminsky> .probe_val is the current value of the motion.probe-input, probably not useful
[18:37:48] <seb_kuzminsky> stat.probing is true when probing, false when not, so you could use that instead of going to hal for motion.motion-type == 5
[18:38:21] <seb_kuzminsky> there's also .probed_position()
[18:40:28] <seb_kuzminsky> so i think you could initiate the probe, wait for stat.probing to go true, wait for it to go false
[18:40:58] <seb_kuzminsky> then, if stat.probe_tripped is true, the probe bumped something, and you can cal stat.probed_position() to get where the trip happened
[18:41:08] <seb_kuzminsky> and if stat.probe_tripped is false, the probe didn't bump anything
[18:41:20] <seb_kuzminsky> that's just a guess from reading the code, i haven't actually tried it
[18:41:46] <jthornton> log
[18:41:46] <c-log> jthornton: Today's Log http://tom-itx.no-ip.biz:81
[18:41:56] <seb_kuzminsky> we don't have any probing tests :-(
[18:44:20] <jthornton> I passed your thoughts on to Blumax on #linuxcnc, he is the one trying to do this
[18:46:25] <seb_kuzminsky> thanks jthornton
[18:47:17] <jthornton> I could see where it would be nice to be able to read params from the python interface...
[18:47:26] <seb_kuzminsky> yeah, for sure
[18:48:07] <jthornton> looks like he found a way to solve his problem :)
[19:15:49] <rene_dev_> andypugh not in the forum... according to rob the PR is complete
[19:16:58] <rene_dev_> lets just merge it, and see what happens.
[19:17:21] <rene_dev_> the spindle stuff will come later this month
[19:21:24] <rene_dev_> his issue seems to be related to somehting else, there was an issue on github about the requested vel
[19:50:04] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[20:05:45] -!- commavir has quit [Ping timeout: 252 seconds]
[20:06:24] -!- commavir has joined #linuxcnc-devel
[20:14:00] <andypugh> Can you merge it?
[20:14:22] <andypugh> My current policy is almost “do it unless told not to” :-)
[21:56:47] <rene_dev_> andypugh ok
[21:58:56] <andypugh> I remembered the lathe roughing cycles today. I don’t think that those can break anything, but the current implementation isn’t all that it couldbe.
[22:00:08] <andypugh> Unrelated…. I was reading through some C-code today, and it contained _lots_ of foo = !! bar
[22:00:46] <andypugh> is that just a way to make sure anything that might be an int is definitely boolean?
[22:05:10] <rene_dev_> uh ohh
[22:05:21] <rene_dev_> dont know
[22:05:28] <rene_dev_> doesnt sound very readable
[22:09:16] -18VAA0JSA:#linuxcnc-devel- [13linuxcnc] 15rene-dev pushed 6 new commits to 062.7: 02 https://github.com/LinuxCNC/linuxcnc/compare/a859f005c7e0...ed75267689fc
[22:09:16] -18VAA0JSA:#linuxcnc-devel- 13linuxcnc/062.7 14a2adf31 15Robert W. Ellenberg: Remove atspeed from blend arc since the previous segment will not be consumed (fixes accel violation with G96 and arc blending).
[22:09:16] -18VAA0JSA:#linuxcnc-devel- 13linuxcnc/062.7 141fcb261 15Robert W. Ellenberg: tp: Fix fallback to parablic blending when tangent blend fails....
[22:09:16] -18VAA0JSA:#linuxcnc-devel- 13linuxcnc/062.7 1478e5f23 15Rene Hopf: fix compile error about c99 mode
[22:09:16] -17SAAXMFZ:#linuxcnc-devel- [13linuxcnc] 15rene-dev closed pull request #512: Rellenberg/bug447 fix blend tangent fallback (062.7...06rellenberg/bug447-fix-blend-tangent-fallback) 02 https://github.com/LinuxCNC/linuxcnc/pull/512
[22:10:08] <rene_dev_> oh
[22:10:18] <rene_dev_> now 2.7 wont merge into master...
[22:13:37] <rene_dev_> pathpilot has g70 and g71
[22:13:48] <rene_dev_> I wonder what implementation they use
[22:49:12] -!- pcw_home has quit [Remote host closed the connection]
[22:52:15] -!- ve7it has quit [Remote host closed the connection]
[22:53:29] <linuxcnc-build> build #3841 of 1405.rip-wheezy-armhf is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>, Robert W. Ellenberg <rwe24g@gmail.com>
[22:53:53] -!- ve7it has joined #linuxcnc-devel
[22:55:21] <linuxcnc-build> build #5687 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org blamelist: Rene Hopf <renehopf@mac.com>, Robert W. Ellenberg <rwe24g@gmail.com>
[23:00:29] <rene_dev_> hmm
[23:01:17] <rene_dev_> I cant figure out if that fail is related to the code change...
[23:55:47] <andypugh> What does the Travis log say?
[23:56:52] -!- andypugh has quit [Quit: andypugh]