#linuxcnc-devel Logs

May 02 2018

12:53 AM IchGucksLive: morning from germany
12:55 AM IchGucksLive: I Discoverd a Small problem in Stepconf this morning
12:55 AM IchGucksLive: THe Homing does run the wrong direction on inverting the AXIS Joint dir in 2.8 MASTER frech pull
12:55 AM IchGucksLive: Synaptics from buildbot i need to say
12:55 AM IchGucksLive: wheezy
12:55 AM IchGucksLive: pre1 3709 gd459474
12:56 AM IchGucksLive: with a manuell SCALE Change to negative and a non negativ axis it works
12:56 AM IchGucksLive: so double inversion on joint
12:56 AM IchGucksLive: gets the homing the wright direction
12:56 AM IchGucksLive: Example X Axis
12:57 AM IchGucksLive: Real World Running wrong direction Then invert SCALE = -100 While PIN Xdir is not inverted
12:58 AM IchGucksLive: then positiv Home search
12:59 AM IchGucksLive: THE Homeswitch is on the positiv END of the Joint
12:59 AM IchGucksLive: somone needs to adress that
01:00 AM IchGucksLive: I onow what im doing "I do Hope so " but many will be confused on it
01:00 AM IchGucksLive: ok THEY will invert the SEARCH and it will also work
01:01 AM IchGucksLive: So then the HomeSearchVel will be negative while mashine homes in pos value
05:59 AM rene-dev: Linuxcnc meeting in germany: https://doodle.com/poll/rrzknkwiaukwgrar
08:53 AM sliptonic: I've got a quick question about G43 TLO. Does G43 act like a modal or does it have to be called after EVERY tool change?
08:55 AM rene-dev: call on every toolchange
08:56 AM sliptonic: rene-dev: thanks
09:08 AM cradek: because I'm not sure what you mean by modal, just to be clear, doing a tool change does NOT change or affect tool offsets in any way
09:09 AM cradek: if you want the tool offset to change to the one from the tool table entry of the new tool, you have to execute a new G43 command
09:09 AM cradek: if you do not do this, you will still have the tool offset from the last G43 you issued
09:10 AM sliptonic: Gotcha. I guess I had it in my mind that If I did M6 T1 G43 the offset for T1 was applied. Then if I did an M6 T2, the offset for t2 would be applied because G43 was active.
09:11 AM sliptonic: That means we need to make the linuxcnc post processor for FreeCAD a bit smarter to check if the user wants to use compensation for the new tool.
09:13 AM rene-dev: the user always wants that. if not, you just dont put numbers in the tooltable.
09:15 AM sliptonic: That's certainly an option and makes it easier for us :-) Is there really never a case where a user would have numbers in the TT but choose not to use compensation?
09:16 AM rene-dev: I dont think there is when you are using a cam. the post should imho always use g43
09:17 AM rene-dev: are you working on the freecad post?
09:18 AM sliptonic: Yes. I guess I'm the 'captain' of the FreeCAD path workbench
09:18 AM rene-dev: ah, I never really used freecad. is the cam usable now?
09:19 AM sliptonic: Yes, quite usable for 2.5D stuff. True 3D stuff is still pretty limited.
09:19 AM rene-dev: I know there was a release a few weeks ago
09:19 AM MarkusBec: it crashes if you select a ball mil :)
09:19 AM sliptonic: 0.17 was just released. A major overhaul of Path from 0.16
09:20 AM sliptonic: MarkusBec: How so? What operation?
09:20 AM rene-dev: what toolpath does it support?
09:20 AM MarkusBec: sliptonic: i dont know exactly
09:21 AM MarkusBec: lasst weekend a friend and I testet 3d milling for the first time
09:21 AM MarkusBec: every time he selected a ball mill kicad crashed
09:21 AM MarkusBec: i uses inventor HSM
09:21 AM sliptonic: Basically clipperlib (libarea) for the 2.5D stuff. There's a *very* basic waterline/dropcutter operation using OpenCamLib but OCL has to be installed manually.
09:21 AM MarkusBec: used
09:21 AM sliptonic: kicad?
09:22 AM MarkusBec: freecad :)
09:22 AM MarkusBec: sorry
09:22 AM sliptonic: 3D milling is using the OCL. That's the one that isn't done. In fact, you have to jump through hoops to even turn it on in FreeCAD.
09:23 AM MarkusBec: ahok
09:23 AM sliptonic: 3D pocket is a 2.5D pocket of a 3D shape and works well but doesn't take tool shape into account.
12:03 PM mozmck: Speaking of toolchange, is there yet any good solution for manual toolchange where you need to manually touch off the new tool before continuing?
12:05 PM seb_kuzminsky: :q
12:05 PM seb_kuzminsky: oops
12:06 PM seb_kuzminsky: mozmck: i do that by putting each tool in a different g-code file, and doing the manual toolchange and touch-off in mdi before running the program for that tool
12:06 PM seb_kuzminsky: i think without a tool length switch you can't use remap for what you want
12:06 PM mozmck: Yeah, I've seen that method mentioned, but that is apparently a no-go for a lot of people.
12:11 PM seb_kuzminsky: yeah, it feels like a workaround for not having a tool length sensor
12:13 PM mozmck: I can think of ways to make it work with a sensor, but we need something for folks without a sensor. I think they are used to moving the bit over the workpiece or something and zeroing it there, then continuing.
12:17 PM seb_kuzminsky: stop the program with Esc, swap tools manually, jog over to the workpiece, zero Z there manually, Run-from-line to continue? that's the only manual option i can think of
12:20 PM mozmck: Yeah, that might be an option. Run-from-line is badly broken in some cases, but I might can make that work.
01:58 PM JT-Shop: it's much better to just split your program up by tool
02:06 PM mozmck: In what way is it better? I can think of several ways that it is not better for many shops. The operator then has to know and select the correct file for each tool, multiple times per part. Everything of that sort introduces more points of failure. If it is all in one file, then at least you don't have to worry about the operator loading the right file for the next tool.
02:07 PM cradek: I can't imagine a shop and a machine run by an operator but without repeatable tool lengths
02:07 PM cradek: no matter what you do it is SO error prone
02:08 PM cradek: to futz with lengths for every tool
02:21 PM mozmck: Well, these are not generally machine shops. We have customers building routers for ice carving, and the operators are not machinists. Same for quite a few other small shops with router tables. The routers use collets, and the bits don't have a depth stop normally.
02:22 PM JT-Shop: I doubt most shops have to touch off between tools they have VMC's not smithy's
02:24 PM mozmck: True, but small shops with router tables are pretty common, and so is touching off between tools on those machines.
02:24 PM cradek: these are so nice for pcb tools. I wonder if you can get them in 1/4 and 1/2 or whatever wood router bits are: https://www.precisebits.com/reference/depth_setting_rings.htm
02:25 PM mozmck: I don't know - I haven't seen them for larger sizes. A lot of times there is not enough extra shank on a bit for those either.
02:28 PM cradek: then maybe a gage with a step in it that lets you tighten the tool at a particular stickout?
02:31 PM JT-Shop: install one of those tool setting things that use the probe input and move to tool change position operator changes tools maybe even the right one and then press resume and it probes the tool length updating the tool table
02:31 PM mozmck: I thought about that, but at least one customer said that their bits can vary a lot in length.
02:32 PM JT-Shop: I think the tool moves as you tighten it up a bit
02:32 PM * JT-Shop goes back to work
02:32 PM mozmck: JT-Shop: the tool setting probe was my suggestion, but it seems that might not be feasible on some retrofits or something. I'll certainly keep that in mind and mention it some more.
02:35 PM JT-Shop: yea without a probe having multiple tools in one G code file is problematic
02:35 PM JT-Shop: with router type of equipment
03:14 PM KimK: <sliptonic wrote:> "3D milling is using the OCL. That's the one that isn't done. In fact, you have to jump through hoops to even turn it on in FreeCAD."
03:14 PM * KimK asks: OCL?
03:14 PM seb_kuzminsky: OpenCamLib
03:14 PM sliptonic: KimK: OpenCamLib
03:14 PM seb_kuzminsky: by Anders Wallin
03:14 PM sliptonic: jinx
03:15 PM seb_kuzminsky: :-)
03:15 PM KimK: Ah OK. Thanks, guys.
03:15 PM seb_kuzminsky: sliptonic: have you experienced any problems from clipper's use of linear interpolation instead of native support for arcs?
03:19 PM sliptonic: Not really. We're fitting arcs back but I'm not sure exactly where that's done.
03:20 PM seb_kuzminsky: oh, interesting
03:24 PM sliptonic: A developer named realthunder did a new implementation of the libarea wrapper. It does some pretty impressive stuff. I think the arc fitting is done there.
03:40 PM jepler: I'm going to take flo18 offline tonight, it seems to have served its purpose.
04:43 PM andypugh: I just noticed https://github.com/LinuxCNC/linuxcnc/issues/394
04:45 PM andypugh: I am not sure who that belongs to. It looks like micges has been most active in there since Seb (I think) wrote the original.
04:46 PM andypugh: I do have a tendency to pick up Hostmot2 stuff, but so far I have not actually touched the encoders. (in fact I have hardly ever used one, I am a Resolver fan :-)
08:34 PM jepler: patches welcome y'all
08:34 PM jepler: jfc can't you depend on an API being stable for 30 years
08:37 PM jepler: contrary to what has been stated in that bug, glibc 2.27 as packaged in debian sid and ubuntu bionic both have the related headers. I didn't check link-time libraries. perhaps debian is protecting us from upstream boneheadedness
08:38 PM jepler: .. checked 2.27-3 (sid) and 2.27-3ubuntu1 (bionic)