Back
[03:13:23] <memleak> seb_kuzminsky, will you be using 64-bit RTAI at all personally?
[03:13:56] <memleak> i've been working on a fix but it's a lot closer without SMP support.
[03:21:28] <memleak> With PAE though, you can still use 4+GB of RAM on a 32-bit system.
[03:23:13] <memleak> CaptHindsight: ^
[06:53:03] <skunkworks> odd question..
http://imagebin.org/265027
[06:53:16] <skunkworks> how come I cannot select which thread to use?
[06:53:56] <skunkworks> I ended up editing the halscope text file. shouldn't there be a drop down in the middle of that popup somewhere?
[06:54:57] <skunkworks> (this is the new rtos-master-v0 branch)
[06:55:15] <skunkworks> (on 12.04)
[06:55:30] <skunkworks> let me boot up my 10.04 vm
[06:59:43] <jthornton> that screen looks different
[07:04:55] <jepler> Tom_itx: no, it's running one of the standard reprap boards so far. linux retrofit is for the future.
[07:05:52] <skunkworks> right - it should look like this
http://imagebin.org/265028
[07:06:48] <skunkworks> and you can't resize it (thinking that it is just squashed or something)
[07:24:19] <jepler> uh oh, somebody needs to change that gcode splash screen
[07:39:34] <skunkworks> heh - didn't even notice that.
[07:42:22] <Tom_itx> jepler, at least you got the nicer one instead of the original
[08:29:03] <skunkworks> pretty darn cool
[08:29:03] <skunkworks> http://imagebin.org/index.php?mode=image&id=265037
[08:57:10] <skunkworks> de-accelerating..
http://imagebin.org/index.php?mode=image&id=265038
[09:20:15] <cradek> that one looks nicer
[09:21:51] <skunkworks> how is the delta coming? I saw jeff printed
[09:22:43] <skunkworks> I don't think the transistion is 100% perfect every time - but the blip is not causeing any issue that we can tell.
[09:28:32] <jepler> skunkworks: I still have to finish the heated bed, then work on leveling and calibration
[09:30:06] <skunkworks> jepler, Cool - no videos yet? ;)
[09:30:07] <jepler> I'm not a videos kind of guy
[09:30:13] <jepler> anyway 3d printing seems a lot like watching paint dry
[09:30:18] <skunkworks> heh
[09:30:19] <jepler> that cube took 40 minutes or so
[09:30:41] <skunkworks> do the layers look conistant in hight?
[09:31:13] <jepler> yes the height looks fairly consistent
[09:31:19] <skunkworks> neat
[09:39:12] <jepler> oh and apparently I should install this crazy little 25mm fan by the hot end
[09:39:47] <jepler> it's the electronics board (RAMBo) which seems like it needs a fan .. the little driver chips sure get hot
[09:40:16] <seb_kuzminsky> the stepper drivers on the 3d printers at the boulder hackspace fail completely unless you cool them with a fan
[09:40:29] <seb_kuzminsky> good thing they saved $0.25 by not putting heatsinks on
[09:41:45] <jepler> too bad I threw out a handful of "vga ram heatsinks" when I cleaned up downstairs in preparation for getting the rostock
[09:50:23] <jepler> seb_kuzminsky: stops when it gets hot, or eats itself? I see that A4982 claims it has "thermal shutdown circuitry" but I suppose that doesn't mean I should trust it
[09:51:36] <jepler> Maximum Junction temperature Tj(max) = 150C; thermal shutdown temperature Ttsd = 165C
[09:52:05] <jepler> seems like you should make it shut down before reaching the absolute maximum junction temperature
[10:16:49] <seb_kuzminsky> jepler: stops moving the motor
[10:16:59] <seb_kuzminsky> let it cool for a half hour and it starts moving again
[10:22:35] <KGB-linuxcnc> 03seb 05joints_axes3 5225786 06linuxcnc 10configs/ 10common/core_sim.hal 10common/core_sim9.hal 10sim/simulated_home.hal * fixup typos i introduced in the merge i just did :-(
[10:43:33] <jepler> seb_kuzminsky: oh that's fine then
[10:48:25] <pcw_home> Is the 2.6 release going to incorporate JA3 or is that just master for n ow?
[10:56:47] <jepler> pcw_home: it's not yet settled whether 2.6 will incorporate JA3
[10:56:49] <cradek> that is not yet known
[10:56:57] <cradek> it's also not yet in master
[11:02:12] <jepler> skunkworks: do you have any insight into how to choose the velocity to switch from half to full step?
[11:02:39] <jepler> is it more complicated than simply waiting for there not to be enough periods to half step?
[11:06:33] <jepler> http://emergent.unpythonic.net/files/sandbox/stepgen-morph-accel.png http://emergent.unpythonic.net/files/sandbox/stepgen-morph-decel.png
[11:06:53] <jepler> you could build the morphing right in to stepgen and then there's no need to worry about whether switching the stepgens leads to lost position over time
[11:08:35] <skunkworks> jepler, it was a hardware issue for me...
[11:08:50] <skunkworks> around 20ipm - half stepping stalled.
[11:08:52] <jepler> so you'd want to setp stepgen.0.morph-velocity 20
[11:08:57] <skunkworks> yes
[11:09:17] <skunkworks> jepler, ooh - that is cool
[11:12:57] <seb_kuzminsky> about ja3... i finished the my first attempt at rebasing it onto master last night, but i accidentally introduced some discrepancies, so i'm tidying those up
[11:13:33] <seb_kuzminsky> some of the discrepancies are lack of bugs introduced by merge commits in the ja3 branch (since rebasing removes all the merges)
[11:14:41] <jepler> skunkworks: do the waveforms look right to your eye?
[11:14:41] <seb_kuzminsky> i'm now going through all the discrepancies between ja3 and my new ja4 branch, and figuring out which ones are "ja4 got rid of ja3 merge turds" and which ones are "seb messed up the rebase"
[11:14:56] <jepler> seb_kuzminsky: aha that's why you merged master into ja3
[11:15:01] <seb_kuzminsky> i'm leaving the first kind in (and compiling a list of them, noting which merge commits introduced the bugs in ja3)
[11:15:13] <seb_kuzminsky> i'm going back and re-rebasing ja4 to undo my hickups
[11:15:17] <seb_kuzminsky> jepler: yes
[11:15:28] <cradek> how different are they?
[11:15:43] <seb_kuzminsky> i merged master into ja3 (it had been a while...), then rebased ja3 onto the commit in master that i merged into ja3
[11:16:18] <seb_kuzminsky> that creates a situation where the final tree of ja3 should be equal to that of ja4, but they get there by different histories
[11:16:50] <seb_kuzminsky> cradek: it's mostly configs, but a couple of bloopers i introduced in emc/motion etc
[11:17:18] <seb_kuzminsky> the configs are all broken in ja3 (even before my merge), many don't start due to lack of [KINS] in the .ini
[11:17:51] <seb_kuzminsky> i'd like to finish ja4 (hopefully over the weekend...) and then we/i can go back and look at the configs with a critical eye, in ja4
[11:19:22] <seb_kuzminsky> err, my words above were wrong and ambiguous, let me clarify
[11:19:38] <jepler> wrong *and* ambiguous? are you sure they can be both?
[11:19:39] <seb_kuzminsky> i've not rebase the branch called joints_axes3, and i dont intend to
[11:21:29] <seb_kuzminsky> i created a new branch called "ja4", pointing at the head of joints_axes3, and i've been rebasing *it* (ja4)
[11:22:13] <seb_kuzminsky> ja3 is continuing like normal: merge master into it occasionally
[11:22:41] <skunkworks> jepler: yes - after I figured out you didn't have them in order ;)
[11:22:45] <seb_kuzminsky> ja4 is the tidied up version that will replace ja3 as the "active" joints_axes branch if i pull it off, and be fast-forward merged into master eventually
[11:23:16] <seb_kuzminsky> is that more clear? does it seem like a reasonable approach?
[11:23:43] <cradek> it sounds great, given someone who wants to do all that work
[11:23:49] <seb_kuzminsky> heh
[11:24:29] <pcw_home> I think its great but It will be a red-letter day for people using master
[11:24:32] <seb_kuzminsky> beats twiddling my thumbs while waiting for the rtos branch to be ready to merge ;-)
[11:25:04] <seb_kuzminsky> pcw_home: yes, it will be a flag day - everyone's configs will break ...
[11:25:21] <cradek> unless we choose to make them not
[11:25:27] <cradek> and do the work
[11:27:45] <jepler> skunkworks: unfortunately there's something fishy in my modified stepgen :-/
[11:27:55] <seb_kuzminsky> the .ini [AXIS_%d] sections split into [AXIS_%c] and [JOINT_%d], not sure how to do that mechanically in the general case
[11:28:39] <jepler> http://emergent.unpythonic.net/files/sandbox/stepgen-morph-fishy-small.jpg
[11:28:50] <jepler> the waveform seems to slow down when the commanded velocity is slowing
[11:34:45] <skunkworks> jepler, shouldn't it?
[11:34:52] <jepler> err I didn't say what I meant
[11:35:00] <jepler> when the commanded velocity is still rising
[11:35:19] <skunkworks> oh
[11:35:32] <jepler> link should have been
http://emergent.unpythonic.net/files/sandbox/stepgen-morph-fishy.png
[11:35:32] <skunkworks> (that picture is too small to see,...)
[11:35:38] <jepler> siggen.0.sine => stepgen.0.velocity-cmd
[11:36:05] <skunkworks> that is odd
[11:37:18] <jepler> I'll keep playing with it
[11:38:24] <skunkworks> that is really cool.
[11:39:14] <skunkworks> How would you select different phase patters - like what if you where using bipolar steppers - so 10 and whatever the single step pattern would be...)
[11:39:39] <skunkworks> heh 'single step' I mean full step.
[11:39:44] <jepler> I understand
[11:40:26] <jepler> I looked at the 9 and 10 tables and noticed that the odd numbers were the same as the two-winding full step tables
[11:56:20] <seb_kuzminsky> jon elson ftw
[12:01:43] <cradek> responding to "someone should port to this new cool platform with 32k of ram"?
[12:05:17] <Tom_itx> jepler those stepper drivers they use on those reprap almost seem underpowered to me
[12:13:26] <pcw_home> The propeller does not seem to be a Z80 however (its 8x 8 bit RISC processors with 32 bit instructions)
[12:14:00] <pcw_home> rather slow though at 4 clocks per instruction
[12:16:58] <pcw_home> There is a GCC compiler for it!
[12:17:51] <cradek> I love embedded systems for appropriate tasks but I don't understand this sudden desire to make linuxcnc run on them
[12:19:20] <archivist> oops /me tries to bury the Z80 deeper :)
[12:23:33] <jepler> Tom_itx: the motors are pretty scrawny too, but remember: never any cutting forces
[12:23:49] <jepler> everything that is moved by the motors in my machine weighs something on the order of 1lb
[12:27:59] <jepler> and the claimed speed of 300mm/s is only 600rpm which is well inside the high torque region of those small steppers
[12:42:50] <Tom_itx> nema17
[12:55:55] <skunkworks> jepler, do you think after running the 2 stepgens back and forth for a long long time - they would start to diverge?
[13:02:41] <zultron> Anyone know how to get un-truncated output from 'dpkg -l'? Here's what I'm getting:
http://paste.ubuntu.com/5891522/
[13:03:08] <zultron> I specifically want the entire package name, so this isn't helpful.
[13:03:40] <zultron> 'COLUMNS=160 dpkg -l libboost-thread\*' works fine, but that's a lot of typing....
[13:04:12] <cradek> |cat
[13:04:31] <zultron> Ah, that's less typing. :)
[13:04:46] <zultron> ... but doesn't help. :(
[13:04:52] <cradek> huh, it did for me
[13:05:42] <cradek> maybe you want dpkg-query -W
[13:05:44] <zultron> I have 'COLUMNS=80' in my environment.
[13:06:01] <zultron> YES!
[13:06:03] <zultron> Thanks!
[13:06:18] <cradek> yay
[13:34:50] <jepler> ah I always dpkg-query | cat
[13:36:45] <jepler> skunkworks: well .. I don't know what keeps them in synch but that's probably just because I haven't read the HAL
[13:36:56] <jepler> if they're both driven in position mode then it's probably fine
[13:37:12] <jepler> originally I thought you were trying to beat the frequency limit of linuxcnc so that wouldn't have worked
[13:42:22] <skunkworks> ah - no. these are pretty low steps/inch (half stepping is 3657.6073152 steps / inch)
[13:43:11] <jepler> anyway, I think I found my bug
[13:46:09] <jepler> skunkworks: if you're feeling interested you could try with this patch:
http://emergent.unpythonic.net/files/sandbox/0001-stepgen-implement-step-morphing-for-half-step-modes.patch but it does look like I broke at least one runtest so there's more work to be done
[13:50:16] <jepler> .. make that at least 2
[13:52:46] <skunkworks> heh
[13:55:45] <jepler> I now think it's more broken than right. certainly I won't be pushing that patch anywhere anytime soon
[13:56:33] <skunkworks> heh - A good start though. Thanks for think ing about it :)
[14:01:08] <jepler> I think I could get it right if I went back and took out the double-frequency part
[14:01:17] <jepler> so that you remain limited to the old limit, but morph to full-step mode
[14:04:09] <skunkworks> maybe disable the double frequency part if morphing is used?
[14:10:49] <skunkworks> that would allow you to get twice the frequency you would normally...
[14:11:00] <jepler> that's the part that's broken, I think
[14:11:07] <jepler> but I'm not sure at this point, except it don't work so good
[14:11:14] <skunkworks> heh
[14:13:26] <KGB-linuxcnc> 03Kim 05master 3612017 06linuxcnc 10docs/src/hal/ 10halui_examples.txt 10halui_examples_de.txt 10halui_examples_es.txt 10halui_examples_pl.txt * Docs: Fix a typo left over from rebranding
[14:13:26] <KGB-linuxcnc> 03Kim 05master de7f668 06linuxcnc 10src/Makefile * Docs: Fix typo left over from rebranding
[14:13:31] <KGB-linuxcnc> 03elson 05master 0f35a67 06linuxcnc 10docs/src/drivers/pico_ppmc.txt * keep 2.5 in synch with master docs
[14:13:37] <KGB-linuxcnc> 03seb 05master 6a19af0 06linuxcnc 10tests/ 10(9 files in 9 dirs) * tests: increase task/motion timeout
[14:13:43] <KGB-linuxcnc> 03seb 05master 59572ae 06linuxcnc 10src/Makefile * Merge branch 'v2.5_branch'
[14:13:48] <KGB-linuxcnc> 03seb 05v2.5_branch 6a19af0 06linuxcnc 10tests/ 10(9 files in 9 dirs) * tests: increase task/motion timeout
[14:57:58] <jepler> I think jon e's criticism of Propeller is not quite accurate. Each "cog" has 2kB of local RAM (von Neumann architecture) plus shared access to 32kB RAM + 32kB ROM. My impression is that it requires carefully writing code, but if your accesses to the shared memory happen on the right cycle it is relatively efficient (maybe no more than 2x the speed of the local RAM)
[14:58:52] <jepler> Propeller might not be a bad choice for step generators or encoder counters, because each cog could have one generate or read task
[15:10:30] <jepler> yes, you can read or write a long every 16 cycles from every cog, so your tight stepgen loop would involve copying frequency request from shared memory, adding it to your dds register, maybe outputting a step, and writing the new step count to shared memory. If the hub memory bandwidth is the limit, you can do that at 2.5MHz for a top step rate of 1.25MHz, not shabby at all.
[16:04:21] <KimK> seb_kuzminsky: (Re: your post of a couple days ago) So if I had already written a fix on the ja3 branch, and then if I had received your request to push fixes to ja4 instead, how could I "git" out of that problem? (I really need to read more about git.)
[16:05:21] <seb_kuzminsky> if you've pushed it to git.linuxcnc.org already, there's nothing you can do
[16:05:29] <seb_kuzminsky> if you haven't pushed it, you can do the following:
[16:05:46] <seb_kuzminsky> 1. use 'git cherry-pick' to copy the commit to the branch you want it on
[16:06:00] <seb_kuzminsky> 2. use 'git reset' or 'git rebase' to remove the commit from the branch it shouldn't be on
[16:06:31] <seb_kuzminsky> but we can't reset or rebase things that have been pushed to the shared repo, because that would mess everyone else up
[16:07:06] <KimK> Yes, "haven't pushed it" was what I intended to ask, sorry I wasn't clear on that.
[16:07:31] <seb_kuzminsky> i should grow some pimples, then i could charge $200/hr for all this git consulting:
https://www.youtube.com/watch?v=CDeG4S-mJts
[16:17:20] <KimK> Ja! Oops, I mean, yes!
[16:17:24] <seb_kuzminsky> heh
[16:41:30] <skunkworks> seb_kuzminsky: no turning back now..
https://www.youtube.com/watch?v=ZdJ6wSctXVA
[16:51:22] <memleak> In case anyone wants to know the ideal settings for the RTAI kernel, I just finished re-writing the docs for building RTAI and uploaded some good baseline example kernel configs.
[16:51:59] <memleak> link is here:
https://github.com/ShabbyX/RTAI
[16:52:46] <seb_kuzminsky> thanks memleak, i'll take a look at it
[16:53:05] <memleak> The file is README.INSTALL
[16:53:59] <memleak> yikes formatting issues..
[16:55:01] <seb_kuzminsky> cool skunkworks :-)
[17:01:51] <memleak> fixed that..
[23:08:16] <zultron> skunkworks, Stella looks just like her dad! Except her faux-hawk is cooler than her dad's 'do. :)
