#linuxcnc-devel Logs

Aug 09 2018

02:50 AM -!- #linuxcnc-devel mode set to +v by ChanServ
04:37 AM dlcastc is now known as Guest92205
05:02 AM hazzy-lab1 is now known as hazzy-lab
09:39 AM skunkworks: rene has been working on 'fixing' the tool table situation.. I don't know how far he is.
09:49 AM -!- #linuxcnc-devel mode set to +v by ChanServ
10:11 AM -!- #linuxcnc-devel mode set to +v by ChanServ
10:11 AM cradek_ is now known as cradek
10:12 AM cradek is now known as cradek_
10:13 AM cradek_ is now known as cradek
10:13 AM cradek: sorry
11:06 AM hazzy-lab: skunkworks: I think rene-dev is waiting on this PR to continue working on the tool table: https://github.com/LinuxCNC/linuxcnc/pull/415
11:24 AM seb_kuzminsky: #415 looks like it's not ready
11:34 AM hazzy-lab: seb_kuzminsky: I don't think it is. I meant I think he is waiting to get that sorted before continuing on with the tool table improvements
11:34 AM seb_kuzminsky: ok cool, we're seeing the same thing
11:35 AM seb_kuzminsky: it's sometimes confusing as a maintainer when there are open PRs that are not ready to pull, so thanks for the sanity check
11:35 AM seb_kuzminsky: (and i'm sure guilty of making PRs like that in other projects)
11:39 AM hazzy-lab: yes, that PR is a little confusing! almost more of an issue ..
02:26 PM rene_dev_: 18:24 <rene_dev_> it works, but isnt complete
02:26 PM rene_dev_: 18:25 <rene_dev_> some things like t remap dont work properly
02:26 PM rene_dev_: 18:25 <rene_dev_> and I discovered more bugs, that are also present in master...
02:32 PM seb_kuzminsky: rene_dev_: thanks for being careful and diligent
02:52 PM Tom_L is now known as Tom_shop
02:52 PM Tom_shop is now known as Tom_itx
02:52 PM Tom_itx is now known as Tom_L
02:57 PM Tom_itx is now known as Log
03:01 PM c-log is now known as Guest85094
03:09 PM rene_dev_: one bug I already fixed, and is merged in master
03:09 PM rene_dev_: I discoverd it while writing tests for the pockets
03:11 PM seb_kuzminsky: the #5400 fix?
03:32 PM rene_dev_: yes
03:33 PM rene_dev_: there is possibly more like that
03:33 PM rene_dev_: I dont understand why not all parameters are named
03:33 PM rene_dev_: numbers are hard to remember, or read
03:33 PM seb_kuzminsky: named parameters are fairly recent
03:34 PM seb_kuzminsky: numbered parameters are "standard" g-code
03:34 PM rene_dev_: hmmm, not really.
03:35 PM seb_kuzminsky: numbered parameters can also be used with indirection, though i don't know if people do that a lot
03:35 PM rene_dev_: indirection?
03:36 PM rene_dev_: I find them really hard to read in gcode.
03:37 PM seb_kuzminsky: me too
03:38 PM rene_dev_: I was working with some local made controller, fixing a machine today
03:38 PM rene_dev_: and I must say I like the way they handle toolchange
03:39 PM rene_dev_: you just create a file m6.cnc, and it does whats in there on m6. thats all.
03:39 PM rene_dev_: why isnt it that simple in linuxcnc?
03:39 PM seb_kuzminsky: indirection like this:
03:39 PM seb_kuzminsky: READ => #1 = 2
03:39 PM seb_kuzminsky: READ => #2 = 10
03:39 PM seb_kuzminsky: READ => g0 x##1 6 N..... STRAIGHT_TRAVERSE(10.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
03:40 PM rene_dev_: uff, why would someone do that :O
03:40 PM seb_kuzminsky: i don't know! :-)
03:40 PM seb_kuzminsky: just pointing out something you can do with numeric parameters that you can't do with named parameters
03:40 PM seb_kuzminsky: "though i don't know if people do that a lot" :-)
03:41 PM seb_kuzminsky: anyway, yeah I'm not at all about to claim linuxcnc does everything best, or that the way things are now is the way things should be in the awesome future
03:41 PM seb_kuzminsky: it's just how far we've all pushed it forward since the beginning, so far
03:43 PM rene_dev_: yeah :D
03:44 PM rene_dev_: to me it just looks like remaps are just waaay to complicated
03:44 PM rene_dev_: there should only ever be one simple way of doing things like this
03:45 PM seb_kuzminsky: sigh, yeah
04:26 PM hazzy-lab: seb_kuzminsky: I have never been able to get indirection to work, and I have spent a LOT of time trying
04:26 PM hazzy-lab: I think it may only work with sub calls
04:28 PM hazzy-lab: hmm, maybe I did not have the right syntax, I was tried things like #[#1 * #2]
04:32 PM cradek: READ => #1=2
04:32 PM cradek: READ => #2=3
04:32 PM cradek: READ => #6=3.14
04:32 PM cradek: READ => g0 x#[#1*#2]
04:32 PM cradek: 6 N..... STRAIGHT_TRAVERSE(3.1400, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
04:33 PM cradek: (?)
04:36 PM hazzy-lab: cradek: for example, I want to get the z offset of the current work coord system, so I tried this:
04:36 PM hazzy-lab: (debug, #[5203 + [20 * #5220]])
04:36 PM hazzy-lab: But it does not seems to work when entered into the axis MDI input
04:41 PM cradek: I think debug has limitations, because it does its own substitution, and it doesn't know how to do the evaluations
04:41 PM hazzy-lab: cradek: it works when I run rs274 in the terminal!
04:42 PM hazzy-lab: hurray!
04:42 PM cradek: #1=#[#5203+[20*#5220]]
04:42 PM hazzy-lab: I should not have jumped to conclusions that it was not working
04:42 PM cradek: (debug,#1)
04:42 PM cradek: you could do these two things in mdi to get the result you want
04:43 PM cradek: er I spelled it wrong
04:43 PM cradek: you get the idea
04:43 PM hazzy-lab: yes, that works in MDI!
04:43 PM cradek: you were not wrong, (debug) in mdi violates some very reasonable expectations
04:50 PM hazzy-lab: cradek: you can not imagine how exiting it is to be able to use indirection!
04:51 PM hazzy-lab: rene_dev_: A practical application of indirection in a probing routine: http://dpaste.com/3Y7YTS9
04:51 PM hazzy-lab: that saves a LOT of typing ...
04:51 PM cradek: it gives you array workalikes etc, too
04:52 PM hazzy-lab: yes, that is true!
04:52 PM cradek: (wish we had G53 G38.x)
04:52 PM * hazzy-lab does too
04:52 PM hazzy-lab: I think that is better than adding parameters ...
04:52 PM hazzy-lab: but I think seb already started adding parameters for ABS probed pos
05:07 PM seb_kuzminsky: https://github.com/LinuxCNC/linuxcnc/commits/seb/2.7/abs-probe
05:08 PM seb_kuzminsky: it doesn't add g53 g38.n, but it does make it so g38.n stores the probed location in both the currently active work coordinate system and in the g53 coordinate system
05:08 PM seb_kuzminsky: (in different sets of numbered parameters)
05:09 PM seb_kuzminsky: http://buildbot.linuxcnc.org/doc/scratch/v2.7.14~seb-2.7-abs-probe~23f90ce/html/gcode/overview.html#sub:numbered-parameters
05:09 PM seb_kuzminsky: g53 in #5081-#5089
05:17 PM seb_kuzminsky: like rene_dev_ and i were just talking about above, sort of, doing this the way i think users would want is harder than it seems like it should be
05:18 PM seb_kuzminsky: Motion determines the probe location, and linuxcnc makes it available to "the user" in Interpreter parameters and in the Status buffer
05:18 PM rene_dev_: would be cool if you could also add named parameters... would make probing macros SO much easier to read
05:18 PM hazzy-lab: seb_kuzminsky: just a thought. Since Fanuc uses the same parameters for the ABS probed pos as LCNC currently used for the REL probed pos, might it be better to make it possible to use G53 with G30.x, rather than adding additional parameters?
05:18 PM hazzy-lab: Than all that would be needed to make a Fanuc probing routine compatible with LCNC would be to add a G53 before the probe
05:18 PM hazzy-lab: I know we are not trying to be consistent with any commercial controller, but it seems like it might be a cleaner solution overall
05:18 PM seb_kuzminsky: the status buffer has a raw copy of the probe location from Motion, which is in G53 (because all of Motion is in G53 and knows nothing about work coordinates)
05:18 PM rene_dev_: I came across this same issue years ago, and no one replied on the ML :D
05:19 PM seb_kuzminsky: the interp parameters (before my branch) have the work coord offsets of the g53 position from motion
05:20 PM seb_kuzminsky: so copying the g53 coords into new interp params is easy, but getting the work coord positions into the status buffer has to happen in a totally different place (from inside interp)
05:20 PM seb_kuzminsky: hazzy-lab: thanks, i didn't know that about fanuc
05:21 PM seb_kuzminsky: (though i think you meant "G38.n" instead of "G30.n"?)
05:21 PM hazzy-lab: seb_kuzminsky: I think it is fine it the status buffer only reports probed pos in G53 coords, it is easy to convert from G53 to a work coord, but not so much the other way around
05:21 PM seb_kuzminsky: changing the meaning of existing parameters is awkward, because it breaks existing g-code
05:22 PM hazzy-lab: seb_kuzminsky: Yes, i meant G38 :)
05:22 PM cradek: neither conversion is easy or obvious
05:22 PM seb_kuzminsky: cradek: because of rotation?
05:22 PM cradek: and units
05:22 PM seb_kuzminsky: oh, right
05:22 PM cradek: and tool offset and g92 offset and g5x offset
05:23 PM hazzy-lab: seb_kuzminsky: it would not bread existing code, because the parameters would have the same meaning they do now, unless G53 was sued with G38
05:23 PM seb_kuzminsky: right, it'd be much better to do it once and do it right, inside linuxcnc, and users can just use those precomputed values
05:23 PM hazzy-lab: break*
05:23 PM cradek: I think (THINK) the one you currently get is the one you can use right away in a motion command without being surprised
05:24 PM seb_kuzminsky: cradek: i just looked at this, the Status buffer has the numbers directly from motion, but the interp params have the converted-to-work-coords numbers
05:24 PM hazzy-lab: cradek: yes, but who would use a probed pos for a motion command?? Probe pos are almost always used for setting a work coord offset
05:24 PM cradek: that seems plausible
05:25 PM cradek: hazzy-lab: that's where G10 L20 works nicely
05:25 PM hazzy-lab: no
05:25 PM seb_kuzminsky: hazzy-lab: i see what you're saying, use "G53 G38.n" if you want G53 coords everywhere, or keep using "G38.n" without G53 to maintain the current behavior of work coordinates in Interp parameters
05:26 PM cradek: G38.2 Z-...; G0 [#5220+1]; G10 L20 Z1
05:26 PM hazzy-lab: because G10 L20 sets the current location to the values specified, what you want to do is set the work coord offsets
05:27 PM hazzy-lab: cradek: but then probing holes and slots that is not so trivial ..
05:27 PM cradek: my probe routine ends up with the probe in the center of the hole when done, and then G10 L20 X0 Y0 sets the coordinate system to the hole
05:28 PM hazzy-lab: as setting the work offset becomes a "causes motion" type command and you have to be careful you don't crash the probe
05:28 PM cradek: I don't see why nobody likes what it does now
05:28 PM cradek: huh?
05:28 PM seb_kuzminsky: cradek: is your hole probe sub posted somewhere?
05:29 PM seb_kuzminsky: is it the probe-hole.ngc in our nc_files?
05:29 PM cradek: it's just like all of them...
05:29 PM cradek: probably?
05:29 PM Tom_L: cause we copied yours :D
05:29 PM seb_kuzminsky: obviously not everyone knows your technique
05:29 PM hazzy-lab: cradek: for example, you are in a narrow slot and want to set zero to one side of the slot
05:29 PM cradek: yeah that looks like mine :-)
05:30 PM seb_kuzminsky: it was added by jthornton in 2008
05:31 PM seb_kuzminsky: and then rewritten by you in 2010 :-)
05:33 PM cradek: g38.2 x...; g0 x[#5xxx-.01]; g10 l20 x-.01
05:34 PM cradek: you always want to pull off at least a little I think?
05:35 PM hazzy-lab: with indirection this becomes almost a non issue :)
05:35 PM hazzy-lab: G38.2 Z-.75; G0 G10 L2 P#5220 Z[#5063 + #[5203 + [20 * #5220]]]
05:36 PM cradek: (G0 G10 is invalid)
05:36 PM hazzy-lab: oops, how did that G0 sneak in there?
05:36 PM hazzy-lab: lol
05:36 PM cradek: I think I see what you mean
05:36 PM cradek: how do you write "pull off a little bit" then?
05:37 PM hazzy-lab: G90 G38.2 Z-.75; G0 Z.1; G10 L2 P#5220 Z[#5063 + #[5203 + [20 * #5220]]]
05:37 PM hazzy-lab: better?
05:37 PM hazzy-lab: make use of that G0 :D
05:37 PM cradek: what would you G0?
05:37 PM hazzy-lab: or G1 ...
05:38 PM cradek: to what endpoint?
05:38 PM hazzy-lab: but you can pull off fast
05:38 PM hazzy-lab: .1 up in Z
05:38 PM cradek: in a narrow slot how would you just barely pull off the surface?
05:39 PM cradek: remember you don't know how far you overtravelled
05:39 PM hazzy-lab: What I do is store the initial probe pos and go back there
05:39 PM cradek: depends on your probing speed
05:39 PM hazzy-lab: then you know you are safe
05:39 PM cradek: ah that makes sense
05:39 PM Tom_L: you took your probe routines offline ehh?
05:39 PM cradek: Tom_L: my whole personal blog is gone, at least for now, going pro with the watch repair
05:39 PM Tom_L: saw that
05:40 PM Tom_L: looks good btw
05:40 PM cradek: thank you
05:40 PM seb_kuzminsky: you need an unprofessional website too
05:40 PM cradek: works on computers and tablets and phones, felt like a huge accomplishment
05:40 PM cradek: seb_kuzminsky: I need more hours in each day too
05:41 PM seb_kuzminsky: :-)
05:41 PM Tom_L: there are 48 hrs in a day, they're just shorter
05:41 PM seb_kuzminsky: mars has 24.5 hrs/day
05:41 PM Tom_L: long commute
05:42 PM Tom_L: you don't mind if i re'post em if i find em here do ya?
05:42 PM cradek: of course not
05:42 PM Tom_L: i swear i had em on my server somewhere
05:42 PM cradek: archive.org should have everything
05:42 PM cradek: apparently they were up for over a decade
05:44 PM Tom_L: ah hah..
05:45 PM cradek: on my vmc I use them as touchy macros, and you can fill in "1" for "set coord system 1 here" or leave it blank for just probe and pull off
05:45 PM Tom_L: http://tom-itx.no-ip.biz:81/~webpage/cnc/cradek/
05:48 PM seb_kuzminsky: sooo, hazzy-lab, no need for me to finish that abs-probe branch? you got what you need from cradek?
05:48 PM cradek: adding more #vars to probing if you feel like it makes perfect sense
05:49 PM cradek: if there's room in the numbers, even better
05:49 PM cradek: I always envisioned supporting g53 g38.2 (reusing the #vars) but your way is fine too
05:49 PM * cradek shrugs
05:49 PM seb_kuzminsky: yeah we haven't run out of numbers yet
05:49 PM hazzy-lab: seb_kuzminsky: I guess so. The problem is the same (not having ABS probed pos), but the use of indirection makes it much easy to work around
05:51 PM hazzy-lab: seb_kuzminsky: thanks for mentioning indirection earlier! That is what induced me to give it another go
05:51 PM seb_kuzminsky: yay!
05:52 PM hazzy-lab: I actually had it, but the (debug, ) messages were wrong, which thru me off
05:52 PM seb_kuzminsky: yeah, it's pretty crazy that the rules for parameter expansion are different in "real gcode" vs in (debug)
05:53 PM cradek: wellllll
05:53 PM cradek: the obvious solution is to just execute the code, but that's also an obvious problem
05:53 PM cradek: because most things you (debug,...) aren't gcode
05:54 PM cradek: so I don't know what particular hack is best because neither printing as-is or running it as gcode and printing that are right
05:54 PM seb_kuzminsky: i think most things i (debug) are parameters
05:55 PM cradek: (debug, the radius is #1)
05:55 PM seb_kuzminsky: can parameter expansion cause motion, or cause interpreter state to change in any way? not that i can think of
05:55 PM cradek: I don't think so either
05:56 PM seb_kuzminsky: but i see your point that pulling parts out of a (debug) argument string and running them through the interpreter seems a bit sketchy
05:57 PM cradek: but you can't just blindly expand # can you? (debug, the radius is #1 and doesn't this stuff afterward cause a bunch of syntax errors now?)
05:57 PM seb_kuzminsky: even if you just run the string through the parameter-expansion function
05:57 PM * hazzy-lab needs to start using the rs274 command line tool more, it is really very convenient
05:57 PM seb_kuzminsky: yeah, you'd have to parse it enough to know what the parameter is
05:57 PM cradek: I'm truly not sure, but I'm uneasy about it