Back
[00:00:09] <SWPadnos> "known possible to make good in one instance, depending on the hardware and BIOS revisions and settings" is about as close as you'll get
[00:00:54] <topls64> reinstalled live cd, moved a hd. Tried swapping video and ned cards. Did tweak some bios settings. That may be it.
[00:01:16] <JymmmEMC> topls64: moved a hdd?
[00:01:51] <SWPadnos> could be an ACPI or power setting of some sort (like suspend/standby settings)
[00:02:00] <SWPadnos> or the disk controller
[00:02:03] <SWPadnos> or the video driver
[00:02:35] <topls64> Its a raid board. Tried to use the raid, but it is a 'fake raid'. So, essentially I am rebuilding the box
[00:02:45] <SWPadnos> SCSI?
[00:02:48] <JymmmEMC> topls64: onboard RAID?
[00:03:14] <topls64> older abit kt7a-raid. Highpoint 370 raid controller
[00:03:19] <topls64> onboard
[00:03:21] <SWPadnos> ok
[00:03:31] <SWPadnos> you should have "normal" IDE ports as well then
[00:03:39] <topls64> yes. I use them
[00:03:42] <JymmmEMC> topls64: Yeah highpoint ctrl is crappy iface
[00:03:50] <SWPadnos> ok, so you should be able to disable the RAID entirely
[00:04:01] <SWPadnos> (which could help, but isn't guaranteed to)
[00:04:05] <topls64> yes, I have. Bios setting
[00:04:09] <SWPadnos> ok
[00:04:12] <JymmmEMC> topls64: I had the intel version of that board... that is REALLY REALLY old.
[00:04:19] <SWPadnos> ah, ok. you moved away from the RAID - duh :)
[00:04:39] <SWPadnos> Intel made a board with a VIA chipset?
[00:04:46] <topls64> I used the ide, tried and said f the raid, moved back to ide
[00:04:46] <SWPadnos> for the AMD processor?
[00:05:05] <JymmmEMC> SWPadnos: That board came out in amd and intel cpus version
[00:05:10] <topls64> it is a 1.2 thunderbird via chipset
[00:05:40] <JymmmEMC> maybe not the same series as I was thinking...
[00:05:43] <JymmmEMC> topls64: P3 ?
[00:05:49] <JymmmEMC> or amd equiv?
[00:05:54] <topls64> amd 'thunderbird'
[00:05:59] <JymmmEMC> nfc
[00:06:03] <SWPadnos> Athlon
[00:06:06] <JymmmEMC> ah
[00:06:06] <topls64> yes
[00:06:18] <JymmmEMC> still nfc about amd =)
[00:06:26] <SWPadnos> well, get googling! :)
[00:06:28] <JymmmEMC> wish I did though
[00:06:41] <JymmmEMC> SWPadnos: not gonna bother
[00:07:00] <SWPadnos> well, true. the history isn't aqs important as knwoing current chips
[00:07:02] <SWPadnos> -q
[00:07:24] <JymmmEMC> topls64: are devices still physically attached to the highpoint controller?
[00:07:37] <topls64> no. it is also disabled in bios
[00:08:01] <JymmmEMC> topls64: Is DMA/ATA133 enabled?
[00:08:12] <topls64> would 2 diff memorry sticks matter?
[00:08:21] <topls64> dma/ata yes
[00:08:23] <skunkworksemc> SWPadnos: running the latency test all day and screwing around - highest so far is 11087
[00:08:25] <JymmmEMC> topls64: like 256 and 512?
[00:08:32] <SWPadnos> skunkworksemc, nice
[00:08:42] <topls64> let me look...
[00:08:43] <JymmmEMC> topls64: shouldn't really
[00:08:49] <SWPadnos> I've been using one of my GOAL3 units to develop the G540 config
[00:08:53] <SWPadnos> using the parport
[00:09:07] <SWPadnos> next I'll throw in a Mesa card or two and see what happens :)
[00:09:09] <skunkworksemc> what base period are you running?
[00:09:22] <JymmmEMC> topls64: latest BIOS?
[00:09:27] <topls64> btw - latency hovers ~8k till I move a window around. Then shoots to 100k+
[00:09:39] <SWPadnos> I'm not sure - I let stepconf choose it for me
[00:09:49] <skunkworksemc> topls64: sounds like a video problem... :)
[00:10:10] <JymmmEMC> topls64: what video? onboard? pci? agp?
[00:10:17] <SWPadnos> I think the latency was under 15k, and the base period ended up being 30000 or so
[00:10:40] <skunkworksemc> ah - I ran 15us for a while - hours and finally it pop up a rt error. ;)
[00:10:58] <skunkworksemc> so I would think 20us would be safe..
[00:11:04] <skunkworksemc> if needed
[00:11:08] <SWPadnos> should be, but can't guarantee step timing :)
[00:11:09] <topls64> video is ati radeon ve / 7000
[00:11:17] <SWPadnos> topls64, what driver?
[00:11:19] <topls64> agp
[00:11:44] <topls64> tried X radeon, ati(failed), and vesa drivers
[00:12:00] <SWPadnos> vesa should give you the best latency, but of course the worst performance
[00:12:54] <JymmmEMC> https://help.ubuntu.com/community/RadeonDriver
[00:13:00] <topls64> btw - ram is same kingston 256/133, same part number, differt size
[00:13:09] <JymmmEMC> You are currently not able to use the "radeon" driver for the following cards and derivatives:
[00:13:21] <JymmmEMC> For these cards you must use the "fglrx" driver.
[00:14:42] <JymmmEMC> https://wiki.ubuntu.com/Bugs/AtiDriver
[00:15:49] <topls64> I have the 7000, so radeon is the correct one?
[00:17:46] <SWPadnos> according to that wiki page, it should work
[00:17:56] <SWPadnos> that doesn't mean it will be good for RT latency
[00:18:20] <SWPadnos> if you have the time to test this stuff, it would be great to have some real data in the wiki
[00:18:25] <SWPadnos> hint hint
[00:18:28] <topls64> ah.
[00:18:48] <topls64> Sure, ill donate a night are 2 to it
[00:18:57] <SWPadnos> in general, accelerated drivers have worse latency
[00:19:24] <topls64> Is there a list of guidelines / where to post
[00:19:27] <SWPadnos> this isn't true of all chips (Matrox chips seem to be fine)
[00:20:06] <SWPadnos> there is a troubleshooting page on the wiki, which may link to more specific setup info
[00:20:13] <topls64> I have a matrox on this box i'm on now...
[00:20:26] <SWPadnos> there's a "BasicSteps" link at the bottom of every page which tells you how to edit the wiki
[00:20:36] <SWPadnos> what generation?
[00:20:48] <SWPadnos> Millennium, G100/G200/G400 ...
[00:20:53] <SWPadnos> Parhelia?
[00:20:58] <topls64> let me look
[00:23:20] <topls64> fx 5200, if that is a matrox. I forget
[00:23:28] <SWPadnos> nope
[00:23:29] <eric_u> I thought someone was having problems with a G400 under 8.04
[00:23:37] <SWPadnos> NVidia
[00:23:46] <topls64> Ah
[00:23:54] <SWPadnos> eric_u, could be, I don't recall
[00:24:07] <SWPadnos> unfortunately, the Parhelia doesn't seem to work at all (though I haven't checked lately)
[00:24:08] <eric_u> and my G400 isn't helping my latency
[00:24:28] <topls64> Wha tabout a voodoo 3000
[00:24:53] <SWPadnos> dunno - test away :)
[00:25:03] <eric_u> I'm thinking about going back to my nvidia
[00:25:04] <topls64> or whatever the series was. I'll hve my buddy bring it mack
[00:26:10] <topls64> I'll be back later. Have to hang some stair handrails
[00:26:39] <eric_u> handrails, we don't need no stinkin' handrails
[00:27:03] <eric_u> SWPadnos, newegg raised the price on the Goal3 3 bucks, but there is a new rebate
[00:27:09] <SWPadnos> heh
[00:27:36] <SWPadnos> only $10 now, used to be $15
[00:27:45] <SWPadnos> oh no, itwas $10
[00:27:56] <SWPadnos> but the price went up $7
[00:28:01] <eric_u> what do you think about a dual celery machine?
[00:28:07] <eric_u> dual core
[00:28:13] <SWPadnos> ick
[00:28:18] <eric_u> for emc
[00:28:23] <SWPadnos> unless it works well for you
[00:28:26] <SWPadnos> yeah, ick
[00:28:54] <eric_u> is that based on empirical evidence?
[00:29:33] <eric_u> SWPadnos: I was thinking about dedicating a core to realtime
[00:29:49] <SWPadnos> sure, that works
[00:30:14] <SWPadnos> however, on the core2 Duo I tried, the latencies didn't improve at all unless I put a do-nothing CPU hog process on the non-RT core
[00:30:52] <eric_u> did you try on an AMD?
[00:31:30] <SWPadnos> no. I tried to boot an SMP RT kernel a long time ago on a dual dual-core Opteron, but it never worked right
[00:31:59] <SWPadnos> I think that PC had a problem with 32-bit kernels, and the one I tried was 32-bit and compiled with MAX_CPUS=2 I think
[00:32:24] <eric_u> I forgot about the smp issue
[00:32:38] <SWPadnos> it's not aas well tested as UP, for sure
[00:33:08] <eric_u> it's been a while since I built an RTAI kernel, last time I tried, I failed
[00:33:11] <eric_u> not patient enough
[00:33:17] <SWPadnos> me too, I think
[00:33:27] <SWPadnos> can't really remember - it's been a while :)
[00:33:51] <eric_u> somebody wrote a good howto, so the RTAI guys changed the build process
[00:34:20] <SWPadnos> one day I'll figure it out again
[00:34:34] <SWPadnos> but once I do that, someone will expect me to be the liveCD maintainer or something ;)
[00:34:51] <eric_u> that's a downside, to be sure
[00:35:28] <eric_u> for a while there, I think I was the only person that had RTAI-lab working, I'd get emails every couple of months
[00:36:42] <eric_u> they'd always wait until I forgot how to do it
[00:36:51] <SWPadnos> heh
[00:38:35] <skunkworksemc> * skunkworksemc might be glad he is just an excited user..
[00:38:53] <eric_u> tmi
[00:45:40] <skunkworksemc> are the spammers on vacation also? I not getting any mail at all...
[00:46:00] <skunkworksemc> I am feeling a little neglected..
[00:46:17] <eric_u> I think a lot of the spam is generated by work at home types
[00:48:53] <eric_u> trying to figure out why I get spam in russian though
[00:50:13] <skunkworksemc> for the longest time I was getting span i spanish
[00:50:58] <skunkworksemc> spam even
[00:52:15] <skunkworksemc> spamish?
[01:18:58] <eric_u> I probably have 50 wall warts, the only 5v wall wart I have is dead
[01:30:53] <skunkworksemc> heh - usb power? ;)
[01:31:58] <eric_u> not a bad idea, but it's for my switch in the closet
[02:27:57] <topls64> back
[02:40:47] <eric_u> amirite?
[02:52:13] <topls64> for the latency test, the base thread speed is what I'm interested in, correct?
[02:54:38] <topls64> sorry. base thread max jitter. currently 14476 and holding on livecd install, no s/w updates yet
[02:55:26] <SWPadnos> are you "stressing" the system, as recommended on the troubleshooting(?) wiki page?
[02:55:59] <topls64> glxgears, firefox and misc junk. now 15613
[02:56:16] <SWPadnos> ok, drag stuff around, launch something like openoffice, etc also
[02:56:25] <SWPadnos> might as well hit the disk and memory a little bit :)
[02:56:29] <topls64> doesn't skyrocker on window moves amymore
[02:58:09] <topls64> opened gimp and office, holding 15613
[02:58:16] <SWPadnos> cool
[02:58:34] <SWPadnos> leave it going for a while (20 minutes to a day)
[02:58:46] <SWPadnos> with all that other stuff running
[02:59:21] <topls64> when the time comes, should I install the updates it reccommends?
[02:59:44] <SWPadnos> probably. do you see an RT kernel update?
[02:59:48] <topls64> yes
[02:59:53] <SWPadnos> hmmm
[03:00:16] <SWPadnos> you should update emc2 and the RT kernel, then do the latency test
[03:00:48] <topls64> images, headers and modules for 2.6.24-16 rt
[03:01:05] <SWPadnos> ok, definitely update that and EMC2
[03:01:10] <topls64> I will update them now
[03:01:38] <ds3> SWPadnos: are you doing EMC2 talk at ESC again?
[03:01:44] <SWPadnos> nope
[03:01:52] <SWPadnos> I wasn't sure there would be a machine to demo with :)
[03:02:10] <SWPadnos> not that seeing the machine move seemed to be a big hit anyway
[03:02:50] <ds3> oh okay...I can lend out my machine in exchange for a working EMC2 config ;)
[03:02:58] <SWPadnos> heh
[03:03:19] <SWPadnos> darn! the deadline for class submissions has passed
[03:03:35] <ds3> oh :(
[03:03:49] <SWPadnos> like last August or something
[03:04:16] <ds3> oh well
[03:04:33] <ds3> got to add onemore condition... someone has to supply cutters ;)
[03:04:37] <SWPadnos> heh
[03:04:48] <SWPadnos> oooh - cutting something would be interesting now wouldn't it? :)
[03:05:17] <SWPadnos> oh, I guess the deadline was October 10
[03:05:23] <SWPadnos> still quite a while ago
[03:05:28] <ds3> only if the machine doesn't crash as you talk ;)
[03:05:48] <SWPadnos> as I scream you mean :)
[03:05:52] <ds3> I don't think the deadlines are a hard thing... I got squeezed into the Boston even very late
[03:06:11] <ds3> my machine is a taig so it isn't that loud
[03:06:20] <SWPadnos> speaker submission deadlines are a little more critical, since the papers are supposed to be on the CD
[03:07:18] <ds3> yeah... suppose to be on CD... minedidn't make it on CD
[03:08:44] <SWPadnos> oh, did you present at ESC Boston?
[03:08:55] <ds3> yeah
[03:09:01] <SWPadnos> cool. what about?
[03:09:08] <SWPadnos> I might have popped down if I had known :)
[03:09:52] <ds3> you were there?
[03:10:03] <ds3> I was talking about bluetooth on the beagle
[03:10:20] <topls64> hal update also
[03:10:22] <SWPadnos> no, but it's only a few hours away by car
[03:10:30] <SWPadnos> topls64, that's not the same HAL
[03:10:35] <ds3> Oh
[03:11:01] <ds3> I'll probally be doing one at San Jose if all goes well
[03:11:05] <SWPadnos> cool
[03:11:12] <SWPadnos> I should be there, I usually attend
[03:11:17] <ds3> this assumes I can get it done by the deadline
[03:11:20] <topls64> I'll remove it
[03:11:30] <SWPadnos> topls64, no, don't do that
[03:11:40] <topls64> ah!
[03:11:46] <topls64> ok
[03:11:48] <SWPadnos> everyone calls their hardware layer the HAL (Hardware Abstraction Layer)
[03:12:14] <ds3> except for HAL ;)
[03:12:22] <SWPadnos> heh
[03:13:02] <topls64> it was an update it was recommending
[03:13:22] <topls64> hal and hal-info
[03:13:40] <SWPadnos> yep, that's something to do with the hardware layer for hot-plug or something
[03:15:53] <topls64> oik. down to 13104
[03:16:04] <SWPadnos> that's lucky
[03:16:06] <SWPadnos> I mean good
[03:16:33] <topls64> wish i had a sound card installed to play mp3s
[03:17:09] <ds3> mmmmm realtime MP3 decoding ;)
[03:17:10] <topls64> now, last time i installed all the recommended updates, and the lat was like 128k+, any ideas?
[03:20:35] <SWPadnos> not really
[03:21:05] <SWPadnos> just guesses, like different BIOS settings, different drivers, different defaults chosen by the installer ...
[03:22:29] <topls64> Ok. I'll let this run for some time (after I put a soundcard in ;) ) and post the results. I'll try some other configs tom night if I have a chance also
[03:23:02] <SWPadnos> hmmm. I wonder how sound will work if you installed the OS without the card plugged in
[03:23:22] <SWPadnos> let me know how straightforward it is to get it working - I'm curious
[03:25:33] <topls64> I'll plug in my old sb live in a min
[03:25:44] <topls64> holding at 13104 btw
[03:26:05] <SWPadnos> cool
[03:26:19] <SWPadnos> gotta run, but I'll probably read back later tonight or tomorrow morning
[03:26:20] <SWPadnos> good luck
[03:27:03] <topls64> u know, whenever I shutdown (from the menu), the os stops, but machine stays powered. No setting I have found yet fixes this
[03:27:12] <topls64> later
[03:27:32] <SWPadnos> you probably won't fix that, shutdown is an ACPI function, and ACPI needs to be disabled or it screws up latency
[03:27:41] <topls64> it is. ok
[03:27:50] <SWPadnos> (though I think there's a kernel boot option to allow shutdown, but nothing else)
[03:30:00] <topls64> would be a good feature
[03:30:15] <topls64> to, you know, shut it off and all
[03:40:24] <topls64> for those who care: sound card worked plug and play
[03:45:05] <topls64> streaming mp3s in - much higher latency 18634 up from 13104
[04:08:18] <eric_u> what did you change from earlier?
[04:11:31] <eric_u> this post about mach just go more interesting
http://www.cnczone.com/forums/showthread.php?t=70712
[04:12:14] <eric_u> executive summary: mach runs away and ruins 15 hours of machining
[04:12:32] <eric_u> one response: "basically this is not a bug... In Mach3 you have Look ahead features...If your Look ahead is 20Lines, then actually your machine is running 20 lines in past but the processor has calculated 20 lines ahead and cammanded in Buffer to run ur machine..."
[04:19:10] <cradek> the only way to change feed rate on precalculated queued motion is to scale time. this changes feed AND acceleration. with steppers this excessive acceleration can cause stalls and therefor position loss, which is what happened to him.
[04:19:34] <cradek> it's a fundamental limitation of that system, and one from which EMC2 does NOT suffer due to its realtime planning.
[05:13:18] <KimK> I did everything in the wiki "Highlighting_In_Gedit", but I'm having trouble with the last three lines from the wiki: Rebuild the mime-database, from the command-line: (new line) sudo su (new line) update-mime-database /usr/local/mime (new line) exit
[05:14:07] <KimK> It acts like its becoming root, but then has permission issues so seems not to be root? I'm confused.
[06:10:30] <KimK> I was able to fix it. My first EMC2 wiki edit, neat!
[12:50:19] <JanVanGilsen> http://imagebin.org/34829
[13:24:01] <JymmmEMC> nice
[13:24:16] <rayh> Awesome!
[13:25:23] <micges> cool
[13:46:42] <alex_joni> JanVanGilsen: nifty
[13:46:44] <alex_joni> hi rayh
[13:47:05] <rayh> Hi Alex. Happy new year.
[13:47:13] <alex_joni> happy new year.
[13:47:17] <alex_joni> all is well on your end?
[13:47:22] <rayh> I think I read that you are at the cabin in the mountains.
[13:47:30] <alex_joni> yup, that's so ;)
[13:47:33] <rayh> Ye are doing well.
[13:47:35] <alex_joni> untill tomorrow I think
[13:47:38] <rayh> We
[13:47:51] <rayh> That is such beautiful country.
[13:48:02] <alex_joni> yup, it's sure nice and quiet :)
[13:48:17] <alex_joni> seen the pics I took a couple days ago?
[13:48:26] <rayh> No I didn'
[13:48:34] <alex_joni> http://dsplabs.utt.ro/~juve/blog/index.cgi/photography/01230658670
[13:48:34] <rayh> t
[13:49:59] <micges> alex_joni: that's you on the pic?
[13:51:21] <alex_joni> not the fury one ;)
[13:51:59] <rayh> Wow. We were out playing in the snow yesterday. But you have the better view.
[13:54:21] <alex_joni> todays really cold
[14:00:25] <rayh> We had -25f reecently
[14:03:45] <rayh> Gotta run.
[15:13:57] <JanVanGilsen> added an arrow indicator:
http://imagebin.org/34835
[15:27:20] <eric_u> JanVanGilsen: nice
[15:28:49] <Poincare> JanVanGilsen: nog steeds met uw eindwerk bezig? :-)
[15:29:30] <JanVanGilsen> neen hoor dit is hobby
[15:29:44] <JanVanGilsen> had trouwens een 19 op 20 =)
[15:29:53] <fragalot> Batterij? o;O
[15:30:03] <fragalot> Nice
[15:31:27] <JanVanGilsen> We'r moving my fathers liberary to the attic =) so we can place a PUMA robot there =)
[15:31:55] <fragalot> :o
[15:32:05] <skunkworks> JanVanGilsen: puma? what model?
[15:32:05] <JanVanGilsen> ofcoarse we'll implement EMC2 control :)
[15:32:09] <JanVanGilsen> 560
[15:32:21] <skunkworks> heh - where you on the mailing list a few months ago asking about it?
[15:32:27] <JanVanGilsen> no
[15:32:30] <skunkworks> oh - wow
[15:33:00] <fragalot> What will you have it do?
[15:33:14] <JanVanGilsen> Make cocktails =)
[15:33:20] <fragalot> xD
[15:33:23] <skunkworks> JanVanGilsen: we have a puma 560 also...
http://www.electronicsam.com/images/puma/pumaarm.jpg
[15:33:28] <skunkworks> no control
[15:34:30] <JanVanGilsen> we have a broken mkII controller
[15:34:48] <skunkworks> are you going to use the drives?
[15:35:09] <JanVanGilsen> there's somthing wrong with the memory of the VAL-computer
[15:35:44] <skunkworks> one of the reason I am making these..
http://www.electronicsam.com/images/KandT/servostart/schem/newcurrentlimit/close.jpg
[15:35:53] <JanVanGilsen> yes, i'm planning on reusing the drives
[15:36:56] <fragalot> skunkworks: so, those have been a proximity meter, an oversized LED controller, but.... what is it?
[15:37:00] <JanVanGilsen> i found a document on the web about thes drives, so im hoping to figure out where to attach the +/-10V
[15:37:04] <skunkworks> It has been mentioned that the encoders are sin/cos not square. (a couple of comparators are needed)
[15:37:53] <skunkworks> fragalot: big current limited h-bridge. Takes pwm-up/down.
[15:38:26] <fragalot> skunkworks: K
[15:41:02] <JanVanGilsen> I'll hook a scope on to it and look at the ecoder signals, thx it good info...
[15:41:13] <JanVanGilsen> *it's
[15:42:29] <JanVanGilsen> I'm hoping it would be possible to write a VALII interpreter
[15:42:49] <JanVanGilsen> controlling a robot shouldn't be don i g-code
[15:44:01] <JanVanGilsen> *done in ... (geez, I have to learn how to type)
[15:49:57] <skunkworks> heh
[15:50:33] <skunkworks> yah - that is what people mention - being able to teach the robot.. (I think someone had played with doing that in germany) Alex would know
[15:53:03] <JanVanGilsen> i'll first have to lean C++
[15:53:09] <JanVanGilsen> *learn
[15:54:28] <JanVanGilsen> I might put a dremel on the arm and do some 5 axis engraving
[15:55:41] <skunkworks> that is what I wanted to play with.. :)
[15:56:16] <skunkworks> the manual says +/- .002 iirc ;)
[15:58:23] <JanVanGilsen> we micht put a fixed spindle and put the workpiece in the gripper :-)
[16:05:52] <BigJohnT> JanVanGilsen: is the new pyVCP meter in trunk?
[16:05:55] <JanVanGilsen> and there still are the joint vs. axes issues...
[16:06:02] <JanVanGilsen> No
[16:06:22] <BigJohnT> it looks nice
[16:06:51] <JanVanGilsen> I'll pastebin my current pyvcp_widgets.py file
[16:07:03] <skunkworks> JanVanGilsen: yes - they are working on that..
[16:07:25] <skunkworks> off and on.
[16:08:10] <JanVanGilsen> http://pastebin.com/m46683a4f
[16:09:34] <JanVanGilsen> I also want to add some scaling parameters to the meter
[16:09:35] <jepler> JanVanGilsen: to get it incorporated in a future release of emc, the best way is to send a patch to the developers list.
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
[16:10:09] <JanVanGilsen> so the user can change the major tick unit and the number of minor ticks
[16:14:20] <JanVanGilsen> jepler: thx, I ended up using you're tuplet sugestion, and added up to 3 regions <region1><region2><region3>
[16:16:07] <jepler> JanVanGilsen: yes, I saw that in scanning the file .. seems like that may be the best compromise possible at the moment
[16:26:40] <JanVanGilsen> need some advise on parameter names, can somebody think of better/nicer names? <subtext> <majorscale> <minorscale> <region#>
[16:37:48] <JanVanGilsen> jepler how hard would it be to change vcpparse so it returns an array if the element contains childs instead of text? something like region[0]['min'] region[0]['color']
[16:47:09] <jepler> JanVanGilsen: I only glanced at it, but I think that there's only one level below a widget that is passed directly to that widget, and it's not structured to make changing that easy
[16:47:20] <jepler> clearly it could be done, but I don't think it's just a small change
[16:53:58] <JanVanGilsen> i'm sure it needs some recursive algorithm, I might look at it one day ..
[19:20:07] <skunkworks> http://www.cnczone.com/forums/showpost.php?p=546106&postcount=11
[19:21:54] <alex_joni> http://www.theregister.co.uk/2009/01/02/swoopo_startrup/ heh
[19:24:48] <alex_joni> skunkworks: ouch
[19:27:00] <jepler> .unpythonic.net
[19:27:04] <jepler> oops
[19:47:58] <micges> if emc will have dxf2gode converter, where it will be put in dir-tree ?
[19:49:30] <alex_joni> probably outside
[19:50:30] <skunkworksemc> http://imagebin.ca/img/VZkb4B1m.jpg
[19:51:36] <skunkworksemc> http://imagebin.ca/img/dW5pWu.jpg
[19:56:00] <alex_joni> skunkworks: what no smoke?
[19:56:20] <skunkworks> not yet - give it some time
[19:56:22] <skunkworks> ;)
[21:30:32] <LesNewell> Is there a way of telling if emc is busy?
[21:30:35] <LesNewell> I am playing around with emcrsh and I want to add a function to check if emc is busy in any way.
[21:31:06] <LesNewell> Basically I need to know if both the interpreter and motion are idle.
[21:36:39] <jepler> axis uses this condition to determine whether the 'run' command should be active:
[21:36:39] <jepler> state {$task_state == $STATE_ON && $interp_state == $INTERP_IDLE } \
[21:37:10] <jepler> but it doesn't account for an ongoing jog or mdi; that'd be the sound of the user shooting himself in the foot
[21:38:20] <LesNewell> Thanks. Ideally I want something bombproof.
[21:38:46] <LesNewell> I especially want to know if the current MDI move has finished
[21:41:51] <LesNewell> Ideally I'd like to create an auto mdi mode. Automatically switch to mdi. run it then switch back to jog.
[21:50:55] <jepler> we're really only archaeologists of what the state machine in task does
[21:51:11] <jepler> so I can't suggest anything more foolproof than looking at what's in the stat buffer and guessing what is an appropriate test
[21:52:19] <LesNewell> OK - I'll do some digging.
[21:52:51] <LesNewell> The reason why I want to do this is because I tend to often use my machines in a mix of manual and MDI
[21:52:59] <LesNewell> MDI: G0x10
[21:53:09] <LesNewell> Using Z MPG, drill a hole
[21:53:14] <LesNewell> Go x15
[21:53:21] <LesNewell> use the MPG again.
[21:53:58] <LesNewell> It's for one-offs where I can't be bothered to work out suitable feeds :-)
[21:55:35] <LesNewell> BTW I found a buffer overrun bug in emcrsh. I'll stick a patch up later.
[21:58:14] <jepler> always nice to fix those
[21:59:32] <LesNewell> Drove me nuts trying to find what was going on. I kept getting intermittent segfaults.
[22:00:11] <jepler> looking at stat->status seems to be a pretty good guess at whether an mdi is ongoing. though checking that I noticed that my run button flickers during homing...
[22:00:49] <jepler> specifically, I'm greying out 'run' when stat->status == RCS_EXEC
[22:02:55] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/grey-out-run-better.patch
[22:03:09] <jepler> it also greys out while a jog is ongoing
[22:03:15] <jepler> so maybe it's close to the test you're looking fro
[22:03:16] <jepler> for
[22:05:31] <LesNewell> Looks promising. I'll have a play tomorrow and see what happens. Thanks.
[22:06:02] <jepler> btw, to figure that out I just looked at what fields were changing in 'show emc status', and made educated guesses
[22:08:38] <LesNewell> I didn't know about show emc status. I'll have a play.
[22:18:42] <LesNewell> It looks like status is the one. Thanks.
[22:21:28] <topls64> soory.
[22:22:50] <topls64> SWPadnos: from yesterday - sound card worked plug-n-play, but latency was up over 19000 during playback.
[22:23:11] <topls64> Took it out. Lat now holding 15287 overnight
[22:25:38] <jepler> no mp3s while milling, I guess
[22:28:37] <LesNewell> I'm running axis in sim. When I shut it down I get this error:
[22:28:39] <LesNewell> ERROR: Can't remove RTAI modules, kill the following process(es) first
[22:29:08] <LesNewell> Next time I run it, it immediately aborts with an error
[22:29:09] <jepler> only the one line?
[22:29:16] <LesNewell> Yup.
[22:29:24] <jepler> well that's interesting
[22:29:48] <jepler> to try again to unload the realtime modules: halrun -U
[22:30:26] <jepler> if $FUSER -s /dev/rtai_shm 2>/dev/null; then
[22:30:26] <jepler> # at least one process is using it
[22:30:26] <jepler> echo "ERROR: Can't remove RTAI modules, kill the following process(es) first"
[22:30:29] <jepler> $FUSER -v /dev/rtai_shm
[22:30:42] <jepler> it looks like the process using /dev/rtai_shm could exit between the first fuser and the second
[22:31:26] <jepler> a kind of race condition so to speak
[22:31:35] <LesNewell> It only appears to do it if the machine is on and I have made at least one move.
[22:31:56] <LesNewell> Aha. Different message:
[22:31:58] <LesNewell> ERROR: Can't remove RTAI modules, kill the following process(es) first
[22:31:58] <LesNewell> USER PID ACCESS COMMAND
[22:31:58] <LesNewell> /dev/rtai_shm: les 5368 ....m hal_manualtoolc
[22:32:17] <jepler> did the 'halrun -U' clean things up after the first error?
[22:32:44] <jepler> was hal_manualtoolchange still running a moment later when you checked in the terminal?
[22:32:57] <LesNewell> Sorry, I've just been re-running emc. If it fails once on startup, it will work the next time.
[22:33:33] <jepler> sounds like the scripts aren't giving hal_manualtoolchange enough time to clean up and exit
[22:33:54] <LesNewell> I didn't notice if the tool change was active or not. I'll do some more tests.
[22:34:12] <LesNewell> This is a reasonably quick machine.
[22:35:30] <LesNewell> halrun -U fixes the restart issue
[22:36:26] <jepler> there's simply no check for the userspace components actually exiting .. it's assumed that by the time 'realtime stop' is making this test, they've already exited due to an earlier 'halcmd unload all'
[22:38:13] <jepler> I guess I'll file an item on sourceforge about this
[22:38:58] <LesNewell> Is there any way to stop the toolchange widget from loading?
[22:39:09] <jmkasunich> since realtime stop is smart enough to figure out what to kill, maybe it should just do the kill commands?
[22:39:21] <jepler> sure. it's just a 'loadusr' in your hal files
[22:39:27] <jmkasunich> LesNewell: sure, the toolchange thing is part of the config
[22:39:27] <jepler> jmkasunich: that's a possibility too
[22:39:45] <jepler> but in this case hal_manualtoolchange is exiting in an orderly fashion (I think), it just takes too long
[22:40:20] <jmkasunich> then perhaps "unload all" should sleep for a few seconds?
[22:41:26] <LesNewell> Disabled the tool change and as expected all works fine now.
[22:45:04] <LesNewell> Next question. Is it possible to move the machine during a tool change?
[22:45:22] <jepler> sure, if you have a forklift
[22:45:36] <LesNewell> For instance I put a drill in the chuck. I now need to reference it.
[22:45:59] <jepler> no, it's not possible to jog with keyboard or mpg during toolchange or during any other gcode pause
[22:46:18] <LesNewell> jepler: Haven't got a forklift
[22:46:45] <skunkworks> LesNewell: what works great is a touchoff microswitch.
[22:46:46] <jmkasunich> if the machine is a sherline, you don't need a forklift ;-)
[22:47:15] <LesNewell> BP Series 1 CNC. Can't lift it on my own :-)
[22:47:18] <LesNewell> So how do you get around the problem of fitting a tool of unknown length?
[22:48:22] <LesNewell> skunkworks: Can you do that during a tool change?
[22:48:29] <skunkworks> yes.
[22:48:55] <skunkworks> it would be part of your program.. manually change tool - touchoff to get length
[22:49:55] <skunkworks> LesNewell:
http://cvs.linuxcnc.org/cvs/emc2/nc_files/tool-length-probe.ngc
[22:51:26] <LesNewell> So what do you do if you don't have a switch?
[22:51:29] <LesNewell> Currently with Mach I use a gage block. Presumably you can't do that in EMC
[22:51:38] <skunkworks> 2 different programs.. :)
[22:51:58] <skunkworks> no - that is one thing that mach can do that emc can't
[22:52:57] <jepler> LesNewell: actually instead of filing a tracker item, I tried to fix it .. it's the 'for i in ...' section of the just-changed scripts/emc.in on TRUNK
[22:54:05] <LesNewell> Thanks. It isn't currently an issue as I'm only testing but it is good to know there is a fix.
[22:54:27] <LesNewell> skunkworks: I wonder how difficult it would be to add. I't a very useful feature, especially for one-offs
[22:55:17] <skunkworks> I would not know.. :)
[22:55:36] <jmkasunich> LesNewell: not simple
[22:56:12] <jmkasunich> move while paused, which can be reworded as "restart from line", tends to raise a number of tough issues
[22:56:55] <LesNewell> such as - how do you move back to the cut.
[22:56:56] <jmkasunich> what if you pause in the middle of an arc, then move to a point not on the arc? (just one of many)
[22:57:24] <jepler> though "jog during toolchange" might eliminate a bunch of those concerns -- for instance, it's not in an arc
[22:57:37] <LesNewell> However, tool changes never occur halfway through a move.
[22:57:39] <jepler> what it needs is a motivated developer
[22:57:44] <jmkasunich> yes - I was just about to say that move during a change reduces the scope of the problem
[22:58:25] <LesNewell> Once I've got my current project out of the way, I might investigate.
[23:00:17] <jepler> fair warning, you'll have to wallow around in task, which is the part of the software none of us loves
[23:01:12] <LesNewell> Let me guess- that's why no-one else has done it yet.
[23:01:33] <jmkasunich> probably that and insufficient motivation
[23:01:40] <jmkasunich> cradek has a tool turret on his lathe
[23:01:54] <jmkasunich> some people use touch off switches
[23:01:55] <jmkasunich> etc
[23:06:52] <LesNewell> It would be a lot of work to fit a touch of switch on my mill. It's got no home switches and no index on the encoders.
[23:07:16] <jmkasunich> there is no connection between either of those things and a touch-off switch
[23:07:48] <LesNewell> There is if you want a fixed touch off switch - the machine has to know where it is.
[23:07:52] <jmkasunich> a touch-off switch is mounted somewhere in the work envelope, and after a tool-change, the g-code pokes the switch with the end of the tool
[23:07:54] <jmkasunich> duh
[23:08:21] <jmkasunich> so you aren't doing any kind of homing at all>?
[23:08:30] <LesNewell> Nope.
[23:08:41] <jmkasunich> some people home to a mark on the table, so at least soft limits will work
[23:09:07] <jmkasunich> you can align marks by eye (jogging), then hit home, and the machine will at a "known" position, for some value of known
[23:09:13] <jmkasunich> +/- 0.050" shouldn't be hard
[23:10:04] <LesNewell> Another problem on my machine is the limited quill travel. I often need to move the knee to allow for a long tool. The knee is manual.
[23:21:03] <LesNewell> Thinking about it, do you need to muck around in task?
[23:21:35] <LesNewell> If the tool change simply stops the interpreter then you can run from the next line.
[23:22:09] <LesNewell> I suppose something like this would make it choke : t5m6g0x5
[23:22:52] <LesNewell> But would anyone ever do that?
[23:29:27] <LesNewell> Oh well, off to bed. I'll think about it more in the morning...
