Back
[07:55:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15midyukov-anton commented on issue #106: Compiling with libmodbus version 3.1.4 fails.... 02
https://github.com/LinuxCNC/linuxcnc/pull/106#issuecomment-263122093
[12:11:19] <andypugh> bpuk:
https://youtu.be/PGfAPQDYUZE
[12:12:49] <skunkworks> andypugh, holy crap!
[12:12:52] <skunkworks> nice work!
[12:14:06] <andypugh> Surprisingly the hardest part was handling lines parallel to the feed direction exactly on the feed path. That turned out to be really quite a challenge.
[12:18:40] <skunkworks> How would someone test this ;)
[12:23:10] <cradek> wow that looks extremely tricky
[12:24:05] <andypugh> Clearly no real tool could machine that shape, but it ought to work better on sane shapes. But an insane shape seemed like a good test
[12:24:26] <cradek> sure
[12:25:18] <andypugh> Where is a good place to put the config file as a zip?
[12:29:12] <skunkworks> couldn't you push a config to master?
[12:30:15] <andypugh> It’s just a G-code remap at the moment.
[12:31:02] <andypugh> I was just trying out algorithm ideas, and that’s easier in Python than C++
[12:33:24] <cradek> I'd use a branch named something like andypugh/g71type2remap
[12:33:39] <cradek> off master or wherever you're working
[12:34:11] <cradek> I'm amazed you could do that in remap
[12:34:30] <andypugh> It’s not elegant. I had to re-invent arcs.
[12:34:50] <andypugh> Definitely not the desirabe way to do it.
[12:37:17] <skunkworks> I really don't think it matters :)
[12:39:56] <andypugh> skunkworks: It would be much better to have the arcs used by G71 calculated by the same code that does arcs in all the other G-codes
[12:43:25] <skunkworks> sure - I remember you guys talking about it
[12:45:11] <skunkworks> it is because you are using python? (don't have access to the internals)
[12:45:30] <skunkworks> or was it just easier to do it again?
[12:47:35] <bpuk> looks good andy
[12:48:12] <skunkworks> so - the mailing list - creating a desktop icon from a rip install - seems to work as expected.. For me. And I have used it on other systems.. (this is jessie)
[12:48:36] <skunkworks> It launches the correct rip version - or the installed version depending on how the icon was created.
[12:48:47] <skunkworks> am I missing something?
[12:49:03] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap 4fc4e42 06linuxcnc 03configs/sim/axis/g71/lathe.ini 03configs/sim/axis/g71/lathe.tbl 03configs/sim/axis/g71/python/remap.py 03configs/sim/axis/g71/python/toplevel.py G71 as remap for testing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4fc4e42
[12:51:52] <andypugh> skunkworks: If you want to try it out, all you need to do is to make the INI changes in that config and put the “Python” folder in your own config.
[12:52:10] <skunkworks> I am pulling your branch currently
[12:52:14] <skunkworks> building
[12:56:27] <andypugh> Nothing to build…
[12:56:51] <andypugh> It’s all in the remap
[13:01:59] <skunkworks> right - but my dev repository needed to be updated..
[13:02:14] <skunkworks> where is the sample program?
[13:02:25] <skunkworks> (I need something to start with) :)
[13:07:25] <andypugh> Ah, yes, not in the Git repo
[13:07:31] <andypugh> Just a moment
[13:09:10] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap a0d1129 06linuxcnc 03nc_files/G71test1.ngc 03nc_files/G71test2.ngc 03nc_files/G71test2.ngc~ Add sample files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0d1129
[13:10:02] <skunkworks> yay - thanks
[13:19:45] <andypugh> Hmm, I seem to have created a regex which _requires_ that the G-code be indented.
[13:38:39] <skunkworks> what spec (what does each word do?) I have an english shape that I am trying to profile
[13:50:51] <skunkworks> andypugh, I am getting
[13:50:54] <skunkworks> interp __init__ 0 23929
[13:50:54] <skunkworks> {'d': 1.0, 'f': 900.0, 'i': 0.01, 'k': 0.01, 'j': 1.0, 'l': 1.0, 'p': 100.0, 'r': 0.01}
[13:50:54] <skunkworks> X Y I J
[13:50:54] <skunkworks> invalid words in block {'Z': '0'}
[13:50:54] <skunkworks> invalid words in block {'Z': '0.0000', 'F': '3'}
[13:50:55] <skunkworks> invalid words in block {'Z': '-0.0094'}
[13:50:57] <skunkworks> invalid words in block {'Z': '-0.0248'}
[13:50:59] <skunkworks> invalid words in block {'Z': '-0.0457'}
[13:51:43] <andypugh> You are not in the G18 plane
[13:53:10] <andypugh> (though I am also not 100% sure that I have IJK arcs working. Which is annoying because re-inventing arcs is a waste of time)
[13:55:05] <skunkworks> ok now I am down to
[13:55:07] <skunkworks> interp __init__ 0 23929
[13:55:07] <skunkworks> {'d': 1.0, 'f': 900.0, 'i': 0.01, 'k': 0.01, 'j': 1.0, 'l': 1.0, 'p': 100.0, 'r': 0.01}
[13:55:07] <skunkworks> X Z I K
[13:55:07] <skunkworks> call(remap.g71):
[13:55:07] <skunkworks> Traceback (most recent call last):
[13:55:08] <skunkworks> File "./python/remap.py", line 317, in g71
[13:55:10] <skunkworks> g7x(self, 71, **words)
[13:55:12] <skunkworks> File "./python/remap.py", line 284, in g7x
[13:55:14] <skunkworks> for p in range(0, pcount + 1):
[13:55:16] <skunkworks> UnboundLocalError: local variable 'pcount' referenced before assignment
[13:56:22] <skunkworks> (I may not have the G71 line correct - as I was guessing from metric to english
[13:58:32] <andypugh> does the sample file work?
[13:58:54] <skunkworks> andypugh,
http://pastebin.com/CQNSCrWa
[13:58:55] <skunkworks> yes
[13:58:59] <skunkworks> sample file swork
[13:59:00] <skunkworks> work
[13:59:04] <andypugh> The meaning of the G71 letters is listed in the remap.py file
[13:59:48] <andypugh> I think D1 means no cuts were generated
[13:59:55] <andypugh> ie, 1” DOC
[14:07:08] <andypugh> In lathe diameter mode, are I-offset arc centres in radius or diameter?
[14:08:31] <skunkworks> close
http://electronicsam.com/images/KandT/testing/Screenshot-21.png
[14:10:41] <andypugh> Start a bit further out?
[14:14:24] <bpuk> Finally made some progress on the o-word profile. re-doing the conversion code now.
[14:14:43] <bpuk> or possibly extend the last line out in X?
[14:15:45] <skunkworks> further out doesn't seem to help
[14:20:04] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-22.png
[14:22:37] <andypugh> Something odd going on, I am getting the same.
[14:23:15] <andypugh> In remap.py change line ~286 to for p in range(0, 10):
[14:23:26] <andypugh> pcount isn’t being set right.
[14:29:44] <skunkworks> what is the original line?
[14:32:10] <andypugh> rang(0,pcount)
[14:32:36] <andypugh> Though I have now found the problem
[14:32:53] <andypugh> And found new unsolved bugs…
[14:33:25] <skunkworks> heh
[14:33:30] <skunkworks> I am good at that
[14:35:19] <andypugh> It doesn’t do well if the patch hits a point exactly.
[14:35:25] <andypugh> (path)
[14:56:33] <andypugh> So, I am thinking that if the path hits a profile node exactly, and if the next node is on the same side as the previus node, then the node should be ignored. Thoughts?
[15:01:08] <bpuk> same side?
[15:07:24] <andypugh> if (x2==x and x1<x and x3<x) or (x2==x and x1>x and x3>x)
[15:08:08] <bpuk> wouldn't that give inconsistent depth of cut?
[15:11:33] <andypugh> Cases like this:
http://pasteboard.co/36DBWkrXW.png
[15:11:59] <andypugh> See how the cut stops at the point, but shouldn't
[15:13:24] <bpuk> now I see what you mean. I'd expect that to continue onwards
[15:13:54] <andypugh> So, how to detect that situation…
[15:14:27] <bpuk> actually, no - I would expect it to stop there
[15:14:44] <bpuk> if the cut was 0.01mm bigger, I'd expect it to continue
[15:15:51] <bpuk> and the triangular undercut would be dealt with once everything to the right of it had been cut out
[15:17:49] <andypugh> It can stop and then restart at the exact same point, or continue. But in either case it _should_ cut the triangle at the same height
[15:19:18] <andypugh> The problem is that the point-hit is seen as entering the “inside” of the part, and it doesn’t think it is “outside” again until the next arc.
[15:28:16] <bpuk> I'm not convinced it's a problem - once you implement type2 retract I think the problem will more or less go away
[15:28:43] <andypugh> I am convinced that it is a problem.
[15:28:45] <bpuk> mulling it over but I could be confusing myself at this point
[15:29:22] <andypugh> It is to do with a singularity confusing the inside/outside tag, mainly
[15:33:03] <linuxcnc-build_> build #1251 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/1251 blamelist: andypugh <andy@bodgesoc.org>
[15:36:36] <andypugh> Odd..
[15:45:51] <linuxcnc-build_> build #4639 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4639 blamelist: andypugh <andy@bodgesoc.org>
[15:46:14] <bpuk> Really odd
[15:46:34] <andypugh> Given that all that is new is a config
[15:46:53] <andypugh> Unless: perhaps it tried to run the nes G-code files?
[15:55:18] <bpuk> possibly
[15:55:19] <bpuk> https://postimg.org/image/e2vqd125r/
[15:57:20] <bpuk> still got a lot of cleanup and TODO's to clear, but that's the old type1 code using oN profile... endprofile
[16:01:14] <bpuk> https://postimg.org/image/kqz2fpn0z/
[16:01:16] <bpuk> that ones better
[16:25:20] <bpuk> or. and this one has a whole bunch of unfinished code in
[16:25:21] <bpuk> https://postimg.org/image/iiuzsukx9/
[16:25:28] <bpuk> and that's as much as I'll get done tonight
[16:27:28] <bpuk> I'll do a cleanup pass tomorrow then push it to my git
[16:46:10] <cradek> andypugh: radius, and I'm shocked to not find that in the docs
[16:46:46] <andypugh> did you look? I didn’t
[16:47:07] <andypugh> I guess that most lathe code uses R-format
[16:47:32] <cradek> yeah, I did look for it
[16:50:08] <cradek> > raise LinuxCNC_Exception("interpreter state %d did not reach target state %d" % (self.state.interp_state, target_state))
[16:50:24] <cradek> andypugh: I don't understand that test failure but I'm sure it's not your fault
[16:53:29] <andypugh> I have added some sample G-code that can’t run on a normal setup. But I don’t think that runtests excercises the sample g-codes, does it?
[16:55:31] <cradek> nope, only gcode specificially in tests gets run
[16:55:56] <cradek> specificiaicilyy
[16:56:31] <cradek> I'm going to need to get my lathe working again...
[16:57:00] <cradek> somewhere I have a whole bunch of 1" aluminum bar
[16:58:44] <bpuk> for comment -
https://github.com/bpuk/linuxcnc/commit/3f3f374cd8aed4320673c61802ba4c82b1b0afd7
[16:58:54] <bpuk> and cradek: I'm getting the same feeling
[17:00:46] <cradek> bpuk: I was picturing that you'd use a subroutine defined with the existing sub/endsub as the profile. can you help me understand why new O words profile/endprofile is better?
[17:01:35] <cradek> (argh, 16:30 and it's already getting dark.)
[17:02:15] <bpuk> less potential breakage - for a G71 profile anything other than G0/G1/G2/G3 is invalid. merging that into the existing sub code without breaking _anything_ is likely to be tricky
[17:02:46] <cradek> oh I see - yes there's a lot of new restrictions
[17:03:12] <bpuk> especially when python remaps are considered to be o subs internally
[17:03:49] <cradek> I was hoping for the feature where the sub could be called once more after turning on cutter comp or something like that. but if we want that, I bet we could make O-profile callable with O-call with a very simple change
[17:03:50] <bpuk> it's probably doable, but it's a particularly complex bit of code :D
[17:04:25] <bpuk> and G70 should be callable with cutter comp - I'm pretty sure (now) that I can do G71 with cutter comp on
[17:04:36] <cradek> oh!
[17:04:42] <cradek> that would be really great
[17:05:19] <bpuk> I only see that being useful using button cutters though - cutter comp shouldn't effect much for roughing
[17:05:45] <cradek> I don't know what a button cutter is
[17:06:08] <bpuk> RCMT insert?
[17:06:32] <cradek> oh, round
[17:06:52] <bpuk> yeah - only time I can see cutter comp making a big difference for roughing
[17:07:00] <cradek> but if you have any nose radius at all, arcs end up the wrong radius and in the wrong place, and so do tapers
[17:07:17] <cradek> ... without compensation on
[17:07:29] <bpuk> yes - but if you've got 1.1mm instead of 1mm left on the part from roughing, I can't imagine it making an impact
[17:07:41] <bpuk> as long as your finishing works correctly
[17:08:00] <cradek> yes if it always leaves extra material - I haven't thought that through enough to convince myself
[17:08:08] <cradek> my hunch is that it does
[17:08:27] <bpuk> but either way - I'll get cutter comp working before we merge to master - lot of more significant bugs to fix
[17:08:31] <cradek> so for the finishing you expect to be able to use cutter comp?
[17:08:46] <bpuk> yup, pointless having a finishing cycle without it
[17:08:47] <cradek> sweet, I'll quit grousing about it
[17:09:05] <cradek> you know what you're doing :-)
[17:09:23] <bpuk> heh, it's fine - if people don't let me know what's important how the heck do I know what is :P
[17:10:03] <cradek> if the cycle uses comp at the right time, I can't think of a reason to need to O-call the profile manually
[17:10:08] <cradek> so that fixes both my concerns
[17:10:53] <bpuk> I haven't tested putting a profile in a different file yet, but _in theory_ it should work
[17:13:50] <bpuk> nope, it doesn't. I know where to fix that though
[17:23:26] <kwallace2> If anyone has gotten FreeCAD .obj files to work with Vismach, please let me know. I tried a meshlab .obj file lifted from the Net and it works in my setup.
[17:28:39] <andypugh> kwallace2: Have you looked at the files in a text editor? Maybe it’s a binary / ascii variant thing.
[17:33:46] <kwallace2> andypugh, The only big difference is that the FreeCAD file uses a face format something like "f 1 2 3" and the meshlab "f 1//2 3//4 5//6". I'm looking at how I can make decent files by hand, to try to understand the format better.
[17:34:26] -!-
logger[psha] was kicked from #linuxcnc-devel by ChanServ!ChanServ@services. [User is banned from this channel]
[17:36:36] <andypugh> I wonder if Pavel even reads the logs any more? I haven’t seen much sign of him for a while.
[17:38:09] <cradek> I don't know... that ban will expire in 1 day - hope he notices and finds the problem by then
[17:44:12] <andypugh> Here is the lathe pawn in G71 mode. Note how it goes wrong at 1:48
https://www.youtube.com/watch?v=O6rUjl6jNts
[17:45:05] <andypugh> Seems I need a cleverer algorithm for knowing when to start a new pocket.
[17:45:56] <cradek> it's sooooo close
[17:46:09] <bpuk> Looks to go wrong at 1:36. But yeah, the gouge at 1:48 isn't good. Close :D
[17:47:36] <bpuk> I'd expect the pockets to cut in the opposite order (from Z+ rather than from X+)
[17:50:01] <andypugh> Yes, they should have been. Except the code only identified two “pockets”
[17:50:36] <andypugh> So it thinks that all the second pass of cuts are the same pocket.
[17:51:00] <andypugh> This is because the pockets don’t overlap in X
[17:52:19] <bpuk> darn
[17:53:37] <andypugh> The answer might be to group the cuts in a second operation, rather than try to assign them to pockets when they are discovered.
[17:54:55] <andypugh> Though, with a cleverer retract strategy it would be entirely usable.
[17:58:58] <andypugh> Right, time to stop I think. I will let my subconcous work on the problem for a while.
[17:59:05] <andypugh> Goodnight all.
[17:59:14] <bpuk> night
[17:59:47] <bpuk> I'm also going to vanish. Night all
[18:04:01] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap 64bfcde 06linuxcnc 10configs/sim/axis/g71/python/remap.py 03nc_files/lathe_pawn_G71.ngc Bug-fixes and Pawn sample file as a G71 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=64bfcde
[18:15:19] <skunkworks> wow
[18:15:21] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-23.png
[18:17:49] <skunkworks> close.. does things in the wrong order
[18:17:57] <skunkworks> and cuts through the part
[18:56:02] <cradek> skunkworks: he had the same problem with the pawn
[18:56:07] <cradek> sure is close, isn't it
[19:04:31] <kwallace> Yay, The FreeCAD .stl file works, but one needs to export as "STL Mesh" with a file extension of .ast (ascii stl) .
http://wallacecompany.com/tmp/Screenshot_FreeCAD_ast_file.png . The color didn't come through though. Darn.
[19:04:49] <cradek> neato
[19:14:34] <jepler> wikipedia gives decent documentation of .obj 3d format:
https://en.wikipedia.org/wiki/Wavefront_.obj_file
[19:15:26] <jepler> sounds like your file was an example of Vertex Normal Indices Without Texture Coordinate Indices
[19:16:10] <jepler> (specifying surface normals can give "smooth looking" shapes with fewer triangles)
[19:16:28] <jepler> I'm not against improving vismach to import a larger subset of all valid .obj files
[19:16:45] <skunkworks> Yes - he is very close
[19:27:31] <kwallace2> jepler, thanks for the link. I need to study the Vismach source, well everything I guess. I am hoping FreeCAD can make complex objects with hi fi rendering easy.
