#linuxcnc-devel Logs

Sep 07 2018

02:46 AM Jin|away is now known as Jin^eLD
08:49 AM jthornton: did something change in 2.7 uspace to require libboost-python 1.62.0? trying to apt-get install uspace on Linux Mint 18
10:47 AM seb_kuzminsky: jthornton: looks like we don't track the version of boost needed: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
10:47 AM seb_kuzminsky: but i know that 2.7 builds on wheezy, which surely has an older version of boost
10:47 AM seb_kuzminsky: oh, and lucid
10:50 AM jepler: you need to distinguish between the minimum required version, and the version that a particular deb for a particular OS ends up built with. That will potentially be a higher version number.
10:50 AM jepler: you should always match the deb to the right os
10:50 AM jepler: linux mint is not debian, so it's just pure luck if any debian particular package manages to install there
10:51 AM seb_kuzminsky: i agree in general, but aren't some mints debian?
10:52 AM jepler: it looks like globally we use the "libboost-python-dev" package as a build time dependency, and let the package building process determine the correct binary package name based on the linked in shared libraries ("shlibdeps")
10:52 AM jepler: so we always select whatever the default boost version is on whatever OS we're building a .deb-format package on.
10:52 AM Jin^eLD: btw are there any plans to get into non-debian distros? I was surprised that LinuxCNC was not in Fedora, had to compile it myself
10:53 AM seb_kuzminsky: Jin^eLD: every once in a while someone starts an effort to provide packaging for fedora/gentoo/freebsd, but so far none of those efforts has resulted in a PR
10:53 AM Jin^eLD: I think the problem is getting a maintainer for it, afaik thats how it works
10:54 AM Jin^eLD: that is if you dont want to go the effort yourselves
10:54 AM JT-Shop: seb_kuzminsky: something is odd then
10:54 AM Jin^eLD: we were lucky on our project in the past that someone got interested and went through all the submission process and guidelines and stuff to get us in there
10:54 AM Jin^eLD: would not want to do that myself either
10:55 AM rene_dev_: jepler looks like I cant download attachments from the forum
10:55 AM seb_kuzminsky: Jin^eLD: for the past 10+ years, the most active linuxcnc developers have all been debian people, with some of us flirting with ubuntu for a while
10:56 AM rene_dev_: requested content cannot be loaded, please try again later
10:57 AM Jin^eLD: seb_kuzminsky: ok that explains the rpm absence then :)
10:57 AM JT-Shop: oh ok I should use precise... slaps his head
10:57 AM jepler: rene_dev_: investigating
10:58 AM rene_dev_: trying this post
10:58 AM rene_dev_: https://forum.linuxcnc.org/41-guis/26550-lathe-macros#34357
10:58 AM rene_dev_: same here: https://forum.linuxcnc.org/41-guis/26550-lathe-macros
10:58 AM seb_kuzminsky: i think it'd be good for the project if someone would do the work to integrate linuxcnc with other distros, but i personally have neither the time, knowledge, or interest
10:58 AM jepler: rene_dev_: odd, I can see the image and download LatheMacro-3.zip
10:58 AM jepler: rene_dev_: let me go look at the logs
10:59 AM rene_dev_: https://imgur.com/a/ve0sBi8
11:00 AM jepler: rene_dev_: to download the .zip, click the "document" (dog eared paper) icon
11:01 AM jepler: rene_dev_: clicking the "(i)" icon for the zip file gives me that message
11:06 AM rene_dev_: ah :D thanks :)
11:06 AM jepler: rene_dev_: I could change the text to say "no preview available" but then it would just get replaced when I upgrade joomla
11:07 AM jepler: which reminds me to check for updates
11:08 AM jepler: apache package update, standby for probably-unnecessary forum reboot...
11:09 AM jepler: hm this message is worrying
11:09 AM jepler: Setting up grub-pc (2.02-2ubuntu8.4) ...
11:09 AM jepler: Installing for i386-pc platform.
11:09 AM jepler: grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
11:09 AM jepler: grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
11:10 AM jepler: [rebooted fine though]
11:15 AM Jin^eLD: btw anyone ever played around with embedded platforms like imx or similar? I am not sure about the rt support there, I am a bit too far from lowlevel kernel things, but they are pretty good in terms of processing power and linux runs fine there
11:16 AM Jin^eLD: I was mostly thinking if it would be worth it to come up with a LinuxCNC recipe for Yocto/OpenEmbedded
11:17 AM seb_kuzminsky: i've occasionally daydreamed about a linuxcnc ipkg for openwrt...
11:18 AM jepler: LinuxCNC is more or less resistant to cross-compilation. Again, patches welcome.
11:18 AM Jin^eLD: and where did those daydreams lead you? I assume the real hard dependency is RT support, all userspace stuff should probably be easily portable?
11:19 AM Jin^eLD: jepler: what's the main obstacle, i.e. what does it use that makes problems in a cross env?
11:19 AM Jin^eLD: i.e. stuff that you are at least awqare of, would be interesting to hear
11:19 AM jepler: Jin^eLD: laziness, mostly
11:19 AM Jin^eLD: lol :)
11:20 AM Jin^eLD: so no x86 assembly code or weirdo build system or whatever? :)
11:20 AM jepler: oh it's perfectly portable to ARM
11:20 AM jepler: the build system is just configure+make
11:20 AM Jin^eLD: autoconf? thats good
11:21 AM jepler: right
11:21 AM * Jin^eLD hates cmake
11:21 AM jepler: it all needs a good reaming for freshness
11:22 AM Jin^eLD: I might give it a try to see how far it goes in Yocto in the current state, but that's something for the time after I finish my comp
11:24 AM Jin^eLD: but I'm not a kernel hacker so not sure about RT stuff; if it would work it'd be pretty cool to have an OE recipe though, opens up tons of hardware choices
11:24 AM pcw_home: I had ~zero problems compiling LinuxCNC on a RPI
11:25 AM Jin^eLD: pcw_home: but you did a native build I assume, not cross?
11:25 AM pcw_home: native
11:25 AM Jin^eLD: although if you say it went fine, then I'd only expect problems in the autoconf part which can be fixed rather easily
11:25 AM pcw_home: cross building LinuxCNC is probably silly (though cross building a kernel may make sense)
11:26 AM Jin^eLD: pcw_home: I disagree, cross building anything is not silly at all; you can spit out bootable images in any combination for any hardware supported by yocto
11:26 AM pcw_home: even on a RPI compiling LinuxCNC just a few minutes (where a kernel wouls be many hours)
11:27 AM Jin^eLD: RPI runs a stock distro, like debian or whatever, so you can easily download the native toolchain
11:27 AM Jin^eLD: that's not usually the case on the majority of embedded hardware that is out there
11:28 AM Jin^eLD: surprised about the few minutes though, I think it took me a while to compile it on my notebook here :) well, its not the newest one but I'd still expect it not to be slower than an rpi...
11:30 AM pcw_home: I cant remember exactly might have been 10-20 minutes or so a kernel can take 8 hours...
11:31 AM pcw_home: getting all LinuxCNC dependencies satisfied on random hardware may or may not be worth it (especially if you want a local GUI)
11:32 AM Jin^eLD: GUI might indeed be a problem, thats true, at least I dont have any boxes with a display around
11:32 AM pcw_home: most of the RPI clones dont have accelerated OpenGL support so you get dreadfully slow gremlin backplots and 100% CPU
11:32 AM Jin^eLD: but that's the cool thing about OE - it has tons of recipes for almost everything
11:33 AM Jin^eLD: meaning that most deps will most likely be already ported
11:33 AM pcw_home: even the RPIs hardware Opengl support is flaky
11:34 AM Jin^eLD: to be honest I never checked which of the embedded boxes have opengl that is there and that is supported
11:35 AM Jin^eLD: so far I worked only with headless stuff, we have a "server" application at work so our hardware does not have an LCD
11:35 AM pcw_home: most have OpenGL ES very few have hardware OpenGL support (you can probably get it with Android...)
11:36 AM Jin^eLD: does LinuxCNC make sense in headless mode?
11:36 AM Jin^eLD: or is there no use case for something like that?
11:36 AM pcw_home: There are some attempts to do this (RockHopper?)
11:37 AM Jin^eLD: what would the scenario be? upload and execute g-code?
11:37 AM Jin^eLD: i.e. so its just used as a pure controller for some machine?
11:38 AM pcw_home: Yeah GUI on Whatever (android, Windows, Linux) and RT/Machine control on embedded system
11:40 AM pcw_home: I think Machinekit is more focused on this architecture (but who knows if Machinekit is viable it seems stalled)
11:41 AM Jin^eLD: machinekit is a linuxcnc fork? I saw it in google results but somehow did not get what it was
11:42 AM pcw_home: Other issue with lots of Arm SOC systems is the they require hardware specific patches that have not been mainlined may be proprietary etc which makes building a RT kernel problematic on many
11:42 AM Jin^eLD: if hal had an option to forward some stuff (thinking input/output pins for UIs where timing is not critical), that'd probably be a possibility to connect remote UIs?
11:42 AM pcw_home: Yes Machinekit is a fork of LinuxCNC
11:43 AM Jin^eLD: well, OE/Yocto have support for tons of hardware and they do not use any proprietary code, but indeed the question is if there is any RT support, I'll need to ask the Yocto people about that
11:54 AM Jin^eLD: I see there is a meta-reailtime layer in Yocto, so some work is being done
12:50 PM seb_kuzminsky: Jin^eLD: "lead me"? haha nowhere
12:52 PM Jin^eLD: seb_kuzminsky: lol :) well I thought you may have done something beyond daydreaming, some investigation if its doable etc :)
12:53 PM Jin^eLD: but indeed from what I see the biggest blocker is probably getting RT support
12:58 PM pcw_mesa: Also RT support of interface hardware this likely needs to be hand done per SOC type
01:03 PM Jin^eLD: oh true.. the interfaces
01:17 PM pcw_mesa: Thinks like SPI need to be hand wriitten unless the driver is patched by the Preempt-RT people which is unlikely on oddball hardware
01:17 PM Jin^eLD: seb_kuzminsky: sounds like embedded will stay a daydream for a while :P
01:18 PM Jin^eLD: I could have helped with a Yocto recipe/cross compile, but hardware and drivers - not my battlefield
01:18 PM pcw_mesa: It depends on whether someone needs it and takes an interest
01:20 PM pcw_mesa: If the cross compile stuff makes more platforms accessible, thats a good thing
01:20 PM Jin^eLD: well, the use case would be to have really cheap small boxes that are capable of driving your machine which is kind of cool, if it all was userspace this goal would be more or less easy to achieve as a lot of this hardware has a pretty good overall linux support
01:20 PM Jin^eLD: but the RT stuff and hand-writing/tuning drivers per platform is a killer
01:21 PM Jin^eLD: well, what does it help to have it accessible on a platform where it can not run in RT mode?
01:22 PM pcw_mesa: It allows people to add the RT driver stuff that would have not even bothered before because of the overhead involved
01:23 PM Jin^eLD: hmm, so it would still be worth the effort?
01:23 PM Jin^eLD: ok
01:27 PM pcw_mesa: Well the guy the wrote the RPI SPI driver pretty much nailed it so if you look at is as a LinuxCNC driver issue its not so bad as long as you can get a RT kernel running
01:28 PM Jin^eLD: well that RT thing seems to be a story of its own as well..
01:30 PM pcw_mesa: its really a question of getting the SOCs kernel patches mainlined so the RT patches work without going through pain&suffering
01:31 PM Jin^eLD: yes, that'd be the goal of course
01:33 PM pcw_mesa: I know this is the goal of some of the ARM dev board makers but not sure how close it is to reality
01:33 PM pcw_mesa: not true and may never be true with RPI but people have worked around it to make RT kernel
01:35 PM Jin^eLD: to be honest I never did much with RPI, I think I have an RPI1 somewhere because I got it at some point for some project, but apart from that I never really used it
01:35 PM Jin^eLD: the more or less decent boxes are freescale imx based/armv7
01:37 PM seb_kuzminsky: my "hostmot2 firmware on the beagelebone black PRU" project is slightly farther than the daydream stage
01:37 PM seb_kuzminsky: i've turned steppers with it
01:37 PM seb_kuzminsky: uhh where did i put it?
01:37 PM Jin^eLD: actually I see there is an rt version for the hardware I have here, linux-fslc-imx-rt_4.1-2.0.x.bb
01:38 PM seb_kuzminsky: https://github.com/SebKuzminsky/hostmot2-firmware-beaglebone
01:38 PM Jin^eLD: SUMMARY = "Realtime version of the FSL Community BSP i.MX6 Linux kernel with backported features and fixes"
01:38 PM Jin^eLD: so that would probably be the hw to look at
01:39 PM Jin^eLD: seb_kuzminsky: I need to google up hostmot2 first, not familiar with it :)
01:39 PM seb_kuzminsky: it's pcw_mesa's awesome fpga motion control firmware
01:39 PM Jin^eLD: ah, thats this card that drivers the machines via linuxcnc
01:39 PM seb_kuzminsky: it's probably the most common interface hardware for driving machines with linuxcnc,yeah
01:40 PM Jin^eLD: what hw interface does it have, i.e. how would you connect it to some embedded box?
01:41 PM pcw_mesa: it has 5 different interfaces: PCI, Parallel EPP, SPI, Ethernet and Serial
01:41 PM seb_kuzminsky: Jin^eLD: by "it" you mean pcw_mesa 's hostmot2 fpgas?
01:41 PM Jin^eLD: yes, the mesa to your "computer" so to speak
01:42 PM Jin^eLD: pcw_mesa answered that :L)
01:42 PM Jin^eLD: those embedded boxes usually have serial, all of them have ethernet, a lot will proabbly have spi as well
01:42 PM Jin^eLD: but does ethernet play along with rt??
01:43 PM pcw_mesa: Yeah with Preempt-RT (Maybe EtherCAT works with RTAI also not sure)
01:43 PM Jin^eLD: interesting, so that would indeed be a usable option
01:52 PM rene_dev_: seb_kuzminsky Interesting, as you might know I also have a working hostmot version written in c, woring on the stm32
01:54 PM seb_kuzminsky: rene_dev_: i did not know that, but that's very interesting! got a link?
01:55 PM rene_dev_: its currently in a private git repo
01:56 PM rene_dev_: supports ethernet transport. implemented modules are currently io, stepgen, pwm, watchdog and smart serial, but the smart serial is still very expreimental and has a few issues
01:59 PM rene_dev_: still working on encoder support
02:00 PM rene_dev_: I will opensource it once its complete
02:00 PM seb_kuzminsky: cool
02:25 PM Jin^eLD: do the build scripts support out of tree builds, does not look like it, right?
02:47 PM Jin^eLD: hmm no option to build without tcl/tk? trying first cross build with a minimum configuration
03:14 PM Jin^eLD: ok so seems I will have to look into the tcl part in configure first, finding tcl does not seem to work out of the box in a cross env
04:20 PM jepler: that (optionally removing any particular dependency such as tcl/tk or python) at compile time sounds like a great candidate for an initial PR
04:21 PM jepler: pretty sure you'll find out that python is required by configure too, despite it tricking you into thinking otherwise based on --help
04:21 PM jepler: (it worked once but bitrotted, if not before then when we took in the patches to make the interpreter python-extensible)
04:29 PM Jin^eLD: well, python in OE is not really an issue
04:30 PM Jin^eLD: tcl uses this tclConfig.sh which is supposed to be sourced, I saw that OE does install it, but something still did not work out, linuxcnc configure script was saying it can't find it even tough I pointed it to the right location
04:31 PM Jin^eLD: I never worked with tcl before so not quite familiar, would have to see how other OE packages handle that and if something special there is required, surely doable
04:31 PM Jin^eLD: but yeah, making it optional in configure would be a starting point
04:32 PM Jin^eLD: what is tclConfig.sh anyway, aren't most modern distros now using pkg-config?
04:33 PM Jin^eLD: I see that distros still do package tclConfig.sh, looks quite odd though
04:36 PM mozmck: tcl is simply odd :-)
04:38 PM Jin^eLD: that is what I was thinking but did not want to say out loud :)
04:39 PM Jin^eLD: and for as long as I remember it, starting from 1998 (probably first time I saw it) - it looked ugly and it still does look ugly :)
04:41 PM mozmck: yeah, but it's there and it works. If I had time I would be interested in optionally replacing both tcl and python (bloated and slow) with something like lua.
04:42 PM Jin^eLD: I was not aware that there are comparable lua UI frameworks?
04:42 PM mozmck: That would probably help things on some of the ARM computers and other embedded platforms.
04:42 PM Jin^eLD: lua might be smaller and slicker than python, but imho python is much more widespread and much easier to use, especially given the huge amount of modules
04:43 PM Jin^eLD: and the embedded platforms are actually small PCs these days
04:43 PM Jin^eLD: so I think running python is not a big issue
04:43 PM Jin^eLD: I mean, that armv7/imx one I have here is a quadcore
04:43 PM mozmck: Yeah, probably not a problem overall
04:44 PM mozmck: I know there are lua binding for some gui toolkits - wx for one.
04:44 PM Jin^eLD: and as you said, its there and it works, building up the pyvcp UI via xml was quite easy; yes, looks terrible :) but it does the job and thats all I needed, at least for the simulation UI
04:44 PM Jin^eLD: for a nicer look people can always invest some time in glade/gtk which is also supported
04:45 PM mozmck: I'm more of a C/C++ guy myself, but some sort of scripting for HAL files is quite useful.
04:45 PM Jin^eLD: same here, although I dislike C++ and hate the so called "modern C++", like 11 and later
04:46 PM Jin^eLD: I'm more into C
04:46 PM mozmck: I haven't used pyvcp much - gladevcp is pretty nice and you can build gui files with glade.
04:46 PM Jin^eLD: but of course python is a handy tool if you need something quickly
04:46 PM Jin^eLD: I did play around with glade back in the day and it is indeed cool with the editor and callbacks and so on, but for my task it would have been overkill
04:46 PM Jin^eLD: I needed the UI only to be able to test my component
04:47 PM mozmck: I like C++ for a lot of things. Modern C++ has features which are nice and are already in python - lambda functions etc.
04:47 PM Jin^eLD: I wrote two components, one that simulates the machine and the other one that controls it (the "real" one so to speak)
04:47 PM mozmck: Nice.
04:48 PM Jin^eLD: my problem with C++ is that it tries to be able to do absolutely everything, but if you look at it closely - you don't need 90% of the academic-theoretical-mind-twisted stuff
04:48 PM Jin^eLD: a lot of things can be implemented in a much easier and simplier way, which makes the code better readable and better maintainable
04:48 PM mozmck: It's easy to not use the parts you don't need :-) I have used it in one bare-metal arm project and it works well there.
04:48 PM Jin^eLD: the die-hard C++ guys tend to forget about that and you end up with code that is complicated for the only sake of being complicated and I just see no sense in that :)
04:49 PM mozmck: I find it much harder to read and use object-oriented C code such as is done in gtk+, when they could have done it much more simply in C++, but oh well.
04:50 PM Jin^eLD: gtk oop is a topic of its own ;)
04:50 PM Jin^eLD: although I did not have problems with it when I coded some gtk stuff
04:50 PM mozmck: I don't tend to use a lot of the features that are harder to read and understand. Templates are nice for library stuff, but can be a *pain* to debug or parse the error output.
04:51 PM Jin^eLD: templates are hell :)
04:51 PM Jin^eLD: linux kernel is actually a perfect example that clean and modular code can be done in pure C
04:52 PM Jin^eLD: I won't deny that C++ has its benefits
04:52 PM Jin^eLD: shared pointers, stl containers, strings are handy
04:52 PM mozmck: yes, kernel code seems really good for all I've looked at.
04:52 PM Jin^eLD: but somehow each c++ project I was in ended up escalating into some pile of "we'll do it like that because we can" direction
04:53 PM mozmck: spaghetti++
04:53 PM Jin^eLD: I mean, we had that guy at work who wrapped a simple library in C++ and then he needed about an hour to explain why he did stuff the way he did with double apersands and some move directives and what not, with some features not even being in C++14
04:54 PM Jin^eLD: and I was like - wtf?! what is the damn point of it if you can just take the perfectly working C library where you do not have to come up with work arounds to prevent too copying of data etc
04:54 PM Jin^eLD: *too much copying
04:55 PM Jin^eLD: and you always have at least one C++11/14/27/666 fanatic around :)
04:56 PM Jin^eLD: which at some point leads to a complete mess, and its easy to get into a big mess with C++ if you are not careful and try to use every new feature the language offers
04:56 PM mozmck: I guess so. I have lightly used some features of C++11 such as 'auto' in particular - that one is quite nice in iterators especially.
04:56 PM Jin^eLD: oh well, I'll shut up, its a topic that has hit a nerve ;)
04:56 PM mozmck: heh! I see some of the same thing in some python code I've looked at!
04:56 PM Jin^eLD: :)
04:57 PM Jin^eLD: I guess I have never been in a "python project" :) only used it as a helper for myself
04:57 PM Jin^eLD: but yeah, I remember looking at the twisted python libraries
04:57 PM mozmck: Same here. But I've read a bit of the code in some projects.
04:57 PM Jin^eLD: and as the name says... they indeed were twisted
04:58 PM Jin^eLD: not sure if thats still around though, it was a bigger framework with webservers and what not
04:59 PM Jin^eLD: I think they tried to provide pretty much everything, but had a totally weird and... well, twisted and complicated API :)
04:59 PM mozmck: Maybe they were trying to get more speed out of python
05:00 PM Jin^eLD: could be, but I remember I gave up trying to understand how it works back then :)
06:04 PM Jin^eLD: nite
06:04 PM Jin^eLD is now known as Jin|away