Back
[11:14:59] <skunkworks> pcw_home, I tried the same two installs on different motherboard hardware for grins. (12.04 and 10.04 rtnet)
[11:15:49] <skunkworks> same effect - 12.04 has the missing symbol and 10.04 seems to comunicate but doesn't send the config and gets encoder errors.
[11:20:06] <pcw_home> What hardware?
[11:21:00] <pcw_home> If its a 7I80 you dont send a config
[11:21:28] <skunkworks> sorry - 7i80 - I mean the config line.
[11:21:52] <skunkworks> If I send it all 0 for pwmgen encoders and such - I still get the ecoder errors.
[11:23:03] <pcw_home> Maybe the config parsing is broken in the driver
[11:23:37] <norbert> Halo, I am working on a glade widget to load a file to linuxcnc using an IconView, so it is very touchscreen friendly. My widget do use some part of code witch is under the BSD license. I got also the permission from the author of the original code to use it. Does somebody know if it is allowed to relicense the code under GPL, or would it be a problem to include the code if it is under the BSD license?
[11:24:16] <cradek> which BSD license is it?
[11:24:53] <skunkworks> pcw_home, this is what I am seding.. loadrt hostmot2 loadrt hm2_eth ip="192.168.0.2" config="num_encoders=0 num_pwmgens=0 num_stepgens=0"
[11:25:07] <skunkworks> (other than it is the default ip address of the 7i80)
[11:25:35] <norbert> @cradek, the autor send me a mail with this information: The license for the code examples on ZetCode is BSD.
[11:26:05] <cradek> ok, that is not enough information to answer your question, because there are several licenses that people commonly call BSD.
[11:27:03] <norbert> I will than write an other Email to the author, just asking for his permission to public my code under GPL, Lets see waht he will answer.
[11:27:43] <cradek> the license that gives us the most compatibility with the rest of linuxcnc is "GPL 2 or later"
[11:28:24] <cradek> but if you get clarification about which BSD license the author means, it may be just fine, since some are perfectly compatible
[11:30:06] <cradek> you might like to read
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
[11:46:49] <kwallace2> norbert: Off hand, have you looked at the GScreen or Touchy source to see how it is done there? It seems Glade and Python should provide what you need without too much fiddling.
[11:47:48] <cradek> touchy gives a scrolling list, it is only functional, not pretty
[11:56:50] <norbert> and gscreen does use the standard dialog.
[11:57:43] <kwallace2> http://www.wallacecompany.com/tmp/Screenshot-1.png
[11:59:13] <kwallace2> I wasn't involved with the file bits, but it didn't seem that too much magic was used here.
[12:03:25] <norbert> Where can I find the code?
[12:03:34] <norbert> looks nice
[12:07:57] <kwallace2> You might ask Daniel Rogge from Tormach on the e-mail list. The lathe and software is due to be released by the end of this year, maybe.
[16:36:16] -morgan.freenode.net:#linuxcnc-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp
[16:39:40] <andypugh> remasterys has nothing to do with the unified build, or any build of linuxCNC.
[16:40:00] <andypugh> I just happened to mention them consecutively.
[16:40:46] <andypugh> However, it might effect us if we plan on making any more LiveCDs, and if remasterysys is the way that that is done.
[17:23:46] <ctbenergy> mhaberler: Hi, you're doing a great job, nice greetings from the district of Leibnitz, Suedsteiermark :-)
[17:24:06] <mhaberler> ah, nebenan?
[17:24:47] <ctbenergy> ja, gleich nebenan
[17:25:14] <mhaberler> ah! und wofür verwendest Du LinuxCNC?
[17:28:30] <ctbenergy> Faesmaschine Optimum BF30 Vario und spaeter noch fur Optimum D280 Drehmaschiene, die ist aber noch nicht auf CNC umgebaut
[17:28:54] <mhaberler> ah, ok, ganz ordentlich. Stepper?
[17:29:26] <ctbenergy> Ja Stepper, Wantai Motors
[17:30:03] <mhaberler> nja, ich beschäftige mich sozusagen mit dem 10-Jahre-Software-Kehraus ;)
[17:30:55] <andypugh> mhaberler: Any thoughts?
http://pastebin.com/rpwth370 This is an attempt to run ub-1 on my 5i23 system. OS is lubuntu 12.04. Please forgive the rather excessive pin list in the middle.
[17:32:22] <mhaberler> this is a failure in axis to find some file related to dynamic tabs
[17:32:58] <mhaberler> any chance you can upload the config and related files as a tar somewhere?
[17:33:00] <andypugh> Ah, OK, I may have a relict webcam tab in that setup.
[17:33:19] <andypugh> This is a clean new build with a rather old config.
[17:34:24] <mhaberler> the topmost line in the trace file tells you where Python stalled; yes, remove the tab for now, probably will come up
[17:34:56] <andypugh> It will be failing to find camview-emc as it won't be on this new system.
[17:34:57] <mhaberler> does this run with master? we didnt touch anything UI related
[17:35:01] <mhaberler> ah
[17:38:09] <andypugh> And now it works. For levels of "work" which include a Resolver driver where raw-counts oscillate by several million revolutions every servo cycle...
[17:38:25] <andypugh> Which is the bug I built this system to fix
[17:38:47] <mhaberler> why dont you use gdb to poke into it
[17:39:02] <mhaberler> sudo gdb -p <pid of rtapi_app>
[17:39:12] <andypugh> I am pretty sure that I know exactly what the bug is.
[17:39:34] <mhaberler> ah, inner vision replacing debugging;)
[17:39:36] <andypugh> I just needed a real 64-bit system with real hardware to test it with.
[17:39:40] <skunkworks> oops.
[17:41:08] <mhaberler> I got me a N450 el-cheapo board to iron out the x86_64 peculiarities
[17:41:57] <skunkworks> how is the latency?
[17:42:33] <mhaberler> puh, I use it only as a build slave, but will have a look tomorrow
[17:43:16] <skunkworks> eh - don't go out of your way
[17:43:52] <mhaberler> I did not the 3.10-4rt-preempt kernel gives surprisingly good results, around 20/25us
[17:46:19] <skunkworks> wow
[17:46:55] <mhaberler> yes, a bit of a surprise, there's been a lot of work on rt-preempt
[17:47:15] <skunkworks> that would run stepping machines... (to a point)
[17:47:35] <skunkworks> Those little lathes we have are running a 50us base thread
[17:47:48] <cradek> it'd be nice if you knew what command it was popening
[17:51:25] <andypugh> where are s32 and u32 defined in the LinuxCNC headers? Or are those Linux defines?
[17:52:08] <andypugh> And are they "better" or worse than int32_t and uint32_t ?
[17:52:20] <mhaberler> hold on, yes
[17:52:29] <mhaberler> __u8 - grep in the rtapi dir
[17:53:08] <andypugh> This ought to carry back to 2.5 ideally.
[17:53:34] <mhaberler> in rtapi.h
[17:53:36] <andypugh> I would imagine it is just as broken on a 64-bit RTAI build
[17:56:44] <andypugh> That resolves back to an include of <asm/types.h> ?
[17:58:09] <KimK> skunkworks: Hi Sam, re: my earlier posts (about what to new-install on E350N #2), do you have any advice for me beyond what I have received from andypugh, memleak, and ctbenergy?
[17:58:48] <skunkworks> no... :) I have not tried the new rtai build either
[17:59:19] <andypugh> What is the purpose of defining the same thing twice in successive lines in lines 116 and 117 here:
http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/types.h
[18:00:56] <andypugh> Ah, I think I am reading it backwards....
[18:01:15] <andypugh> It's a typedef not a define.
[18:03:37] <KimK> skunkworks: It sounds like the new RTAI build should work, albeit with the ethernet hiccup. So absent any contrary advice from you, I'll give it a try. More news later.
[18:06:14] <andypugh> However, reading the notes in rtapi.h it seems to suggest that my habitual use of s32 and u32 is an error. Ought I to change them all to __s32 and __u32 etc?
[18:09:09] <CaptHindsight> 64bit RTAI is still a work in progress, might done in a few weeks
[18:12:19] <memleak> Paolo and I are working on unifying the architectures in RTAI, keeping as much code interchangeable between both 32 and 64
[18:13:05] <memleak> 64 is far behind but a lot of the 32-bit code is compatible with 64, but not entirely.
[18:13:31] <memleak> takes time to over which functions are and are not compatible.
[18:14:06] <memleak> RTAI math issues though are fixed in the master github branch in the ShabbyX tree for 32 and 64 architectures.
[18:14:14] <ctbenergy> KimK: E350N use the Realtek 8111E, you to not need to build the kernel module for Realtek 8168B
[18:14:56] <memleak> ctbenergy, for 8111E doesn't it use the 8169 driver?
[18:16:12] <memleak> 8168B with a 8169 driver causes issues interrupt issues but I personally haven't had any.. i'm pretty sure my board is a 8168 based controller.
[18:18:23] <memleak> If you need 64-bit RTAI support you'll need 2.6 based kernels (vulcano branch) I've tested it and it runs great.
[18:18:39] <CaptHindsight> KimK: Gigabyte GA AMD E350N
http://www.gigabyte.com/products/product-page.aspx?pid=3681#ov Is this your board?
[18:21:59] <CaptHindsight> 2.6 kernels would be Ubuntu 10.04 Lucid IIRC
[18:22:53] <mhaberler> andypugh: no, just use u<size>/s<size>
[18:23:08] <mhaberler> my mistake referring to __u8
[18:23:24] <ctbenergy> KimK: Oops! you are right, it use the same driver.
[18:23:31] <andypugh> Now I am confused.
[18:24:02] <andypugh> rtapi.h cleary states that you should use the __s<size> versions.
[18:24:53] <mhaberler> ok, I guess I should actually read it first..
[18:26:01] <KimK> CaptHindsight: Very close, mine are the rev 3.0's at
http://www.gigabyte.com/products/product-page.aspx?pid=4379#ov I don't see a how-to, so, (not counting the NIC situation for now), I'm looking at Seb's debs at
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/ So do I install and update 12.04 as an "ordinary" install, then install whatever RTAI features I need using the deb installer? Then run the (10.04?) LinuxCNC i
[18:26:02] <KimK> nstall script?
[18:26:04] <mhaberler> the code and the comment dont agree
[18:26:05] <KimK> oops
[18:26:53] <mhaberler> the type name is u8 etc, via a reference to __u8 wherever that comes from, and that is what Charles uses in the code
[18:27:19] <mhaberler> eg here:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/rtapi/userpci/firmware.h;h=0341970c1e23a5766798890501d187181f245505;hb=9898998e7e9dde11158b02a12d0d6d891ecd882e#l56
[18:28:55] <memleak> KimK, for the 3.4 debs (3.4.55) they are meant to be used with precise and they can be installed via dpkg -i
[18:29:46] <memleak> i.e. sudo dpkg -i <package>.deb
[18:30:16] <memleak> as for the exact order (as there is like 4 or 5 debs) i'm not sure but dpkg will tell you what you need to install something
[18:30:43] <andypugh> I think that someone who knows this for sure needs to take a look at the code.
[18:30:46] <CaptHindsight> KimK: before seb left he posted instructions on the dev mail list
[18:30:58] <andypugh> I see a disturbing number of casts to (long)
[18:31:08] <mhaberler> right, int userland the __u* typedefs come in via /usr/include/asm-generic/int-ll64.h
[18:31:10] <mhaberler> where?
[18:31:38] <CaptHindsight> 1) Install Ubuntu Precise 12.04 32-bit. 2)Fetch and install the the "-1-rtai" debs of the Shabby/Memleak RTAI
[18:31:38] <CaptHindsight> from here:
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/ 3) Reboot to the RTAI kernel. 4) Fetch the git repo at linuxcnc.org.
[18:31:52] <CaptHindsight> 5) Build 2.5 or master (both should work).
[18:32:05] <CaptHindsight> 6) Try it out and let us know!
[18:32:37] <KimK> memleak: OK, I'll give that a try. CaptHindsight: Thanks, I'll go back and search there. Oh, hey, you're pretty fast, thanks!
[18:32:42] <andypugh> I am especially nervous of stepgen.c which looks like it might make exactly the same mistake as me adding a long delta to a long long accumulator and letting the magic of twos-complement handle the wrap in the delta.
[18:36:25] <ctbenergy> KimK:
http://public.weinhandl.org/drivers/r8168-8.036.00.instal-3.4.55-rtai-1.txt
[18:38:41] <andypugh> I wonder if anyone is using software stepping on a 64-bit system?
[18:38:56] <cradek> I wonder if anyone is using a 64-bit system
[18:39:15] <andypugh> KimK set one up at the fest.
[18:39:39] <andypugh> And I am running one now (but only because KimK's didn't work at all)
[18:40:30] <andypugh> I can't see any advantage at all in 64-bits over 32-bits for LinuxCNC
[18:40:46] <cradek> buzzword compliance
[18:41:26] <KimK> ctbenergy: OK, thanks!
[18:44:02] <KimK> andypugh: didn't work at all? I thought that it worked but that it had some math errors when running the resolver/RTAI? BTW, thanks for getting your 64-bit hardware and pursuing this.
[18:44:34] <andypugh> Yes, what I menat was that some of my code didn't work at all.
[18:45:47] <andypugh> The apparent resolver position oscillates by millions of revs every servo cycle. That's a bit worse than a "math error" :-)
[18:46:04] <KimK> OK, I misspoke too: s/it worked but/it worked incorrectly and/
[18:48:33] <KimK> Ha, yes, a good bit bit worse! But good for you (and the rest of us!) in that you are getting to the bottom of this. Thanks again in advance.
[18:51:04] <andypugh> I think I fixed it about an hour ago, but it is too late now to go out to the workshop and actually energise the motors...
[18:52:32] <KimK> andypugh, cradek: Maybe 64-bits is better, not so much for LinuxCNC itself, but for the OS (and new integrated CPU/graphics drivers?) in general? If even small boards are going 64-bit...?
[18:52:48] <andypugh> Then I need to spin the spindle long enough to wrap 32 bits of revs. It won't take too long as the base-resolution is 24-bits.
[18:52:51] <mhaberler> better for what?
[18:53:07] <andypugh> Better for eating memory?
[18:53:21] <mhaberler> valid use case
[18:53:40] <mhaberler> the only one I can think of though
[18:53:42] <KimK> Better generally, I mean, for the OS. Not so much for LinuxCNC itself.
[18:54:27] <mhaberler> it would only be relevant if you hit 32bit limit. Not aware of such a case. In absence of that, it's just overhead
[19:02:22] <tjtr33> mhaberler, funny search engine looks for book on ZMQ "Results for ZeroMQ: No catalog results found. Did you mean: jerome?" ( true story )
[19:02:50] <mhaberler> bing.com ;-?
[19:03:15] <tjtr33> local library net in Chicago
[19:03:42] <mhaberler> are you looking for a book?
[19:04:49] <tjtr33> i dont understand the idea of apps publishing data yet, and began reduplicationg your work to get a HalWeb, then it dawned on me what you are doing, so wanted to read up.
[19:05:27] <mhaberler> ah. do you speak python?
[19:05:36] <tjtr33> un petit pu
[19:05:44] <mhaberler> good enough
[19:05:56] <cradek> I wonder why the heck mini does that
[19:06:21] <mhaberler> pretty bizarre, yes - no reason I can see
[19:06:22] <cradek> mhaberler: I'm glad you actually looked at it
[19:06:44] <mhaberler> yes, it might push the problem a few layers up ;)
[19:07:01] <mhaberler> get the zguide from the zmq website, and study the publish/subscribe example there; let me see which one..
[19:07:08] <cradek> well there's probably no problem - it's working according to design
[19:07:15] <cradek> whatever the heck the design was
[19:07:42] <cradek> it's ... uh, good of charles to try all these old unmaintained UIs to see the particular ways they bite
[19:08:32] <tjtr33> mhaberler, thx
http://zguide.zeromq.org/page:all
[19:09:22] <cradek> if he had turned on debug he'd've seen the pause and resume messages being issued
[19:10:52] <mhaberler> there's no really simple pub/sub example there, but the pattern is well explained
[19:12:00] <mhaberler> the only thing to remember - if you dont get any messages at the receiving end, subscribe to "" which will make you get messages for all channels; then play with different channels
[19:13:44] <tjtr33> mhaberler, the book is >>funny<< :)
[19:13:56] <tjtr33> thx, off to read
[19:13:58] <mhaberler> yes, a bit
[19:14:28] <mhaberler> the only patterns you need to fully grasp are: req/rep, router/dealer and pub/sub
[19:14:46] <mhaberler> the rest is academic for our purposes
[19:24:04] <tjtr33> mhaberler: oops you're gone but: this also as a dummies guide to ZMQ
http://hintjens.wdfiles.com/local--files/main:files/cc1pe.pdf
[21:08:01] <mozmck> heh, I like this quote from hintjens book linked above, "The only downside was that we lost a single unified history. Now, perhaps historians will feel robbed, but I honestly can't see that the historical minutiae of who changed what, when, including every branch and experiment, are worth any significant pain or friction."
[21:11:09] <mozmck> From my perspective (which is probably skewed), it looks like some people go through more work trying to preserve the minutiae of history than it would take just to rewrite the whole thing from scratch! :) (Not pointing any fingers here, just a general observation)
