#linuxcnc-devel Logs

Sep 17 2023

03:30 AM rmu: Beef: a compile_commands.json may help with vscode and c++ language server. you can generate that with e.g bear ("build ear") or cmake (https://stackoverflow.com/questions/20059670/how-to-use-cmake-export-compile-commands)
04:36 AM pere: Anyone understand why the string patched in <URL: http://paste.debian.net/1292221/ > is translatable and passed on to translators? Seem like a waste of translator time to me.
04:40 AM rmu: why is it there in the first place?
04:48 AM pere: no idea.
07:07 AM IAmTheRealBeef is now known as Beef
07:27 AM Beef: Hm, attempting to run the unit tests after building the master branch results in seemingly everything failing. Is this due to running inside a VM or a bad configuration on my end? LinuxMint 21.2
07:27 AM Beef: When running "runtests -s" as I saw on the forum, fair number of "SHMEM: Can't take semaphore", some segfaults, some permissions errors, and others.
07:29 AM Beef: I'll get a good count in a few minutes, as I just re-cloned the repository here to start from scratch and went through (what I believe to be) the full steps of building/testing it for running in RIP
07:29 AM Beef: and sorry, it's supposed to be "runtests -v" that I am running, not -s
07:35 AM Beef: Runtest: 258 tests run, 187 successful, 71 failed + 0 expected, 3 skipped
07:35 AM Beef: Hm, so better than I expected but still not good. I can provide a list of the failed ones but I don't know that its so helpful
07:40 AM rmu: did you run "make setuid"?
07:40 AM Beef: sudo make setuid yes
07:42 AM Beef: this list of commands I used (also checking for dependencies) after cloning the repo into ~/dev/linuxcnc/rip/
07:42 AM Beef: cd ~/dev/linuxcnc/rip/
07:42 AM Beef: cd debian
07:42 AM Beef: ./configure uspace
07:42 AM Beef: cd ..
07:42 AM Beef: dpkg-checkbuilddeps
07:42 AM Beef: cd src/
07:42 AM Beef: ./autogen.sh
07:42 AM Beef: ./configure --with-realtime=uspace
07:42 AM Beef: make
07:42 AM Beef: sudo make setuid
07:42 AM Beef: source ../scripts/rip-environment
07:42 AM Beef: runtests
07:43 AM Beef: after I saw so many XFAIL messages, started fresh and the second time around I used runtests -v to get more details along the way
07:52 AM IAmTheRealBeef is now known as Beef
07:53 AM Beef: hm, perhaps some of it has to do with the RT kernel, as it's got 5.15.0-1032-realtime after double-checking with uname -r but my CNC PC is running preempt_rt version
08:08 AM rmu: i'm not sure but i think the test's don't really depend on a real time system
08:17 AM Beef: sudo ldconfig ~/linuxcnc lib
08:17 AM Beef: got me another 10 passed tests, and most of the rest are reporting permission errors this time around, so I assume it's related to not running sudo runtests. I guess i'll call it good enough for now.
08:17 AM Beef: I've gotten Grotius' work to compile/run, and now just trying to set up a dev environment to understand it better and refactor it a bit. I'm hardly a programmer but I figure if I can get it down from a 16hr task getting it to compile that other people much more talented than me may end up taking a harder look at it.
08:18 AM rmu: Beef: got a branch?
08:20 AM rmu: Beef: it can probably adapted for the "simpletp" i.e. jogging planner, but for the general TP it is probably a dead end
08:20 AM Beef: ah poo, why's that?
08:23 AM Beef: I just forked LinuxCNC into my own repo for now, and am planning to manually work through the s-curve files as they're all nicely packaged into that CMake folder so it's surprisingly mildly understandable for me, but I wasn't aware that it could be a dead end
08:23 AM Beef: I was using your smooth velocity profile fork and ran it on my actual machine after some sim testing, but it unfortunately doesn't respect toolsetting subroutine - only reacts to the input when jogging. I figured I'd try this one as its based on ruckig
08:27 AM rmu: i'm not sure what you are talking about, grotius started a bunch of approaches, most of them completely independent of linuxcnc and ignorant of more than one axis or kinematics
08:27 AM rmu: but it's been a while, not sure if i remember correctly
08:29 AM Beef: yeah, I saw that in the forum history
08:29 AM Beef: his most recent approach and the one I understand to be used as of the last github commit is using the ruckig library and is more sensible
08:29 AM Beef: https://github.com/grotius-cnc/linuxcnc/tree/main/cmake/components/sc_tp_src
08:29 AM rmu: my smooth velocity profile hack doesn't have anything to do with toolsetting or the like, but there are some cases where it doesn't reach the target position/velocity for some reason i don't understand /didn't investigate further
08:30 AM rmu: because there are some strange things going on where the trajectory planner is interfering with already planned segments and i don't/didn't understand the reason and the circumstances where that happens
08:30 AM rmu: i will probaböy revisit this stuff at the next stuttgart linuxcnc meeting ;)
08:34 AM Beef: good to know, I just dislike having to choose between low accelerations or having the machine vibrate the building, so I guess I'll end up beating my head against the wall for this and maybe i'll break through somewhere
08:35 AM rmu: i have no idea how https://github.com/grotius-cnc/linuxcnc/tree/main/cmake/components/sc_tp_src fits into linuxcnc, it seems the repository isn't even a fork or branch of linuxcnc but a separate upload that is somewhat mangled structure-wise. so not easy to distill changes from stock linuxcnc
08:36 AM rmu: AFK for a while, ttyl
08:36 AM Beef: I understand that your hack doesn't change toolsetting directly, but at least based on my testing on the machine (swapping from 2.9 to your fork) it appears that when its started movement in a subroutine that it doesn't react to the sensor input.
08:36 AM Beef: anyway, thanks for the chat and take care
08:36 AM Beef: 8)
08:37 AM rene-dev5: https://github.com/grotius-cnc/linuxcnc/commit/40ad2068bca255d31e599e40e83cc4e3bac3103c
08:37 AM rene-dev5: There is a single commit including all of linuxcncs code
08:38 AM rene-dev5: its unmaintainable, and impossible to tell what is even going on, or how it fits in
08:43 AM Beef: Right, that's why I am intending to refactor this as I've gotten it to compile/run and understand a bit more what's going on - with the caveat that I'm likely not any better at programming. That's why I came here, so that I can ensure that my new fork with the refactored code is more in-line with LinuxCNC
08:43 AM Beef: I had the vibe that since April when he stopped uploading that nobody else wanted to put the time in to understand what's going on as its not following any good coding practices
10:12 AM IAmTheRealBeef is now known as Beef
10:26 AM Beef: Does anyone have a link to a forum post or similar about setting up another TP inside of src/emc?
10:26 AM Beef: I tried the naive solution of copying tp and renaming references inside, but i'm missing something as the there's no object or component generated. Or do I need to explicitly include the files in the MakeFile?
11:37 AM IAmTheRealBeef is now known as Beef
11:41 AM rmu: Beef: in one of the "s-curve" threads somebody suggested to grotius how to set up a TP module, but I don't have a link at hand. but forum search should turn it up
12:04 PM Beef: thanks much, i had a vague recollection of seeing it somewhere
12:51 PM rmu: Beef: i think that is the relevant forum post https://forum.linuxcnc.org/38-general-linuxcnc-questions/33459-linuxcnc-s-curve-accelerations?start=290
12:52 PM rmu: or rather this one https://forum.linuxcnc.org/38-general-linuxcnc-questions/33459-linuxcnc-s-curve-accelerations?start=290#263550
12:52 PM rmu: it really sucks that the forum can't render all of a thread on one page
01:05 PM IAmTheRealBeef is now known as Beef
01:09 PM Beef: Hey thanks again, I appreciate it - I'll make some more progress tonight but probably won't have anything nice to show until next week (or so) depending on how much my brain melts. Just want to ensure that I can figure out how to get a basic TP to compile properly with the standard LinuxCNC method before I start porting his code over. At least
01:09 PM Beef: Ruckig does all the math and doesn't have any dependencies.
01:13 PM rmu: I'm not holding my breath, the problem isn't even really very clearly defined, and it is a hard problem
01:16 PM rmu: I didn't look too closely at ruckig, but if you want to keep current path blending, you will have to live with infinite jerk on some joints at e.g. line->circle transition
01:18 PM rmu: does ruckig modify the path? if so how?
01:23 PM Beef: About the path blending, it sounds like a problem for future me at the moment '=D . Until I have achieved parity with what he managed then I won't think about it yet. Having maintainable/readable/understandable code that others can grasp and contribute to is the greater part of the battle. And if i find it's a dead end, then at least with the
01:23 PM Beef: experience maybe there's another library more suitable. I don't have an answer for you about modification of the path yet.
01:23 PM pcw---home: Shouldn't a line->circle transition obey jerk limits in a 3rd order planner just as it currently obeys acceleration limits with a 2nd order planner?
01:25 PM rmu: acceleration on axis perpendicular to line makes a jump
01:26 PM pcw---home: right but blending should fix that as it does now for acceleration
01:27 PM rmu: then you need a different blend to something not-circle
01:38 PM pcw---home: Yeah, I'm not sure why circular blending was chosen compared to cubic or higher polynomials, maybe it simplifies something...
01:45 PM rmu: there is a video with rob ellenberg explaining why he chose circular arcs and how it is implemented. IIRC it has something to do with optimization under constraints (max acceleration) and tractability. with circles it is relatively easy.
01:53 PM pcw---home: maybe this one? https://www.youtube.com/watch?v=412N5A-N8Fc
02:04 PM rmu: yes i think that's the one i remember
02:05 PM rmu: one problem e.g. with higher order bezier curves is that there is no closed parameter form where parameter is path length
02:08 PM pcw---home: Yeah just listening now (I think I watched this a long time ago also)
02:11 PM pcw---home: I do see that the tangential and centripetal acceleration are independent so easier to see whats available for tangential
02:18 PM pcw---home: You do see that the choice was largely determined by the characteristics of Tormach machines of the time...
03:05 PM IAmTheRealBeef is now known as Beef
03:32 PM IAmTheRealBeef is now known as Beef
04:48 PM IAmTheRealBeef is now known as Beef
06:18 PM Unterhaus_ is now known as Unterhausen
06:35 PM IAmTheRealBeef is now known as Beef
07:28 PM skunkworks: could the software encoder module not be high enough precision?
07:28 PM skunkworks: I really think it is losing position slowly as the spindle is turning.
07:28 PM skunkworks: (I mean it is - but I don't think it is a hardware issue - missing a count)
07:31 PM skunkworks: if I run a threading opeation - so lets say an inch .1" pitch - I never see the position be off (it is falling at the same time after the gap - (missing tooth encoder))
07:32 PM skunkworks: No issues. But if I have a threading operation like this..
07:32 PM skunkworks: https://www.youtube.com/shorts/vzy376NQP_U
07:33 PM skunkworks: where the index is found once - then a ton of G33 motion - the encoder positon slowly moves
07:34 PM skunkworks: So you would see that motion slowly wrap around the cylinder.
07:35 PM skunkworks: it is moved by a goot 5 counts by a couple hundred rotations. Always moving the same direction.
07:35 PM skunkworks: good
07:36 PM skunkworks: and again - threading at 1 inch long .1 pitch thread over and over. I have never seen the position drift. (so no more than 10 turns)
07:36 PM skunkworks: you would think if it was random noise - or missing edge - you would also see it during the 10ish turns..
07:37 PM skunkworks: at some point of testing
07:37 PM Beef: you don't have some kind of backlash compensation turned on?
07:37 PM skunkworks: no
07:37 PM skunkworks: This is strictly comparing the encoder position based on where the index is.
07:39 PM skunkworks: https://github.com/LinuxCNC/linuxcnc/issues/2635
07:39 PM Beef: I was just missing the previous context thanks
07:40 PM skunkworks: you can see in my bottom screen shots - the int position is slowly moving to the left..
07:40 PM skunkworks: I thought maybe I was missing a edge every now and again - but now I am not so sure..
07:41 PM skunkworks: it is pretty consistant as the spindle position goes up
08:54 PM pcw---home: Does it vary with speed?