#linuxcnc Logs
Aug 01 2022
#linuxcnc Calendar
01:23 AM CaptHindsight[m]: https://www.ebay.com/itm/354191440810 could be a nice deal for someone
01:48 AM * CaptHindsight[m] uploaded an image: (64KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/XswfrGtCRkDkRbtwSeQlOpyC/glassf-01Aug2022-1122.png >
04:38 AM -!- #linuxcnc mode set to +v by ChanServ
05:00 AM JT-Cave: morning
09:45 AM roguish[m]: good morning....
09:45 AM roguish[m]: cool and overcast here on the left coast
09:45 AM roguish[m]: at least in the Bay Area....
09:46 AM perry_j1987: quiet in here this morning
09:50 AM roycroft: we'll be back to average temperatures starting today
09:50 AM roycroft: which is around 30 this time of year
10:15 AM perry_j1987: first thing on the list today..
10:15 AM perry_j1987: head out to shop and figure out why the pulse index sensor isnt working
10:16 AM perry_j1987: i transfered everything to a new cnc control box yesterday and now its not lighting up when the headstock rotates
10:33 AM ReaktoringJustus: Hello, i probably am kinda blind again but I've got a small problem, and that is that at higher Feedrates if I move my z axis I get a following error for joint 2. I'll attach my configs, gimme a sec. I am aware that the max accel of stepgen should be ~10% higher than the max accel of the machine, and It can't really be a hardware issue because I am running open loop steppers. Maybe my machine can just not handle fast enough steps on
10:33 AM ReaktoringJustus: my parport?
10:37 AM * ReaktoringJustus posted a file: (6KiB) < https://libera.ems.host/_matrix/media/r0/download/jauriarts.org/bimsxKSDkCytpoSbKpQiOUWK/configs.zip >
10:42 AM rmu: ReaktoringJustus: your Z-axis has max vel 25, joint 2 has max vel 23.75
10:42 AM rmu: that should probably be the other way round
10:43 AM roguish[m]: Reaktoring / Justus Flügel: also, for Z axis, gravity works........... so it may need more power than the horizontal axes.
10:43 AM rmu: shouldnt matter for open loop stepper system, it will produce following error even if motors are powered off
10:43 AM rmu: (or not produce)
10:44 AM CaptHindsight[m]: perry_j1987: check all of the connections, most issues like these are just wiring problrms
10:45 AM rmu: following error with open loop stepper system can't be wiring problem
10:46 AM roguish[m]: CaptHindsight: nice SSD you found. back in the old daze. i recall paying $1200 for a simple 2g hard drive......
10:46 AM rmu: max vel of axis > max vel of joint can't work
10:47 AM CaptHindsight[m]: rmu: my comment was not for your issue, it was for perry_j1987
10:47 AM perry_j1987: lost internet what did i miss
10:48 AM rmu: sorry
10:48 AM roguish[m]: Bill Russel died.
10:48 AM CaptHindsight[m]: perry_j1987: check all of the connections, most issues like these are just wiring problems, if you copied your configs properly
10:48 AM perry_j1987: ya so i have an inductive probe im using with magnet taped to spindle for pulse
10:49 AM perry_j1987: it has same color wires as the two hall effect switches im using for endstops now
10:49 AM roguish[m]: Lt. Uhura also died. that is the actress, Nichelle Nichols
10:49 AM perry_j1987: so i wired the brown of all of them to positive and blue to negative and then all the blacks got their own pin on the aircraft connector
10:49 AM perry_j1987: the stickers on the endstops and the index pulse probe all show the same wiring so i dunno
10:50 AM perry_j1987: i have a spare hall effect endstop i could swap it out for today though same diameter will thread right in
10:50 AM ReaktoringJustus: Thanks, I missed that. Still the same problem tho
10:52 AM ReaktoringJustus: I can go up to ~330mm/min which is ~528000steps/min
10:53 AM ReaktoringJustus: After that I get the joint following error
10:53 AM ReaktoringJustus: And somehow double step doesn't work for me, so I disabled that.
10:53 AM rmu: your thread rate is 16kHz, so you are limited to 8kHZ, 528000 per min is 8800 per sec
10:57 AM perry_j1987: ok heading to shop now
10:59 AM ReaktoringJustus: Hmm sorry if those questions are kinda dumb but it's my first time doing something with CNC & linuxcnc so ... Can someone link me to some docs or tell me where I find those values?
11:04 AM rmu: ReaktoringJustus: you configured 62500ns as your thread period in stepconf
11:05 AM rmu: ReaktoringJustus: this value is in mpcnc.ini
11:06 AM rmu: [EMCMOT] BASE_PERIOD
11:08 AM ReaktoringJustus: Ah, thx
11:11 AM ReaktoringJustus: Should that be a value that is bigger than the max jitter in latency test? As I've never gotten something above 11000, 15000 should be just fine, right?
11:14 AM rmu: should be fine
11:16 AM rmu: is this with rt preempt kernel? what motherboard / cpu are you using?
11:26 AM ReaktoringJustus: Yes preempt, Debian 10 from linuxcnc.org, I am running on an optiplex 7010 from dell and I have turned on only a single core in the bios as that reduced jitter for me.
11:28 AM ReaktoringJustus: As a vcp I am currently using probe_basic
11:29 AM ReaktoringJustus: But it works now after I've reduced my Microstepping from 1/16 to 1/4
11:29 AM ReaktoringJustus: Thanks for your help
12:55 PM perry_j1987: there we go all back and running
12:55 PM perry_j1987: put new index sensor in and its working
12:55 PM perry_j1987: anoyingly had to swich the magnets direction though
01:35 PM CaptHindsight[m]: 🎉
02:14 PM gywilo[m]: so I'm looking at this example, FDM delta 3d printer, for examples in .hal and .ini files to see how the extruder is handled.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/356344f651bc4646b8aaac2cfee9f1bcf858dcee)
02:32 PM CaptHindsight[m]: gywilo: A axis gets its own limits set for velocity/accell
02:33 PM CaptHindsight[m]: the TJ only handles 3-axis
02:33 PM perry_j1987: ok so im real curious now that i got everything sorted on this lathe nicely now... how do i run this gang tooling so i just touch off T1 and the other tools are offsets from that tool
02:33 PM CaptHindsight[m]: trajectory planner
02:34 PM CaptHindsight[m]: gywilo: https://forum.linuxcnc.org/38-general-linuxcnc-questions/43036-trajectory-planner-for-3d-printing-a-axis-blending-issues
02:35 PM gywilo[m]: okay great, sounds like it should be straight forward to setup. If I were to take genhexkins.c and configure mesaCT for 7 axis, would the A axis function properly?
02:50 PM gywilo[m]: Are you confident this statement is correct?
02:51 PM gywilo[m]: I see a comment from AlessandroT from the link you provided:
02:51 PM gywilo[m]: "The behaviour of our machine changes a lot if we use a gcode where there is the fourth axis "A". Without the fourth coordinate, all the movements are smoother.
02:51 PM gywilo[m]: Nothing changes if we use "U" instead of "A". "
02:54 PM perry_j1987: man its tough to get these er16 collets out of the slimline nuts
02:54 PM unterhaus_: the good trajectory planner only works for 3 axes
02:54 PM unterhaus_: there was some talk of the author porting the multi-axis version over from machinekit
02:56 PM CaptHindsight[m]: that sounds like a project for someone willing and able
03:11 PM perry_j1987: CaptHindsight[m] you know what i mean?
03:11 PM perry_j1987: about the touch off on t1 thing
03:12 PM perry_j1987: right now i have to touch off each tool in the gang tool block and its so teadeously anoying lol
03:12 PM unterhaus_: I was going to look into the tp think but Andy thought it was being handled. Apparently not
03:15 PM gywilo[m]: in the case of multi axis trajectory planner, how would it control the machine differently?
03:16 PM JT-Shop: gywilo[m], I'm working on adding a second card to mesact
03:16 PM CaptHindsight[m]: Nothing changes if we use "U" instead of "A". "
03:16 PM gywilo[m]: wonderful, thank you JT
03:16 PM CaptHindsight[m]: try U and see if it's more better
03:16 PM gywilo[m]: I need U for driving a joint/motion axis
03:19 PM gywilo[m]: X,Y,Z,U,V,W for hexapod type motion; A for extruder
03:19 PM gywilo[m]: was my thinking
03:19 PM CaptHindsight[m]: is there a hexapod example anywhere on the forums?
03:21 PM gywilo[m]: this guy has built hexapods with linuxCNC
03:21 PM gywilo[m]: https://www.youtube.com/watch?v=G_UmhUjZhNo
03:21 PM gywilo[m]: Andrii Kyrychenko
03:23 PM * gywilo[m] uploaded an image: (144KiB) < https://libera.ems.host/_matrix/media/r0/download/jauriarts.org/DGKxidLMQeLfyICSmxpDDPMN/unknown.png >
03:23 PM gywilo[m]: and it looks like he's helped develop the kinematics file too
03:23 PM gywilo[m]: but his example is for a mill
03:32 PM -!- #linuxcnc mode set to +v by ChanServ
03:32 PM ZincBoy[CAON][m]: gywilo the stock trajectory planner still does not use blending when anything other than XYZ moves are preformed. There are some experimental versions that allow blending including UVW but AFAIK, these are not in any of the 2.8 or master builds.
03:34 PM ZincBoy[CAON][m]: Also for a hexapod you can have 6 joints for the actuators but only 3 axis (XYZ). This obviously is only true if you don't need/use the rotary axis allowed by a stewart platform.
03:40 PM gywilo[m]: what are the repercussions driving a 6 axis machine with trajectory planning only for X,Y,Z? practically, does it mean my paths in x,y,z space will be rounded/smoother/faster but that rotations will not, will go to exact angle without 'rounding the corner' or is there more impacted than that?
03:42 PM ZincBoy[CAON][m]: It means that as soon as you use anything other than XYZ the TP will fall back to 1 block lookahead and will not do any advanced smoothing or blending. Motion will be not smooth and code with lots of short segments will run much slower.
03:43 PM JT-Cave: Tom_L, debian 10.12 would not install so trying 10.11...
03:44 PM gywilo[m]: That's a real bummer. It sounds like we need a TP that supports all axii
03:46 PM gywilo[m]: I understand this forum post a bit more now too.... thanks. they are moving extruder to one of X,Y,Z so that it IS included in TP
03:47 PM ZincBoy[CAON][m]: Exactly
03:47 PM gywilo[m]: what's the problem with including UVWABC in TP? is there any technical hurdle or just hours in the day type thing?
03:50 PM ZincBoy[CAON][m]: A multi axis TP is mathematically interesting. In that mathematicians are still writing papers on ways to solve for the optimal path without violating the constraints. There are versions out there that could be used but it is certainly technically difficult.
03:51 PM ZincBoy[CAON][m]: A 3rd or higher order planner would benefit more people as adding jerk limits would improve things quite a bit. This is an easier problem.
03:52 PM ZincBoy[CAON][m]: I don't see either being implemented anytime soon baring someone being hired to do so.
03:53 PM gywilo[m]: where do I find the trajectory planner code?
03:55 PM gywilo[m]: what constraints? we are NOT talking robot arm/serial manipulator path planning right?
03:55 PM ZincBoy[CAON][m]: https://github.com/LinuxCNC/linuxcnc/tree/master/src/emc/tp
03:55 PM ZincBoy[CAON][m]: No, that is joint planning which is part of it but is taken care of by the kinematics.
03:57 PM gywilo[m]: okay, good, agreed
03:57 PM ZincBoy[CAON][m]: The constraints are the position, velocity, acceleration, and jerk. Getting these as close as possible is the challenge.
03:58 PM gywilo[m]: shoot
03:59 PM gywilo[m]: so what I'm understanding is that linuxCNC is really not good at controlling anything more than a 3 axis machine
03:59 PM ZincBoy[CAON][m]: Bingo.
03:59 PM ZincBoy[CAON][m]: It will do it, but only at a basic level.
04:00 PM ZincBoy[CAON][m]: That might be fine for many applications and with clever tricks (like swapping Z and A) you can get some more advanced systems going.
04:03 PM gywilo[m]: hmmm, so why can't the same math that is applied to X,Y,Z be applied to U,V,W? one is translation and one is rotation....
04:03 PM gywilo[m]: hmm
04:03 PM gywilo[m]: do you have links to papers that you referred to earlier?
04:03 PM gywilo[m]: "mathematicians are still writing papers on ways to solve for the optimal path without violating the constraints"
04:04 PM ZincBoy[CAON][m]: UVW are not rotation typically. They are for an addition set of linear axis. Like in a wire EDM
04:05 PM ZincBoy[CAON][m]: Not handy. I looked into this a while ago and came across a bunch. Some quite recent.
04:05 PM gywilo[m]: okay, A,B,C then
04:06 PM gywilo[m]: okay, I'll take a look, any suggested search terms?
04:08 PM ZincBoy[CAON][m]: "jerk limited trajectory generation"
04:11 PM gywilo[m]: thanks
04:11 PM gywilo[m]: are you aware of anyone working on a new version of TP?
04:12 PM ZincBoy[CAON][m]: There is a thread on the forum where someone was working on it.
04:34 PM gywilo[m]: man, this sets me back a couple pegs. I appreciate you bringing it to my attention. how significant do you think the performance gap will be? I've already bought most of the hardware so will probably continue giving the proof of concept a shot, but also might take a look at RRF. supposedly it will support the additional axii
04:37 PM roycroft: that was just a weird spam call
04:37 PM roycroft: the phone rang, i picked up and said "hello"
04:37 PM roycroft: and heard "invalid voice response. please do not speak until prompted"
04:37 PM XXCoder: lol
04:37 PM perry_j1987_: hmm where did the option in fusion 360 go to offset the model in the stock
04:38 PM Tom_L: JT-Cave, how do you tell the exact version?
04:38 PM perry_j1987_: in the setup i use to be able to add stock to the front of the part on lathe ops
04:38 PM XXCoder: roycroft: I guess you hang up then?
04:38 PM roycroft: yes
04:39 PM XXCoder: id do same too. lol
04:42 PM JT-Shop: Tom_L, https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/
04:43 PM Tom_L: i've got 10 installed with linuxcnc
04:43 PM Tom_L: 11 gives me errors compiling linuxcnc
04:43 PM Tom_L: even with the sid patch
04:43 PM Tom_L: tried building with no docs and still get an error
04:44 PM Tom_L: just get more errors with them
04:44 PM JT-Shop: cat /etc/debian_version
04:45 PM JT-Shop: I'll be up to 11 in a couple of days, I doubt I'll build master though
04:45 PM Tom_L: so if 10 & 11 are supposed to be buster & bullseye why do they have separate directories for them?
04:45 PM Tom_L: i've got sid installed as well but no linuxcnc
04:45 PM JT-Shop: who is they?
04:45 PM Tom_L: did build mesaflash & yours on both
04:45 PM Tom_L: the link you just posted
04:46 PM Tom_L: cdimage.xxxxxx
04:46 PM JT-Shop: there is a directory for every version and minor version
04:46 PM JT-Shop: no clue what the directories at the bottom of the page are
04:47 PM JT-Shop: interesting that 11.3 is the latest directory but 11.4 is the current one
04:47 PM Tom_L: heh
04:48 PM Tom_L: 102F last i looked
04:48 PM JT-Shop: lol I think the directories at the bottom are left overs
04:48 PM JT-Shop: 89°F
04:49 PM * Tom_L wonders if the 2 checks he got in the mail will cover the 2 bills he also got
04:49 PM JT-Shop: heat advisory until wed
04:49 PM JT-Shop: watermelon time for the hens
04:50 PM Tom_L: this is debian 10.12
04:51 PM Tom_L: no issues here
04:53 PM roycroft: i don't like heat advisories
04:58 PM XXCoder: looks like 82f peak today
05:01 PM roycroft: a shipment of gummy bears just arrived
05:02 PM roycroft: that's good, because i need the packing material that is in that shipment soon
05:05 PM XXCoder: thats good
05:06 PM JT-Shop: I may have had a bad d/l dunno I just switched to 10.11 and it installed just fine
05:10 PM roycroft: i have to go stretch some clamps now to about 8-1/2 feet long so i can glue up the trim pieces on my counter top
05:15 PM XXCoder: jt I just wish linuxcnc downloads has sha256 hashes listed
05:16 PM XXCoder: while corruption is quite rare, I'd love to always have it when it is OS install image file
05:27 PM refo[m]: tinyG/g2core has it to a certain degree. Its enabled for all 9 axis, but I've looked their source code, it seems like they treat angular distances as equivalent to linear distances
05:27 PM refo[m]: it can cause some funky effects
05:30 PM gywilo[m]: "it seems like they treat angular distances as equivalent to linear distances"
05:30 PM gywilo[m]: how difficult would it be to take the same approach for linuxCNC?
05:30 PM ZincBoy[CAON][m]: Yes a true 6 axis planner with TCP is what would be perfect to have. Unfortunately it non-trivial.
05:31 PM Tom_L: JT-Shop, you get a fix for your utility yet?
05:32 PM JT-Shop: I did a temp fix this morning
05:32 PM Tom_L: i'll wait a bit then
05:32 PM ZincBoy[CAON][m]: The biggest issue is wrapping your head around the TP code and how it interacts with everything else. My programming skills aren't up to it. I can read it and see what it is doing but that is about it.
05:33 PM Tom_L: i doubt many are knocking doors down with rpi4s
05:34 PM refo[m]: the kinematics space makes it tough. the architecture of linuxcnc calls for constraints solving in the kinematics space rather than in joint space
05:34 PM refo[m]: and that makes it a lot harder than 100% orthogonal space that g2core works in
05:37 PM ZincBoy[CAON][m]: Exactly, that is why the TP intended for robots is a good option. But also very complex.
05:38 PM refo[m]: i don't think the math exists to solve the general case
05:38 PM ZincBoy[CAON][m]: No, I don't think it does. That is why I motioned that it was mathematically interesting 🙂
05:38 PM refo[m]: if it were up to me i would start by trying to classify spaces and solve for subset of spaces
05:40 PM gywilo[m]: what does this mean? kinematics space rather than joint space?
05:41 PM refo[m]: no, i mean particular classes of kinematics spaces
05:42 PM refo[m]: because in reality 95% of actual machines have actuators that directly correspond spatial dimensions
05:42 PM refo[m]: you can't do a robot arm
05:42 PM refo[m]: but you would be able to do a 5axis cnc
05:44 PM ZincBoy[CAON][m]: Yes, I was thinking that having a milling machine focused TP would be the way to go. Which has already kind of happened with the XYZ only look-ahead planner that I think came from Tormach.
05:45 PM refo[m]: but the code rework to introduce the concept of classes of spaces so that they would be available to the planner is large
05:45 PM refo[m]: it was hard enough to refactor this huge project to separate joints from axis
05:45 PM refo[m]: this is likely harder
05:46 PM refo[m]: s/axis/axes/
05:49 PM gywilo[m]: I don't see how kinematics of machine come into play for trajectory planning XYZIJK, except for tuning.
05:49 PM gywilo[m]: My understanding: trajectory planning for XYZ involves looking at the next couple set of moves and reacting ahead of time, to appropriately round the corners. Like we look ahead when driving. It would be the same for IJK, look ahead at the next couple unit vectors and de-rate appropriately. XYZ lookahead and IJK lookahead can both slow the system down.
05:49 PM refo[m]: the kinematics matter a lot, because once you bring in angular velocities, they correspond to different errors at different radii
05:50 PM roguish[m]: gywilo: just FYI. the current TP was done by a guy who works with Tormach.
05:51 PM refo[m]: your planner is a constraints solver. its trying to find an optimal solutions under constraints of maximum error while trying to optimize speed, acceleration, jerk and other variables
05:51 PM refo[m]: the error has to be defined somehow
05:54 PM refo[m]: somewhat unrelated: is there a good reason why the planner has to be real time at all?
05:55 PM refo[m]: why can't it be "infinite-lookahead"?
05:56 PM gywilo[m]: could the lookahead instead be done in CAM/slicer software with lookahead limited to 1?
05:57 PM gywilo[m]: s/with lookahead limited to 1//
05:58 PM gywilo[m]: if the path is a rectangle, instead of 4 orthogonal points, a series of points that round the corners and ramp the velocity
05:59 PM gywilo[m]: then linuxCNC set with TP to only look to the next block
06:22 PM * hazzy[m] uploaded an image: (4607KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/BfYLLYwyJbksdsBlIlAgBZGW/ima_dcf8f18.jpeg >
06:23 PM hazzy[m]: JT-Shop: kittens first day out. Very curious about the chickens
06:24 PM * roycroft found his clamp stretchers, and is about ready to go
06:32 PM roguish[m]: hazzy: that look way to good......
06:33 PM roguish[m]: get a tractor yet?
06:38 PM hazzy[m]: roguish: haha, yes. I have a little ford and a kubota
06:38 PM roguish[m]: ah, the kubotga is supposed to be the best
06:38 PM roguish[m]: kubota
06:39 PM roguish[m]: a good buddy has one for his little vineyard and strawberry field
06:39 PM roguish[m]: glad you're having fun
06:40 PM * hazzy[m] uploaded an image: (7991KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/xTIBKtTNTqPhHpieypQYOAxq/ima_d24366a.jpeg >
06:40 PM hazzy[m]: They are tiny, but perfect for the size I my yard. The kubota is from the 70s and been used heavily, but keeps on going!
06:41 PM hazzy[m]: roguish: how’s everything out there man?
06:53 PM t4nk_freenode is now known as t4nk_fn
07:17 PM ZincBoy[CAON][m]: The main reason is that there are real time inputs like feedrate override, adaptive feed, and feed hold that would require a complete re-plan every time they changed. Perhaps it would be do-able on a small program and fast CPU but a 10MB program would pose a challenge. A look ahead buffer is pretty much mandatory unless you want to give up real time overrides.
07:59 PM unterhaus_: you can't do that
08:00 PM unterhaus_: sorry, wrong terminal
08:00 PM XXCoder: was wondering lol
08:16 PM gywilo[m]: Klipper uses look ahead planning based on angles between multiple moves. Couldn't the same thing be done for IJK where the look ahead derate is simply based on difference of IJK unit vectors (vs XYZ direction vector)
08:16 PM gywilo[m]: https://github.com/Klipper3d/klipper/blob/master/docs/Kinematics.md
08:20 PM gywilo[m]: s/Couldn't/Could/
08:24 PM gywilo[m]: angular velocities.... are we talking cutting forces from machining?
08:26 PM gywilo[m]: or angular velocities of joints of the machine
08:30 PM gywilo[m]: how are the machine kinematics accounted for in the path planner with 3 axis machines?
08:31 PM gywilo[m]: different radii of what?
08:37 PM djdelorie: build day 4 results: http://www.delorie.com/photos/cnc2/PXL_20220802_004622482.html
08:37 PM djdelorie: new bldc driver boards are "in the mail", need to start figuring out how to interface the mesa board to all those wires
08:39 PM jdh: Do you have a webcam looking at a power meter?
08:40 PM djdelorie: I have a webcam looking at the status leds of my generator's transfer switch
08:40 PM djdelorie: because that was the easiest way to automate answering the "is the generator running?" question
08:41 PM djdelorie: technology lets us solve simple problems in the most complex ways
08:43 PM jdh: yeah. I had one looking at fill gauges when pumping up HP air tanks.
08:47 PM refo[m]: If your workpiece is turning on A/B axes, the error is different depending on how far your tool is from the center of rotation
08:48 PM refo[m]: 3 axis CNC is the “easy” case, your kinematics are trivial, linear axes correspond to spatial dimensions
08:49 PM gywilo[m]: not necessarily, kinematics would not be trivial for delta, coreXY, those are 3 axis machines
08:50 PM gywilo[m]: not necessarily, kinematics would not be trivial for delta, coreXY, those are 3 axis machines
08:51 PM gywilo[m]: I guess those are not typical CNC
08:52 PM gywilo[m]: I guess those are not typical CNC
08:54 PM refo[m]: It has pros and cons. In theory, a smart optimizer can precompute feed override constraints for different parts of the job timeline along with increased/decreased error tolerance. If an operator needs to push the machine beyond these limits the job can be paused, reomptimized and resumed. On the upside, a developer would be able to use all the optimizer libraries in the world
08:55 PM gywilo[m]: couldn't the same be said for a 3 axis machine. when Z is high, cutting forces, torque from the workpiece weight is much higher than when the workpiece Z is low, so the mechanics change for 3 axis translations just like they do for rotations IJK
08:55 PM refo[m]: You are right, but in most cases I imagine the relationship between joint position and Cartesian coordinates are linear
08:56 PM refo[m]: * most cases of 3 axis machines I, * I can imagine the
08:59 PM refo[m]: That’s the problem with trying to build a general case optimizer, it would have to be able to operate with a set of constraints and weights described both in the “part space” (max deviation of tool path) and joint space (max joint torque in various joint configurations)
09:00 PM gywilo[m]: does linuxCNC trajectory planner do this today for XYZ?
09:01 PM refo[m]: No, it operates entirely in “part space”
09:01 PM refo[m]: And it can only do it more or less effectively for an XYZ machine
09:01 PM gywilo[m]: does any tractory planner for any software do what you are describing?
09:02 PM refo[m]: No, but some planners do a better job of working in XYZABCUVW space
09:02 PM refo[m]: Without taking kinematic into consideration
09:02 PM refo[m]: s/kinematic/kinematics/
09:03 PM refo[m]: g2core has s-curve jerk limits in all axes and axes combination
09:04 PM refo[m]: Including rotational axes, which are assumed to be workholding, radius scaling errors are ignored
09:05 PM refo[m]: It’s easier in other planners because their architecture does not include the concept of non-trivial kinematics
09:05 PM refo[m]: LinuxCNC does, which makes the planner development more involved
09:06 PM gywilo[m]: are machines with non-trivial kinematics able to be run with g2core?
09:06 PM refo[m]: Why not?
09:07 PM refo[m]: That CNC that is hanging from a sheet of materials by two cables has non-trivial kinematics
09:07 PM refo[m]: Oh, sorry, misread your comment
09:08 PM refo[m]: G2core can run it, but g-code would have to be heavy preprocessed
09:08 PM refo[m]: Essentially translated to joint space
09:08 PM gywilo[m]: ahhha
09:09 PM gywilo[m]: okay, so with G2core, joint space positions need to be provided in G-code, it can't take cartesian coords and determine joint space from them
09:09 PM refo[m]: You wouldn’t be able to tell it “move the tool down 100mm”, you would tell it “feed both cables 66mm each”
09:09 PM refo[m]: Yep
09:09 PM refo[m]: LinuxCNC can, though
09:09 PM gywilo[m]: right, I think that get's messy too fast
09:10 PM refo[m]: s/materials/material/
09:11 PM refo[m]: Depends on your CAM
09:11 PM refo[m]: and sender
09:11 PM refo[m]: If you can move the complexity ther, the user experience remains mostly the same
09:11 PM refo[m]: s/ther/there/
09:14 PM refo[m]: I don’t think it works well for milling of complex CAD-generated parts, because CAM for geometric models has a lot of assumptions
09:14 PM refo[m]: But it definitely works well for things like pick and place
09:16 PM gywilo[m]: so klipper, GRBL uses look ahead planning based on angles between multiple move directions. Could the same thing be done for IJK where the look ahead derate is simply based on difference of IJK unit vectors (vs XYZ direction vector)
09:16 PM gywilo[m]: I guess I still don't understand why this can't be done for linuxCNC
09:16 PM gywilo[m]: klipper is setup the same way as linuxCNC with kinematics modules and non trivial kin
09:17 PM refo[m]: I haven’t read the sources for klipper, but I’ve read LinuxCNC, grbl(HAL) and g2core.
09:17 PM refo[m]: LinuxCNC is the most architecturally involved of them all, with most both complexity and historical baggage
09:18 PM refo[m]: It’s definitely possible
09:18 PM refo[m]: It’s just a lot of work
09:19 PM refo[m]: I’ll definitely go and take a look at klipper, thank you for the idea
09:19 PM refo[m]: GRBL is doing planning by ignoring the fact that rotational axes are rotational
09:20 PM refo[m]: It treats all axes as orthogonal
09:20 PM refo[m]: Which makes sense for a lot of use cases, in my opinion
09:21 PM refo[m]: But it’s still very limited in terms of what math it can do by the fact that it must run on an Arduino
09:21 PM gywilo[m]: right, that's a huge limit
09:21 PM refo[m]: GrblHAL has no such limitation, but it’s planner didn’t go much beyond
09:21 PM gywilo[m]: right, that's a huge limitation
09:22 PM gywilo[m]: I'm interested in your perspective once you've given it a review
09:23 PM gywilo[m]: does GrblHAL support non triv kinematics?
09:23 PM refo[m]: grbllHAL is targeting Teensy 3, which is ARM and a lot more capable. It also runs on Teensy 4, which is 600Mhz
09:24 PM refo[m]: Not to my knowledge, it’s mostly GRBL
09:27 PM gywilo[m]: where do I go to familiarize myself with linuxCNC path planning? is it all in this one directory?
09:27 PM gywilo[m]: \src\emc\tp
09:34 PM ZincBoy[CAON][m]: If you look into most of the commercial controls and even some of the academic papers, the solution seems to be to turn the tool path into multidimensional splines. These splines can be used to blend the motion after solving for minimal error on the constraints. Fanuc calls this type of thing nanosmoothing. The goal is to curve fit a spline that has minimal error from your position while meeting the joint constraints.
09:35 PM ZincBoy[CAON][m]: Yes, but it ties in with a bunch of other things. It is not really a separate module that can be swapped out.
09:41 PM gywilo[m]: interesting
09:45 PM gywilo[m]: so with 'nanosmoothing' it looks like we are working with perfect math models of the geometry that then drive joint motion
09:46 PM refo[m]: The spline is a good description of the problem, the actual optimization is the hard problem
09:47 PM refo[m]: An exhaustive search is impossible, so some sort of descent is necessary, likely with heuristic limitations on non-local effects
09:48 PM refo[m]: These heuristics start to make assumptions on kinematics, and that’s why I don’t think a general case solution is likely
09:49 PM refo[m]: It’s definitely doable (and not too complicated) in XYZ space
09:51 PM gywilo[m]: exhaustive search of what? optimal tool path based on constraints?
09:52 PM refo[m]: Yes. You have a huge configuration space, every spline point and very joint configuration for every spline point is a parameter
09:52 PM ZincBoy[CAON][m]: Not really. The spline acts to interpolate between points and the ends of the line segments. It is meant to smooth out the facetted effect you see with discrete line segments.
09:53 PM refo[m]: s/very/every/
09:54 PM refo[m]: The problem is optimizing for the actual spline shape (including the speed dimension)
09:55 PM gywilo[m]: but can't the problem be broken down into many smaller problems where for each point, we are only looking at the 10 moves ahead of us
09:55 PM ZincBoy[CAON][m]: Agreed. Most practical implementations I have seen start with building a model to reduce the search area. This is difficult with LinuxCNC unless the kinematics are constrained or someone is willing to build the model for the typical use cases.
09:55 PM refo[m]: yep, that’s one optimization heuristic
09:56 PM refo[m]: But its going to cause problems in some scenarios
09:56 PM ZincBoy[CAON][m]: That is kind of what the default 1 block TP is doing. You need to look much further ahead..
09:56 PM refo[m]: You do, in a general case
09:56 PM refo[m]: Imagine, you have a huge fast move and then 10 tiny moves
09:57 PM refo[m]: If you forget about your huge move after 10 tiny moves you are going to wreck your machine
09:57 PM refo[m]: You need to guarantee that you don’t
09:57 PM ZincBoy[CAON][m]: You end up need to do an exact stop for each move or you will violate the constraints.
09:57 PM refo[m]: So you will have to limit your speed to be able to stop
09:59 PM refo[m]: The smaller the lookahead window, the greater the constraints on speed
09:59 PM refo[m]: The slower and jerkier your machine will run
09:59 PM refo[m]: and in some cases the effects are worse than in others
09:59 PM XXCoder: lookahread should be based on time, not number of lines
10:00 PM refo[m]: That’s another great heuristic
10:00 PM refo[m]: Better than the one based on instruction counts
10:00 PM XXCoder: well it would be dual cap
10:00 PM ZincBoy[CAON][m]: lookahead calculation should be based on time, yes.
10:01 PM XXCoder: 10 minute line in 10 second lookahread would be no cache at all. so 10 seconds + 10 lines minium
10:01 PM XXCoder: for example
10:01 PM XXCoder: note 10 seconds is completely made up time. dunno what time span is best
10:01 PM refo[m]: However, your computational budget is limited, what if you have a zillion of tiny instructions from a CAM gone mad
10:02 PM ZincBoy[CAON][m]: Realistically you need the lookahead to be long enough that the machine can come to a complete stop without violating constraints. Around 500ms should be plenty.
10:03 PM refo[m]: What if your machine is a warehouse logistics system
10:03 PM ZincBoy[CAON][m]: Just because I set my CAM tolerance to 0.0001 and doesn't mean I am mad 🙂
10:03 PM refo[m]: It’s inertia can be huge
10:04 PM ZincBoy[CAON][m]: True, but you are unlikely to have complex gcode in that case and even a simple 1 block planner would be fine.
10:04 PM refo[m]: I’m trying to say that these constraints are machine-specific
10:05 PM ZincBoy[CAON][m]: For sure they are. You are correct that for a generic control system all of the parameters would need to be open.
10:08 PM refo[m]: I’m kind of getting a feeling that the optimization needs to be two-stage with a pre-processor that conveys some information to the real-time planner
10:08 PM refo[m]: So that the real-time planner can be kept simple
10:09 PM refo[m]: Some information beyond g-code that is
10:11 PM refo[m]: For example, a preprocesor can precompute model sensitivity
10:11 PM refo[m]: So that the lookahead can be dynamic and constrainted in real time
10:12 PM ZincBoy[CAON][m]: I think that should be more centered around the kinematics and machine dynamics.
10:12 PM refo[m]: Like “here we have a sharp turn, we will come to a near stop, nothing from before this turn will affect stuff after it”
10:13 PM ZincBoy[CAON][m]: Virtual rally navigator 🙂
10:13 PM ZincBoy[CAON][m]: 5 left descending
10:13 PM refo[m]: Yea, except for managing the computational budget
10:13 PM ZincBoy[CAON][m]: I don't think that is much of a problem anymore.
10:14 PM refo[m]: Kinematics increase the computational complexity
10:14 PM refo[m]: By increasing the number of dimensions
10:14 PM refo[m]: I’m guessing that doing it in real time would be tough
10:14 PM refo[m]: I may be biased by my use cases
10:14 PM refo[m]: Which are different from milling
10:15 PM ZincBoy[CAON][m]: That is why some prework needs to be done to model the system as it is implemented. You don't need to solve the generic case in real time just the specific case.
10:16 PM ZincBoy[CAON][m]: Modern processors can do a hell of a lot. I recall a paper that had 6 axis path planning and could plan 100ms ahead in 1ms.
10:17 PM refo[m]: It depends on what it’s optimizing for
10:17 PM refo[m]: I can sure plan ahead in that time if I’m doing exact stop
10:17 PM ZincBoy[CAON][m]: IIRC that was a 4th order planner.
10:17 PM refo[m]: Oof
10:17 PM refo[m]: we’ll
10:18 PM refo[m]: You can do those analytically
10:18 PM refo[m]: Meaning, if you have a specific model, you can just solve it
10:18 PM refo[m]: In a symbolic math package ahead of time
10:18 PM refo[m]: Then everything is really quick
10:20 PM ZincBoy[CAON][m]: Yes, and I think that is what is needed for linuxcnc path planning. Have the kinematic and machine solver separate from the real time TP.
10:20 PM refo[m]: You would be limited to a particular set of kinematics and particular properties of look ahead though
10:20 PM refo[m]: Interesting
10:20 PM refo[m]: * well
10:21 PM ZincBoy[CAON][m]: In today's made with linuxcnc:
10:21 PM * ZincBoy[CAON][m] uploaded an image: (727KiB) < https://libera.ems.host/_matrix/media/r0/download/jauriarts.org/CcAvNkgfsZDUeKGOXyKIMtAy/IMG_1370.jpg >
10:21 PM refo[m]: Nice!
10:22 PM ZincBoy[CAON][m]: Support bracket. About 10.5x7.5". Was a pain to keep it from warping too much
10:22 PM refo[m]: Why would it warp?
10:22 PM refo[m]: Never had experiencing milling large pieces of aluminum
10:23 PM refo[m]: s/experiencing/experience/
10:23 PM ZincBoy[CAON][m]: Had to reorder the tool paths a few times until I could keep it under 0.005"
10:23 PM ZincBoy[CAON][m]: It is 6061-t6 and made from an 8"x0.625" extruded bar.
10:23 PM ZincBoy[CAON][m]: I should have used MIC6 but I had this on hand.
10:24 PM ZincBoy[CAON][m]: 6061 has lots of internal stress and when you mill big flat sections it will warp. The first attempt had it go out by 0.05"
10:27 PM refo[m]: Didn’t know about internal stress in 6061, kinda had an idea that it’s soft and plasticky
10:27 PM refo[m]: Never dealt with it much aside from relatively thin sheets
10:29 PM norias: haha
10:29 PM norias: 6061 potato chips
10:29 PM ZincBoy[CAON][m]: You run into the same thing with steel. That is why hot-roll is better than cold-roll if you are doing any significant machining. Cold-roll has a ton of internal stress. You can also normalize steel but aluminum is trickier without re-heat treating.
10:30 PM norias: sometimes, with aluminum and facing...
10:30 PM norias: you will find the middle is low
10:30 PM norias: it didn't warp
10:31 PM norias: it got hot during the cut, the middle expanded, got cut flat
10:31 PM norias: then cooled
10:31 PM norias: the edges don't have as much of that effect
10:31 PM norias: so you end up with a concave thing
10:32 PM ZincBoy[CAON][m]: Yup.
10:32 PM gywilo[m]: I'm curious, what are your use cases?
10:32 PM refo[m]: I need milled parts, thinking of getting pocketNC for 5-axis
10:33 PM refo[m]: Are there any good alternatives to it
10:33 PM ZincBoy[CAON][m]: I have flood coolant that leans heavy on the flood side of things so not too much issue with heat build up.
10:34 PM ZincBoy[CAON][m]: I did see a Chinese version of this that looked pretty good. I can't remember the name of it now.
10:34 PM norias: when i did this stuff, i did as much dry or low lubricant milling as possible
10:35 PM refo[m]: DesktopNC?
10:35 PM refo[m]: DesktopNC? I think it went under
10:36 PM ZincBoy[CAON][m]: On aluminum? Any reason why?
10:36 PM refo[m]: The web site is gone
10:36 PM norias: i have a tough time believing in a machine made from aluminum
10:36 PM XXCoder: alum machine can cut alum. heck, theres wood machines that can cut alum
10:37 PM norias: XXCoder: vibrations are what i'd be concerned about
10:37 PM XXCoder: just need to think though proper rigidity and how much sideforce. and yes vibrations
10:37 PM refo[m]: I’m moving a heavy tool quickly at large distances with multiple rotational axis, relatively light torque criteria
10:37 PM refo[m]: s/axis/axes/
10:37 PM norias: ZincBoy[CAON][m]: honestly it started because my hands got cold, cleaning was a pain and air quality
10:37 PM ZincBoy[CAON][m]: Kern machines are made from aluminum. They are nothing to sneeze at.
10:37 PM XXCoder: I sorta want to build pocketnc ripoff
10:37 PM XXCoder: but I have no idea what cam would be lol. cant afford most of em
10:38 PM norias: ZincBoy[CAON][m]: but once I got in to it, some of the tooling seemed to last long
10:38 PM norias: ZincBoy[CAON][m]: I suspect thermal shock was the thing
10:38 PM XXCoder: ones I can afford, or are free, cannot do 5 axis
10:38 PM refo[m]: CAM seems to be another grand on top
10:39 PM refo[m]: Which kinda sucks, but the machine costs 5 by itself
10:39 PM XXCoder: pocketnc? isnt that cost mopre
10:40 PM ZincBoy[CAON][m]: https://www.robotdigg.com/product/1707/
10:40 PM refo[m]: The smaller version is about 5k
10:41 PM XXCoder: interesting
10:41 PM refo[m]: Nice, thank you
10:42 PM norias: hmmm
10:43 PM norias: is that saying it has a roughly 5'x'6'x6' work area and costs $500?
10:45 PM ZincBoy[CAON][m]: Interesting. I do pretty much all my steel machining dry as modern carbide and coatings love the heat. Aluminum I have had too many issue with chip welding to want to avoid coolant. I hear you on it getting everywhere though 🙂
10:46 PM ZincBoy[CAON][m]: Ha, no. You need to select the machine and not the cover. The machine is $4000.
10:47 PM norias: ah
10:47 PM norias: hmm, chip welding it seems boiled down to the right coating
10:47 PM norias: still, $4k isn't bad
10:47 PM ZincBoy[CAON][m]: If it were $500 I would have bought one a long time ago 🙂
10:49 PM norias: so tempting but i really should get a lathe first
10:50 PM ZincBoy[CAON][m]: I haven't played with the coatings too much. Just using a standard ZrN right now. I have a trico microdrop system that I haven't hooked up yet. Maybe I should bump the priority on that.
10:50 PM norias: yeah
10:55 PM norias: i think i'll end up with the little tormach just because payments
10:55 PM norias: although i have really good credit. maybe i could get a personal unsecured loan for a decent rate
11:30 PM roycroft: i've heard so many mixed reviews of tormach
11:30 PM roycroft: my sense is that they had some problems early on, but have become more reliable and consistent in recent years
11:31 PM XXCoder: they actually return changes to open source programs they use
11:32 PM XXCoder: including lcnc if I recall right
11:35 PM roycroft: hmm, i guess china is officially part of north america now, at least according to ebay
11:35 PM roycroft: when i add a "north america only" location filter, 100% of the results say 'from china'
11:35 PM XXCoder: as in shipped from china?
11:35 PM roycroft: yes
11:36 PM XXCoder: ok because thats bit amgious since everything is made in china lol
11:36 PM roycroft: which would not be horrible, except i'm getting delivery estimates of late october
11:36 PM roycroft: and i want to find something i can get in a couple weeks at most
11:37 PM XXCoder: yeah thats bit concerning
11:37 PM XXCoder: because when you want local seller, often theres a good reason