Back
[03:57:08] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_2 ae8a52e 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into gmoccapy_2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ae8a52e
[03:57:08] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_2 59d8285 06linuxcnc 10configs/sim/gmoccapy/gmoccapy.ini 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_2_0_2 - added command line arguments * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=59d8285
[03:58:45] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_2 da3079c 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into gmoccapy_2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=da3079c
[06:18:35] <tinkerer> Hi fellows, was the emc-users couch moved to the devel list?
[07:50:56] <skunkworks_> zlog
[07:53:55] <mozmck> andy is spoiling the fun
[07:54:01] <mozmck> https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/30096-dead-in-the-water-on-7i92-config?start=20#69474
[08:08:51] <archivist> https://xkcd.com/386/
[09:02:19] <skunkworks_> it also looks like we have to revisit 'I have an idea - lets move realtime to external hardware' every few months.'
[09:05:26] <cradek> but but but we already have a very smart division with the various fpga cards
[09:05:54] <seb_kuzminsky> maybe what people want is to run the guis on separate hardware, not the realtime code
[09:06:18] <skunkworks_> sure. but this idea of trying to find hardware that works with our 2 realtime kernels is super hard.
[09:06:32] * skunkworks_ is being sarcastic...
[09:07:20] <cradek> it really seems to me that whatever I try always works
[09:07:21] <seb_kuzminsky> it's only hard if you dont have years and years of experience building PCs
[09:07:43] <skunkworks_> heh
[09:08:12] <cradek> you may be right. it's often hard for me to put my head inside others' heads.
[09:09:14] <cradek> I think sometimes people fall in love with a certain piece of hardware, like a raspberry, and want to use that no matter what, even if it's not the simplest/cheapest/best way to solve a problem at hand
[09:09:53] <cradek> then using that particular hardware becomes the problem they want to solve, losing sight of everything else, like machining
[09:10:28] <cradek> but that might just be me being ungenerous in some way, I can't tell
[09:12:28] <tinkerer> cradek: was your last pluto parport challenge crowned with success? ;)
[09:12:35] <seb_kuzminsky> cradek: i think you're right, i think people behave that way sometimes
[09:13:10] <cradek> tinkerer: I plugged it back into the old working machine and stopped worrying about it. only built-in parallel ports ever work with it.
[09:13:13] <seb_kuzminsky> high hoe, high hoe, it's off to work i go
[09:13:31] <cradek> yeah and I should go get some coffee
[09:19:47] <tinkerer> ok, I tried to ask a question here about ARM progress in LCNC but so I should go back to mk...
[09:38:59] <skunkworks_> I know jepler has done a lot of work with getting arm working correctly... But that is about all I know.
[09:39:29] <jepler> we build on ARM, but we don't have any rpi or bb -specific drivers and we don't furnish any kernels for any ARM devices.
[09:39:51] <mozmck> tinkerer: linuxcnc runs on arm I'm pretty sure. Your question was only posted on the dev list half a day ago, and you only clarified it this morning.
[09:39:53] <jepler> we would not turn down properly-written drivers
[09:40:00] <mozmck> ah, there's jepler!
[09:40:40] <skunkworks_> Wheezy (uspace: realtime with RT-Preempt, and simulation)
[09:40:40] <skunkworks_> architectures: amd64, armhf, i386
[09:40:56] <skunkworks_> http://buildbot.linuxcnc.org/
[09:41:01] <cradek> skunkworks_: I looked at the same thing on buildbot, but I see no armhf packages
[09:41:11] <jepler> the reason machinekit has good arm support and we don't is because they never offered us their hardware drivers except in the "big ball of mud" that had accumulated in the branch that later became mk.
[09:41:41] <jepler> cradek:
http://buildbot.linuxcnc.org/dists/wheezy/2.7-rtpreempt/binary-armhf/
[09:41:53] <cradek> yes but it's empty
[09:41:56] <jepler> and by "good arm support" I suppose I mean that they have rpi and bb hardware drivers
[09:42:05] <jepler> is it? hm that's a surprise to me as well
[09:43:48] <jepler> I agree, your skills at detecting empty directories are on target
[09:44:16] <cradek> it's only one of my superpowers
[09:44:41] <jepler> on the buildbo grid, there's a rip-wheezy-armhf builder but not a armhf deb builder
[09:51:35] <tinkerer> mozmck: yes and the user guys trashed my thread...
[09:55:53] <skunkworks_> so - right now the only option is to pull it with git and build it?
[09:56:02] <skunkworks_> (no deb)
[09:56:45] <cradek> I think the answer is if you have a rt-preempt kernel you can build linuxcnc and run it
[09:56:59] <cradek> if I understood your question
[09:57:08] <skunkworks_> or a sim setup
[09:57:08] <cradek> I agree that thread went wild in a surprising way
[09:57:40] <cradek> skunkworks_: I understand it's about a hardware driver
[09:58:49] <tinkerer> and before starting a arm devel challenge I just wanted to ask
[09:59:50] <cradek> (?)
[10:00:50] <tinkerer> my driver
https://github.com/tinkercnc/spi-fpga-driver works with the mk-image from here
http://0ptr.link/files/RPi2-machinekit-1.0.img.bz2 very well.
[10:01:43] <tinkerer> cradek: shunkworks_ allready did it :)
[10:16:08] <cradek> (?)
[10:34:05] <skunkworks_> wow - I must be a crotchety old man but I don't ever want to run a machine cnc machine from a tablet. ( tinkerer - your work is cool - don't get me wrong )
[10:37:07] <skunkworks_> (good thing I am not a developer)
[10:38:37] <tinkerer> shunkworks_: ???
[11:59:51] <tinkerer> shunkworks_: i think there are too many idioms in. or sarcasm? please enlighten me.
[12:01:11] <tinkerer> cradek: he asked the question: "so - right now the only option is to pull it with git and build it?"
[12:06:57] <cradek> there aren't currently armhf packages built by buildbot, but we believe that the armhf platform works. you can build and try it.
[12:11:53] <tinkerer> and whats about cross compiling environment?
[12:13:08] <cradek> I don't know, please let us know what you find out
[12:15:54] <mozmck> skunkworks_: I think the people talking about tablets and all are mostly thinking about 3d printers and other desktop sized machines.
[12:18:44] <cradek> I certainly understand the desire for the controlling computer stuff to be smaller than the machine itself.
[12:18:55] <tinkerer> where? on the buildbot?
[12:19:14] <cradek> tinkerer: I don't understand
[12:20:18] <tinkerer> is there someone who has ever build a arm version?
[12:20:40] <cradek> yes!
[12:20:41] <mozmck> cradek: yes, but I bet skunkworks_ has truck and house sized machines in mind, and I would agree with him there for sure!
[12:22:44] <tinkerer> aha, and I should find out how he has done it?
[12:23:24] <cradek> wait a second
[12:23:40] <cradek> are you asking how to build linuxcnc on arm, or how to build linuxcnc at all? it is not different on arm.
[12:24:04] <cradek> I figured you had built linuxcnc lots of times
[12:24:24] <tinkerer> yes.
[12:24:33] <cradek> yes what?
[12:24:49] <tinkerer> (built linuxcnc lots of times)
[12:24:53] <tinkerer> but
[12:25:39] <tinkerer> cross building is different and difficult
[12:26:46] <cradek> yes, I don't know how to do that, so I wouldn't try to cross compile
[12:26:50] <tinkerer> are there env variables to choose the target arch aso...
[12:28:19] <cradek> setting up an environment for cross compiling is tricky, and I think it's not really even a linuxcnc-specific question
[12:28:26] <cradek> so don't cross compile, at least at first
[12:29:29] <tinkerer> yes, but if someone has already done it, then it would be very helpfully
[12:30:46] <tinkerer> reinventing already done things is boring
[14:37:00] <jepler> I think our build system needs work before cross building works. pull requests welcome.
[14:37:45] <jepler> I hold and run on an odroid u3 from time to time and out buildbot also builds (but apparently doesn't package) on an armhf system.
[14:38:40] <tinkerer> jepler: Hi jeff
[14:39:31] <tinkerer> packages are not necessary
[14:42:17] <tinkerer> but I would like avoid the time consuming part to find a running cross platform environment
[14:43:14] <tinkerer> hints welcome too :)
[14:45:51] <tinkerer> I've a odroid x and I'm curious about your work.
[14:46:18] <tinkerer> as I know, the u3 lacks spi
[15:03:12] <CaptHindsight> if you need to cross compile your arm board is too weeny :)
[15:05:30] <CaptHindsight> I started following the thread on the dev list about using a micro again
[15:06:18] <CaptHindsight> they start running in the same circles talking about irq's vs gpu for the gui
[15:06:42] <CaptHindsight> rather than spend a few $ on an FPGA
[15:07:34] <CaptHindsight> maybe I should put up a page on the wiki with the price vs performance
[15:14:35] <mozmck> That would probably be helpful!
[15:14:56] <tinkerer> CaptHindsight: yes please
[15:16:39] <KGB-linuxcnc> 03Norbert Schechner 052.6 17c396e 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_6_1 - dangerous bug in jogging with keyboard * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17c396e
[15:17:58] <KGB-linuxcnc> 03Norbert Schechner 052.7 545e46f 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=545e46f
[15:18:46] <KGB-linuxcnc> 03Norbert Schechner 05master 4336381 06linuxcnc Merge branch '2.7' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4336381
[16:20:30] <CaptHindsight> mozmck: what people are really complaining about is the cost of the FPGA board
[16:20:58] <CaptHindsight> but Peter offers far more than just hardware
[16:22:02] <mozmck> oh? looks like some are complaining that a PC can't do the job
[16:22:24] <mozmck> Yes, and his boards are reasonably priced too.
[16:22:35] <mozmck> fpga chips are expensive.
[16:26:00] <CaptHindsight> and micros can't do the job if you want a GUI
[16:27:24] <CaptHindsight> if TI had chosen a GPU with drivers and enough power to run a proper display then this would be another story
[16:28:08] <mozmck> Yes, so that is why they want to run a gui on a separate device.
[16:28:21] <CaptHindsight> like a PC :)
[16:28:45] <CaptHindsight> so smart and yet can't see more than a step or two ahead that they are going in a circle
[16:28:55] <mozmck> :-) And a PC quite capable can be had refurbished for less money than a single BB
[16:30:11] <CaptHindsight> even new Intel boards are cheap
[17:29:17] <tinkerer> another Q: where is the default place for firmwares?
[17:30:39] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid closed pull request #32: Nicokid (06master...06nicokid) 02
https://github.com/LinuxCNC/linuxcnc/pull/32
[17:40:18] <andypugh> That’s the apron casting ready for the mounting holes to be drilled. Then I can look at scraping in the saddle gib.
https://picasaweb.google.com/108164504656404380542/Holbrook#6247207163278932930
[17:49:43] <JT-Shop> your having too much fun Andy
[17:51:07] <andypugh> Nah, too much fun was last week: (This isn’t us, but we did this run, supposedly the wildest _on_piste_ run in Europe.)
https://www.youtube.com/watch?v=RP8cZb45g7M
[17:51:40] <cradek> will the X motor stick out or be inside?
[17:52:26] <andypugh> It goes inside, and pokes a shaft out through the oval hole.
[17:52:31] <cradek> neat
[17:52:46] <cradek> that ski run looks both fun and foolhardy
[17:53:14] <andypugh> Well, if you fall one way you end up in Meribel, and the other way Courcheval.
[17:53:39] <cradek> I just got my car unstuck (couldn't get away from the curb on the ice) with two squares of scrap carpet. they're staying in the car for a while :-)
[17:53:48] <cradek> you mean your remains end up there?
[17:54:31] <andypugh> My ex-girlfriend fell off (a ski popped off) and survived.
[17:54:58] <andypugh> She had a helicopter ride and a bad back for a few years though.
[17:55:13] <cradek> yikes
[17:55:20] <cradek> glad she was ok
[17:56:32] <andypugh> So am I. It was before I met her.
[18:02:17] <cradek> I have never skiied and as I get older I'm more and more sure that's the ideal number of times
[18:04:49] <andypugh> Each to their own. I rather enjoy it.
[18:05:11] <andypugh> Mainly because i like the mountains. And the cold.
[18:05:37] <cradek> I'm sure it would be great fun, but I know I don't have the knees for it
[18:05:54] <cradek> I have enough trouble without the skiing
[18:07:32] <andypugh> I have a bit of trouble _because_ of the skiing.
[18:26:14] * skunkworks does too.. None of this cross country crap.. down hill only.
[18:34:22] * JT-Shop used to do cross country way back when living in Alaska
[18:41:27] <andypugh> I like ski mountaineering.
[18:41:54] <andypugh> (Randonée / Alpine touring)
[18:47:02] <jepler> tinkerer: odroid u3 had spi. I've driven a mesa 7i90 with it.
[18:47:20] <jepler> linuxcnc.org doesn't build cross-development toolchains, ugh the very thought chills me
[18:48:39] <jepler> tinkerer: board-specific zip files from mesanet.com are the most official place for hostmot2 board firmwares. we build firmwares for a subset of peter's boards and host them on linuxcnc.org, emphasis on the boards with volatile firmwares. debian package name hostmot2-firmware*
[18:54:07] <tinkerer> jepler: a little misunderstanding. I meant the place where the firmwares are stored for uploading to the boards.
[18:55:26] <tinkerer> ie: I use this string static char *firmware = ""; // if this is empty, no firmware upload will be performing (ie. for CPLD or Config Rom) RTAPI_MP_STRING(firmware, "Firmware Path");
[18:55:58] <jepler> oh
[18:56:08] <tinkerer> and a default path would be nice
[18:56:08] <jepler> that's specified in the hostmot2 manpage
[18:56:36] <jepler> search down for the section beginning
[18:56:37] <jepler> firmware [optional]
[18:57:24] <tinkerer> for the pluto board? :D
[18:57:44] <jepler> oh pluto board, that damn thing
[18:57:53] <jepler> that firmware is built in at compile time
[18:58:07] <tinkerer> yes i know
[19:00:16] <tinkerer> I mean a generalized place where all the firmwares are have to be stored like /lib/firmware... or so
[19:01:11] <jepler> rtapi_request_firmware / rtapi_release_firmware APIs are only minimally documented
[19:01:25] <jepler> but they operate much like the kernel APIs request_firmware / release_firmware
[19:01:31] <jepler> including the default path
[19:01:51] <jepler> pull request to improve the manual page appreciated
[19:04:43] <tinkerer> ok, but where are the firmwares copied with make install?
[19:05:11] <jepler> for pluto?
[19:05:50] <jepler> in linuxcnc.org's 2.7 or master branch?
[19:06:02] <tinkerer> no matter general
[19:06:22] <tinkerer> pick both ;)
[19:06:55] <jepler> If a particular driver uses rtapi_request_firmware / rtapi_release_firmware, then it will search in the path that those APIs define
[19:06:59] <jepler> which is /lib/firmware or so
[19:07:22] <tinkerer> ok, and in linuxcnc?
[19:07:27] <jepler> however, pluto does not use this API, it incorprates the firmware directly into the hal component .ko/.so file
[19:07:38] <tinkerer> yes i know this!
[19:07:41] <jepler> as far as I remember without grepping, only mesa uses this API
[19:07:55] <jepler> I am sorry that I am not understanding your question,.
[19:08:25] <tinkerer> I'am writing on a driver based on pluto
[19:08:54] <jepler> If you want to load a firmware, I encourage you to write your driver to use rtapi_request_firmware / rtapi_release_firmware
[19:08:56] <tinkerer> and on the pluto driver respect...
[19:09:07] <tinkerer> aha
[19:15:12] <tinkerer> it means that "make install" copies the firmwares to /lib/firmware
[19:15:20] <tinkerer> is this correct?
[19:15:41] <jepler> right now there is no firmware installed by "make install"
[19:16:24] <jepler> because pluto is built-in to the component, and mesa is installed from a different package (hostmot2-firmware)
[19:16:51] <jepler> but yes, "make install" should put the firmware file in its correct location where rtapi_request_firmware will find it
[19:17:17] <jepler> but there is an additional wrinkle for users with "run in place" systems, so some alternate method needs to be provided for them.
[19:19:23] <tinkerer> yes this would be my next question
[19:20:00] <jepler> fpga firmware images require proprietary software to build, and so placing them inside our source tree is a problem for a long-term goal we have, which is a source tree which complies with the Debian Free Software Guidelines, and might some day allow linuxcnc to be in the debian "main" archive.
[19:20:57] <jepler> Even though I made the mistake with pluto to put the firmware file directly in the linuxcnc source tree, I would prefer not to see that mistake repeated again. What we have done with hostmot2-firmware, to separate out software that is related to LinuxCNC but cannot meet DFSG, I think is a better way
[19:21:23] <jepler> (that software might eventually be able to be in debian's "non-free" section)
[19:21:34] <tinkerer> yes
[19:22:59] <tinkerer> but would this mean that the hostmot driver does not work after just a git clone?
[19:23:41] <seb_kuzminsky> i wonder why the armhf sim deb builders are disabled
[19:23:50] <seb_kuzminsky> i wonder if my git historyy will tell me?
[19:24:31] <jepler> seb_kuzminsky: I bet you didn't like waiting for it
[19:24:41] <seb_kuzminsky> comment out wheezy-armhf for now
[19:24:47] <seb_kuzminsky> wow thanks, guy
[19:24:50] <jepler> .. particularly the doc-building part
[19:24:51] <jepler> hi seb_kuzminsky
[19:24:56] <seb_kuzminsky> hi :-)
[19:25:03] <seb_kuzminsky> it's doing rip, so it already builds the docs
[19:25:05] <seb_kuzminsky> once
[19:25:45] <jepler> tinkerer: right, a user with a hostmot2 card with volatile firmware, such as the venerable 5i20, has to install the firmware, such as by installing the hostmot2-firmware package.
[19:25:59] <jepler> or by manually installing a file in a .zip from peter into /lib/firmware
[19:26:09] <tinkerer> aha ok
[19:26:14] <jepler> hostmot2 is at a level of maturity where these files change rarely so that's fine for the majority of users
[19:27:09] <tinkerer> this clarifying it
[19:30:29] <tinkerer> the point is, fpga boards are very polymorph and it's a feature loading different firmwares/behaviors with the driver
[19:33:23] <tinkerer> IMHO your approach with the pluto is a good idea
[19:34:33] <tinkerer> ok was ;)
[22:36:48] <jepler> http://forum.odroid.com/viewtopic.php?f=135&t=18683
[22:36:51] <jepler> oooh
[22:38:53] <jepler> 64-bit ARM, and this time the (gigabit) MAC is in the SoC, not off in USB, and a nice price point ($40 without eMMC)
[22:40:25] <jepler> said to be using the 3.14 kernel, which has an RT patch
[22:42:44] <jepler> .. I think I want one!
[22:50:11] <CaptHindsight> and with ARM Mali™-450 MP3 GPU
[22:51:05] <CaptHindsight> and hopefully no hiccups with hm2_eth