Back
[11:30:17] <ktchk> Hi any robot kinematic expert?
[11:30:58] <cradek> hi ktchk, welcome, please just go ahead and ask your real questions, if someone can help they will
[11:31:28] <ktchk> How to put serial kinematic into linuxcnc?
[11:33:14] <cradek> There is documentation about making your own custom kinematics:
http://linuxcnc.org/docs/2.7/html/motion/kinematics.html
[11:33:23] <archivist> is it not already there though
[11:33:29] <cradek> also there are many existing kins modules you can use
[11:33:47] <cradek> you might want to investigate genserkins
[11:34:29] <ktchk> Can genserkin control robot arms
[11:34:43] <cradek> yes
[11:35:48] <ktchk> how to generate the g code for robot arms?
[11:38:03] <cradek> it depends on what you're doing I guess?
[11:39:30] <ktchk> like robot cnc?
[11:40:40] <ktchk> Is the DH (Denavit-Hartenberg) parameters different machine to machine?
[11:41:06] <cradek> yes that's how you describe different machines
[11:41:40] <ktchk> Hard to find out?
[11:42:19] <cradek> there are lots of tutorials online
[11:42:45] <ktchk> where please?
[11:42:57] <cradek> please do some searches and reading yourself
[11:43:11] <cradek> I don't know a good one offhand, without searching
[11:45:02] <ktchk> I found
http://juve.ro/blog/puma have a set to put into, but he did not said how to get it
[11:50:38] <ktchk> Thanks I have to go
[11:50:47] <cradek> welcome, good luck!
[13:04:52] <andypugh> Has anyone tested halcompile option singleton recently? With uspace?
[13:24:22] <jepler> andypugh: I don't doubt user's report that it doesn't work. user is having 3 unrelated problems at the same time, it seems like.
[13:24:44] <andypugh> Indeed. Though there may be no common cause
[13:25:32] <andypugh> I feel a bit responsible because we seem to have talked him in to an upgrade that has hindered rather than helped.
[13:26:05] <jepler> is user trying to build user's own code, or code someone else provided to user?
[13:26:09] <andypugh> I don’t have a handy uspace machine to run a test on, though there is nothing stopping me trying to compile a test singleton
[13:26:49] <andypugh> Hmm, thinking about it, it’s a modbus comp. Does he have option userspace?
[13:27:43] <andypugh> Yes, he does.
[13:28:56] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-halcompile-userspace-singleton-failing-test.patch
[13:29:02] <jepler> this test fails
[13:31:17] <jepler> as for libraries, user needs to specify them with option extra_link_args as documented
[13:31:26] <jepler> -lm for floor, something else for modbus
[13:32:25] <jepler> http://linuxcnc.org/docs/2.7/html/hal/comp.html#_options
[13:36:26] <andypugh> It does actually compile with no errors for me
[13:36:38] <andypugh> (If I remove option singleton)
[13:37:32] <jepler> right, that's the part that seems to be relatively clearly a bug in halcompile (option singleton yes + option userspace)
[13:38:18] <jepler> the test without "option singleton yes" is in tests/halcompile/userspace and it copies the example from the docs
[13:40:03] <andypugh> He seems to have found option extra_compile_args looking through the code, it is undocumented
[13:46:17] <jepler> no reason not to document it, must have been overlooked.
[14:29:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15reox opened issue #215: SHA1 on debian repo is untrusted in apt 1.4 02
https://github.com/LinuxCNC/linuxcnc/issues/215
[15:36:09] <skunkworks> rescapind
[15:36:12] <skunkworks> right
[16:32:08] <andypugh> bpuk: I really do think that life would be easier if we had an X (and possibly Z) move as part of the G71 line.
[16:32:24] <andypugh> Do you have any feel for if the parser can manage that ?
[16:34:12] <andypugh> I think that the XZ move in the G71 should define the “cut line” (which could, potentially, be angled). This makes it rather easier to determine the quadrant. Currently there are points when it would be nice to know the direction but it isn’t defined yet
[16:34:49] <bpuk> parser can, in theory, handle that
[16:35:24] <andypugh> The remap code can be given XYZ (ABC, UVW) so I had guessed that it could
[16:35:44] <bpuk> the method for determining quadrant varies by machine control - one method is to specify +/-ve U,W (J/L for us) values to define the quadrant
[16:36:27] <andypugh> Currently I don’t know quite how the depth-to-machine to is controlled in the other implementations.
[16:36:27] <bpuk> in the code tested (the final 2012) patch, it detected the quadrant for monotonic profiles - not sure if type2 introduces something extra that complicated it
[16:36:43] <bpuk> final depth to machine, or depth per pass?
[16:37:09] <andypugh> Unless there is detection for where the “first move” intersects the profile?
[16:37:45] <andypugh> Depth to stop machining at
[16:39:22] <andypugh> It just seems that an X and a Z in the G71 would be a more obvious way to say how deep and how far. (well, I can think of 2 things Z could be, but I doubt anyone needs a sloping cut-line, you can do it in the profile)
[16:40:37] <bpuk> Sorry, it's been a long day - I'm not quite understanding how the control doesn't know the depth to stop at - that's the profile? the 'fake' first move defines the starting point of the profile
[16:41:59] <bpuk> if the profile (in a type2) goes deeper than the starting point, that's then the max depth
[16:42:31] <andypugh> Maybe I am just not fully understanding the description on the web site I am looking at then
[16:42:49] <bpuk> which one are you looking at?
[16:43:38] <andypugh> http://www.cnccookbook.com/CCCNCGCodeG71RoughTurning.htm
[16:43:54] <bpuk> funnily enough, that's the same one I was looking at at the same time :D
[16:44:05] <bpuk> hmm - the Haas book is quite good
[16:44:14] <bpuk> https://diy.haascnc.com/g71-odid-stock-removal-cycle-group-00-0
[16:44:19] <andypugh> I guess you would never not want to machine the full dpeth of the profile, you would change the profile.
[16:44:26] <bpuk> exactly
[16:45:02] <bpuk> or... if you wanted to keep the profile the same, but larger, you could use finishing thickness in X
[16:45:11] <andypugh> It uses the sign of J to determine something, doesn’t it?
[16:45:32] <bpuk> J and L (U/W traditional) to determine quadrant
[16:46:00] <andypugh> Which is odd, because the “first move” does that too
[16:46:03] <bpuk> not quite sure why, since the starting position (of the G71 block, not of the profile) defines the quadrant (from memory)
[16:46:15] <andypugh> Yes, quite
[16:46:57] <andypugh> I think I am going to decide not to use the sign of J (U) for anything, as it makes 0 ambigous
[16:47:30] <andypugh> suppose we could use UW, but then if we ever have UW arcs in LinuxCNC it would break.
[16:47:47] <bpuk> the parser does _not_ like passing UW
[16:48:13] <andypugh> (And my code version will actually support UW G71, but only through re-writing arcs)
[16:48:39] <andypugh> Odd, it passes XYZ but not UVW?
[16:49:04] <bpuk> there was something really funky - I'd have to try it again, but there was a reason I had to switch the words
[16:50:26] <andypugh> I think we keep them switched. All that is lacking is arcs, supporting UW profiles without arcs is a worthy ambition, and not difficult.
[16:51:02] <bpuk> I bet the profile code I'm using could be tweaked really easily to allow UW arcs
[16:51:54] <bpuk> since all the functional stuff so far is done using primitives, and the arc code is mostly internal
[16:52:27] <andypugh> Mine handles any plane defined in LinuxCNC G-code.
[16:52:29] <bpuk> but I'm happy with JL, it opens up possibilities for those
[16:53:08] <andypugh> (And by making the plane mutable G72 is just a coordinate swap. I think)
[16:53:12] <bpuk> to be honest, your code is quite a way ahead of mine in a lot of ways
[16:53:22] <andypugh> That reminds me, I haven’t tried a G72 for a while
[16:53:24] <bpuk> I'm slowly refactoring to allow arbritrary planes etc
[16:53:31] <bpuk> but it's slow ;)
[16:54:19] <andypugh> I wouldn’t bother. Get it working as-is and then we can work in the Type11 algorithm once there is one that works.
[16:55:00] <bpuk> I'll rephrase, I'm adding things like that as part of the larger refactor
[16:55:30] <bpuk> I pick a function (or set) and go 'hmm, that could be better, ok. what _should_ it do'
[16:55:59] <bpuk> biggest challenge at the minute is getting the o profile stuff to readahead and read from other files - I consider that an important milestone
[16:58:03] <bpuk> frustratingly - under nesting conditions (G71 inside an O sub), it usually works
[16:58:15] <bpuk> so i'm missing something. I'll spot it soon
[17:06:27] <andypugh> I keep wishing that if X (>)*b Y (or similar) would mean X < Y if b = -1 :-)
[17:07:13] <bpuk> heh :D
[17:07:45] <andypugh> There are so many places where the combination of > < >= <= change with direction.
[17:08:17] <bpuk> yup - I'm really considering doing a macro
[17:08:31] <andypugh> In C, you could.
[17:08:48] <bpuk> you could do a function in python?
[17:09:04] <bpuk> oh, I've also been playing on paper with algorithms for offsetting the profile - I think I've got most of it
[17:09:08] <andypugh> Yes, and I am thinking of doing it right now.
[17:11:42] <bpuk> but it's going to involves a lot of > < >= <= changing with direction
[17:12:11] <bpuk> your idea of splitting the arc into quadrants is good, and makes the offset pretty good
[17:13:13] <andypugh> It was having that idea the prompted me to want to fiddle
[17:13:38] <bpuk> the joy of an idea grabbing your brain and running with it
[18:59:59] <skunkworks> big flywheel? Yes please!
http://electronicsam.com/images/matsuura/20161129_155522.jpg
[19:00:50] <skunkworks> edm is on the stand..
http://electronicsam.com/images/matsuura/20161129_160909.jpg
[19:05:03] <skunkworks> zlog
[19:27:33] <skunkworks> andypugh, odd gap
http://electronicsam.com/images/KandT/testing/Screenshot-25.png
[19:31:06] <andypugh> Probably fixed. But now something else is broken
[19:31:24] <skunkworks> heh
[19:31:31] <skunkworks> I never have that problem ;)
[19:32:02] <andypugh> I had a majot reqork, still sorting out the fallout
[19:32:13] <andypugh> (rework)
[20:07:30] <skunkworks> you guys are awesome
[20:54:26] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap 2f007ac 06linuxcnc 10configs/sim/axis/g71/python/remap.py 03nc_files/G72test1.ngc 10nc_files/lathe_pawn_G71.ngc G71: Robustness improvements and direction-aware comparison functions. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2f007ac
[20:55:29] <andypugh> skunkworks: Let me know how that one works for you. One known-problem, LinuxCNC forces the L (axial clearance) to be an integer. Probably a problem in Inch units.
[21:31:06] <cradek> darn, just missed him
[21:32:40] <cradek> andypugh: fwiw, the interpreter knows and maintains the difference between +0 and -0, and there is precedent for it mattering: with wrapped rotary, G90G0A+0 and G0A-0 move in opposite directions
