Back
[09:10:32] <seb_kuzminsky> that test failure seems unrelated to the commits that triggered the build
[09:12:52] <jepler> 6DOF from six linear axes:
https://sites.google.com/site/3dprinterlist/multiple-axis-printers/sextupteron (bad dubstep on video)
[09:14:10] <seb_kuzminsky> jepler: wow that's a lot of linkages
[09:14:46] <seb_kuzminsky> neat
[09:15:14] <seb_kuzminsky> i got most of the kinks worked out of the robot arm kins last night, it *almost* runs the splash code with a magic marker now
[09:16:57] <jepler> seb_kuzminsky: nice
[09:17:54] <jepler> I don't see how this thing is supposed to work, there's just one belt for each pair of joints
[09:18:32] <jepler> > This style mechanism is protected under patent law and I don't control the patent
[09:22:01] <seb_kuzminsky> hrm, patent law
[09:25:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 fb93967 06linuxcnc 10debian/control.in 10src/Makefile 10src/hal/user_comps/Submakefile 03src/hal/user_comps/scorbot-er-3.py add a non-realtime driver for the scorbot-er-3 robot arm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb93967
[09:25:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 ec790d5 06linuxcnc 10src/Makefile 03src/emc/kinematics/scorbot-kins.c kins: start adding scorbot-kins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ec790d5
[09:25:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 d7985f8 06linuxcnc 10(5 files) add a sample config for the scorbot-er-3 robot arm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7985f8
[09:25:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05scorbot-er-3 d465def 06linuxcnc 10src/emc/kinematics/scorbot-kins.c kins: add debugging (commented out) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d465def
[09:29:09] <archivist> that machine looks like maths(with silly limits) and dont bother about machine strength
[09:34:49] <cradek> seb_kuzminsky: that looks tricky
[09:36:59] <jepler> archivist: it's 3d printing people, so they don't care about machine strength
[09:37:17] <ssi> can't imagine what benefit 6dof gives you for 3d printing
[09:37:19] <jepler> and they don't care much about cartesian velocity and acceleration constraints either
[09:38:22] <jepler> ssi: the proponents seem to think it would let you build overhangs that you can't accomplish with 3DOF
[09:45:59] <archivist> but they also dont seem to realise the flex and inaccuracies of their designs
[09:46:34] <archivist> the play in all the joints is going to add up
[09:48:31] <ssi> hrm
[10:02:45] <seb_kuzminsky> cradek: the kins? it looks hairy but it's just finding the intersections of two circles
[10:06:54] <cradek> ah
[10:07:29] <cradek> it's too bad that often a sketch is part of the coding process, but then it's lost
[10:07:51] <seb_kuzminsky> ... yeah
[10:07:53] <seb_kuzminsky> i agree
[10:08:10] <seb_kuzminsky> maybe i'll take a picture of my coffee-stained notebook and add it to the Code Notes page
[10:09:43] <mozmck> pcw: Looks like the deadline scheduler may have a little higher latency than CFQ
[10:11:36] <mozmck> PCW: Odd thing is that I'm seeing two peaks equidistant on either side of center about 2/3 of the time. On deadline they are out about 12us, with CFQ it was much less.
[10:13:44] <pcw_home> is this with a base thread?
[10:16:39] <mozmck> yes, I'm just running latency-histogram
[10:17:46] <pcw_home> You might try just servo thread ( --nobase )
[10:21:05] <mozmck> hmm, ok
[10:21:32] <mozmck> I'm running glxgears and found a bluegrass mix on youtube that runs for hours :)
[10:23:52] <cradek> but there are only about five bluegrass songs...
[10:24:33] <mozmck> :) That would be Irish music
[10:24:39] <cradek> haha
[10:24:51] <mozmck> or at least Irish fiddle tunes
[10:24:58] <cradek> the fiddle one, the one with the little whistle thing, ...?
[10:25:20] <mozmck> haha ;)
[10:25:20] <cradek> maybe there's a waltz
[10:26:24] <mozmck> This is with the deadline scheduler, no RCU_BOOST, and only glxgears running:
http://pasteboard.co/2dzrXZhD.png
[10:26:31] <cradek> mozmck: I saw the del mccoury band live a year or so ago - they were really good. they wore their matching suits and all played acoustic instruments standing around one mic, like from another era. if you haven't seen them, do, before it's too late
[10:27:45] <mozmck> I've seen them, and many others like them :) Haven't been to a show in a while though.
[10:29:03] <cradek> they were the tightest I had ever seen. their voices!
[10:29:16] <mozmck> If you get a chance to see Doyle Lawson & Quicksilver, they are always good.
[10:29:18] <cradek> they didn't play so fast that they couldn't keep up
[10:29:33] <cradek> that's a curse of a lot of bluegrass I think
[10:30:13] <mozmck> well, especially of younger folk ;)
[10:30:22] <cradek> heh
[10:31:49] <mozmck> Best show I've seen was in Guthrie OK. Used to be a band called California, and the former members all met for a show there - they were called back for another song 3 times.
[10:33:19] <mozmck> pcw_home: this is with CFQ scheduler, RCU_BOOST, and working the computer harder playing videos etc:
http://pasteboard.co/2dzH65rh.png
[10:35:37] <jepler> mozmck: probably better to test without a base period, since you won't be running with one typically
[10:35:44] <mozmck> ok
[10:38:11] <jepler> latency-histogram --nobase --sbinsize 200 --sbins 400
[10:38:33] <jepler> that'll also adjust the bins so that you can see all the way up to those +43.1us latencies that it recorded on the servo thread
[10:38:51] <mozmck> ah, I see.
[10:40:39] <jepler> how are you changing the scheduler of rtapi_app?
[10:41:02] <mozmck> I'm changing the kernel scheduler
[10:41:48] <mozmck> I'm building a preempt-rt kernel for *buntu 14.04 and playing with settings.
[10:45:16] <mozmck> If there's any interest I'll certainly make the kernel available when I think I'm done tweaking it. I hope to make a liveCD based on xubuntu as well, and the kernel should work equally well in LinuxMint 17.x
[10:53:05] <pcw_home> really lumpy, here's a e8500 with just a servo thread:
[10:53:07] <pcw_home> http://freeby.mesanet.com/e8500-preemt-rt.png
[10:54:04] <mozmck> Interesting. I wonder if a 32 bit kernel would perform better on this machine.
[10:55:49] <mozmck> I'm running now with just a servo thread, and it is still lumpy and latency went right up to around 35 +/-
[11:05:17] <pcw_home> I have been using only 32 bit kernels
[11:09:03] <mozmck> I see. That latency will work, but less would not hurt. I'll try 32 bit and see what that looks like.
[11:11:27] <jepler> it would be interesting to compare 32 and 64 bit linuxcnc userspace on a 64 bit kernel
[11:14:18] <mozmck> Hmm, had not thought of that. I could set up and compile linuxcnc for 32 bit and try it on the machine.
[11:22:29] <pcw_home> Dell laptop:
[11:22:31] <pcw_home> http://freeby.mesanet.com/e6420.png
[11:35:11] <pcw_home> some modern MBs are quite a bit better:
[11:35:12] <pcw_home> http://freeby.mesanet.com/h97-g3258-preemt-rt.png
[11:35:14] <pcw_home> and quite impressive with RTAI:
[11:35:15] <pcw_home> http://freeby.mesanet.com/h97-g3258.png
[11:36:35] <pcw_home> my tupperware PC is coming today, I'll give that a try
[11:36:47] <mozmck> That h97-g3258 is good enough with preempt-rt for software stepping!
[11:36:59] <pcw_home> Yeah
[11:37:34] <pcw_home> and hm2-eth at 4KHz while running hd videos
[11:38:38] <pcw_home> the DC7800 will run hm2_eth at 4 KHz but will stumble occasionally at 4 KHz running you tube videos
[11:39:07] <mozmck> What latency is needed for 4 khz?
[11:40:01] <pcw_home> I dont think latency tells the whole story for uspace Ethernet
[11:40:59] <mozmck> oh.
[11:41:32] <pcw_home> its related but CPU speed and perhaps cache size seem the main thing that determine worst case Ethernet latency
[11:42:14] <mozmck> does isolcpus help with preempt-rt?
[11:42:26] <pcw_home> seem to hurt
[11:42:31] <mozmck> ok
[11:42:58] <pcw_home> maybe with the right IRQ affinities
[11:44:05] <pcw_home> on the other hand a 1 KHz servo thread running a velocity drive (or stepgen) is adequate for anything but fairly exotic machines
[11:45:11] <pcw_home> and thats doable without futzing on just about any PC
[11:45:46] <pcw_home> well PIIs and below maybe not
[11:50:23] <jepler> "tupperwrare pc"?
[11:52:30] <pcw_home> http://store.hp.com/webapp/wcs/stores/servlet/us/en/pdp/desktops/hp-stream-mini-desktop---200-010
[11:54:57] <jepler> I see what you mean
[11:56:10] <jepler> > Windows 8.1 with Bing 64
[11:56:14] <jepler> wow there's a 64-bit verison of bing?
[11:56:43] <mozmck> I thought bing was a search website?
[11:57:30] <seb_kuzminsky> why do the USB ports say "SS" on them?
[11:57:50] <mozmck> Super Speed
[11:58:03] <mozmck> USB 3
[11:58:09] <seb_kuzminsky> aha, thanks
[12:03:14] <jepler> mozmck: that's why it seems absurd to me
[12:04:18] <pcw_home> windows wont be on it for long
[12:04:20] <mozmck> heh, marketing - or maybe really IE is finally 64-bit
[12:08:43] <jepler> I think the name of the OS is "Windows 8.1 with Bing", and this is the 64-bit version of that
[12:09:18] <jepler> these days I'm starting to feel bad for poor microsoft
[12:09:59] <pcw_home> My wife bought a cheap laptop with windows 8.1 +bing
[12:10:01] <pcw_home> full of hard to remove crapware
[12:13:20] <pcw_home> I guess microsoft gives it away free
[12:14:11] <jepler> the OEMs add their own layer of it
[12:14:39] <jepler> .. I am sure you heard about Lenovo's trouble in that area
[12:31:02] <seb_kuzminsky> a friend just bought one of those thin light little dell notebooks that's advertised as linux-friendly
[12:31:09] <seb_kuzminsky> it caught on fire in the first week
[12:32:19] <mozmck> batteries overheat?
[12:32:47] <seb_kuzminsky> his theory is some metal component of the frame flexed and shorted the battery
[12:33:06] <seb_kuzminsky> it happened when he was turning the laptop around on a table to show the screen to a neighbor
[12:33:14] <mozmck> wow
[12:33:24] <mozmck> I bet the neighbor was impressed
[12:37:35] <jepler> you can spend a fun afternoon if you google li-ion battery fires
[12:37:55] <jepler> seems to be as easy as shorting the outputs or puncturing the cell
[12:38:01] <jepler> and then you inhale some really nasty stuff
[12:38:17] <seb_kuzminsky> mmm.. lithium
[12:39:15] <seb_kuzminsky> i'm looking at the git log of freebsd for my dayjob, the current HEAD says "Remove bogust cast.", but i keep reading it as "cat"
[13:59:17] <mozmck> What does this line mean in my linuxcnc_debug_txt file? Can not find -sec APPLICATIONS -var DELAY -num 1
[14:06:15] <skunkworks> for as long as I was a kid - I thought the TI99/4a booted to 'IT BASIC'
[14:08:17] <mozmck> Seems like the postgui.hal is getting run before the GUI is ready when using Gscreen with a custom skin.
[14:36:27] <seb_kuzminsky> Jessie's due out April 25, wooo party
[15:07:06] <skunkworks> neat
[15:58:01] <PCW> mozmck: dc7800 preemt-rt latency
[15:58:03] <PCW> http://freeby.mesanet.com/dc7800-preemt-rt.png
[18:04:23] <KGB-linuxcnc> 03Dewey Garrett 052.7 b1c6283 06linuxcnc 10scripts/linuxcnc.in linuxcnc.in: prevent uneeded msg in linuxcnc.debug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1c6283
[18:05:13] <seb_kuzminsky> awesome
[18:29:59] <PCW> well rats the wheezy live cd wont boot on tupperware
[18:40:53] <skunkworks> why not?
[18:43:09] <PCW> looks very similar to the Baytrail issue
[18:43:34] <PCW> boot starts then turns off USB power
[18:45:28] <skunkworks> oh
[18:45:38] <skunkworks> really - that was fixed for the baytrail
[19:03:29] <mozmck> PCW: Thanks for the latency chart. It's interesting because the max and min are almost identical to what I'm getting, but it's a lot smoother chart
[19:31:28] <PCW> I tried turning off the power options and using the 1KHz tic but no difference I could see
[19:32:34] <PCW> It would be nice if the wheezy install included a up-to-date vanilla kernel so its would at least boot
[19:32:35] <wortley_> Are the KERNEL SYMBOLS that I see by using nm on xxx.comp available to the functions within that xxx.comp file? The whole kernel? just linuxcnc?
[19:57:44] <seb_kuzminsky> PCW: the kernel on the 2.6 & 2.7 install images both have the baytrail fix, iirc
[19:58:31] <seb_kuzminsky> wortley_: on rtai they're available to the whole kernel, including comps you load later (i think)
[20:10:22] <wortley_> I was pointed at using hal_data to allow my functions to find everything, but I tried adding a reference to it and the compiler barfed.
[20:11:15] <wortley_> I guess I need to add hal_priv.h to get at it?
[20:13:06] <wortley_> I just want the functions within my component (i.e. return_ptr_to_a_buffer) to be able to find the buffer that was declared in __comp_inst.
[20:22:51] <wortley_> seb_kuzminsky: Are my other symbols like __comp_first_inst somehow accessible by other functions within the component? I would prefer to not have to grab the mutex and crawl the tree just to find myself.
[20:25:54] <wortley_> Those two, __comp_first_inst, default_count, count are declared as global variables...
[20:28:45] <wortley_> and it appears that at least the main function "_" made by the component generator has access to it...
[21:15:57] <jepler> A function which is an argument to EXPORT_SYMBOL or EXPORT_SYMBOL_GPL is available in another component which is loaded later. I don't think that we deliberately do this anywhere for data symbols, only for functions, so data may not work.
[21:16:58] <jepler> additionally, symbol names like __comp_foo are intended for the internal use of halcompile, and might change from release to release.
[21:17:21] <wortley_> jepler: Would mean I would be limited to single instance of something that exports a function?
[21:18:18] <wortley_> jepler: ahh, yes. So using __comp_first_inst in a function (since I didn't make it) is probably risky.
[21:19:36] <wortley_> When I get all done, I guess I could turn the .comp into a .c (should this be accepted as part of linuxcnc some day).
[21:21:55] <jepler> well I'd hate to add a .c file which is 90% comp-generated and then 10% hand-edited, that is a sad event too
[21:22:41] <jepler> .. one option would be to improve comp until it can do what you need; another would be to just write in C
[21:22:54] <jepler> once you start stepping outside of what halcompile was intended to do, it quickly becomes painful
[21:24:01] <wortley_> I am happy to report that I DO have a working driver running a motor over SPIBUS and parport -- The rest of this is about how I can clean it up such that it could be consumed by the masses.
[21:24:29] <jepler> cool
[21:24:57] <jepler> (I am quite out of touch with what people are up to these days)
[21:25:00] <wortley_> There has definitely been some pain with using a .comp. I wish there was a "preinclude" directive that would allow me to use #define constants in my variable definitions...
[21:26:04] <wortley_> Cool and scary. I'm getting pretty close to handing over control of a 4HP spindle and NEMA42 steppers to ***my code***. Which is kinda creepy...
[21:27:10] <wortley_> The single axis bench tests have been going well enough to start thinking about hooking up the beast.
[21:28:25] <jepler> is there more information about your hardware interface online?
[21:34:18] <wortley_> Not in one place by me. I'm using L6480 EVAL boards from ST Micro time 4 to drive a Shizuoka AN-S Milling machine.
[21:35:10] <wortley_> The spi protocol is being spoke over generic IO provided via the parport driver.
[21:35:52] <jepler> bitbanged spi, or epp -> spp translator in a microcontroller or something?
[21:35:54] <wortley_> I have separate L6480 driver that sends/gets serial data from the spibus.comp driver that is hooked to the parport io pins.
[21:36:00] <wortley_> bitbanged spi.
[21:36:09] <wortley_> But fast enough to get 5.5bytes/ms.
[21:36:59] <jepler> interesting, the L6480 detects motor stalls?
[21:37:03] <wortley_> I will probably have each controller board on it's own dedicated bus with it's own io pins, but we'll see.
[21:37:18] <wortley_> It is supposed to, but i haven't dialed in the voltage levels that far yet.
[21:38:24] <wortley_> The demo board is pretty sweet though. I have driven 12Amps into my motors with just some air blowing over the boards. No heat sink!
[21:38:31] <jepler> does this use the hal parport component, or the hal_parport_* C APIs?
[21:38:42] <wortley_> hal_parport component
[21:38:57] <wortley_> I have a MAX7219 LED display working over the spibus too.
[21:39:10] <wortley_> It's on the linuxcnc user forum.
[21:39:25] <jepler> ah, I'm a mailing list guy, rarely browse the forum
[21:40:31] <wortley_> Until I get all of this buffer pointer kernel symbol business worked out, it shouldn't really be used by other people. Right now I am casting pointers to unsigneds and passing them over pins.
[21:40:38] <wortley_> It's gross, but it works.
[21:43:24] <jepler> so you use the "run" command to set a step frequency and read the ABS_POS register back to "close" the loop?
[21:43:27] <wortley_> But I have learned a lot (goal 1) and am close to having something usable (goal 2) and hopefully will be able to clean it up enough to give back (goal 3).
[21:43:54] <wortley_> Yes. And as a bonus, it actually works.
[21:44:01] <wortley_> :)
[21:44:23] <wortley_> It is kind of like having an absolute encoder.
[21:45:38] <jepler> the hostmot2 driver has some examples of how to make multiple components work together and send the kind of data that is not best transported by HAL pins
[21:45:45] <wortley_> I was mostly attracted to the part because the demo board was so beefy, and it has its own motion engine. Although Step/dir is pretty simple.
[21:46:14] <jepler> yeah though with step/dir you run into tradeoffs between maximum speed, microstepping, and base period really quickly
[21:46:25] <wortley_> Andy was kind enough to point me toward the uart.c in hostmot as a decent model.
[21:46:32] <jepler> ah so you've already talked to him. good.
[21:46:44] <jepler> he also has experience working at the boundaries of what comp can do
[21:47:39] <wortley_> He has provided me so good references and advice -- but since a lot of this is new, I'm struggling to digest it all.
[21:48:03] <jepler> my advice, for what it's worth, is that you're best off just writing in C. Then stuff like defining the structures you need, making sure you can refer to what you need where you need to do it, etc., is easy (it's just C, with EXPORT_SYMBOL for stuff that the later-lodaed component needs to be able to call)
[21:48:13] <jepler> anyway, I have to go. it was nice talking to youl
[21:48:15] <jepler> you.
[21:49:17] <wortley_> Thanks Jeff -- I plan to go that way eventually. Thus far I have been able to get away with letting comp do the tedious work. Later...
