#linuxcnc-devel Logs

May 06 2020

12:39 AM seb_kuzminsky: buster-python3 is intended to run src/configure with python3 for python and boost, on any branch whose version (as reported by scripts/get-version-from-git) is 2.9 or bigger, so master and anything derived from master
12:43 AM seb_kuzminsky: on branches less than 2.9 it doesn't pass anything special to configure
12:43 AM seb_kuzminsky: i haven't got a clean run through it yet, on either side of the conditional, i'll check tomorrow
01:47 AM linuxcnc-build: build #6799 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6799
02:37 AM linuxcnc-build: build #3 of 1660.rip-buster-python3 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/3 blamelist: Sebastian Kuzminsky <seb@highlab.com>
02:37 AM linuxcnc-build: build #6800 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6800 blamelist: Sebastian Kuzminsky <seb@highlab.com>
07:06 AM linuxcnc-build: build #4 of 1660.rip-buster-python3 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3/builds/4 blamelist: Phillip Carter <phillcarter54@gmail.com>
07:06 AM linuxcnc-build: build #6801 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6801 blamelist: Phillip Carter <phillcarter54@gmail.com>
07:25 AM jepler: hm python3 doesn't even get past configure for me.
07:25 AM jepler: configure:9656: g++ -o conftest -g -O2 -I/usr/include/python3.7m conftest.cpp -lXinerama -lpython3.7m -lboost_python >&5
07:25 AM jepler: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libboost_python.so: undefined reference to `PyString_Size'
07:26 AM jepler: libboost-python1.67-dev:
07:26 AM jepler: Installed: 1.67.0-13+deb10u1
07:26 AM jepler: libpython3.7-dev:
07:26 AM jepler: Installed: 3.7.3-2+deb10u1
07:28 AM jepler: maybe it's the wrong boost library, this works. but why can't configure autodetect it?
07:28 AM jepler: libpython3.7-dev:
07:28 AM jepler: Installed: 3.7.3-2+deb10u1
07:28 AM jepler: ./configure --with-python=python3 --with-boost-python=boost_python3-py37
07:56 AM rene_dev_: Jepler its picking up the wrong boost
07:56 AM rene_dev_: did you make clean?
07:57 AM rene_dev_: the test that fails needs the one PR merged to pass, I will take care later today.
07:57 AM rene_dev_: If you only reconfigure some objects remain that have python 2 references
09:04 AM jepler: I already pushed a fix for the failing test, sorry we crossed paths.
09:05 AM jepler: rene_dev_
09:19 AM seb_kuzminsky: good morning
09:19 AM linuxcnc-build: build #5146 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/5146 blamelist: Jeff Epler <jepler@gmail.com>, Dewey Garrett <dgarrett@panix.com>
09:19 AM jepler: hi seb_kuzminsky
09:19 AM seb_kuzminsky: looks like master is failing the halmodule.0 test with python3
09:19 AM seb_kuzminsky: i saw the failure both on the buildbot and on my buster dev machine
09:20 AM jepler: seb_kuzminsky: yeah I recently pushed a fix for it, and rene_dev_ mentioned also working on a PR
09:20 AM jepler: dunno what's going on with those last two failures, more erratic tests? :( :(
09:20 AM jepler: /home/buildslave/emc2-buildbot/wheezy-rtpreempt-amd64/wheezy-amd64-rtpreempt-rip/build/tests/halui/mdi
09:20 AM jepler: two different tests even
09:21 AM seb_kuzminsky: oh, great! thanks :-)
09:21 AM seb_kuzminsky: i knew taking a nap would fix the problem
09:24 AM jepler: some problems require longer than 1 nap for someone else to fix them, so if trouble persists try getting a full night's sleep
09:42 AM seb_kuzminsky: all of 2.9 will build on that builder with python3, including any old (pre-rene-py3) commits, and any branches based on old master commits, and those will fail rip, so they won't build debs
09:42 AM seb_kuzminsky: maybe that's a price we're willing to pay
09:43 AM seb_kuzminsky: or maybe we should make 2.9.0~pre1 to mark the occasion, and then we can build post-2.9.0~pre1 with py3 and pre-2.9.0~pre1 without
09:46 AM rmu|w: i suggest naming the python 3 linuxcnc version 3
09:47 AM rmu|w: (insert "may" at the beginning)
10:18 AM rene_dev_: Jepler it’s not my PR, its from damian, a few days ago
10:33 AM linuxcnc-build: build #6803 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6803 blamelist: Jeff Epler <jepler@gmail.com>, Dewey Garrett <dgarrett@panix.com>
10:34 AM rene_dev_: jepler https://github.com/LinuxCNC/linuxcnc/pull/824
11:11 AM rene_dev_: jepler At the same time, it has great performance, being between 2x and 15x as fast as numpy!
11:11 AM rene_dev_: pyglm is faster than numpy
11:17 AM jepler: If the speed of numpy is too low then I guess you should investigate debian-packaging this other thing.
11:21 AM rene_dev_: jepler what other changes can you think of? I would like to integrate vismach, so you can load objects into gremlin
11:21 AM rene_dev_: btw, vismach works with python3 :)
11:26 AM jepler: Yeah that is so obvious to do, but the codes are so different that it was hard
11:27 AM jepler: if it gets a well-deserved rewrite, best to design it so that they can work together
11:32 AM jepler: I don't know whether "tesselation" of arcs / splines can be moved into the graphics engine in a better way now
11:35 AM mozmck: qtpyvcp is using vtk for the opengl stuff and I've heard it is *much* faster than gremlin. I don't know if that code could be used for gremlin?
11:36 AM jepler: I have no idea about the state of 3d graphics honestly
11:38 AM mozmck: I've been rather out of the loop myself for a while. I thought you were talking about gremlin but I guess more just python2 vs 3?
11:39 AM jepler: mozmck: axis, gremlin, and vismach all use "old" openGL and need a full rewrite to work with "modern" opengl and/or in-between libraries like vtk
11:39 AM jepler: I guess rene_dev_ has someone who has started some kind of work in that direction
11:40 AM mozmck: I see. I was wondering if the rewrite might could use some of the code from qtpyvcp with vtk. It might be tied to QT tightly though...
11:40 AM mozmck: http://www.qtpyvcp.com/
11:54 AM mozmck: Is there any way to make motion.digital-out-xx pins to turn off when linuxcnc is in estop?
11:58 AM seb_kuzminsky: mozmck: not that i know of, but you could use some hal logic to AND the digital output and the estop pin maybe?
11:59 AM mozmck: I can, but then they come back on when you come out of estop. My thought is that if you went into estop everything should stop and you should have to manually restart it?
12:01 PM jepler: It's not clear to me whether it's universally true that it's safe to set these outputs to false / 0 / 0.0 on an estop condition
12:01 PM jepler: like, on some hypothetical machine that might make a toolchanger START rotating back to pocket 0
12:02 PM rene_dev_: mozmck where is the code? does it use legacy or core profile?
12:03 PM rene_dev_: mozmck the problem is, you cant have a legacy profile in gtk3. it is not as such a python3 problem.
12:03 PM rene_dev_: the real problem is, that the gurrent gtk2 code cant work with python3
12:06 PM mozmck: jepler: that may be true - I'll need to think some more about that. Currently M3, M7 and M8 turn off with estop, but I need a couple more outputs that do that I think.
12:07 PM mozmck: rene_dev_: the qtpyvcp code or vtk? I think both are on github - I can look it up. I don't know details, just wondering out loud I guess.
12:07 PM rene_dev_: so you want then to turn off, but not turn on autonatically
12:08 PM rene_dev_: https://github.com/kcjengr/qtpyvcp/blob/master/qtpyvcp/widgets/display_widgets/vtk_backplot/vtk_backplot.py
12:08 PM mozmck: yes
12:08 PM rene_dev_: found it
12:08 PM rene_dev_: it uses vtk... not sure how that can be put into gtk3
12:09 PM mozmck: rene_dev_: Maybe this? https://github.com/Kitware/VTK/tree/master/Wrapping/Python/vtkmodules/gtk
12:10 PM rmu|w: mozmck: you could pipe it through classicladder
12:11 PM rene_dev_: uses gtkgl, which you cant use in gtk3 :(
12:11 PM rene_dev_: Im even thinking about xembedding something into gtk3 :D
12:11 PM mozmck: rmu|w: thanks - I'll look into that.
12:11 PM rmu|w: vtk is not pip-installable on the rpi, and building from source is tedious and didn't work in my tries
12:12 PM rene_dev_: mozmck rmu|w the problem is, you really want to change the internal state of the outputs
12:12 PM jepler: and we need things in debian packages anyway, for users to be able to rely on them
12:13 PM rene_dev_: mozmck how about running a gcode macro on estop?
12:13 PM jepler: (they can be .deb files shipped from linuxcnc.org, but it still needs to be in a package)
12:13 PM mozmck: rene_dev_: hmm, I already do that for something - I could add that to it. Good idea!
12:13 PM rmu|w: i think there can't be much going wrong if all outputs are reset in estop. if it was dangerous, how would you power up the machine?
12:14 PM rene_dev_: would not work on my machine, at least if you reset the analog pins
12:14 PM rene_dev_: I control the carousel comp with analog out form gcode
12:14 PM mozmck: rene_dev_: When I first used the ABORT macro I (well Rob mostly) had to fix a bug where it would jump ahead in the code and run another line. That's fixed now though.
12:14 PM rmu|w: thinking about it, my toolchanger also would not like it if you reset all outputs while tool-changing
12:15 PM mozmck: Interesting.
12:16 PM rmu|w: i control some sort of tool-elevator from motion digital outputs, and retracting this elevator while the spindle is still in there could result in damage
12:27 PM hazzy-m: My $0.02, VTK is very easy to work with extremely capable, but I'm not sure its ideal for the backplot. Installation is a bit heavy and it's not readily available on all platforms (RPi for example). I modern GL backplot written in C or C++ with python bindings would probably be ideal
12:46 PM rene_dev_: My short research shows that you can’t integrate it into gtk3
01:16 PM rene_dev_: https://www.twitch.tv/limuxcmc
01:19 PM mozmck: rene_dev_: what is going on there?
01:22 PM sync: that's end refactoring the GL stuff
02:33 PM -!- #linuxcnc-devel mode set to +v by ChanServ
03:44 PM rene_dev_: dwrobel did you ever run a machine with python3?
05:26 PM skunkworks: jepler: your image is running the green machine. no issues
05:37 PM dwrobel: rene dev not yet. I'm helping to prepare a linuxcnc (and possibly packaging it into Fedora) while my son is building plasma and waiting for mesa 7I92+7I77+thcad
06:00 PM skunkworks: jepler: survived an apt-get update/upgrade :)
07:13 PM jepler: skunkworks: great! Real test is when a new rpi kernel comes out, but it should be fine
07:57 PM seb_kuzm1nsky: skunkworks: what mesa card are you using with your rpi4? 7i92?
07:57 PM seb_kuzm1nsky is now known as seb_kuzminsky
07:57 PM Tom_L: he is
07:57 PM seb_kuzminsky: has anyone tried rpi4 -> i2c -> mesa?
07:58 PM Tom_L: not lately. jepler did early on
07:58 PM Tom_L: rpi3 iirc
07:59 PM Tom_L: that would likely be a 7i90?
07:59 PM seb_kuzminsky: yeah, that's what i had in mind
08:00 PM seb_kuzminsky: the only issue is, does the i2c on the rpi4 work well with linuxcnc?
08:00 PM Tom_L: i don't have a pi but do have the 7i90
08:00 PM seb_kuzminsky: i always ran my 7i90 via EPP
08:00 PM Tom_L: same here
08:00 PM Tom_L: still am
08:01 PM seb_kuzminsky: are you running a machine with it? i've only ever used mine for testing drivers
08:01 PM Tom_L: tested my config with the 7i80 as well which is a 7i90 with ethernet interface
08:01 PM Tom_L: it's on my mill on wheezy yes
08:01 PM Tom_L: d525
08:01 PM seb_kuzminsky: neat :-)
08:02 PM Tom_L: pp was just what i happened to start with
08:02 PM Tom_L: you seen the mill?
08:02 PM Tom_L: hand built
08:03 PM Tom_L: based off this cad model http://tom-itx.no-ip.biz:81/~webpage/cnc/Column_Mill_VMC.jpg
08:04 PM seb_kuzminsky: very cool! is that welded box section for the main frame?
08:04 PM Tom_L: yes
08:04 PM Tom_L: 2" box with a 4" column
08:04 PM seb_kuzminsky: how did you true all the surfaces up after welding?
08:04 PM Tom_L: hammer :)
08:05 PM Tom_L: and shims
08:05 PM seb_kuzminsky: lol!
08:05 PM seb_kuzminsky: how does it run now?
08:05 PM Tom_L: i was gonna take it to my bud and let him mill it but he's always busy so i decided not to
08:05 PM Tom_L: great
08:06 PM Tom_L: the sherline spindle is a little weak
08:06 PM Tom_L: https://www.youtube.com/watch?v=Jmmw4qLhLMk
08:07 PM seb_kuzminsky: chip guards and everything, so professional looking
08:07 PM Tom_L: it's a hack
08:08 PM Tom_L: all surplus parts save the rails and mesa stuff
08:08 PM seb_kuzminsky: seems to work well though judging by the snow drifts of chips in the corners
08:08 PM Tom_L: yeah it does ok
08:08 PM Tom_L: it far exceeded the goal of being better than a sherline
08:08 PM seb_kuzminsky: did you broach the hex hole in the speed handle?
08:09 PM Tom_L: no i cut it
08:09 PM Tom_L: https://www.youtube.com/channel/UCoG_JaILNz3Q-jBZ5MiK1dA/videos?view_as=subscriber
08:09 PM Tom_L: it's probably there somewhere
08:09 PM Tom_L: https://www.youtube.com/watch?v=bBHNrJPnAaU&t=18s
08:10 PM Tom_L: that was the final edge chamfer
08:50 PM jepler: seb_kuzminsky: do you mean spi when you say i2c?
08:50 PM jepler: I think I spun motors with spi on the odroid, maybe even the ones on zenbot
08:51 PM jepler: seb_kuzminsky: andypugh where do I pick up the rtai kernel? maybe I'll dig up the time to try it in a VM as well
08:53 PM Tom_L: https://github.com/NTULINUX/RTAI/blob/master/README.INSTALL
08:57 PM jepler: ugh build it like a peasant !?
08:57 PM Tom_L: i'm not sure where andy's build is
08:57 PM jepler: (sorry that's the jerk talking)
09:01 PM seb_kuzminsky: http://linuxcnc.org/temp/ i think?
09:01 PM Tom_L: yeah i just opened that
09:01 PM Tom_L: looks like it
09:01 PM Tom_L: you also need that linux build ver for that rtai
09:03 PM Tom_L: i had better luck building it
09:08 PM skunkworks: seb_kuzminsky: yes. 7i92 ethernet
09:09 PM seb_kuzminsky: skunkworks: and you use the wifi for normal file transfer and remote access and such?
09:09 PM skunkworks: yes
09:10 PM seb_kuzminsky: jepler: yes maybe i did mean spi... what i really meant was... is there a way to connect a mesa card to the rpi4 gpio pins?
09:10 PM skunkworks: i do have to run 500hz servo thread
09:11 PM skunkworks: peter says spi works great at 1khz
09:11 PM seb_kuzminsky: how does 500 Hz work in real life?
09:11 PM seb_kuzminsky: oh interesting!
09:11 PM skunkworks: you have seen the videos.... ;)
09:11 PM jepler: seb_kuzminsky: yeah with pi4 you can use ethernet or spi. I haven't done anything "real" with spi, but it does work
09:11 PM seb_kuzminsky: so you get better refresh rate over the gpio pins than over gigabit ethernet, that's a bit surprising
09:12 PM jepler: peter has a couple of cards where you perch the pi (4) on top of it with standoffs, and run a short ribbon cable.
09:12 PM seb_kuzminsky: ok fiiiiine, i'll buy another rpi4 to play with
09:12 PM skunkworks: less overhead i guess
09:12 PM * seb_kuzminsky clicks submit
09:12 PM seb_kuzminsky: i thought i was done with crappy little arm boards
09:12 PM seb_kuzminsky: but maybe this one's not so terrible
09:12 PM seb_kuzminsky: at least if other people do all the hard work to make it work well with linuxcnc
09:12 PM jepler: http://store.mesanet.com/index.php?route=product/product&product_id=338 is one of the boards designed for pi and I think http://store.mesanet.com/index.php?route=product/product&path=83_85&product_id=345 is the other one
09:13 PM skunkworks: i like the ethernet as the pi is outside of the electrical box.
09:13 PM jepler: yeah you don't want to run multi-tens-MHz SPI over a long cable run, 3 inches is plenty
09:15 PM skunkworks: I should try 1khz again. it was at the edge.
09:15 PM jepler: I don't know that anything's improved, but I s'pose you can
09:15 PM jepler: or go to 666Hz
09:16 PM skunkworks: that seems wrong on many levels
09:17 PM skunkworks: seb_kuzminsky: i didnt think i would actually use the pi4 perminat
09:18 PM seb_kuzminsky: skunkworks: but now you're considering it, since it's not terrible?
09:18 PM Tom_L: i think he's fallen in love with it
09:18 PM skunkworks: permanently.. but it seems viable
09:19 PM skunkworks: it is so small and cute
09:19 PM Tom_L: skunkworks, you should mill one of those cases for it
09:20 PM skunkworks: heh
09:20 PM Tom_L: you seem to like a challenge
09:20 PM seb_kuzminsky: oh, is there a good model for a machinable rpi4 case floating around somewhere?
09:21 PM skunkworks: instead of a cheese grader.. polygrader?
09:21 PM Tom_L: i haven't looked but the most likely place would be grabcad
09:21 PM seb_kuzminsky: i'm underwhelmed by the blobby stringy plastic junk coming off my 3d printer... a nice machined one would be just the thing
09:21 PM seb_kuzminsky: though i guess it'd have to be made out of plastic if you want the wifi to work
09:22 PM seb_kuzminsky: the stuff on thingiverse all seems very additive, with overhangs and snap fits and things
09:22 PM seb_kuzminsky: i'll check grabcad
09:22 PM skunkworks: that would be a question for andy
09:23 PM skunkworks: the metal case i have seemed to let the wifi work
09:25 PM skunkworks: (another reason i wanted it out of the electical box)
09:25 PM * Tom_L snickers: https://grabcad.com/library/fresh-baked-raspberry-pi4-case-1
09:25 PM seb_kuzminsky: i guess it had to be done
09:26 PM skunkworks: wow
09:31 PM sync: seb_kuzminsky: well on the rpi4 at least the ethernet is not connected to usb anymore
09:31 PM seb_kuzminsky: so i've heard - i guess that's why skunkworks machine works so well
09:31 PM sync: that is why it works at all
09:33 PM Tom_L: skunkworks, you should cut this one with your boring bar trick: https://grabcad.com/library/octopi-case-with-camera-holder-1
09:33 PM sync: the problem is the that the IO does not talk to the CPU directly
09:33 PM sync: https://www.heise.de/ct/imgs/04/2/7/4/3/7/8/1/RPi4-Block-e4359fdb4be588cf.png
09:38 PM skunkworks: Tom_L: cool!
09:40 PM skunkworks: it has been suprisingly stable.
09:50 PM jepler: Is there no "kern" testsuite in current versions of rtai? that would mean .. they don't do anything to exercise the in-kernel API anymore?
09:51 PM jepler: there used to be testsuite/kern/latency, or somesuch, in which the RT process is loaded in kernel space like classic linuxcnc on rtai
09:52 PM jepler: yeah that ... drwxr-xr-x root/root 0 2010-07-27 18:03 ./usr/realtime-2.6.32-122-rtai/testsuite/kern/latency/
09:53 PM jepler: and ./usr/realtime-2.6.32-122-rtai/modules/latency_rt.ko
09:53 PM Tom_L: yes, that installed on mine
09:54 PM Tom_L: being far above my paygrade i ignored it
09:54 PM jepler: the /kern/ part is important
09:55 PM Tom_L: all i see in testsuite is display and latency
09:55 PM jepler: yeah usr/realtime-.../testsuite/latency is a lxrt test, not a kernel test
09:55 PM jepler: if there's no /kern/ then it's a userspace lxrt test
09:56 PM Tom_L: there's a /realtime/calibration folder
10:03 PM Tom_L: no latency_rt.ko file
10:19 PM jepler: cool, I can get a serial console with libvirt / kvm and see all the kernel messages that it manages to log
10:19 PM jepler: now to set up reproduction of the bug and find out if I can get any additional info
10:19 PM Tom_L: jepler, it is in the rtai.org file
10:20 PM Tom_L: but not the one i linked to you earlier
10:20 PM Tom_L: but it was based on the rtai.org one
10:20 PM jepler: cool but not necessarily relevant: uspace with lxrt realtime has not bitrotted so badly it doesn't even start ... https://gist.github.com/8a04a0b0687fc71d2851229b1e060bc2