Back
[00:19:46] <lerman_> lerman_ is now known as lerman
[01:11:16] <skunkworks> http://www.electronicsam.com/images/pentIII2.JPG
[01:16:20] <skunkworks> The pliers is the on button. :)
[01:51:46] <cradek> skunkworks: cool - P3s?
[01:53:21] <skunkworks> Yes - 600mhz
[01:53:43] <cradek> nice! your junkbox is better than mine
[01:54:35] <skunkworks> I installed the 3 packages from linuxcnc - now it seems to boot to the rtai kernel.
[01:54:44] <skunkworks> I am doing a sudo apt-get build-dep emc2
[01:54:50] <skunkworks> and so on.
[01:55:02] <cradek> cool
[01:55:16] <skunkworks> so the latency test needs some tweeking?
[01:55:19] <cradek> (but that will install the other kernel that you don't need)
[01:55:31] <skunkworks> will it hurt?
[01:55:34] <cradek> nope
[01:55:45] <cradek> just a little space and time
[01:55:48] <skunkworks> the wiki directions to run the latency test don't work
[01:55:52] <cradek> what about the latency test?
[01:55:55] <cradek> oh really
[01:56:00] <skunkworks> for me anyways
[01:56:07] <skunkworks> unless I did something wrong
[01:56:13] <cradek> sudo mknod /dev/rtf3 c 150 3; cd /usr/realtime*/testsuite/kern/latency; ./run
[01:56:20] <cradek> ^^ from memory only
[01:56:29] <skunkworks> ok
[01:56:46] <skunkworks> waithing for the packages to download.
[01:57:16] <skunkworks> I have 3 of these motherboards - backups for our old server.
[01:57:37] <cradek> slick
[01:57:37] <skunkworks> it is a supermicro motherboard. (always liked that brand for servers)P
[01:57:56] <cradek> all loaded with processors and regulator modules?
[01:58:23] <skunkworks> ?
[01:58:56] <cradek> I mean do you have all the processors too, or just the boards
[01:59:02] <skunkworks> No - this is my backup processors. :)
[01:59:08] <cradek> finding matching processors is a pain
[01:59:17] <skunkworks> I lucked out on ebay
[01:59:23] <cradek> there were SO many p3 varietys
[01:59:28] <skunkworks> right
[02:01:37] <skunkworks> sudo mknod /dev/rtf3 c 150 3; cd /usr/realtime*/testsuite/kern/latency; ./run
[02:01:38] <skunkworks> :)
[02:02:36] <cradek> haha
[02:02:49] <cradek> took me a sec to figure that out
[02:03:12] <skunkworksX2> thsi is what I get
http://pastebin.ca/455211
[02:04:58] <cradek> you should be in /usr/realtime-2.6.17-rtai3.5/testsuite/kern/latency
[02:05:14] <cradek> you have two rtais installed now - you have to make sure you use the one that matches your running kernel
[02:05:26] <skunkworks> ok :)
[02:05:42] <cradek> I guess realtime* doesn't quite cut it now
[02:06:55] <skunkworksX2> working nwo
[02:06:59] <skunkworksX2> now
[02:06:59] <cradek> good
[02:08:07] <skunkworksX2> RTD| -648| -718| 860| 5546| 11242| 0
[02:08:22] <cradek> beautiful
[02:08:40] <skunkworksX2> while I am downloading packages
[02:08:56] <jmkasunich> I should fire up kayak and see what it gets for latency
[02:09:14] <cradek> I also get about 11000
[02:09:19] <cradek> on my PII
[02:09:34] <skunkworksX2> seems to be peaking at 11242
[02:09:57] <cradek> I think that's about half what decent machines got before
[02:10:09] <skunkworksX2> Nice
[02:10:21] <cradek> wonder if it's smp, or other rtai improvements
[02:10:36] <skunkworks> have not tried a single proccessor computer yet ;)
[02:10:46] <cradek> I tried just one
[02:10:54] <cradek> seemed to work fine
[02:11:11] <skunkworks> do max latency did you get?
[02:11:15] <skunkworks> what/do
[02:11:17] <cradek> it would be nice if we had one that was problematic before we got the old kernels tweaked
[02:11:32] <cradek> remember there were some that complained about apic? lapic? (??)
[02:12:35] <skunkworksX2> oops - up to 11382 ;_
[02:12:38] <skunkworksX2> ;)
[02:13:09] <cradek> jmk-kayak: do you want to commit silvan's patch for rtlinux?
[02:13:56] <jmk-kayak> yeah
[02:13:59] <skunkworksX2> me doing the apget for emc - will that cause the wrong kernel to boot?
[02:14:37] <cradek> not sure which one will be the default
[02:14:45] <cradek> just choose the one you want on the menu
[02:15:01] <skunkworksX2> we will see = be back
[02:22:43] <skunkworksX2> 11700
[02:22:56] <skunkworksX2> getting trunk now
[02:25:38] <jmk-kayak> building emc2, running find on the whole disk, and glxgears....
[02:25:42] <jmk-kayak> 18265
[02:26:01] <cradek> that's higher than ours, but still pretty good
[02:26:15] <jmk-kayak> glxgears is going at a rockin' one frame every second or so
[02:26:24] <cradek> glxgears seems buggy lately
[02:26:24] <jmk-kayak> in a little window
[02:26:32] <cradek> it just doesn't seem to display right
[02:26:59] <cradek> I wish there was a better GL test
[02:27:07] <cradek> hey I bet you can run any of the screensavers in a window
[02:27:56] <cradek> /usr/lib/xscreensaver/glmatrix -window
[02:28:26] <skunkworksX2> I get 15095 with glxdears running
[02:28:36] <skunkworksX2> or gears
[02:28:58] <cradek> aha! /usr/lib/xscreensaver/gears -window
[02:29:17] <cradek> aha! /usr/lib/xscreensaver/gears -window -fps
[02:29:41] <skunkworksX2> oh -that is cool
[02:30:12] <skunkworksX2> still 15095 with no everruns
[02:30:19] <skunkworksX2> overruns
[02:30:27] <cradek> that's an excellent emc machine then
[02:30:34] <cradek> you should send it to Jymmm :-)
[02:30:34] <skunkworksX2> (this keyboard is at an odd angle)
[02:31:03] <skunkworksX2> don't I have to let it run for a bit ;)
[02:31:20] <jmkasunich> this one is 29863
[02:31:32] <skunkworksX2> what proccessors?
[02:31:45] <jmkasunich> running the screensaver gears (which runs much better than the regular glxgears) and building emc2
[02:31:57] <skunkworksX2> (dual 600 pIII) with a older ati video card
[02:31:57] <jmkasunich> processor singular, sempron 2800+
[02:32:11] <jmkasunich> kayak is the dual P3-666
[02:32:29] <skunkworksX2> seems to run about 10 frames per second
[02:32:43] <skunkworksX2> or 12
[02:32:58] <cradek> I get 20fps on my 300MHz ppc with software rendering
[02:33:18] <skunkworksX2> 15544
[02:33:27] <jmkasunich> the gears screensaver here reports 14-15 fps
[02:33:33] <jmkasunich> latency up to 31367
[02:34:14] <petev> was just reading all the email on the dev list about USB. Seems to me the real issue is path planning, trajectory planning, and trajectory tracking are too intertwined in EMC
[02:34:38] <skunkworksX2> screenshot took me to 21256 ;)
[02:34:45] <petev> I don't see any reason why path planning and trajectory planning couldn't be done non realtime
[02:35:01] <cradek> FO
[02:35:08] <jmk-kayak> hmm, no /usr/lib/screensaver on this box
[02:35:19] <cradek> more specifically, FO > 100%
[02:35:48] <petev> I'm not sure there is much to gain by chaning the path based on FO
[02:35:56] <petev> you would need to calc some new trajectory
[02:36:11] <jmk-kayak> you have to, or you'll exceed machine limits
[02:36:15] <cradek> you can't FO over 100% if you plan at limits
[02:36:17] <petev> but the update can be fairly easy from previous calcs
[02:36:21] <cradek> you'd have to plan at max FO
[02:36:40] <petev> no, you don't have to change the path
[02:36:46] <jmk-kayak> yes you do
[02:36:49] <petev> you can just change the trajectory
[02:36:54] <petev> it may not be time optimal
[02:36:57] <jmk-kayak> a blended corner has a velocity dependent radius
[02:37:01] <petev> but the gain is minimal
[02:37:04] <jmk-kayak> change the FO, you change the radius
[02:37:18] <cradek> I don't understand the distinction you're making between path/trajectory
[02:37:19] <petev> why not just blend to the err tolerance and leave the path alone?
[02:37:33] <petev> trajectory is time/accell stuff
[02:37:40] <petev> path is the position data
[02:37:52] <petev> I think they can be separated
[02:37:58] <cradek> petev: so you should never give results better than the tolerance even when it's easy to do while remaining inside limits? that seems bad
[02:38:02] <petev> and much of the calcs done non-realtime
[02:38:20] <jmk-kayak> path is where you go, traj is how fast you go... I understand the need for a distinction, I just don't like using trajectory to mean that
[02:38:31] <petev> you plan the path based on tolerance and programed feed
[02:38:32] <cradek> ok I understand the distinction
[02:38:40] <petev> under this case you woulnd't be far off
[02:38:45] <cradek> petev: you can't, if you have FO>100
[02:38:48] <skunkworksX2> http://www.electronicsam.com/images/pent3shot.png
[02:38:54] <petev> if the op is adjusting the feed by 300%, the g-code sux
[02:39:03] <petev> cradek, you can
[02:39:15] <petev> I have a flow chart that does much calcs non realtime
[02:39:24] <petev> and some simple stuf RT to obey limits
[02:39:34] <jmk-kayak> he might be running it at 1000% while cutting air or wax to proof the program... you can't just say "the code sux, therefore we can ignore the FO > 100% case"
[02:39:47] <petev> I got the idea from some offline pre-processor that actually changed the g-code for dumb machines
[02:40:14] <jmk-kayak> there is also probing,. homing, and a lot of other stuff that doesn't lend itself to offline calcs
[02:40:21] <petev> I'm saying a program that needs FO of 300% or something should be re-written, then run again
[02:40:33] <jmk-kayak> I really don't understand the interest in non-RT planning
[02:40:39] <jmk-kayak> what does it give you?
[02:40:42] <petev> then if you plan the path on err tol and prog feed, you will be very close to optimal
[02:41:04] <petev> then you can leave the traj tracking to devices on a rope without an RT connection
[02:41:12] <jmk-kayak> bah
[02:41:17] <petev> and they can be simpler devices that can't fully plan
[02:41:48] <jmk-kayak> to me the beauty of EMC is that it takes the power of a high end GHz processor and lets us use it like an embedded machine
[02:42:03] <cradek> I'd be happy to see someone work on that, but like jmk says, I don't think it's EMC anymore
[02:42:04] <jmk-kayak> why would I want to throw that away and do stuff in some much more limited external box?
[02:42:34] <petev> why throw away? a more modular architecture allows more solutions
[02:42:37] <cradek> (ask me again in 5 years when no hardware will do realtime though)
[02:43:11] <jmk-kayak> we'll be jealously guarding our shrinking stacks of P3s....
[02:43:26] <cradek> petev: everyone also seems to forget about servos when talking about 'on a rope'
[02:43:41] <cradek> or would you "just" move pid too?
[02:43:45] <petev> the device on a rope needs to do the trajectory tracking
[02:43:54] <petev> that is the RT part for sure
[02:44:05] <skunkworksX2> cradek:
http://pastebin.ca/455259
[02:44:07] <petev> if it can't do that, then it's not going to work
[02:44:16] <skunkworksX2> seemed to make and such fine
[02:44:34] <petev> but I don't think PID is that complicated, even with integer math
[02:44:44] <jmk-kayak> skunkworks try "scripts/realtime stop"
[02:45:08] <skunkworks> oh - crap. I think I had the latency test running
[02:45:09] <skunkworks> sorry
[02:45:16] <jmk-kayak> ;-)
[02:45:33] <jmk-kayak> still 18265 here ;-)
[02:45:51] <jmk-kayak> it almost seems a shame to put this box back in the corner and let it gather dust again
[02:46:22] <petev> have you guys looked at any of the RT ethernet stuff like powerlink, PTP, etc.?
[02:46:29] <jmk-kayak> no
[02:46:33] <skunkworksX2> cradek: works :)
[02:46:40] <jmk-kayak> my plate is plenty full as it is
[02:46:51] <petev> they are doing RT control by syncing clocks and sending data a little before execution
[02:46:54] <petev> gets around the latency
[02:47:16] <petev> and the PTP protocol is pretty light weight and gives usec synchronization
[02:47:18] <cradek> skunkworksX2: nice, thanks for testing that
[02:47:41] <cradek> skunkworksX2: might be a good controller for your mill when you get it going
[02:48:15] <jmkasunich> 34735....
[02:48:32] <jmkasunich> glad this isn't gonna be my machine controller
[02:48:39] <cradek> jmkasunich: that's the P3? seems really high
[02:48:47] <jmkasunich> no, the sempron
[02:48:51] <cradek> ahh
[02:48:58] <jmkasunich> 2xP3 is 18265
[02:49:24] <jmkasunich> it will be interesting to try the C2D once its running
[02:50:20] <jmkasunich> it would also be interesting to run the latency test without the VMs running, but I'm too lazy to shut them down and restart them
[02:52:17] <cradek> petev: is this boss-plc for your machine?
[02:52:49] <cradek> it's an interesting approach - probably could all be done in ladder, but C is simpler
[02:52:54] <cradek> (for me anyway)
[02:53:53] <petev> yes, it's for my machine and some guy was asking about BP stuff
[02:53:57] <petev> so I thought I would commit it
[02:54:03] <petev> I looked at the ladder
[02:54:22] <petev> but some stuff was painfull and the new cl is bloated with non RT code in the RT image
[02:54:34] <petev> my MB is limited and only has 256MB
[02:54:42] <petev> so I wanted it lean & mean
[02:55:17] <petev> I guess I pretty much suck with ladder too ;-)
[02:55:33] <cradek> I can definitely sympathize
[02:58:54] <jmkasunich> ladder is good for stuff that is inherently concurrent
[02:58:59] <jmkasunich> not so good for sequential
[03:00:10] <petev> state machine stuff also seemed very tedious, I wouldn't want to do a complex tool changer in ladder
[03:00:32] <petev> it's like designing with gates and latches
[03:01:34] <jmkasunich> state machines are sequential
[03:02:00] <jmkasunich> the ladder I did for the Mazak toolchanger is a hack
[03:02:17] <jmkasunich> but it worked, for some value of "worked"
[03:51:22] <skunkworks> Time for bed. Nice work on the kernel. as always - keeps getting better and better.
[15:39:31] <jepler> cradek: was there some other axis bug you were also keeping for me?
[15:41:36] <cradek> not that I recall
[16:00:00] <Guest980> Guest980 is now known as skunkworks_
[16:03:04] <skunkworks_> skunkworks_ is now known as skunkworks
[16:04:40] <jepler> cradek: did you ever do this? 16:47:41 <jepler> cradek: can you add the section name to the i2g docs in 2.1 and trunk for me?
[16:04:46] <jepler> if not, I can do it now
[16:05:03] <cradek> no, sorry
[16:05:08] <jepler> OK
[16:26:15] <jepler> .. done
[16:45:21] <jepler> Merging differences between 1.27 and 1.34 into axis.tcl
[16:45:21] <jepler> rcsmerge: warning: conflicts during merge
[16:45:22] <jepler> ouch
[16:45:25] <jepler> I've been away too long
[18:18:49] <cradek> jepler: oh I thought of another bug - I don't remember if I put it in the tracker: when you type - in MDI, you get a traceback
[18:18:59] <cradek> also +, I suspect
[18:19:34] <jepler> hm OK
[18:42:03] <cradek> moving here...
[18:42:14] <jepler> hi again
[18:42:24] <cradek> the display option saving doesn't suck, does it? say I only had 50% suckage
[18:42:43] <jepler> I haven't noticed that feature yet one way or the other, so I am sure it's just fine
[18:42:48] <cradek> good
[19:04:47] <jepler> alex_joni: want to fix a bug that I have declared is a bug in Task?
[19:07:26] <jepler> Anyone know if this text can be revised? "The Enhanced Machine Controller(EMC) is a public domain CNC software project running on Linux. This is the developers-only list. There is a more general list at emc-users@lists.sourceforge.net."
[19:07:38] <jepler> https://lists.sourceforge.net/lists/listinfo/emc-developers
[19:07:57] <cradek> I think I can
[19:09:18] <jepler> maybe something like ".. is an Open Source CNC controller running on Linux. This list is for anyone interested in the ongoing development of emc. There is a more general list..."
[19:10:49] <cradek> hoszat?
[19:10:54] <cradek> howzat?
[19:12:53] <alex_joni> jepler: I can try
[19:12:58] <alex_joni> hit me ..
[19:13:06] <cradek> alex_joni: done already
[19:13:10] <alex_joni> yay
[19:13:21] <alex_joni> what was it?
[19:13:34] <cradek> what was what?
[19:13:47] <alex_joni> < jepler> alex_joni: want to fix a bug that I have declared is a bug in
[19:13:47] <alex_joni> Task?
[19:13:51] <cradek> ah
[19:13:57] <jepler> alex_joni:
[19:13:58] <alex_joni> about 8 minutes ago
[19:14:01] <cradek> I take back my "done" then
[19:14:02] <jepler> http://sourceforge.net/tracker/index.php?func=detail&aid=1701792&group_id=6744&atid=106744
[19:14:22] <jepler> alex_joni: the user says that you can switch to mdi while in homing (or maybe home sequence?) and that unspecified bad things happen
[19:14:55] <alex_joni> wanna hear my 2 cents?
[19:15:03] <alex_joni> (but don't laugh..)
[19:15:23] <alex_joni> task sends the request for modechange to motion, which changes.. so it can be either one
[19:15:30] <alex_joni> I'll start looking to make sure though
[19:16:19] <jepler> based on playing with sim/axis, the homing sequence ends up being paused while in mdi mode and will continue when returning to manual mode
[19:21:50] <alex_joni> how about a single home operation
[19:21:53] <alex_joni> not a sequence..
[19:30:49] <jepler> beats me
[19:30:52] <jepler> I could test of course
[19:40:35] <alex_joni> I followed the code
[19:40:41] <alex_joni> and it seems task just passes it on
[19:40:48] <alex_joni> changes the motion mode to COORD
[19:43:07] <alex_joni> I think I'll wait for jmk before I dig too deep inside the motion controller
[19:43:34] <alex_joni> it seems it acceptable to get the switch command at any time, and a flag gets set (emcmotDebug->coordinating)
[19:44:29] <alex_joni> it will change modes only when the axis is inposition (e.g. not moving)
[19:44:55] <jepler> hm ok
[19:44:57] <alex_joni> so it's quite probable to catch this while doing a simple homing move too (e.g. between search vel and trip vel)
[20:29:53] <jepler> please tell me if this is too snarky a message to attach to Marcus' "bug" report "Check return codes everywhere":
[20:29:56] <jepler> If you have bug fixes, use the bugs tracker to attach the fixes in unified diff format. Please do not file further bugs about unspecified problems based on automatic source code inspection. This is not a forum for you to propose how we should develop emc, or as a place to promote an unrelated product.
[20:30:02] <jepler> Our software can be accessed through a public CVS server (
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Getting_the_source_with_CVS). This is not a forum for you to propose a different method or service to provide access to the source code.
[20:30:23] <jepler> </>
[20:30:33] <jepler> Status: Closed Resolution: Invalid
[20:32:15] <alex_joni> we could open a patch tracker, for people to submit patches
[20:33:23] <jepler> yes, but that's not quite the issue of this moment
[20:33:51] <alex_joni> I know, you just reminded me of that
[20:34:01] <jepler> it seems to me that this guy is interested in promoting "splint", svn, "aspect-oriented programming" and other things that are really not very interesting proposals
[20:34:10] <jepler> I think he is unlikely to ever actually submit a patch
[20:34:41] <cradek> did he suggest svn? I missed that one
[20:35:12] <jepler> 4. How do you think about to integrate your current sources into a
[20:35:12] <jepler> Subversion repository (at SourceForge)?
[20:35:22] <cradek> offs
[20:35:23] <jepler> yes, in one of his comments on "Check return codes everywhere"
[20:35:23] <alex_joni> I saw he got banned from another projects forum a while ago
[20:36:05] <cradek> well that response looks fine to me
[20:36:11] <jepler> OK, I changed "bug tracker" to "tracker" in case we do open a patches tracker
[20:36:23] <jepler> I also changed the second paragraph:
[20:36:23] <jepler> Our software can be accessed through a public CVS server (
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Getting_the_source_with_CVS). This decision was made carefully by the board of directors after a particularly long outage of sourceforge's CVS services. This is not a forum for you to propose a different method or service to provide access to the source code.
[20:36:46] <jepler> alex_joni: what project was that?
[20:36:46] <cradek> IMO you don't need to justify anything.
[20:37:14] <cradek> Results 1 - 10 of about 227 for "markus elfring" "would you like to"
[20:37:16] <jepler> hm
[20:37:36] <jepler> OK if you think it is better with fewer words :-P
[20:37:38] <jepler> * jepler submits
[20:38:27] <cradek> Results 1 - 10 of about 165 for "markus elfring" "how do you think"
[20:38:41] <alex_joni> http://66.102.9.104/search?q=cache:r5XnephBMzEJ:sourceforge.net/mailarchive/forum.php%3Fthread_id%3D4092526%26forum_id%3D11832+Markus+Elfring+ban&hl=en&ct=clnk&cd=1&client=opera
[20:39:04] <alex_joni> seems it recently got removed from sourceforge
[20:40:07] <cradek> this whole thing is otherworldly
[20:40:52] <alex_joni> it seems rather odd to do stuff like that
[20:42:13] <jepler> I can almost imagine it
[20:42:45] <jepler> "if I can encourage everyone to develop their software just a little bit better, the world will be improved"
[20:42:57] <jepler> he's trying to teach all us poor starving men to fish
[20:42:59] <alex_joni> what? running around finding random projects and suggesting random improvements?
[20:43:01] <jepler> not provide us with fish (patches)
[20:43:27] <alex_joni> * alex_joni shrugs
[20:47:56] <jepler> I don't mean I agree with it -- just that I can (almost) see it his way
