#linuxcnc-devel | Logs for 2018-09-07
Back
[01:03:23] -!- c-log has quit [Ping timeout: 245 seconds]
[01:12:16] -!- c-log has joined #linuxcnc-devel
[01:20:11] -!- ve7it has quit [Remote host closed the connection]
[03:40:00] -!- Robh__ has joined #linuxcnc-devel
[03:45:23] Jin|away is now known as Jin^eLD
[03:47:36] -!- c-log has quit [Ping timeout: 244 seconds]
[03:49:01] -!- c-log has joined #linuxcnc-devel
[06:28:48] -!- Robh__ has quit [Ping timeout: 244 seconds]
[07:09:07] -!- JT-Shop has quit [Read error: Connection reset by peer]
[07:09:44] -!- JT-Shop has joined #linuxcnc-devel
[07:53:57] -!- Robh__ has joined #linuxcnc-devel
[08:49:45] -!- selroc has joined #linuxcnc-devel
[08:50:10] -!- selroc has quit [Client Quit]
[09:18:09] -!- Robh__ has quit [Ping timeout: 252 seconds]
[09:49:01] <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:17:37] -!- JT-Shop has quit [Quit: Leaving]
[10:18:00] -!- JT-Shop has joined #linuxcnc-devel
[11:02:33] -!- Roguish has joined #linuxcnc-devel
[11:46:28] <seb_kuzminsky> jthornton: looks like we don't track the version of boost needed: http://wiki.linuxcnc.org
[11:46:55] <seb_kuzminsky> but i know that 2.7 builds on wheezy, which surely has an older version of boost
[11:47:13] <seb_kuzminsky> oh, and lucid
[11:49:35] <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.
[11:49:41] <jepler> you should always match the deb to the right os
[11:50:07] <jepler> linux mint is not debian, so it's just pure luck if any debian particular package manages to install there
[11:51:08] <seb_kuzminsky> i agree in general, but aren't some mints debian?
[11:51:31] <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")
[11:51:49] <jepler> so we always select whatever the default boost version is on whatever OS we're building a .deb-format package on.
[11:52:03] <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
[11:52:49] <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
[11:53:14] <Jin^eLD> I think the problem is getting a maintainer for it, afaik thats how it works
[11:53:36] <Jin^eLD> that is if you dont want to go the effort yourselves
[11:53:37] <JT-Shop> seb_kuzminsky: something is odd then
[11:54:05] <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
[11:54:14] <Jin^eLD> would not want to do that myself either
[11:55:11] <rene_dev_> jepler looks like I cant download attachments from the forum
[11:55:12] <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
[11:55:29] <rene_dev_> requested content cannot be loaded, please try again later
[11:56:46] <Jin^eLD> seb_kuzminsky: ok that explains the rpm absence then :)
[11:56:56] <JT-Shop> oh ok I should use precise... slaps his head
[11:56:59] <jepler> rene_dev_: investigating
[11:57:27] <rene_dev_> trying this post
[11:57:27] <rene_dev_> https://forum.linuxcnc.org
[11:57:35] <rene_dev_> same here: https://forum.linuxcnc.org
[11:57:44] <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
[11:57:49] <jepler> rene_dev_: odd, I can see the image and download LatheMacro-3.zip
[11:57:51] <jepler> rene_dev_: let me go look at the logs
[11:58:32] <rene_dev_> https://imgur.com
[12:00:15] <jepler> rene_dev_: to download the .zip, click the "document" (dog eared paper) icon
[12:00:35] <jepler> rene_dev_: clicking the "(i)" icon for the zip file gives me that message
[12:05:43] <rene_dev_> ah :D thanks :)
[12:06:10] <jepler> rene_dev_: I could change the text to say "no preview available" but then it would just get replaced when I upgrade joomla
[12:06:42] <jepler> which reminds me to check for updates
[12:08:19] <jepler> apache package update, standby for probably-unnecessary forum reboot...
[12:09:01] <jepler> hm this message is worrying
[12:09:02] <jepler> Setting up grub-pc (2.02-2ubuntu8.4) ...
[12:09:02] <jepler> Installing for i386-pc platform.
[12:09:02] <jepler> grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
[12:09:05] <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..
[12:10:05] <jepler> [rebooted fine though]
[12:15:01] <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
[12:16:08] <Jin^eLD> I was mostly thinking if it would be worth it to come up with a LinuxCNC recipe for Yocto/OpenEmbedded
[12:16:57] <seb_kuzminsky> i've occasionally daydreamed about a linuxcnc ipkg for openwrt...
[12:17:53] <jepler> LinuxCNC is more or less resistant to cross-compilation. Again, patches welcome.
[12:17:55] <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?
[12:18:27] <Jin^eLD> jepler: what's the main obstacle, i.e. what does it use that makes problems in a cross env?
[12:18:58] <Jin^eLD> i.e. stuff that you are at least awqare of, would be interesting to hear
[12:19:06] <jepler> Jin^eLD: laziness, mostly
[12:19:11] <Jin^eLD> lol :)
[12:19:33] <Jin^eLD> so no x86 assembly code or weirdo build system or whatever? :)
[12:19:42] <jepler> oh it's perfectly portable to ARM
[12:20:03] <jepler> the build system is just configure+make
[12:20:19] <Jin^eLD> autoconf? thats good
[12:20:23] <jepler> right
[12:20:26] * Jin^eLD hates cmake
[12:20:29] <jepler> it all needs a good reaming for freshness
[12:22:07] <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
[12:23:45] <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
[12:24:04] <pcw_home> I had ~zero problems compiling LinuxCNC on a RPI
[12:24:26] <Jin^eLD> pcw_home: but you did a native build I assume, not cross?
[12:24:32] <pcw_home> native
[12:25:06] <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
[12:25:13] <pcw_home> cross building LinuxCNC is probably silly (though cross building a kernel may make sense)
[12:26:02] <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
[12:26:09] <pcw_home> even on a RPI compiling LinuxCNC just a few minutes (where a kernel wouls be many hours)
[12:26:40] <Jin^eLD> RPI runs a stock distro, like debian or whatever, so you can easily download the native toolchain
[12:26:53] <Jin^eLD> that's not usually the case on the majority of embedded hardware that is out there
[12:27:59] <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...
[12:29:32] <pcw_home> I cant remember exactly might have been 10-20 minutes or so a kernel can take 8 hours...
[12:30:40] <pcw_home> getting all LinuxCNC dependencies satisfied on random hardware may or may not be worth it (especially if you want a local GUI)
[12:32:00] <Jin^eLD> GUI might indeed be a problem, thats true, at least I dont have any boxes with a display around
[12:32:11] <pcw_home> most of the RPI clones dont have accelerated OpenGL support so you get dreadfully slow gremlin backplots and 100% CPU
[12:32:15] <Jin^eLD> but that's the cool thing about OE - it has tons of recipes for almost everything
[12:32:33] <Jin^eLD> meaning that most deps will most likely be already ported
[12:33:10] <pcw_home> even the RPIs hardware Opengl support is flaky
[12:33:56] <Jin^eLD> to be honest I never checked which of the embedded boxes have opengl that is there and that is supported
[12:34:26] <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
[12:35:08] <pcw_home> most have OpenGL ES very few have hardware OpenGL support (you can probably get it with Android...)
[12:35:42] <Jin^eLD> does LinuxCNC make sense in headless mode?
[12:35:56] <Jin^eLD> or is there no use case for something like that?
[12:36:18] <pcw_home> There are some attempts to do this (RockHopper?)
[12:36:45] <Jin^eLD> what would the scenario be? upload and execute g-code?
[12:36:58] <Jin^eLD> i.e. so its just used as a pure controller for some machine?
[12:38:11] <pcw_home> Yeah GUI on Whatever (android, Windows, Linux) and RT/Machine control on embedded system
[12:39:40] <pcw_home> I think Machinekit is more focused on this architecture (but who knows if Machinekit is viable it seems stalled)
[12:40:51] <Jin^eLD> machinekit is a linuxcnc fork? I saw it in google results but somehow did not get what it was
[12:41:33] <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
[12:41:52] <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?
[12:42:01] <pcw_home> Yes Machinekit is a fork of LinuxCNC
[12:42:49] <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
[12:54:13] <Jin^eLD> I see there is a meta-reailtime layer in Yocto, so some work is being done
[13:49:45] <seb_kuzminsky> Jin^eLD: "lead me"? haha nowhere
[13:52:07] <Jin^eLD> seb_kuzminsky: lol :) well I thought you may have done something beyond daydreaming, some investigation if its doable etc :)
[13:52:38] <Jin^eLD> but indeed from what I see the biggest blocker is probably getting RT support
[13:57:23] <pcw_mesa> Also RT support of interface hardware this likely needs to be hand done per SOC type
[14:02:33] <Jin^eLD> oh true.. the interfaces
[14:06:16] -!- Robh__ has joined #linuxcnc-devel
[14:16:27] <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
[14:16:58] <Jin^eLD> seb_kuzminsky: sounds like embedded will stay a daydream for a while :P
[14:17:30] <Jin^eLD> I could have helped with a Yocto recipe/cross compile, but hardware and drivers - not my battlefield
[14:18:13] <pcw_mesa> It depends on whether someone needs it and takes an interest
[14:19:25] <pcw_mesa> If the cross compile stuff makes more platforms accessible, thats a good thing
[14:19:51] <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
[14:20:12] <Jin^eLD> but the RT stuff and hand-writing/tuning drivers per platform is a killer
[14:20:37] <Jin^eLD> well, what does it help to have it accessible on a platform where it can not run in RT mode?
[14:22:15] <pcw_mesa> It allows people to add the RT driver stuff that would have not even bothered before because of the overhead involved
[14:22:38] <Jin^eLD> hmm, so it would still be worth the effort?
[14:22:42] <Jin^eLD> ok
[14:26:29] <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
[14:27:42] <Jin^eLD> well that RT thing seems to be a story of its own as well..
[14:29:52] <pcw_mesa> its really a question of getting the SOCs kernel patches mainlined so the RT patches work without going through pain&suffering
[14:31:13] <Jin^eLD> yes, that'd be the goal of course
[14:32:29] <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
[14:33:06] <pcw_mesa> not true and may never be true with RPI but people have worked around it to make RT kernel
[14:34:29] <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
[14:35:11] <Jin^eLD> the more or less decent boxes are freescale imx based/armv7
[14:36:31] <seb_kuzminsky> my "hostmot2 firmware on the beagelebone black PRU" project is slightly farther than the daydream stage
[14:36:41] <seb_kuzminsky> i've turned steppers with it
[14:37:08] <seb_kuzminsky> uhh where did i put it?
[14:37:20] <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
[14:37:25] <seb_kuzminsky> https://github.com
[14:37:36] <Jin^eLD> SUMMARY = "Realtime version of the FSL Community BSP i.MX6 Linux kernel with backported features and fixes"
[14:37:56] <Jin^eLD> so that would probably be the hw to look at
[14:38:34] <Jin^eLD> seb_kuzminsky: I need to google up hostmot2 first, not familiar with it :)
[14:38:46] <seb_kuzminsky> it's pcw_mesa's awesome fpga motion control firmware
[14:38:50] <Jin^eLD> ah, thats this card that drivers the machines via linuxcnc
[14:39:11] <seb_kuzminsky> it's probably the most common interface hardware for driving machines with linuxcnc,yeah
[14:39:38] <Jin^eLD> what hw interface does it have, i.e. how would you connect it to some embedded box?
[14:40:44] <pcw_mesa> it has 5 different interfaces: PCI, Parallel EPP, SPI, Ethernet and Serial
[14:41:02] <seb_kuzminsky> Jin^eLD: by "it" you mean pcw_mesa 's hostmot2 fpgas?
[14:41:17] <Jin^eLD> yes, the mesa to your "computer" so to speak
[14:41:27] <Jin^eLD> pcw_mesa answered that :L)
[14:41:56] <Jin^eLD> those embedded boxes usually have serial, all of them have ethernet, a lot will proabbly have spi as well
[14:42:02] <Jin^eLD> but does ethernet play along with rt??
[14:42:43] <pcw_mesa> Yeah with Preempt-RT (Maybe EtherCAT works with RTAI also not sure)
[14:42:57] <Jin^eLD> interesting, so that would indeed be a usable option
[14:51:54] <rene_dev_> seb_kuzminsky Interesting, as you might know I also have a working hostmot version written in c, woring on the stm32
[14:54:22] <seb_kuzminsky> rene_dev_: i did not know that, but that's very interesting! got a link?
[14:55:10] <rene_dev_> its currently in a private git repo
[14:56:15] <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
[14:59:06] <rene_dev_> still working on encoder support
[14:59:37] <rene_dev_> I will opensource it once its complete
[14:59:55] <seb_kuzminsky> cool
[15:25:09] <Jin^eLD> do the build scripts support out of tree builds, does not look like it, right?
[15:38:18] -!- ve7it has joined #linuxcnc-devel
[15:46:24] <Jin^eLD> hmm no option to build without tcl/tk? trying first cross build with a minimum configuration
[16:13:23] <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
[17:20:07] <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
[17:20:23] <jepler> pretty sure you'll find out that python is required by configure too, despite it tricking you into thinking otherwise based on --help
[17:20:47] <jepler> (it worked once but bitrotted, if not before then when we took in the patches to make the interpreter python-extensible)
[17:29:11] <Jin^eLD> well, python in OE is not really an issue
[17:29:51] <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
[17:30:27] <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
[17:30:57] <Jin^eLD> but yeah, making it optional in configure would be a starting point
[17:31:38] <Jin^eLD> what is tclConfig.sh anyway, aren't most modern distros now using pkg-config?
[17:32:34] <Jin^eLD> I see that distros still do package tclConfig.sh, looks quite odd though
[17:36:21] <mozmck> tcl is simply odd :-)
[17:38:03] <Jin^eLD> that is what I was thinking but did not want to say out loud :)
[17:38:34] <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 :)
[17:41:09] <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.
[17:41:43] <Jin^eLD> I was not aware that there are comparable lua UI frameworks?
[17:41:49] <mozmck> That would probably help things on some of the ARM computers and other embedded platforms.
[17:42:09] <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
[17:42:37] <Jin^eLD> and the embedded platforms are actually small PCs these days
[17:42:45] <Jin^eLD> so I think running python is not a big issue
[17:42:57] <Jin^eLD> I mean, that armv7/imx one I have here is a quadcore
[17:42:58] <mozmck> Yeah, probably not a problem overall
[17:43:23] <mozmck> I know there are lua binding for some gui toolkits - wx for one.
[17:43:55] <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
[17:44:16] <Jin^eLD> for a nicer look people can always invest some time in glade/gtk which is also supported
[17:44:24] <mozmck> I'm more of a C/C++ guy myself, but some sort of scripting for HAL files is quite useful.
[17:45:21] <Jin^eLD> same here, although I dislike C++ and hate the so called "modern C++", like 11 and later
[17:45:25] <Jin^eLD> I'm more into C
[17:45:36] <mozmck> I haven't used pyvcp much - gladevcp is pretty nice and you can build gui files with glade.
[17:45:37] <Jin^eLD> but of course python is a handy tool if you need something quickly
[17:46:11] <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
[17:46:18] <Jin^eLD> I needed the UI only to be able to test my component
[17:46:23] <mozmck> I like C++ for a lot of things. Modern C++ has features which are nice and are already in python - lambda functions etc.
[17:46:43] <Jin^eLD> I wrote two components, one that simulates the machine and the other one that controls it (the "real" one so to speak)
[17:46:59] <mozmck> Nice.
[17:47:23] <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
[17:47:46] <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
[17:48:01] <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.
[17:48:16] <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 :)
[17:49:05] <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.
[17:49:35] <Jin^eLD> gtk oop is a topic of its own ;)
[17:49:50] <Jin^eLD> although I did not have problems with it when I coded some gtk stuff
[17:50:12] <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.
[17:50:25] <Jin^eLD> templates are hell :)
[17:51:09] <Jin^eLD> linux kernel is actually a perfect example that clean and modular code can be done in pure C
[17:51:30] <Jin^eLD> I won't deny that C++ has its benefits
[17:51:49] <Jin^eLD> shared pointers, stl containers, strings are handy
[17:51:57] <mozmck> yes, kernel code seems really good for all I've looked at.
[17:52:15] <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
[17:52:47] <mozmck> spaghetti++
[17:53:02] <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
[17:53:48] <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
[17:54:02] <Jin^eLD> *too much copying
[17:54:31] <Jin^eLD> and you always have at least one C++11/14/27/666 fanatic around :)
[17:55:28] <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
[17:55:37] <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.
[17:55:39] <Jin^eLD> oh well, I'll shut up, its a topic that has hit a nerve ;)
[17:56:02] <mozmck> heh! I see some of the same thing in some python code I've looked at!
[17:56:11] <Jin^eLD> :)
[17:56:28] <Jin^eLD> I guess I have never been in a "python project" :) only used it as a helper for myself
[17:56:52] <Jin^eLD> but yeah, I remember looking at the twisted python libraries
[17:56:54] <mozmck> Same here. But I've read a bit of the code in some projects.
[17:56:59] <Jin^eLD> and as the name says... they indeed were twisted
[17:58:06] <Jin^eLD> not sure if thats still around though, it was a bigger framework with webservers and what not
[17:58:26] <Jin^eLD> I think they tried to provide pretty much everything, but had a totally weird and... well, twisted and complicated API :)
[17:59:07] <mozmck> Maybe they were trying to get more speed out of python
[17:59:31] <Jin^eLD> could be, but I remember I gave up trying to understand how it works back then :)
[18:59:13] -!- Tom_itx has joined #linuxcnc-devel
[18:59:13] -!- Tom_itx has quit [Changing host]
[18:59:13] -!- Tom_itx has joined #linuxcnc-devel
[19:01:14] -!- Tom_itx has quit [Client Quit]
[19:04:10] <Jin^eLD> nite
[19:04:17] Jin^eLD is now known as Jin|away
[19:58:44] -!- JT-Shop has quit [Read error: Connection reset by peer]
[20:01:27] -!- jthornton has quit [Ping timeout: 252 seconds]
[20:11:27] -!- jthornton has joined #linuxcnc-devel
[20:12:59] -!- JT-Shop has joined #linuxcnc-devel
[20:42:54] -!- Robh__ has quit [Ping timeout: 252 seconds]