Back
[13:24:47] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jmelson opened issue #213: trigger real time thread from external interrupt 02
https://github.com/LinuxCNC/linuxcnc/issues/213
[16:13:55] <bpuk> jepler: Thanks - that works!
[16:14:35] <bpuk> andypugh: for info - I put a pull request in on the G71 branch. That should bring us back to where I was in 2012
[16:15:24] <bpuk> andypugh: working on getting it moved over from named lines to o-subs. I think that most of the breakage will come from there so seems like the best place to start
[16:19:51] <andypugh> I am not sure how it works with C++. My Python mock-up was just: regex= r'\O0*%(p)i\s*SUB(.*)O0*%(p)i\s*ENDSUB' % words
[16:19:52] <andypugh> gcode = re.findall(regex,open(s.file).read(), re.M | re.S | re.I)
[16:19:52] <andypugh> gcode = gcode[0].split('\n')
[16:20:42] <andypugh> But then I was not trying to be robust at all for the bit I am playing with.
[16:21:24] <bpuk> been trying not to think about type2 - looks like the 'obvious' way is to subdivide on points of inflection and run each segment individually
[16:21:34] <bpuk> almost recursive
[16:21:49] <bpuk> makes sense for a mockup - doesn't matter how you get the profile in ;)
[16:21:53] <andypugh> One side-effect of using O-words is that I think that the profile can actually be in a different file.
[16:22:15] <bpuk> yeah, it certaintly can - is that good or bad though?
[16:22:24] <andypugh> O nn CALL can look in many places
[16:22:48] <andypugh> I think it might be good. You can imagine keeping a library of profiles.
[16:23:08] <bpuk> and if it's a one-off, then define it in the same file?
[16:23:24] <andypugh> Needs thought :-)
[16:24:45] <bpuk> been thinking about how to define the profile as being in an arbitrary plane too. I'm leaning towards making it a class rather than a simple struct
[16:25:11] <bpuk> and yes, yes it does
[16:28:23] <andypugh> Arbitrary plane does’t seem to hard
[16:28:45] <andypugh> # Be agnostic about plane.
[16:28:46] <andypugh> planes={170:('X','Y'), 180:('X','Z'), 190:('Y','Z'),
[16:28:47] <bpuk> simple way is take the first two axes used
[16:28:48] <andypugh> 171:('U','V'), 181:('U','W'), 191:('V','W')}
[16:28:49] <andypugh> for g in s.gcodes:
[16:28:50] <andypugh> if g in planes:
[16:28:51] <andypugh> p, q = planes[g]
[16:29:30] <bpuk> and error if a third axis is used
[16:29:39] <bpuk> pretty much
[16:29:44] <andypugh> Though that’s not arbitrary, it uses the G17-G19.1 setting
[16:30:36] <bpuk> for the lathe ops I'll need at least (X, Z ), (Z, X), (U,W), (W,U)
[16:32:30] <andypugh> Slight wrinkle, yes. The planes are normally called 17-XY, 18-ZX, 19-YZ but the G71 / G72 distinction is on whether you feed in Z or X. Now if G18 G71 feeds in Z, does G17 G71 feed in X ?
[16:34:01] <bpuk> ideally I'd want (X, Z ), (Z, X) to both respect G18 for movement, but flip inside the roughing function
[16:34:39] <andypugh> bpuk: I think this is just something to document and be consistent about. G71 should probably feed in Z for planes with a Z in them, G72 feeds in the other one, and the other combinations go by a fixed (but almost arbitrary) convention.
[16:38:50] <bpuk> makes sense
[16:39:17] <bpuk> other combinations go in alphabetical would do - that way it's consistent at least