Back
[00:18:18] <dgarr> some patches for tooledit:
http://www.panix.com/~dgarrett/stuff/0001-fix-angle-format.patch
[00:18:38] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-use-correct-name-for-default-tooleditor-tooledit-not.patch
[00:18:52] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-make-tkemc-tooledit-behavior-more-similar-to-axis.patch
[00:38:45] <jepler> dgarr: thanks. which do you think might be suitable for 2.4?
[00:41:47] <dgarr> was responding to messages i saw from new users of 2.4 so i think all are appropriate. i don't use tkemc any more but i think these fix the major problems with it and tooledit
[00:42:55] <jepler> OK, that's what I thought
[00:43:05] <jepler> I don't, either, but I'll give them a whirl
[00:44:41] <jepler> * jepler wishes for the 1000th time that 'git am' took a URL to get the patch from
[00:46:00] <dgarr> jepler: when you have time, you might be interested in a problem I've seen with ubuntu 10.04 and the savage video driver, notes:
http://www.panix.com/~dgarrett/stuff/missing_posstrs.txt
[00:50:54] <jepler> dgarr: same problem with 2.4 and master?
[00:52:22] <jepler> does the home indicator appear?
[00:53:16] <dgarr> yes -- no posstrs displayed with 2.4 or master using savage_drv, no home indicator either (tested, didn't test for limit indicator)
[00:54:18] <dgarr> display of posstrs was also correct when running emc on one machine and displaying on the laptop with savage_drv on a different machine (sigh)
[00:58:45] <jepler> dgarr: just for grins, try making this change:
[00:58:46] <jepler> +++ b/src/emc/usr_intf/axis/extensions/togl.c
[00:58:46] <jepler> @@ -1328 +1328 @@ static int Togl_Cmd(ClientData clientData, Tcl_Interp *interp,
[00:58:49] <jepler> - togl->Indirect = GL_FALSE;
[00:58:52] <jepler> + togl->Indirect = GL_TRUE;
[00:59:07] <jepler> I think running on a different machine is mostly the same as forcing indirect rendering
[00:59:51] <dgarr> will take a few minutes, brb
[01:01:54] <jepler> it sounds like this bug from 2004 :(
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg19770.html
[01:08:36] <dgarr> jepler: togl.c GL_TRUE did not change behavior, posstrs not displayed with savage_drv
[01:09:16] <jepler> dgarr: OK
[01:11:08] <dgarr> i don't know that it matters much, vesa may be ok since these laptops are pretty old (8 years maybe), i just get another on ebay when one dies
[01:11:50] <jepler> dgarr: this seems to be the 'drawpix' demo:
http://emergent.unpy.net/files/sandbox/drawpix.tar.gz
[01:12:06] <jepler> you can see whether it works or not, and whether toggling double-buffering makes a difference
[01:16:00] <dgarr> i seem to be missing a pakage for that: drawpix.c:12:21: error: GL/glut.h
[01:16:21] <jepler> freeglut3-dev
[01:25:03] <dgarr> thanks, got it, i don't know what it's supposed to do, says "Loaded 194 by 188 image" but i just see a black window (this is 10.04/savage_drv)
[01:25:10] <dgarr> the benchmark command works
[01:26:27] <jepler> an image should show up in the lower left corner if it's working
[01:26:45] <jepler> if you press "f" with focus in that window do you get an image?
[01:27:13] <jepler> so it looks like a driver bug. if the image appears after you hit "f" it is the same as the bug from 2004, otherwise it's different.
[01:34:16] <dgarr> now i see theres a file girl.rgp with the tarball when i use that filename as an arg, it behaves differntly but there is never an image, just a tiny pixelated blog that spills out of the window onto the whole screen
[01:36:43] <jepler> "blog", huh
[01:36:53] <jepler> I don't have to specify an arg to get an image
[01:37:25] <jepler> cleaned up one typo (ReLoad -> Reload) and modified the changelog messages a bit, but all your changes test good for me otherwise
[01:37:38] <dgarr> i meant blot, its only a few tens of pixels and replicated several places; I think it is pretty messed up in general, i should try it on a t23 with hardy
[01:37:39] <jepler> can you tell me why you need [eval exec] and not just [exec] ?
[01:38:52] <dgarr> re:eval just a pattern i've developed, probably not needed this case but i seem to remember it helps when variables contain blanks or something like that
[01:43:18] <jepler> ok, I'll leave it
[01:51:38] <cradek> dgarr: thanks for fixing that stuff so fast
[01:52:24] <dgarr> sorry for the problems but i had stopped using tkemc when tooledit was written so it didn't get tested much
[01:53:56] <jepler> huh, I wonder what I was up to -- I have patches over here to add a "binary mode" output to halsampler
[01:58:57] <CIA-2> EMC: 03jepler 07v2.4_branch * rf9cd27781bf4 10/tcl/tkemc.tcl: tkemc: fix tool editor
[01:58:58] <CIA-2> EMC: 03jepler 07v2.4_branch * r29393fe2a3aa 10/tcl/tkemc.tcl: tkemc: make the tool items more like axis
[01:58:59] <CIA-2> EMC: 03jepler 07v2.4_branch * ra661c173144d 10/src/hal/drivers/parport_common.h: parport: Don't believe linux parport feature bits
[01:59:00] <CIA-2> EMC: 03jepler 07v2.4_branch * re8bf553388da 10/src/modsilent: silence several bogus kernel build warnings
[01:59:06] <CIA-2> EMC: 03jepler 07v2.4_branch * rda78bc3a1a83 10/src/emc/usr_intf/tooledit.tcl: tooledit: fix angle format
[01:59:17] <jepler> dgarr: thanks again for those patches
[02:00:05] <jepler> bbl
[02:56:27] <jepler> huh, I can't have intended this change .. at least not in this commit
[02:56:28] <jepler> git show 570792c9ae5ec9f90fda2bc954ba23cc753b9478 -- src/rtapi/rtai_rtapi.c
[02:57:53] <cradek> nope, bet not
[03:00:21] <jepler> * jepler feels somewhat vindicated(?) by that commit being pre-git
[03:00:27] <jepler> it's not my fault; it was the tools
[03:07:21] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[03:14:14] <Azurra> hello, i`m developing a delta robot (three arms parallel robot) and i found in emc the solution to control the mechanism. can someone help me to introduce how to setup the kinematics of that robot in emc and the other things that i need to know? or better, the steps that i need to study/know to implement that? thank-you.
[13:47:39] <mozmck_work> micges_work: I cleaned up the Ubuntu10.04Notes some last night - see if that's any better.
[13:48:31] <skunkworks_> mozmck_work: how are the latency tests on the new rtai kernel?
[13:49:31] <mozmck_work> Well, so far pretty good when I can get it to boot. I just got the machine here at work to boot again, so I'm going to test that here shortly.
[13:50:12] <skunkworks_> neat - thanks for all your work on this.
[13:51:08] <mozmck_work> I think it was in the 15000 range but I can't remember for sure. 8.04 may have been a little better on this machine. I have been compiling with SMP enabled so that may adversely affect it a little.
[13:52:00] <mozmck_work> I have less hair now...
[13:52:15] <skunkworks_> heh
[13:52:49] <skunkworks_> from being on here for a few years. Building the rtai kernnel seems to be the least liked job.
[13:53:35] <micges_work> mozmck_work: thanks
[13:53:38] <mozmck_work> It wouldn't be near so bad if it didn't take so long to compile.
[13:53:43] <SWPadnos> building an RTAI kernel that is expected to run on more than one computer is the least liked job, I think :)
[13:53:59] <SWPadnos> you need a 24-core PC :)
[13:54:09] <mozmck_work> I need one of those new 6-core... you beat me too it!
[13:54:18] <mozmck_work> to
[13:54:26] <SWPadnos> 6 is old hat, you need 12 per socket
[13:54:59] <mozmck_work> heh, 6 would be more within my budget I think. I is poor!
[13:55:04] <SWPadnos> (but 6 is actually affordable - $200 for the cheaper one and $300 for the faster one, and they work in socket AM3 motherboards)
[13:55:11] <SWPadnos> heh, yeah
[13:56:10] <jepler> SWPadnos: I was just eyeing those .. won't it need a BIOS update, though?
[13:56:16] <SWPadnos> probably
[13:56:49] <SWPadnos> it is AM3 only also, so you'd need a relatively recent motherboard
[13:57:44] <jepler> I have TA780GX XE which is Socket AM3
[13:58:09] <SWPadnos> that should be fine (BIOS willing)
[13:58:11] <jepler> running a Phenom 9600 (X4) in it at the moment
[14:00:26] <mozmck_work> Time you get the board, cpu,memory, and harddrive it gets to be a lot of money for me anyhow. Maybe I should stand out by Walmart with a sign that says "Need money for a new computer"
[14:01:34] <jepler> yeah, it was nearly $600 by the time I had added a motherboard and 8GB RAM to my cart (8GB being overkill for building kernels, but I had in mind building hostmot2 firmwares)
[14:01:39] <SWPadnos> $550 or so for 6-core CPU, motherboard, case/PSU, 1TB+ hard drive, 4G or more RAM
[14:02:09] <SWPadnos> plus CD/kb/mouse/video card, if you're so inclined
[15:02:01] <mozmck_work> which branch has the latest code v2.4_branch or v2.4.0?
[15:02:45] <jepler> v2.4.0 is a tag which will always give you the exact same source code as the 2.4.0 packages
[15:02:59] <mozmck_work> ok
[15:03:09] <jepler> v2.4_branch is a branch which gets just bugfixes; later, 2.4.1 will be made from that branch
[15:03:33] <jepler> master gets new features and is generally permitted to be more broken. from time to time it also gets the bugfixes from v2.4_branch by merging
[15:04:00] <jepler> if your goal is to test emc2 on your new kernels, then I'd recommend you use v2.4_branch
[15:04:44] <mozmck_work> Can I add stuff for 10.04 packaging to the v2.4_branch? It will be some minor changes in the debian directory.
[15:06:02] <jepler> we want to have 2.4 on 10.04 so yes -- you should use v2.4_branch when working on that, and that's where a developer with push access will put your commits when they're ready.
[15:07:53] <mozmck_work> I have push access, just haven't used it in a while.
[15:08:25] <mozmck_work> I can show you the changes before I push though if you'd rather.
[15:08:38] <jepler> ok
[15:08:52] <jepler> that would be great -- I prefer to be conservative about what goes in to 2.4 and it's easier to do that before it's pushed.
[15:10:41] <mozmck_work> will do then - thanks.
[15:17:07] <skunkworks_> I have an i7 quad core that I like.. (shows 8 proccessors)
[15:17:16] <Azurra> hello, i`m developing a delta robot (three arms parallel robot) and i found in emc the solution to control the mechanism. can someone help me to introduce how to setup the kinematics of that robot in emc and the other things that i need to know? or better, the steps that i need to study/know to implement that? thank-you.
[15:21:36] <alex_joni> Azurra: start with the integrator manual
[15:21:41] <alex_joni> there's a section on kinematics
[15:44:52] <mozmck_work> when using run-in-place, how do I make it load the rtai_smi module?
[15:45:47] <mozmck_work> I put the entries in the scripts/rtapi.conf file but when I run lsmod while latency-test is running there is no rtai_smi module listed.
[15:57:41] <cradek> does it work when running installed?
[15:57:45] <alex_joni> mozmck_work: you could also install it using rtai's method: setsmi/rmsmi
[15:57:48] <cradek> (I'd be surprised to learn that they act differently)
[15:57:58] <alex_joni> cradek: iirc there was a difference
[15:58:21] <alex_joni> but I think in my case it was because of different versions/realtime scripts
[15:58:23] <cradek> I thought they both used the system's "realtime start"
[15:58:55] <alex_joni> realtime start is part of emc2, not rtai
[15:59:03] <alex_joni> so it'll use the rip realtime start
[15:59:06] <alex_joni> scripts/realtime start
[15:59:10] <cradek> oh ok
[15:59:16] <mozmck_work> I haven't installed it this time, but a few weeks ago it worked installed.
[15:59:58] <mozmck_work> so I run setsmi before running latency-test?
[16:10:35] <alex_joni> mozmck_work: sure, that might work iirc
[16:11:04] <alex_joni> mozmck_work: or you start realtime, then run setsmi, then the latency test
[16:11:19] <alex_joni> but running the rtai latency test is just as good a test as the emc2 one
[16:14:57] <mozmck_work> ok. finally got it load with setsmi
[16:15:14] <mozmck_work> I wonder why RIP doesn't load it?
[16:16:49] <mozmck_work> I made an rtai package with a modified version of the same debian directory y'all used for rtai in 8.04, and it puts the rtai executables under /usr/realtime-[kernel version]/bin, so they are not in the path.
[16:17:25] <mozmck_work> Should this be changed somehow so they are installed in /usr/bin?
[16:17:55] <alex_joni> I don't think so
[16:18:25] <alex_joni> we don't care much about rtai binaries, we only use .ko's and those get installed to their proper place
[16:19:49] <mozmck_work> ok. I just had to make minor changes and it works fine.
[16:20:28] <mozmck_work> for building a package for the newest rtai that is...
[16:22:50] <alex_joni> cool
[16:43:35] <dgarr> jepler: i tested drawpix on a t23/hardy/savage_drv and it looks ok there so i think savage_drv is broken on 10.04
[16:47:30] <andypugh> If the three-phase motor PWM patch is accepted, the next thing needed is a HAL component to drive it. I am currently thinking that it might be a job of 3 separate components depending on the motor type: One that takes three hall sensor states as input and does trapezoidal commutation, one that takes absolute encoder position and outputs sinusoidal PWM values, and one for incremental encoders that runs an alignment rout
[16:47:30] <andypugh> when a pin is toggled.
[16:47:40] <andypugh> The second two could probably be combined.
[16:48:02] <andypugh> Any other thoughts?
[16:55:57] <dgarr> for comment: add a reload button for tooledit:
http://www.panix.com/~dgarrett/stuff/0001-tooledit-conditionally-add-button-to-write-file-AND-.patch
[21:55:30] <JT-Work_> JT-Work_ is now known as JT-Work