#emc-devel | Logs for 2010-08-01

[00:05:21] <skunkworks> what is the apt line I add to the package manager? is it 'deb http://wwww.linuxcnc.org/' I cannot seem to find that anywhere
[00:09:47] <skunkworks> biab
[00:31:44] <skunkworks> got it. (forgot my laptop had the emc repositorys installed)
[00:35:29] <skunkworks> wow - lucid boots fast.
[00:38:25] <skunkworks> bbl
[01:28:20] <skunkworks> the config for the k&t works on lucid
[01:28:46] <skunkworks> very nice
[01:29:08] <skunkworks> (as far as it is - 2 mesa board both worked)
[01:35:26] <skunkworks> (machine powered up and the tool chain still workes) :)
[02:19:41] <skunkworks> question.. I had run the latency test off of the lucid live cd on this asus motherboard. ran great - latency less than 15k
[02:20:13] <GoSebGo> Thats not a question
[02:20:29] <skunkworks> ran it for a good 4 hours or so. the system had 2gb ram
[02:21:09] <skunkworks> the same motherboard in the k&t only had 512mb ram. (128 used for video) and the latancy was crap >100k
[02:21:47] <GoSebGo> Are bios settings the same?
[02:21:52] <skunkworks> is the 2gb of memory making having 1gb limit for the rt kernel -> the video share never effected it?
[02:21:58] <skunkworks> yes
[02:22:27] <skunkworks> not a big deal - I just put a video card in it and now the latency is well under 15k
[02:23:12] <skunkworks> I guess I can test this more monday - I could remove the memory from the other motherboard and do the same test. The only difference was installed vs livecd
[02:23:47] <skunkworks> (the k&t was installed on the HD with 512 ram while the one I tested with good latency was 2gb off the livecd)
[02:24:44] <GoSebGo> So, no video card & 512mb = high latency, with video card & 2gb = low latency?
[02:25:11] <GoSebGo> Does the mobo have on-board video?
[02:28:49] <skunkworks> no - no video & 512 high latency. No video card 2gb low latency. video card 512mb low latency. When I say 'no video card' I mean 'on board video - shared memory'
[02:29:21] <skunkworks> Hi seb!
[02:29:43] <GoSebGo> Hi :-)
[02:32:50] <skunkworks> still cannot believe how fast it boots.
[02:34:00] <GoSebGo> Yeah lucid is ftw :-)
[10:37:04] <moopy> anyone have an estimate on how long till next livecd release?
[10:37:29] <micges> few days
[10:37:37] <micges> maybe week
[10:37:56] <moopy> so no chance of adding software to it?
[10:38:23] <micges> what software?
[10:38:32] <moopy> opencv
[10:39:13] <micges> when it will be out, you can rebuild livecd with programs you want, there are instructions on net
[10:39:36] <moopy> where are rebuild instructions?
[10:40:39] <micges> there are few
[10:41:07] <micges> I'll ask our livecd builder to put livecd rebuild intructions on wiki
[10:43:07] <moopy> thanks micges
[10:43:55] <micges> I'll also use this instruction myself
[11:08:45] <robh__> cradek, tested out the G99 G98 change, and all looks fine and working here with number of test programs, G83 fix also works grate all as exspected
[11:26:45] <alex_joni> micges: the instructions I used for the hardy livecd are in git
[11:26:49] <alex_joni> infrastructure.git
[11:27:02] <alex_joni> eventually the instructions for the lucid LiveCD will end up there too
[11:27:32] <alex_joni> http://git.linuxcnc.org/gitweb?p=infrastructure.git;a=blob;f=livecd/hardy_i386.livecd;h=5257e25e9dace5e0ce3a2582b5c9184f4a91174e;hb=HEAD
[11:27:42] <alex_joni> robh__, micges : ^^ most of that still applies
[13:04:21] <jthornton> should I update the wiki to say 2.4.3 release?
[14:03:12] <cradek> robh__: great, thanks for testing
[14:09:30] <alex_joni> jthornton: yeah
[14:09:39] <alex_joni> there are a couple places which need updating in the wiki
[15:39:47] <micges> wiki updated
[17:31:28] <jthornton> stump uprooted :0
[19:07:22] <alex_joni> jthornton: big one?
[19:07:44] <jthornton> very big!
[19:07:59] <jthornton> took 3 1/2 hours with the backhoe to dig it out
[19:08:38] <alex_joni> ouch
[19:09:11] <micges> alex_joni: in io struct names and such what purpose have AUX in names? like EMC_AUX_INPUT_WAIT
[19:09:15] <jthornton> that was the second one dug one out yesterday that took 4 hours
[19:09:32] <jthornton> gotta make room for addition to shop :)
[19:09:56] <alex_joni> micges: historical reasons only
[19:10:13] <alex_joni> initially there were separate controllers for each part
[19:10:24] <micges> I thought so
[19:10:28] <alex_joni> there was a separate AUX controller that was communicating with the IO controller
[19:10:54] <alex_joni> remember that emc was initially started as a testcase for rcslib
[19:11:05] <alex_joni> so there were lots of (unneeded) NML channels
[19:11:22] <micges> mess in one word
[19:11:50] <alex_joni> well.. call it what you want
[19:13:51] <alex_joni> mess, overengineering, etc
[19:14:37] <alex_joni> luckily there are such things as redesigns ;)
[19:15:02] <micges> yep
[19:15:30] <micges> but redesign emc will be not an easy task
[19:15:46] <alex_joni> one step at a time ;)
[19:19:44] <micges> so I'm at one step now
[19:19:58] <alex_joni> one small step for a man..
[19:42:37] <micges> alex_joni: as for adding tool logic to task: I think all io logic (estop, din, dout, tool, coolant and lube) should go to iotaskintf
[19:43:01] <micges> then taskintf and iotaskintf will be talking to motion via shared memory
[19:44:19] <micges> only traj, spindle and config part should be left in taskintf
[19:52:15] <alex_joni> micges: sounds good to me
[19:52:26] <alex_joni> iotaskintf is new, right?
[19:52:46] <micges> no it's there now
[19:53:01] <micges> it's task interface to iotask now
[19:53:20] <alex_joni> ah, the one sending NML messages?
[19:53:26] <micges> yes
[19:54:25] <alex_joni> the only odd thing will be that only one of taksintf and iotaskintf will get status from shm
[19:56:19] <micges> I think iotaskintf will be slave to taskintf and update it's status
[19:56:50] <alex_joni> ok
[19:57:07] <micges> like now emcTrajUpdate()
[20:41:28] <CIA-2> EMC: 03jepler 07v2.4_branch * r2728cb469aad 10/src/Makefile: install emctool.h
[21:22:17] <alex_joni> jepler: the pdf's read just fine