#linuxcnc-devel Logs

Nov 02 2018

01:09 AM -!- #linuxcnc-devel mode set to +v by ChanServ
01:45 PM linuxcnc-build: build #3840 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/3840 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
01:45 PM linuxcnc-build: build #5686 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5686 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
03:31 PM 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?
03:34 PM seb_kuzminsky: mozmck: yes, i believe they can
03:35 PM mozmck: hi seb_kuzminsky!
03:38 PM seb_kuzminsky: hi :-)
03:38 PM seb_kuzminsky: i think interp also assumes a, b, and c are angular, and x, y, z, u, v, and w are linear
03:39 PM seb_kuzminsky: eg https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L1722-L1731
03:47 PM 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.
03:48 PM mozmck: Is there a reason this is not a good idea that you can think of?
03:49 PM 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
03:50 PM 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?
03:50 PM seb_kuzminsky: i think abc moves in degrees (or whatever angular units are set in the ini), independent of the g20/g21 setting
03:50 PM seb_kuzminsky: yes, it probably should
03:50 PM seb_kuzminsky: is it not?
03:51 PM seb_kuzminsky: (note: it's also possible my 5-minute reading of the code is missing something here)
03:51 PM mozmck: It does not give any error!
03:51 PM seb_kuzminsky: what happens when you try to run the machine that way?
03:51 PM mozmck: I think we have people using A as linear in any case.
03:52 PM 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.
03:54 PM 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(?)
03:55 PM KimK: s/"toothpase"/"toothpaste"/
03:56 PM KimK: Degrees being the external standard for gcode of course, never saw any other there.
04:00 PM mozmck: So from that function in interp_convert it looks like it at least assumes that coordinate system offsets are degrees for those axes.
04:02 PM jepler: "linear" vs "rotary" for *axes* is probably a leftover bug from when axes and joints were thoroughly muddled together in the inifile
04:02 PM jepler: now, axes have their nature defined by the gcode spec, but joints should specify angular/linear
04:02 PM jepler: </result of thinking about this for all of 15 seconds>
04:03 PM jepler: counterpoint: glue gun cnc machines use a/b as linear
04:03 PM mozmck: I should also say that that I failed to mention I'm using 2.7
04:05 PM seb_kuzminsky: my 3d printer runs master, and uses A for the extruder, but pretends that the units are mm instead of degrees
04:05 PM seb_kuzminsky: err
04:05 PM seb_kuzminsky: it doesn't specify angular or linear for AXIS_A, but set [JOINT_3]TYPE=ANGULAR
04:07 PM 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.
04:16 PM KimK: mozmck: That's an interesting one. Is the gcode executing in linear? Maybe it doesn't care?
04:18 PM 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.
04:57 PM rene_dev_: jepler there are still units hardcoded in many places...
05:05 PM andypugh: Interesting question on the main forum.
05:05 PM andypugh: How _do_ you tell if a probe has completed sucessfully from the Python interface?
05:06 PM 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.
05:12 PM jthornton: how does G code read the params?
05:13 PM rene_dev_: they are exposed as variables
05:14 PM rene_dev_: or parameters
05:16 PM rene_dev_: the probescreen calls gcode macros, but I have no idea how it checks if it was successful
05:17 PM rene_dev_: https://github.com/verser-git/probe_screen_v2
05:18 PM jthornton: ah that uses remap and stdglue and toplevel might be something in there
05:19 PM rene_dev_: https://github.com/verser-git/probe_screen_v2/blob/master/python/probe_screen.py#L195
05:19 PM rene_dev_: probed_position=list(self.stat.probed_position)
05:20 PM rene_dev_: I think thats only to measure on m6
05:33 PM andypugh: rene-dev: Were you chasing this? https://forum.linuxcnc.org/38-general-linuxcnc-questions/35387-how-to-update-from-git?start=10#119847
05:33 PM andypugh: (spiral to arc blend or something like that)
05:37 PM seb_kuzminsky: the python stat struct has .probing, .probe_tripped, and .probe_val, do any of those help?
05:38 PM seb_kuzminsky: .probe_val is the current value of the motion.probe-input, probably not useful
05:39 PM 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
05:39 PM seb_kuzminsky: there's also .probed_position()
05:41 PM seb_kuzminsky: so i think you could initiate the probe, wait for stat.probing to go true, wait for it to go false
05:42 PM 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
05:42 PM seb_kuzminsky: and if stat.probe_tripped is false, the probe didn't bump anything
05:42 PM seb_kuzminsky: that's just a guess from reading the code, i haven't actually tried it
05:43 PM seb_kuzminsky: we don't have any probing tests :-(
05:45 PM jthornton: I passed your thoughts on to Blumax on #linuxcnc, he is the one trying to do this
05:47 PM seb_kuzminsky: thanks jthornton
05:48 PM jthornton: I could see where it would be nice to be able to read params from the python interface...
05:48 PM seb_kuzminsky: yeah, for sure
05:49 PM jthornton: looks like he found a way to solve his problem :)
06:17 PM rene_dev_: andypugh not in the forum... according to rob the PR is complete
06:18 PM rene_dev_: lets just merge it, and see what happens.
06:18 PM rene_dev_: the spindle stuff will come later this month
06:22 PM rene_dev_: his issue seems to be related to somehting else, there was an issue on github about the requested vel
07:15 PM andypugh: Can you merge it?
07:15 PM andypugh: My current policy is almost “do it unless told not to” :-)
08:58 PM rene_dev_: andypugh ok
09:00 PM 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.
09:01 PM andypugh: Unrelated…. I was reading through some C-code today, and it contained _lots_ of foo = !! bar
09:02 PM andypugh: is that just a way to make sure anything that might be an int is definitely boolean?
09:06 PM rene_dev_: uh ohh
09:06 PM rene_dev_: dont know
09:06 PM rene_dev_: doesnt sound very readable
09:11 PM rene_dev_: oh
09:11 PM rene_dev_: now 2.7 wont merge into master...
09:15 PM rene_dev_: pathpilot has g70 and g71
09:15 PM rene_dev_: I wonder what implementation they use
09:54 PM linuxcnc-build: build #3841 of 1405.rip-wheezy-armhf is complete: Failure [4failed runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/3841 blamelist: Rene Hopf <renehopf@mac.com>, Robert W. Ellenberg <rwe24g@gmail.com>
09:56 PM linuxcnc-build: build #5687 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5687 blamelist: Rene Hopf <renehopf@mac.com>, Robert W. Ellenberg <rwe24g@gmail.com>
10:01 PM rene_dev_: hmm
10:02 PM rene_dev_: I cant figure out if that fail is related to the code change...
10:57 PM andypugh: What does the Travis log say?