Back
[01:20:41] <cradek> jepler: I think so
[02:12:55] <jepler> 4076 85227 649303 ../html/Master_User.html
[02:13:03] <jepler> this HTML file is probably a bit too big to be useful ..
[16:07:00] <jepler> cradek: I believe that, contrary to what you've said, the [EMCMOT]TRAJ_PERIOD value is used
[16:07:47] <jepler> cradek: I made motion.debug-s32-0 increment each time tpRunCycle is called, and .debug-s32-1 increment each time get_pos_cmds is called, and the one value has a much greater slope than the other when running a gcode program
[16:13:43] <SWPadnos> all the configs loadrt [EMCMOT]EMCMOT ... traj_period_ns=[EMCMOT]TRAJ_PERIOD ...
[16:19:43] <jepler> yes, that's true
[16:20:02] <jepler> if I understood what chris told me once, he thought that the value was ultimately ignored, even though it passes through several layers of code
[16:25:07] <alex_joni> all I can remember is that traj and servo period run at the same cycle time, although they should be 5x-10x apart
[16:28:04] <SWPadnos> yeah - running servo at the traj rate seems not so useful
[16:31:46] <jepler> for trivial machines, do the GUIs use the free planner or the teleop planner?
[16:31:53] <SWPadnos> yes!
[16:31:57] <SWPadnos> no!
[16:32:01] <SWPadnos> I have no idea!
[16:32:04] <jepler> me either
[16:32:19] <SWPadnos> is the free planner the coordinated motion planner?
[16:32:35] <jepler> no, that's the other one
[16:32:39] <SWPadnos> oh
[16:32:51] <SWPadnos> ah, free is the jog mode / homing mode one
[16:32:53] <SWPadnos> ?
[16:32:56] <jepler> EMCMOT_MOTION_COORD is used for running gcode
[16:33:19] <jepler> EMCMOT_MOTION_FREE moves in joint space, and EMCMOT_MOTION_TELEOP moves in axis space
[16:33:45] <SWPadnos> ok, so yes, trivial machines do use the free planner for jogs and homing (I think)
[16:34:02] <jepler> EMCMOT_MOTION_TELEOP seems to use the [TRAJ]DEFAULT_ACCELERATION value as a limit
[16:34:26] <SWPadnos> and teleop / coord have the same effect, even if they're different sections of code
[16:35:00] <SWPadnos> that makes sense. teleop doesn't know if it's on trivkins or complexkins, so it can't use joint limits
[16:35:38] <SWPadnos> err - nevermind. using DEFAULT as a limit makes no sense
[16:36:03] <jepler> there are a lot of layers involved so I'm not sure of this..
[16:36:40] <fenn> jepler: it depends if you are using world or joint coords
[16:37:49] <fenn> if s.motion_mode == emc.TRAJ_MODE_TELEOP:
[16:38:14] <cradek> /*! \todo FIXME FIXME FIXME - need to put a rate divider in here, run it at the traj rate */
[16:38:18] <cradek> (motion/control.c)
[16:38:45] <SWPadnos> heh
[16:39:14] <SWPadnos> I wonder what the output of `grep -Ri "FIXME FIXME FIXME" * | wc -l` would be :)
[16:39:30] <jepler> not hard to find out
[16:39:39] <SWPadnos> it is on this windows machine
[16:39:40] <cradek> in emcmotController, everything always gets run
[16:39:46] <cradek> I don't see any kind of divider
[16:39:57] <jepler> $ ./scripts/swish FIXME | wc -l
[16:39:57] <jepler> 236
[16:40:11] <cradek> hmm, but I spell it "XXX"
[16:40:36] <fenn> somehow tkemc gets it right, although looking at the code it seems to be doing it wrong
[16:47:26] <alex_joni> fenn: gets what right?
[16:47:50] <fenn> teleop jogging
[16:56:52] <alex_joni> ah.. and who doesn't?
[16:58:05] <fenn> axis had some problems after uvw was added
[16:58:44] <fenn> has anyone tested tkemc with 9 axes?
[16:58:57] <alex_joni> not me
[17:00:16] <fenn> doesnt seem to know about uvw
[17:01:01] <fenn> and strangely enough, abc is out of order
[17:01:17] <alex_joni> fenn: ???
[17:01:36] <alex_joni> I know I ran tkemc with 6 axes, and it used to be fine
[17:04:30] <fenn> i copied axis_9axis.ini and changed it to use tkemc.. now it shows XYZCAB but when you click on A it jogs B and B jogs C and C jogs A
[17:09:59] <alex_joni> * alex_joni smiles at the reason
[17:10:12] <alex_joni> tkemc assumed XYZ ABC (or RPW)
[17:10:20] <alex_joni> RPW maps to ABC 1:1
[17:10:31] <alex_joni> so the W in there screws up the ABC
[17:10:43] <alex_joni> bogus assumption.. trying a fix now
[17:12:16] <alex_joni> ok, XYZABC work right now
[17:12:23] <alex_joni> but UVW still don't appear
[17:12:39] <SWPadnos> look for the number 6 somewhere ;)
[17:12:43] <alex_joni> :P
[17:12:45] <alex_joni> actually 5
[17:12:46] <SWPadnos> heh
[17:12:55] <SWPadnos> what, tkemc counts from 0?
[17:13:00] <alex_joni> yup
[17:20:48] <alex_joni> bleah.. this is a major diff
[17:21:44] <alex_joni> I think ray never heard of loops
[17:22:00] <SWPadnos> heh
[17:22:07] <SWPadnos> probably not when he started tkemc
[17:22:33] <skunkworksguts> is this normal?
http://pastebin.ca/733242
[17:24:01] <skunkworksguts> http://pastebin.ca/733243
[17:25:19] <alex_joni> nope, but you'll never know that
[17:25:27] <SWPadnos> heh
[17:25:47] <SWPadnos> hard memlock. that can't be good
[17:25:57] <SWPadnos> or maybe it doesn't matter
[17:26:00] <alex_joni> * alex_joni didn't look
[17:26:10] <skunkworks> thought it was odd
[17:26:22] <skunkworks> trying one more time
[17:26:50] <SWPadnos> it looked like it was trying to load modules at install time - that's not a good thing
[17:27:42] <alex_joni> now I'll be damned
[17:27:48] <SWPadnos> damn you!
[17:29:23] <alex_joni> http://imagebin.org/10997
[17:29:40] <SWPadnos> where;s the G-code listing? :)
[17:29:47] <alex_joni> out of my screen
[17:29:54] <SWPadnos> right - oops
[17:31:04] <skunkworks> well - maybe this hardware isn't suited..
[17:31:45] <skunkworks> 1.4ghz pentium 4 rambus.
[17:31:55] <fenn> sure sure blame the computer
[17:32:24] <skunkworks> I just tried to re-install emc deb and got the exact same error. I think I followed the same steps I did yesterday on different hardware.
[17:33:40] <alex_joni> fenn: can you jog UVW in world?
[17:33:50] <alex_joni> using AXIS I mean..
[17:34:03] <alex_joni> with tkemc I can jog, but the readout doesn't change
[17:34:08] <alex_joni> only when in joint mode
[17:36:21] <alex_joni> argh.. I can't change the fontsize :/
[17:36:33] <fenn> you cant jog in teleop mode because UVW isnt part of the XYZABC coordinate system
[17:36:50] <alex_joni> ok.. in joint mode it works
[17:38:09] <alex_joni> http://imagebin.org/10999
[17:38:17] <alex_joni> fenn: can you test tkemc if I commit this?
[17:38:24] <alex_joni> I'm sure it counts as a bugfix
[17:39:49] <fenn> sure
[17:39:55] <skunkworks> hmm - now the computer hard locked..
[17:42:12] <alex_joni> juve@taurus:~/emc2.TRUNK/tcl$ cvs diff -u | wc -l
[17:42:16] <alex_joni> 442
[17:45:25] <alex_joni> fenn: commited now.. let me know how it works
[17:46:41] <fenn> hrm. how am i supposed to start tkemc and axis at the same time?
[17:47:07] <alex_joni> manually
[17:47:18] <alex_joni> * alex_joni forgot the details
[17:47:33] <alex_joni> but you go to the config dir (e.g. configs/sim)
[17:47:53] <fenn> and then ../../tcl/tkemc.tcl right?
[17:48:10] <alex_joni> ../../tcl/tkemc.tcl -ini foo.ini
[17:48:31] <fenn> ah right duh :)
[17:49:59] <fenn> when i try to jog uvw in world mode, it actually does update uvw in axis, but stays at 0 in tkemc
[17:50:15] <alex_joni> ah, that's what I was asking..
[17:50:18] <alex_joni> * alex_joni goes look
[17:54:17] <alex_joni> found the culprit
[17:56:07] <fenn> hang him up by his toes!
[18:08:33] <alex_joni> fenn: it's been hanged
[18:12:18] <cradek> man everything that's been touched by 'indent' sucks
[18:12:26] <cradek> (puzzling through emcsh.cc)
[18:12:27] <alex_joni> fenn: let me know how it works
[18:12:34] <alex_joni> sucks how?
[18:12:53] <cradek> the lines are broken in bizarre places to unnecessarily keep things under 80 columns
[18:13:00] <alex_joni> you mean the .. yeah
[18:13:12] <alex_joni> motion. \
[18:13:16] <alex_joni> traj. \
[18:13:22] <alex_joni> actualPosition.b
[18:13:23] <cradek> line breaks have some conceptual meaning when the programmer does them
[18:13:29] <cradek> yeah that crap
[18:13:49] <SWPadnos> holy shit. what programmer would make a program capable of mangling code that badly?
[18:14:11] <cradek> well, it probably does exactly what it's asked (make it < 80 cols)
[18:14:30] <cradek> it's just that running it is a mistake
[18:14:36] <fenn> editors have this neat feature called 'word wrap'
[18:14:45] <SWPadnos> letting it break at non-whitespace characters is a mistake
[18:14:57] <alex_joni> Joseph Arceneaux, Carlo Wood & David Ingamells
[18:15:20] <SWPadnos> well they're stupid! ;)
[18:16:02] <cradek> my favorite so far is Interp::find_ends()
[18:16:06] <cradek> (in interp_find.cc)
[18:16:13] <cradek> I had to wade through that crap recently
[18:16:38] <cradek> hahaha look at line 212
[18:16:38] <alex_joni> eww
[18:16:48] <cradek> it's < 80 columns, I'll give you that
[18:16:54] <alex_joni> you mean line 212..218
[18:17:00] <cradek> yes :-)
[18:17:07] <cradek> ? ((comp
[18:17:15] <cradek> ^^ and this is one of the lines...
[18:17:32] <alex_joni> (block->b_flag ==
[18:17:41] <alex_joni> ON) ? (...)
[18:17:46] <cradek> haha
[18:18:00] <fenn> alex_joni: tkemc looks the same
[18:18:05] <cradek> and it appears that I faithfully copied the existing "style" too
[18:18:11] <alex_joni> fenn: what do you mean?
[18:18:20] <cradek> that makes me an idiot or a genius practical joker, I'm not sure which
[18:18:25] <alex_joni> cradek: check out 296,297
[18:18:30] <fenn> uvw still read 0 in world mode
[18:18:46] <alex_joni> fenn: you did recompile.. didn't you?
[18:19:02] <alex_joni> this was a change in emcsh
[18:19:15] <alex_joni> *z2 =
[18:19:18] <alex_joni> (z1 -
[18:19:25] <alex_joni> (settings->..
[18:19:54] <fenn> at emc2/ i did cvs up -dPA; cd src; make
[18:20:20] <alex_joni> fenn: it works here..
[18:20:48] <fenn> and emcsh got updated
[18:24:33] <alex_joni> fenn: can't think of any reason for it not to work
[18:25:00] <alex_joni> you're using axis_9axis.. right?
[18:25:08] <fenn> yes
[18:25:13] <alex_joni> make clean?
[18:26:27] <cradek> why are axes 3..8 in their own "else"?
[18:27:08] <cradek> and is that "FIXME -- no rotational offsets yet" stuff just outdated?
[18:27:49] <alex_joni> cradek: I think the own else was because they used to be rotational axes at some point
[18:28:06] <alex_joni> no idea why the own else though.. it doesn't harm though, so I didn't change it
[18:28:27] <cradek> and I also wonder what's wrong with switch()
[18:28:39] <cradek> but now I'm just complaining
[18:28:44] <alex_joni> * alex_joni tries to swallow a response
[18:29:08] <cradek> if I rewrote everything that was written stupidly ... I'd be busy and introduce a lot of bugs
[18:29:19] <alex_joni> * alex_joni agrees
[18:29:27] <skunkworks> jepler: did you see the error I was getting?
[18:30:09] <jepler> skunkworks: no, I missed it
[18:30:18] <alex_joni> [ 486.928987] RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED
[18:30:27] <alex_joni> cradek: brings up memories? ;-)
[18:30:46] <alex_joni> jepler: that was from skunkworks' pastebin
[18:30:51] <skunkworks> well then there was this
http://pastebin.ca/733242
[18:31:20] <skunkworks> I am thinking it may be me though.. this is a bit odd hardware wise
[18:32:42] <jepler> [ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[18:32:46] <jepler> yeah this does seem familiar
[18:32:54] <jepler> so try lapic and tell us what happens :-P
[18:33:15] <alex_joni> skunkworks: can you try 'ulimit -a' ?
[18:33:45] <jepler> the 'hard memlock 20480' is a harmless message
[18:34:04] <alex_joni> yeah, still.. it's interesting to see what his limit is set to
[18:34:12] <alex_joni> on this dapper box it's set to unlimited
[18:34:21] <jepler> on gutsy, the amount of locked memory a user can have is set to a fairly low value. that's the line which increases the limit, which I look for with a 'grep' before adding it (again)
[18:34:40] <jepler> I didn't silence the grep, so if you're installing the package a second time, the grep prints the existing line
[18:35:01] <alex_joni> ahh
[18:36:02] <alex_joni> fenn: still not working?
[18:36:06] <cradek> yeah I've seen that before
[18:36:15] <cradek> you can rebuild ... something ... to fix it
[18:36:27] <alex_joni> kernel obviously :)
[18:36:35] <cradek> or maybe rtai
[18:36:37] <cradek> or both
[18:36:40] <cradek> I don't remember
[18:37:09] <skunkworks> booting
[18:37:30] <alex_joni> woo.. this is interesting
[18:37:42] <alex_joni> * alex_joni is running 3D_Chips in the 9axis config
[18:37:52] <alex_joni> and I wonder why ABCUVW change values
[18:39:08] <alex_joni> err.. UVW don't (they just changed from mm to inch), but ABC reliably go through a lot of values when 3D_Chips starts
[18:39:13] <fenn> alex_joni: sorry i got distracted. tkemc now displays uvw right
[18:39:24] <fenn> however, mdi no longer works
[18:39:24] <alex_joni> fenn: ok :)
[18:39:27] <alex_joni> what?
[18:39:50] <fenn> linear move in MDI would exceed limits
[18:39:56] <fenn> if i g0 any axis
[18:39:58] <alex_joni> works here
[18:40:09] <fenn> i get it with axis too
[18:40:18] <alex_joni> you probably have some offsets
[18:40:19] <cradek> I don't see anything wrong with abcuvw running 3d_chips
[18:40:32] <alex_joni> cradek: don't ABC change values?
[18:40:35] <cradek> no
[18:40:50] <alex_joni> runnign AXIS?
[18:40:59] <cradek> yes
[18:41:03] <cradek> Machine configuration directory is '/usr/local/src/emc2.trunk/configs/sim'
[18:41:03] <cradek> Machine configuration file is 'axis_9axis.ini'
[18:41:12] <alex_joni> * alex_joni was running tkemc
[18:41:33] <cradek> hmmmmm
[18:41:59] <alex_joni> looks ok in AXIS
[18:42:29] <cradek> something makes me think you don't have tkemc right yet...
[18:42:49] <fenn> yah its displaying some crazy numbers here
[18:43:25] <jepler> I have a few-days-old tkemc here; it displays XYZABC and ABC stick at 0
[18:44:12] <jepler> let me see what happens if I 'cvs up'
[18:44:14] <fenn> when in world mode, all the coordinates change by a factor of 25.4
[18:44:32] <alex_joni> fenn: that depends on the G2x chosen
[18:44:42] <alex_joni> and is to be expected.. I think
[18:45:03] <alex_joni> but what I see is that if I keep ABC at 0, nothing happens when running 3D_Chips
[18:45:04] <fenn> even for abc?
[18:45:22] <cradek> why would switching to teleop scale by 25.4?
[18:45:24] <alex_joni> if they are != 0, then they change in the beginning.. no idea why
[18:45:30] <cradek> g20/g21 do not affect abc
[18:45:48] <alex_joni> cradek: obviously because it's broken
[18:46:09] <alex_joni> from what I look at it : it always does inches in joint mode
[18:46:11] <cradek> oh
[18:46:17] <alex_joni> and in world mode it converts to mm
[18:46:25] <alex_joni> (all joints: 0..8)
[18:46:30] <fenn> that sounds somewhat backwards to me
[18:46:33] <alex_joni> even ABC and UVW
[18:46:45] <alex_joni> * alex_joni won't try to fix this
[18:46:55] <cradek> units issues are not terribly well thought out in tkemc </understatement>
[18:47:00] <jepler> come to think of it, axis probably displays UVW wrong
[18:47:06] <jepler> unless cradek tested it
[18:47:33] <jepler> or maybe it's right
[18:47:34] <cradek> what do you think I am, an amateur? oh, wait
[18:47:47] <alex_joni> heh, the ABC issue is in AXIS too
[18:47:57] <fenn> axis displays the same thing that halcmd does
[18:48:02] <alex_joni> cradek: try jogging ABC to some nonzero positions
[18:48:02] <cradek> which one (teleop?)
[18:48:12] <alex_joni> then run 3D_Chips
[18:48:43] <jepler> I issued "g0x1a1u1" with gcode in inches. Then I switched between inch and mm displa. x and u change, a stays the same
[18:49:09] <cradek> jepler: ok that's right
[18:49:15] <cradek> alex_joni: I don't understand
[18:49:18] <fenn> jepler: in the old tkemc?
[18:49:29] <alex_joni> cradek: start axis_9axis.ini
[18:49:38] <alex_joni> cradek: jog XYZABC to non-zero positions
[18:49:44] <alex_joni> all of them
[18:49:51] <alex_joni> then load 3D_Chips.ngc
[18:49:53] <alex_joni> then run
[18:50:43] <cradek> oh you're not saying there's a units thing wrong in AXIS
[18:50:54] <cradek> it's a 'tool change position' bug
[18:50:55] <alex_joni> no.. I'm saying the numbers change
[18:51:03] <alex_joni> ahh.. right
[18:51:07] <cradek> I'll find it
[18:51:11] <jepler> at the start, it moves to the tool change position (which includes A0B0C0)
[18:51:15] <alex_joni> I don't think it's a bug
[18:51:18] <alex_joni> jepler's right..
[18:51:23] <jepler> then it moves back to the old ABC on the next move after the tool change
[18:51:26] <alex_joni> * alex_joni forgot about that
[18:51:25] <cradek> that's the bug
[18:51:56] <cradek> well in this config TOOL_CHANGE_PSOTION is 0 0 2
[18:52:04] <cradek> so, should it move ABC at all? I dunno
[18:52:09] <alex_joni> probably
[18:52:10] <cradek> moving it both direcionts is probably wrong
[18:52:14] <cradek> why the hell can't I type
[18:52:25] <fenn> does it move uvw too?
[18:52:30] <alex_joni> no
[18:52:33] <jepler> fenn: toolchange can't move uvw
[18:52:51] <cradek> tool change position is ill-thought-out
[18:53:04] <cradek> and I made it worse when I halfassedly added support for ABC position
[18:53:04] <alex_joni> * alex_joni postpones this for 2.4.0
[18:53:10] <jepler> all the way up to 2.4.0 now?
[18:53:15] <skunkworks> heh
[18:53:24] <cradek> 2.17.3
[18:53:25] <alex_joni> first we get joints/axes right for 2.3.0
[18:53:37] <jepler> that's a fine goal as long as I don't have to do it
[18:53:46] <cradek> or me
[18:53:48] <alex_joni> * alex_joni started a couple times
[18:53:58] <alex_joni> ended up fixing it by doing up -dPC
[18:54:07] <fenn> might need its own branch
[18:54:12] <alex_joni> cvs up -dPC
[18:55:31] <fenn> or you could learn git if you're selfish :)
[19:00:48] <probin> hi
[19:01:35] <probin> when inside a realtime hal typical read/write function, are hardware interrupts disabled?
[19:01:35] <cradek> strange, I don't spot the bug I expected in CHANGE_TOOL()
[19:02:52] <jepler> the interpreter has to fetch the internal position after a tool change, since it may have changed .. that's what I first thought of
[19:03:07] <alex_joni> probin: I think so
[19:03:21] <cradek> jepler: you're right, it must be up a level
[19:03:47] <jepler> a "slow" HAL thread can be interrupted by a "faster" one, but execution of any non-realtime code in the linux kernel should not be possible.
[19:04:41] <probin> ok, but if a hardware interrput, say from the ethernet PCI card comes in, will it interrupt the realtime HAL write fuction
[19:05:16] <probin> let me be more precise
[19:05:38] <probin> I installed rtnet
[19:05:49] <jepler> in that case, the answer is "I don't know"
[19:05:56] <probin> rtnet runs in realtime using rtai
[19:05:59] <probin> ok
[19:06:15] <jepler> if it was a linux kernel driver for the network card, you could be assured its driver code wasn't entered while a HAL thread is executing
[19:06:25] <jepler> but I don't know the answer when the other code is RTAI real-time code
[19:06:44] <alex_joni> I think hardware interrupts are disabled while RT code is running
[19:06:45] <probin> ok
[19:07:03] <alex_joni> at least that's how hard RTOS'es do it..
[19:07:39] <probin> makes sens
[19:07:46] <fenn> ethernet cards have a small amount of buffering right?
[19:07:53] <probin> yes
[19:10:49] <jepler> you might consider a polling approach instead of an interrupt-driven approach, if rtai allows it. write one packet each thread execution, and read up to one packet each thread execution.
[19:11:03] <probin> does anyone know if work has been done to integrate rtnet with EMC2. I have been playing with it and can send packets in a HAL "write" function. I am now looking at ways to receive back packets as fast as possible. Receiving packets is interrupt based in rtnet so it is a bit tricky
[19:11:26] <probin> jepler, that is exactly what I want to do
[19:11:40] <alex_joni> probin: there was a guy who did it a while ago
[19:11:48] <alex_joni> integrate rtnet with HAL
[19:11:53] <probin> but to do it means modifying each ethernet card dirver I want to support. I am looking at alternatives
[19:12:05] <alex_joni> check the mailing list archive.. he sent his results
[19:12:24] <jepler> probin: what happens when you attempt to allow these interrupts?
[19:13:57] <probin> I am about to try this. I want to try it also to get a time scale of the overhead involved in using the interrupt mechanism instead of polling
[19:14:41] <probin> there is quite a bit of code executed in rtnet when a packet is received. Overkill for CNC typc applications
[19:14:54] <probin> And slows things down
[19:15:59] <probin> All I nned is to write one 64 byte packet and read one back right aften. No tcp/ip stack invloved
[19:16:23] <probin> that gives a roundtrip under 2us
[19:16:36] <SWPadnos> alex_joni, are you thinking of Eric Johnson and the remote shell?
[19:16:37] <probin> I have the read working
[19:16:47] <probin> the write, sorry
[19:17:26] <SWPadnos> probin, I haven't looked at the code lately, but I suspect that interrupts are not disabled while inside HAL functions
[19:18:22] <jepler> there are functions tai_cli() / rtai_sti() / rt_enable_irq() / rt_disable_irq() in rtai_usi.h -- perhaps some calls to these needed to be added in rtai_rtapi.c in the correct places, if indeed it is correct to disable these interrupts during rtapi thread execution.
[19:18:29] <jepler> s/tai_cli/rtai_cli/
[19:18:30] <SWPadnos> I don't believe there's any difference to HAL whether the function is running in a high priority thread or in a low priiority thread. If that's true, then some interrupts must be enabled so that higher priority threads can interrupt low priority threads
[19:18:37] <jepler> (header rtai_usi.h)
[19:18:52] <SWPadnos> I don't believe it is correct in the general case
[19:20:04] <probin> can HAL function be preempted by RTAI ?
[19:20:14] <probin> ok
[19:20:30] <SWPadnos> yes, or it wouldn't be possible for a high priority HAL thread to interrupt a lower priority HAL thread
[19:21:55] <probin> Is there a problem in running a EMC HAL function at the highest priority?
[19:22:10] <SWPadnos> no, there's always a highest priority ;)
[19:22:20] <probin> good
[19:22:46] <SWPadnos> the BASE_THREAD has the highest priority of any HAL threads. I'm not sure how that maps to RTAI priorities
[19:23:14] <SWPadnos> the problem there is that the highest priority thread in HAL is always the fastes thread
[19:23:17] <SWPadnos> fastest
[19:23:55] <SWPadnos> so if you want to look at ethernet every 1ms, but you don't want to get interrupted while doing it, then that must be the fastest HAL thread
[19:24:12] <probin> is there a way to set the priority of a HAL thread besides using the BASE_THREAD name
[19:24:21] <SWPadnos> not at the moment, AFAIK
[19:24:38] <probin> that is ok for my setup
[19:24:53] <SWPadnos> if you want to earn the eternal gratitude of the EMC community (or at least one or two of them), you could add "interrupt threads" to HAL
[19:24:55] <SWPadnos> :)
[19:25:01] <probin> the "servo" thread is the fastest and that is the one talking to ethernet
[19:25:21] <SWPadnos> that's a feature that has been discussed before, but nobody has ever gotten the time (or willpower) to do it :)
[19:25:43] <SWPadnos> if someone changes your config, then that will break
[19:26:02] <SWPadnos> ie, they decide to add another quadrature input in software, and make a 100 uS thread to do it
[19:26:27] <probin> break it , I am not sure
[19:26:33] <probin> add delay, yes
[19:26:43] <SWPadnos> it would no longer ne tje joghest priority thread
[19:26:45] <probin> depends how fast the other thread finishes
[19:26:47] <SWPadnos> so it could get interrupted
[19:26:57] <SWPadnos> wow, that was a bad mis-spelling!
[19:27:11] <SWPadnos> it would no longer be the fastest thread, so it would be interruptible
[19:27:14] <SWPadnos> phew!
[19:27:48] <SWPadnos> gotta run - bbiab
[20:06:53] <skunkworks> So my issue is similar to the mutiproccessor kernel cradek had built - doesn't work on older hardware very well?
[20:07:17] <skunkworks> (apic issue)
[20:07:18] <jepler> skunkworks: you tried lapic and it didn't work?
[20:07:34] <skunkworks> crap - missed that. hold on.
[20:07:58] <skunkworks> wait - is that something I can run from terminal - or add in the boot thingy
[20:08:20] <jepler> add in the grub bootloader
[20:08:39] <skunkworks> ok - I remember trying this with cradeks. let me see if I can make it work.
[20:09:21] <SWPadnos> the kernel has to support it, and there may also be a BIOS setting for local APIC
[20:09:45] <cradek> iirc skunkworks's machine just won't work
[20:09:53] <SWPadnos> or that ;)
[20:10:16] <cradek> it's what made me give up on a smp kernel for the cd
[20:10:34] <skunkworks> wait - it was my fault?
[20:10:59] <skunkworks> it actaully didn't work on my single proccessor portable also
[20:11:19] <skunkworks> (non dual core/hypertreading/duo)
[20:11:41] <cradek> I think a lot of non-intel machines don't work
[20:11:49] <cradek> (I don't know all the details)
[20:12:59] <skunkworks> seemed the bit I played with it - multi proccesor or anything including or above hyperthreading seemed to work ok.
[20:13:04] <skunkworks> but it has been a while.
[20:13:05] <SWPadnos> this computer is an Intel P4
[20:13:17] <cradek> oh hm
[20:13:18] <SWPadnos> with RamBus(tm)(c)(r)
[20:13:28] <cradek> you'd think that would work
[20:13:28] <skunkworks> huh - that is what this is
[20:13:41] <skunkworks> or are you talking about mine..
[20:13:44] <cradek> haha rambus
[20:13:47] <SWPadnos> that's what I was talking about. I don't have any of those :)
[20:14:04] <skunkworks> yah yah - we have 2 of these things - good luck finding ram
[20:14:33] <cradek> oh it's easy to *find*
[20:14:36] <cradek> not so easy to buy
[20:14:53] <SWPadnos> http://www.geeks.com/details.asp?invtid=256RIMM800ECC-N&cpc=SCH
[20:14:54] <skunkworks> *seemed like a good idea at the time..
[20:15:59] <cradek> SWPadnos: interesting, I thought it was more.
[20:16:00] <skunkworks> the last time I looked - no one had any in stock
[20:16:12] <cradek> if you had plenty of slots, that wouldn't be too bad
[20:16:12] <skunkworks> even crucial
[20:16:20] <SWPadnos> that's about the cost of 1G of DDR2/DDR3, but still :)
[20:16:56] <SWPadnos> you can probably get loads of memory and other spare parts by buying whole systems from www.retrobox.com
[20:17:22] <SWPadnos> hmmm - or whatever they are now
[20:17:38] <cradek> http://www.use-enco.com/CGI/INSRIT?PMAKA=240-2874&PMPXNO=4840178&PARTPG=INLMK3
[20:17:51] <cradek> can anyone guess whether this has a taper in it, or is just a hole?
[20:18:16] <cradek> I need one of these but would like it to have the taper so I can use it for length setting too
[20:18:59] <cradek> (I don't think measuring from the flange is any good)
[20:20:42] <cradek> if I'm going to pay $80 it better do both things!
[20:20:46] <cradek> maybe I should call (which is always fun)
[20:21:35] <skunkworks> so - I can just add a line to the grub while booting? just add a line with lapic?
[20:21:39] <skunkworks> (to test)
[20:21:51] <skunkworks> hitting escape at the boot time.
[20:21:52] <cradek> yes you can do it while booting
[20:21:56] <SWPadnos> skunkworks, you can edit the line for testing purposes
[20:21:59] <cradek> append it to the kernel command line
[20:22:09] <skunkworks> just lapic or no lapic?
[20:22:10] <SWPadnos> select the line to edit, the press e at the menu
[20:22:23] <SWPadnos> move down to the kernel line, press e again
[20:22:25] <skunkworks> yes
[20:22:44] <SWPadnos> make the changes, press enter, then b to boot (if you go back to the main menu, the changes are lost)
[20:23:10] <SWPadnos> the error message looked like it wanted the apic enabled
[20:23:22] <SWPadnos> dunno the incanctaion to make that work, if it isn't automatic
[20:23:51] <cradek> lapic is what you want to add
[20:23:53] <SWPadnos> cradek, there's a small description of the use of that tightener here:
http://www1.mscdirect.com/CGI/NNPDFF?PMPAGE=1624&PMT4NO=30804959&PMT4TP=*ITPD&PMITEM=84941251&PMCTLG=00
[20:23:59] <SWPadnos> top right
[20:24:30] <SWPadnos> of course, they're too stupid to use PDF files for catalog pages, so you need flash
[20:24:33] <SWPadnos> idiots
[20:24:34] <cradek> wow, their prices are much higher...
[20:24:40] <cradek> s/PDF/html/
[20:24:55] <cradek> hmm "to radially hold"
[20:25:09] <cradek> I wonder what that means
[20:26:03] <cradek> maybe I should just make what I want. the taper could be Al with a steel plate and pins on top
[20:26:41] <SWPadnos> if only we could turn polygons ;)
[20:27:11] <cradek> hmm I'm not sure the sherline could turn that size.
[20:27:39] <cradek> and I hesitate to try to turn any taper on the sloppy manual lathe
[20:27:46] <cradek> well, guess I need a new lathe to save $84
[20:29:31] <SWPadnos> that makes sense
[20:29:44] <cradek> yeah
[20:29:47] <SWPadnos> well, you'd only save around $75 or so - you still have to buy stock
[20:29:54] <cradek> cnc too, because everyone knows you can't turn a taper without cnc
[20:30:07] <SWPadnos> you can't turn a polygon without CNC, that's for sure
[20:35:50] <skunkworks> this computer sucks
[20:36:13] <skunkworks> http://www.electronicsam.com/images/KandT/gutsy.png
[20:36:37] <skunkworks> it gets latency errors running the 50us period.
[20:37:10] <cradek> nice encoding problem there
[20:37:35] <cradek> 25.0Âs
[20:37:36] <skunkworks> yeh - that to
[20:37:37] <skunkworks> too
[20:37:44] <jepler> hm is that the copy of latency-test that you downloaded yourself?
[20:37:49] <skunkworks> yes
[20:38:07] <jepler> I'll bet cvsweb or firefox screwed it up, but I could be wrong
[20:38:06] <skunkworks> ran it from your link yestday with the bash command
[20:38:23] <skunkworks> well - as you can see :)
[20:38:41] <jepler> yeah
[20:39:52] <skunkworks> but lapic seemed to make it work.
[20:40:03] <jepler> "work" with 300us latency?
[20:41:22] <skunkworks> well - yeah. I thought it was 30us
[20:41:41] <skunkworks> missed a decmal place.
[20:41:55] <skunkworks> bad. but it is staying at 300us :)
[20:42:22] <SWPadnos> consistently bad!
[20:42:47] <jepler> I could compile a kernel image without apic, which is the way all the other kernels are
[20:43:00] <jepler> but I read something on the rtai list that says apic gives less latency
[20:43:19] <jepler> actually, something to the effect of 'you got bad latency because you disabled apic', but I can't find it now
[20:43:20] <SWPadnos> doesn't it also give access to the higher resolution timers?
[20:44:07] <jepler> yes, the timer resolution is higher
[20:44:07] <jepler> not sure if that's important or not
[20:44:07] <SWPadnos> I was just reading the intel developers handbook. I wish I could remember what it said about APICs
[20:44:30] <SWPadnos> it's for P4-era chips also, so it may be a little out of date
[20:44:58] <skunkworks> still have the odd issue with the windows acting funny - the axis preview likes to be on top of whatever I have in the foreground. this is a different video card (ati radion)
[20:45:15] <cradek> I bet they broke mesa
[20:48:56] <jepler> they're probably trying to make jiggly windows work or something
[20:49:10] <skunkworks> http://www.electronicsam.com/images/KandT/Oddvideo.png
[20:49:36] <cradek> if mesa is broken, gutsy is no use to us
[20:49:39] <skunkworks> the cone is screwed up also.
[20:50:03] <jepler> cradek: in fairness it's not released yet
[20:50:07] <skunkworks> heh
[20:50:08] <cradek> right
[20:50:18] <cradek> wonder if they have bug reports about it yet (surely so)
[20:50:31] <skunkworks> I thought though that it was a week or 3 away..
[20:52:01] <jepler> skunkworks: do you have all the updates? I had a ton after I installed from whatever CD image, and a ton a week later..
[20:52:28] <jepler> on the other hand, if you updated since I did two weeks ago, *you* have the newer X server
[20:52:39] <jepler> I didn't have this problem but mine's an on-board nvidia
[20:53:07] <jepler> vesa driver
[20:53:18] <jepler> the two cards you've mentioned, ati and intel, both have some degree of opengl acceleration
[20:53:28] <jepler> (and they probably want very much to get something that's at least usable for jiggly windows..)
[20:54:15] <cradek> * cradek makes a face
[20:54:17] <jepler> skunkworks: anyway, I appreciate you trying out these packages
[20:58:56] <skunkworks> jepler: yes - updated - there wasn't that many as I had downloaded the iso yesteday again.
[20:58:56] <SWPadnos> skunkworks, send that image to Ubuntu with a bug report
[20:58:56] <SWPadnos> it's not a hardware "viewport" problem, because the window border is drawn over the 3D image
[20:59:06] <SWPadnos> though it is interesting that the shadow area is a black bar inside the preview area
[20:59:12] <SWPadnos> (the window shadow)
[20:59:31] <skunkworks> I will also install it on my computer I have at home (1.7ghz pentium.) that I was running the hermes.
[20:59:55] <skunkworks> I know that one worked well with dapper
[21:00:29] <cradek> that would be a great data point for your bug report
[21:00:44] <skunkworks> looking now where to send it.
[21:00:55] <cradek> (anyone's first inclination would be to blame your hardware)
[21:01:58] <skunkworks> looks like some reading
https://help.ubuntu.com/community/ReportingBugs
[21:02:26] <skunkworks> I can definatly do a before and after picture :)
[21:03:44] <skunkworks> jepler: your not seeing that at all?
[21:05:05] <SWPadnos> skunkworks, I'm not sure that's the place for Guty beta bugs
[21:05:14] <SWPadnos> or Gutsy
[21:05:45] <skunkworks> I guess I got there from here.
http://www.ubuntu.com/community/participate/TechnicalUsers
[21:06:20] <SWPadnos> ok, could be right. it just seemed more targeted for released versions
[21:06:43] <alex_joni> * alex_joni really thinks we should invest energy only in LTS versions
[21:06:57] <SWPadnos> I don't think LTS matters much actually
[21:07:12] <SWPadnos> it's only longer support oin the "desktop"
[21:07:13] <alex_joni> SWPadnos: dapper sure was more stable than feisty
[21:13:03] <SWPadnos> sure - they went from stable to radically unstable, on purpose :)
[21:13:14] <SWPadnos> I think edgy was more "normal"
[21:13:49] <SWPadnos> I don't know if it'll be a pattern though: LTS, then experimental, then a couple of normal, then LTS again
[21:15:02] <SWPadnos> the trouble is that hardware changes so fast that the Dapper release won't even boot on some newer motherboards (and that's as of 6 months ago)
[21:15:52] <SWPadnos> (that happened to Ray - he had good luck with a particular ITX motherboard but when he got new ones, using the same part number, the liveCD wouldn't boot)
[21:18:00] <SWPadnos> skunkworks, the gutsy testing page points you to the same place, so it's probably right
[21:18:45] <skunkworks> I was guessing I would pick the package I was bugging about.
[21:19:03] <SWPadnos> heh - good luck ;)
[21:59:19] <SWPadnos> well, I think I can say that it's not just EMC/RTAI that get better performance when you load one core doing nothing
[22:00:04] <SWPadnos> glxgears also gets faster by a few percent when I have a do-nothing loop running in another shell (while true ; do echo "nothing" > /dev/null ; done)
[23:53:23] <jmkasunich_> hi guys
[23:53:38] <jmkasunich_> jmkasunich_ is now known as jmkasunich
