#emc-devel | Logs for 2011-07-15

[00:01:21] -!- OoBIGeye has quit [Ping timeout: 276 seconds]
[00:03:07] -!- theorbtwo has quit [Read error: Operation timed out]
[00:06:48] <andypugh> The parport driver uses code at line 214 in hal_parport (http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/hal/drivers/hal_parport.c;h=2eacc7932873468ad9b7522509dd8f575bfcffca;hb=33f16bd002c66c823dda2b6d8ab8afb24e3e14e1 ) to calculate a factor between CPU clocks and nanoseconds.
[00:07:55] <andypugh> Is there anything built in to rtapi to do the same thing? And does it actually give up and pick a random number for kernels < 2.6.0 or am I missing something subtle?
[00:11:45] -!- OoBIGeye has quit [Ping timeout: 276 seconds]
[00:14:15] <andypugh> I am tempted so set up a pause in the setup code, measure the rtapi_get_clocks delta and the rtapi_get_time delta and calculate a number..
[00:17:41] <cradek> also see motion/control.c:245
[00:17:42] <cradek> also see hal/drivers/hal_parport.c:382
[00:18:09] -!- OoBIGeye has quit [Remote host closed the connection]
[00:18:46] <cradek> bbl
[00:20:01] <andypugh> cradek: The ns2tsc was what I was going to steal, I am writing a reset function for a different browser. But I want something that works in a comp
[00:20:19] KimK_afk is now known as KimK
[00:20:31] <andypugh> different browser? I am losing my mind. Different driver, I mean.
[00:27:30] -!- OoBIGeye has quit [Ping timeout: 255 seconds]
[00:38:33] -!- robh__ has quit [Ping timeout: 264 seconds]
[00:40:51] -!- tom3p [tom3p!~tomp@74-93-88-241-Illinois.hfc.comcastbusiness.net] has parted #emc-devel
[00:41:24] KimK is now known as KimK_afk
[00:42:44] <jepler> I strongly suspect nobody is using pre-2.6 kernels which don't have cpu_khz
[00:44:25] <andypugh> I guess they would need to be a bit perverse, and have built their own EMC2
[00:44:44] KimK_afk is now known as KimK
[00:45:08] <andypugh> Can I use cpu_khz inside comp?
[00:45:47] <andypugh> <experiment>
[00:46:12] <jepler> the reason that this code works in an odd way is that I needed to calculate, in "nofp" code, a conversion from nanoseconds to CPU cycles
[00:47:29] <jepler> in code that *can* use floating-point, I'd write things in the most straightforward way, using cpu_khz if appropriate
[00:47:59] KimK is now known as KimK_afk
[00:48:38] <andypugh> Setup code is perfctly at liberty to use fp, isn't it? And the factor is not likely to change between setup and thread runnng..
[00:49:03] -!- jbunch has quit [Ping timeout: 258 seconds]
[00:49:13] <jepler> yes, startup code can use fp
[00:49:34] <jepler> but the ns2tsc macro is used in nofp code
[00:50:14] <jepler> git says I originally used FP math for calculating ns2tsc_factor, but it "caused a problem on one user's system (gcc 3.4)".
[00:50:50] <jepler> I think that at this point, systems that build the kernel with gcc 3.4 are also far enough into the past to ignore them
[00:52:39] <jepler> (linux 2.6.0 = 2003, gcc 4.0.1 = 2005)
[00:52:51] <andypugh> I assume it is a macro to avoid a global variable? But inside a comp a global variable is probably more normal
[00:53:42] <jepler> ns2tsc is a macro instead of a static function out of some misguided belief that it has an impact on performance (i.e., no good reason)
[00:55:20] <andypugh> Is there any reason that my comp setup code shouldn't just create a u64 factor, store it in a variable and use it?
[00:55:21] <jepler> I feel like I ought to mention that there's also rtapi_delay, which takes an argument in nsec
[00:55:48] <jepler> if you're within a single hal function and trying to wait the documented amount of time an I/O device needs, then you should probably use rtapi_delay instead
[00:56:19] <jepler> again, the structure of parport is weird, because the initial write and the later reset are two separate hal functions. If your code is different, the simpler rtapi_delay might be easier
[00:56:20] <andypugh> Well, this is to mirror parport reset in the pcl720 driver.
[00:56:25] <jepler> ok
[00:56:35] <jepler> then I guess you'll need just about the same suckage
[00:56:39] <andypugh> Yeah.
[00:57:54] <andypugh> I was about to suggest an rtapi_delay(now_time-writetime+delaytime) but that involves the known-bad now-time (or rtapi_get_time, as it is called)
[00:57:54] -!- OoBIGeye has quit [Ping timeout: 276 seconds]
[00:58:10] <jepler> welllllll
[00:58:40] <andypugh> the rtapi header says that can take microseconds to return. Imagine that, whole microseconds!
[00:59:03] <jepler> I honestly don't know the current performance of rtapi_get_time
[00:59:20] <jepler> that advice is from a vintage of bdi4 / ubuntu 5.10
[00:59:33] <jepler> it's entirely possible that rtapi_get_time is still just as bad, and it's entirely possible that it's just dandy now
[01:01:27] <jepler> RTIME rt_get_cpu_time_ns(void)
[01:01:27] <jepler> {
[01:01:27] <jepler> return llimd(rdtsc(), 1000000000, tuned.cpu_freq);
[01:01:50] <jepler> this is the current (ubuntu lucid) implementation of the function that rtapi_get_time calls
[01:03:02] <jepler> that's "long long integer multiply annd divide" and it also has a fairly straightforward implementation
[01:03:21] <andypugh> That's machine code?
[01:03:36] <jepler> sooo in summary, I'd be real tempted to tell you to use rtapi_get_time + rtapi_delay
[01:03:44] <andypugh> Or a kernel function?
[01:03:51] <jepler> it comes from rtapi
[01:03:58] <jepler> er, it comes from rtai
[01:04:21] <jepler> specifically, rtai_hal.h
[01:04:36] <jepler> actually I see that the implementation for i386 is machine code
[01:04:51] -!- OoBIGeye_ has quit [Ping timeout: 255 seconds]
[01:05:03] <andypugh> I was asking about the rather odd-sounding llimd() function.
[01:05:21] <jepler> yes, (rtai_)llimd is a function from rtai
[01:05:31] <jepler> the x86 implementation, just in case you enjoy that sort of thing: http://pastebin.com/8zMkqvjc
[01:05:46] <jepler> bonus comment to tell you what the heck it actually is doing!
[01:05:48] <andypugh> Last time I used machine code I needed to type it in in hex, and we only had add and subtract.
[01:06:40] <jepler> you still don't have to look too hard for a microcontroller without a multiply instruction
[01:06:42] <cradek> subtract -- what luxury!
[01:06:50] <cradek> (sorry)
[01:06:54] <jepler> cradek: yes, please, tell us about writing software on the F8
[01:07:19] <andypugh> Well, I say "subtract" I mean "complement, then add"
[01:07:25] <cradek> first you had to kill a whale to get lamp oil, since this was before there was the sun
[01:07:52] <jepler> the first CPU I wrote for had the luxury of being able to add or subtract in either binary OR bcd!
[01:08:00] <jepler> talk about dead(ish) features!
[01:08:10] <andypugh> It was all the rage
[01:08:28] <andypugh> I am going to go out on a limb and guess Z80?
[01:08:37] <jepler> nah, 6502 (or maybe 6510?)
[01:08:44] <andypugh> Z80 did it too.
[01:09:15] <andypugh> And, that PCL720 board that this driver is for is also configurable to use BCD for the counters/timers
[01:09:53] <andypugh> What are the chances that a driver for an ISA card will also work for a PCI card?
[01:10:28] <andypugh> You would have to be pretty eccentric t keep 8-bit access to PCI?
[01:10:30] <cradek> about nil
[01:10:44] <cradek> with some extra setup, maybe
[01:11:09] <andypugh> Given the same register structure, I would have thought that outb() works just the same?
[01:11:36] <jepler> andypugh: so just to repeat myself, in your place I'd try writing the code in terms of rtapi_get_time and rtapi_delay instead of rtapi_get_clocks and busy-loops
[01:12:19] <jepler> if those functions do turn out to still have performance problems, then decide what to do, and copy bits of the timing code more closely from hal_parport as warranted
[01:13:09] -!- OoBIGeye has quit [Remote host closed the connection]
[01:13:15] <jepler> but from looking at the implementation in rtai, I think there's every chance that the warning in the rtapi_get_time is way past its freshness date
[01:13:16] -!- Calyp has quit [Quit: Leaving]
[01:14:23] <jepler> heck, I'm tempted to think I know exactly why it used to be bad -- there's commented-out code in rtai_rtapi.c's rtapi_get_time() that indicates it used to call the kernel's (non realtime) gettimeofday functionality, which *would* totally kill your realtime performance
[01:14:32] <jepler> /*do_gettimeofday(&tv);*/
[01:14:34] <andypugh> Given that the main function of this one-user driver is as an example of a simple driver for simple hardware written in Comp, keeping it simple and obvious makes sense.
[01:14:35] <jepler> /*return (tv.tv_sec * 1000000000LL) + (tv.tv_usec * 1000L);*/
[01:15:01] <andypugh> eeek!
[01:15:01] <andypugh> ]
[01:24:31] <jepler> geez, I don't even have a machine running a rtai kernel connected in my house
[01:25:38] <Jymmm> jepler: BLASPHEMER!!!
[01:25:46] <Jymmm> GET A ROPE!
[01:25:51] <jepler> what can I say... it hasn't been a priority lately :-/
[01:26:14] <Jymmm> jepler: it's all good =)
[01:27:41] -!- OoBIGeye has quit [Ping timeout: 260 seconds]
[01:28:57] <CIA-11> EMC: 03jepler 07master * r427b22e93798 10/src/hal/user_comps/shuttlexpress.c: Fix build errors on unusual system
[01:29:01] <CIA-11> EMC: 03jepler 07master * r975e6d945534 10/src/rtapi/rtai_rtapi.c: Get rid of crazy commented-out code
[01:29:20] <andypugh> rtapi_delay isn't all that clever, it's udelay(ns/1000)
[01:30:47] <jepler> hm, that's a bit suspect
[01:31:19] <jepler> udelay is also going to turn out to be realtime-breaking code, I think
[01:31:32] <jepler> :-/
[01:32:56] -!- OoBIGeye has quit [Ping timeout: 260 seconds]
[01:33:14] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[01:33:56] <jepler> it should probably call rt_busy_sleep(int nanosecs)
[01:36:09] <andypugh> Does this make more sense to you than to me?
[01:36:52] <jepler> well, it's from very old linux (linux-2.4) for a CPU nobody has (DEC ALPHA)
[01:37:48] <andypugh> Well, that's me + Google for you :-)
[01:37:54] <jepler> heh
[01:38:11] -!- OoBIGeye has quit [Ping timeout: 260 seconds]
[01:39:01] <andypugh> I am coding in X-code on my Mac, and only have the EMC2 source in the project. Once things get into kernel code, I can't see them.
[01:39:21] <jepler> that code's a basic delay loop (decrement and branch if greater than zero) that was calibrated based on a specific 1GHz ALPHA CPU
[01:39:52] <andypugh> Ah, so, that is unlikely to be unchanged in the current i386 kernel, then.
[01:42:54] <andypugh> Sorry to be impolite, but it is 0240 here, and I have work tomorrow. If you do come to a conclusion as to whether rtapi_delay and rtapi_get_time are now less-deprecated, can you email me? Or maybe it is worth a mention on the dev list?
[01:43:05] <andypugh> Night Folks
[01:43:18] <jepler> no problem
[01:43:23] <jepler> rtapi_delay is clearly still broken
[01:43:26] -!- andypugh has quit [Quit: andypugh]
[01:46:00] -!- OoBIGeye has quit [Ping timeout: 276 seconds]
[01:48:18] <cradek> my P3 is sooo sloooow
[01:51:01] -!- OoBIGeye has quit [Ping timeout: 260 seconds]
[02:07:38] <jepler> cradek: I bet
[02:07:46] <jepler> but isn't it SMP!?
[02:07:46] -!- El_Matarife has quit [Client Quit]
[02:08:04] <cradek> real 14m6.875s (yes, -j2)
[02:09:25] KimK_afk is now known as KimK
[02:09:54] <jepler> building emc2? I think that's about 7x what my system takes.
[02:10:04] <cradek> yep v2.5_branch from clean
[02:10:37] <cradek> it's not bad, considering the machine is 10? years old
[02:11:04] <KimK> cradek: Maybe it's my fault? Try it docs vs. No-docs?
[02:11:16] <cradek> no way am I building docs on this one :-)
[02:11:34] <cradek> that takes forever even on my fast(er) everyday laptop
[02:11:48] <KimK> Ah, you've got docs off already. Nevermind.
[02:12:45] <cradek> KimK: how are you feeling about the state of the 2.5 docs?
[02:13:24] <jepler> cradek: that's only 14x the wall time on my system (-j4)
[02:14:36] <jepler> nearly 4 doublings in speed comparing a 2009 CPU vs a 2003 or earlier CPU, 4 doublings in 6 years.. sounds about right
[02:16:37] <cradek> wp says P3-Coppermine (incl 1000 MHz) was March 2000
[02:16:57] <KimK> cradek: Pretty good, I would like to see if the cross-reference page can be restored to proper operation. Perhaps that was commented out during the LyX to AsciiDoc changeover? It was suggested to me to ask if psha and jepler can fix it, but I haven't yet. (hint, hint.)
[02:20:28] <KimK> cradek: Build time is up to (I think it was) 21 minutes, the most I've seen. That's total rebuild, with make clean, on my recent but unremarkable system.
[02:21:30] <cradek> KimK: I sure appreciate all your work.
[02:21:33] <cradek> KimK: how's the Jr coming?
[02:25:08] <jepler> http://embed.cs.utah.edu/csmith/
[02:25:33] <cradek> that's awesome
[02:25:42] <KimK> I started to pull things out, pendant is empty, spindle drive is disconnected, it will come out tomorrow when I can borrow bigger tools from Wes for the mounting bolts. Pictures of what you put in where the old control came out would certainly be appreciated. And pictures (or a line sketch) of your "quadrature move" on the tool changer also appreciated, I want to duplicate your change accurately.
[02:26:08] <jepler> they had a fairly clever idea: write a program that can write correct (but useless) C programs
[02:26:13] <cradek> will you be staying down there until it's completed, or will you pass through or near lincoln?
[02:26:34] <jepler> compile the output with 3 (or more) compilers .. if they disagree, either the program has undefined behavior, or at least one compiler has a bug
[02:26:51] <jepler> for instance, apparently the gcc on ubuntu 8.04 miscompiled this:
[02:26:51] <jepler> int foo(void) { signed char x = 1; unsigned char y = 255; return x > y; }
[02:27:06] <cradek> jepler: so no attempt to know the right output?
[02:27:27] <jepler> cradek: right
[02:27:34] <cradek> that's a brave approach
[02:28:19] <jepler> well, there are "safety checks", for instance it makes sure that generated programs never use uninitialized storage
[02:28:58] <cradek> but (obviously) you can miss the case where they all get it wrong.
[02:29:32] <KimK> I will be here for 3 to 6 weeks for sure. Longer than that is possible, but still undetermined at this point.
[02:29:42] <cradek> KimK: I'll try to get some adequate pictures for you
[02:31:39] <KimK> cradek: Thanks! Greatly appreciated at this point. And was the brand of your "large touch screen purchase" something like "ELO"? (Possibly with odd capitalization?)
[02:31:52] <cradek> I will take pictures of the screen too
[02:31:59] <cradek> yes they're elo something
[02:32:19] <cradek> model ET15xx something something
[02:33:14] <cradek> bbl
[02:36:54] <KimK> cradek: OK, then I can identify which is which. There's a different model here too, a singleton, and I might put that one into the Sajo. Speaking of the Sajo (and its 4-axis capabilities), I haven't studied the Jr. files you sent yet, is there enough servo I/O available to add a fourth axis? A fifth?
[02:37:13] <KimK> I'll be back in a bit too, need a water refill.
[02:50:05] <KimK> jepler: Very interesting about the Csmith business, thanks for posting that. It sounds similar to "random-walk" testing, ( http://en.wikipedia.org/wiki/Random_walk ) a "simple idea", which quickly proves to be much more complex than initially thought, and can do some very rigorous testing indeed.
[02:54:03] <cradek> KimK: my jr actually has 4 axes now.
[02:55:34] <KimK> cradek: Excellent, and is that included in the files you sent?
[02:58:55] <KimK> cradek: What motor and drive did you use for #4 ? Oh, and your spindle motor, that's a standard AC induction motor, right? How many HP/kW? Does the "odd resolver" show up with individual windings/coils in the drawings, or is it just a box/cylinder with wires coming out?
[02:59:25] <cradek> got you some good photos, one minute
[02:59:50] <cradek> I'm pretty sure the spindle motors are the same
[03:00:06] <KimK> You switched to an encoder, I'd guess? Do you remember the resolution?
[03:00:42] <KimK> (Yes, it should be in the HAL files, I can look it up)
[03:02:10] <cradek> the pulleys are a weird ratio. I installed whatever encoder then turned the spindle 100 times and checked the counts
[03:03:58] <cradek> http://timeguy.com/cradek-files/emc/spindle-encoder.jpg
[03:04:12] <cradek> this is the mess I made to protect the encoder atop the motor
[03:05:13] <KimK> I wonder why they did that odd-ratio thing. Thanks for the tip, I'll watch for that.
[03:05:18] <cradek> guess I didn't take a picture of the encoder mount itself - it was a HEDS module and wheel I pulled out of something - the mount was finicky
[03:06:15] <cradek> this is all sealed with gasket goo
[03:07:11] <cradek> the big file I sent you contains photos of the machine setup plus photos (sorry) of any schematic pages that have annotations
[03:09:04] <KimK> No problem, I'll take all the help I can get, thanks! Any problems with heat affecting the encoder above the spindle motor? Or is it off to the side far enough to avoid heat problems?
[03:10:02] <cradek> it's right under a fan. I doubt it even gets warm to the touch.
[03:12:12] <KimK> So your motor is a little less than 5HP continuous, and a little less than 7.5 HP 30 min? Not too shabby. What did you use for an aftermarket drive, and did you have to have one that had selectable parameters, so you could choose between velocity mode with ramp, and servo-position-hold mode?
[03:13:28] <cradek> it doesn't have servo mode
[03:13:45] <cradek> there's a picture of the drive in there
[03:15:24] <KimK> Nice chunk of aluminum in that pix
[03:15:37] <cradek> yeah, certainly a brute force approach
[03:15:55] <KimK> Hey, whatever works!
[03:16:50] <cradek> the fan is slightly higher than originally
[03:17:03] <cradek> but it's still inside the shroud so it probably cools about the same
[03:17:17] <cradek> if I was worried about cooling I'd scrape all the goop off the motor fins first
[03:18:14] <KimK> "Flowerpots" and similar items are always hard to make without either: 1) starting with a casting. 2) starting with a huge billet 3) Welding a bunch of different-sized rings and plates together and then trying to square the mess up by milling and turning
[03:18:34] <cradek> yeah, yuck
[03:19:13] <KimK> So, no apologies necessary, lol.
[03:19:29] <cradek> this didn't take long at all. those 3/4 roughers are my favorite
[03:19:33] <KimK> You were lucky to get/have that big billet
[03:20:04] <cradek> yes those are nice to have around. the bottom plate is pretty big too.
[03:21:17] <KimK> I have seen some pretty big chunks in the scrap bin here, I'll have to go measure some Jr. stuff before "scrap-man day".
[03:21:51] <cradek> you never want for scrap in that shop
[03:24:23] <KimK> Yes, apparently there's a third way you can scrap something here. Not only the usual 1) it was cut away from the part we wanted, and 2) We made a mistake and ruined it, but also 3) We have lost traceability on this raw stock that we haven't even put a tool to yet.
[03:24:35] <cradek> eek
[03:25:05] <cradek> slightly better than after it's done, I guess
[03:25:42] <KimK> Ha, yes, maybe that would be 4, 5, 6 etc., lol.
[03:26:17] <KimK> We scrapped our part, *and* we dropped it on our foot afterwards.
[03:28:20] <KimK> So, plenty of expansion to add the 4th axis, since you did it already. How about a fifth? Sometime I'd like to try building a 5th rotary on a 4th trunnion.
[03:28:51] <cradek> yeah, I think I have encoders/dacs leftover
[03:29:00] <cradek> this machine *might* have enough Z travel to do that
[03:29:21] -!- FinboySlick has quit [Quit: Leaving.]
[03:29:41] <cradek> seems like you could just bolt one "vertical" rotary to another one
[03:31:42] <KimK> You mean right-angle two together? I've never seen that done, maybe too much strain?
[03:32:39] <cradek> yeah it probably wouldn't be very strong, but it'd be very easy and would be enough to do proof of concept
[03:33:57] <cradek> heck I've got a hefty (manual) tilting rotary table I forgot about
[03:34:15] <cradek> not sure if it might be too big though
[03:34:54] <cradek> (don't need a project right now anyway.)
[03:34:55] -!- ries has quit [Quit: ries]
[03:37:42] <KimK> Here are versions for Taig, Haas, and something much bigger: http://www.cncconversionkit.com/product.php?id_product=14 http://atyourservice.haascnc.com/wp-content/uploads/2010/06/Haas_TR160YS.jpg http://www.mitsuiseiki.co.jp/en/machine/vertex/01.html
[03:38:50] <KimK> Yes, I remember talking with you about your table before I ran out of money. Sorry about that.
[03:39:13] <cradek> the taig one is silly. the C table should be much lower wrt the A centerline
[03:39:28] <cradek> the other two have it right
[03:42:13] <KimK> Did John K ever finish his CNC table that he made? How did that work out?
[03:43:11] <cradek> I visited him a while after we saw it last at wichita, and he hadn't made any more progress
[03:44:54] <KimK> Well, he's a busy guy.
[03:45:41] <cradek> the problem we all have
[03:47:03] <cradek> http://timeguy.com/cradek-files/emc/multiturn-noninteger-ccomp.png
[03:47:07] <cradek> I forgot about this feature
[03:49:29] <KimK> Ah, I see, it doesn't have to make a complete circle? Good to know in case needed (but if not, I tend to think in complete circles, lol)
[03:50:00] <cradek> no, you can now make any number of full/partial circles with one g2/g3 command
[03:50:34] <KimK> Nice. Is that in v2.5 ?
[03:50:37] <cradek> yes
[03:51:10] <KimK> Hmm, I wonder if there's something about it in docs?
[03:51:25] <cradek> yeah I even wrote the docs. yay me!
[03:51:50] <KimK> Yes, yay you, lol! Thanks!
[03:51:56] <cradek> http://linuxcnc.org/docs/2.5/html/ sure looks different today
[03:52:12] -!- psha [psha!~psha@] has joined #emc-devel
[03:52:50] <cradek> http://linuxcnc.org/docs/2.5/html/gcode/main.html#sec:G2-G3-Arc
[03:52:57] <cradek> To program an arc that gives more than one full turn, ...
[03:55:38] <KimK> I hope people like the new HTML. If not, I would be willing to have a second HTML page with the old arrangement. But I thought the HTML layout should match the PDF manual layout.
[03:56:26] <cradek> sounds good to me...
[03:56:33] <KimK> Any complaints yet? Maybe still too new and unknown. Wait for the 2.4 to 2.5 upgrades, that'll do it.
[03:57:16] <KimK> Well, we'll see.
[03:57:42] <KimK> And on that happy note, I see it's getting late. Thanks for the chat and some answers to questions. I'm sure I'll have more as I start getting the covers off and get into things a little more.
[03:57:50] <cradek> welcome
[03:58:24] <KimK> Maybe see you here tomorrow. Goodnight.
[03:58:28] <cradek> 'night
[04:01:00] <psha> cradek: morning:0
[04:01:01] <psha> :)
[04:09:41] <KimK> Oops, one more thing. it appears that this official website page may need some adjusting: http://linuxcnc.org/docs/2.5/ Thanks.
[04:19:55] -!- jbunch has quit [Ping timeout: 246 seconds]
[04:22:06] -!- jbunch_ has quit [Ping timeout: 240 seconds]
[04:35:45] KimK is now known as KimK_afk
[04:57:08] -!- dgarr has quit [Quit: Leaving.]
[04:58:56] -!- psha has quit [Quit: Lost terminal]
[05:04:33] -!- Valen has quit [Remote host closed the connection]
[05:16:24] -!- mikegg has quit [Ping timeout: 255 seconds]
[05:23:33] -!- kbarry has quit [Read error: Connection reset by peer]
[05:24:37] -!- SWPadnos_ [SWPadnos_!~Me@74-92-8-214-NewEngland.hfc.comcastbusiness.net] has joined #emc-devel
[05:25:08] -!- SWPadnos has quit [Read error: Connection reset by peer]
[05:25:15] SWPadnos_ is now known as SWPadnos
[05:32:58] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[05:50:54] -!- Loetmichel has quit []
[06:02:58] -!- psha[work] [psha[work]!~psha@] has joined #emc-devel
[06:03:14] -!- ve7it has quit [Remote host closed the connection]
[06:05:27] -!- Poincare has quit [Ping timeout: 255 seconds]
[06:19:15] <CIA-11> EMC: 03mhaberler 07v2.5_branch * r83250db1a74f 10/docs/src/gui/images/small-screenshot.png: docs/gladevcp: add missing png
[06:26:09] -!- theos has quit [Ping timeout: 255 seconds]
[06:34:47] -!- Dannyboy has quit [Ping timeout: 240 seconds]
[06:38:36] -!- adb has quit [Ping timeout: 260 seconds]
[06:38:55] -!- adb [adb!~Moldovean@178-211-230-111.dhcp.voenergies.net] has joined #emc-devel
[06:55:28] -!- e-ndy [e-ndy!~jkastner@nat/redhat/x-vskujtydqdzxsrvd] has joined #emc-devel
[07:18:50] -!- Justin_CNC has quit [Quit: Leaving]
[07:46:24] -!- jbunch has quit [Read error: Connection reset by peer]
[07:50:41] -!- mhaberler has quit [Quit: mhaberler]
[08:07:56] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[08:14:22] -!- Birdman3131 has quit [Read error: Connection reset by peer]
[08:16:12] -!- robh__ [robh__!~robert@5ace7086.bb.sky.com] has joined #emc-devel
[08:17:41] -!- mrsunshine_ has quit [Ping timeout: 252 seconds]
[08:37:56] -!- Valen has quit [Quit: Leaving.]
[08:39:23] -!- mhaberler has quit [Quit: mhaberler]
[09:05:42] -!- mrsunshine__ has quit [Ping timeout: 252 seconds]
[09:46:03] -!- adb has quit [Ping timeout: 252 seconds]
[09:58:40] -!- mrsunshine__ has quit [Ping timeout: 258 seconds]
[09:59:37] -!- nicko has quit [Ping timeout: 252 seconds]
[10:18:42] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[10:34:12] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d847d7c.pool.mediaWays.net] has joined #emc-devel
[10:35:03] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d847d7c.pool.mediaWays.net] has parted #emc-devel
[10:41:48] -!- jbunch_ has quit [Ping timeout: 276 seconds]
[10:43:14] -!- SWPadnos has quit [Changing host]
[10:43:15] -!- SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #emc-devel
[10:50:47] -!- Valen has quit [Quit: Leaving.]
[10:57:51] -!- robin_ has quit [Ping timeout: 276 seconds]
[11:06:47] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d84c3d9.pool.mediaWays.net] has joined #emc-devel
[11:06:53] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d84c3d9.pool.mediaWays.net] has parted #emc-devel
[11:40:15] -!- skunkworks_ has quit [Ping timeout: 258 seconds]
[11:45:00] -!- ries has quit [Client Quit]
[11:50:21] -!- maximilian_h [maximilian_h!~bonsai@ulmg-5d84c3d9.pool.mediaWays.net] has joined #emc-devel
[12:15:40] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[12:16:42] -!- izua has quit [Ping timeout: 276 seconds]
[12:23:13] -!- jbunch has quit [Ping timeout: 258 seconds]
[12:24:59] -!- dgarr [dgarr!~dgarrett@adsl-76-204-28-247.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[12:28:56] <dgarr> for consideration: http://www.panix.com/~dgarrett/stuff/0001-ngcgui-support-search-path-for-filenames.patch
[12:38:22] -!- kljsdfhklj has quit [Ping timeout: 252 seconds]
[12:38:36] <psha[work]> dgarr: since nobody here know tcl better then you - patch looks ok :)
[12:38:58] <dgarr> ok -- need a committer
[12:39:23] -!- skunkworks_ [skunkworks_!447329d2@gateway/web/freenode/ip.] has joined #emc-devel
[12:39:47] <psha[work]> however it won't work with spaces in paths?
[12:41:11] <dgarr> correct
[13:03:03] -!- jstenback has quit [Ping timeout: 258 seconds]
[13:05:40] -!- izua has quit [Changing host]
[13:12:34] <JT-Shop> I need commiting does that help
[13:13:01] <dgarr> psha[work]: revised patch for better behavior for spaces in paths
[13:15:04] <psha[work]> dgarr: nice, everything else is too hard for me :)
[13:19:57] <psha[work]> so - ack
[13:47:36] <psha[work]> mhaberler: i suspect i've some problems with syntax highlight
[13:48:03] <mhaberler> details?
[13:48:18] <psha[work]> links file is not generated...
[13:48:22] <psha[work]> since {ini} is not set
[13:48:33] <psha[work]> and thus asciidoc generates invalid xml
[13:50:20] <psha[work]> during main build it's defined and everything is ok
[13:51:09] <psha[work]> adding -a ini=ini fixes problem
[13:52:06] <psha[work]> hm, where {ini} attribute is defined?
[13:54:48] -!- izua has quit [Ping timeout: 258 seconds]
[13:55:29] <mhaberler> where: since {ini} is not set ?
[13:55:35] <mhaberler> Submakefile, some .txt?
[13:55:46] <psha[work]> gladevcp.txt
[13:56:06] <psha[work]> line 273 for example
[13:56:24] <psha[work]> and more later
[13:56:34] <mhaberler> hold on
[13:58:55] <mhaberler> ok, so: what's wrong with [source,{ini}]
[13:58:55] <mhaberler> and how do I do it right?
[13:59:18] <mhaberler> add a '-a ini=ini' : where?
[14:02:23] <psha[work]> wrong with [source,{ini}] is that if {ini} is not defined it becomes [source,] which is leads to unbalanced docbook xml tags
[14:02:49] <psha[work]> -a ini=ini in makefile rule: 614 objects/%.links-stamp: $(DOC_SRCDIR)/%.txt
[14:04:14] <mhaberler> well, can you fix it and I pull? Honestly, I fail to understand the flow in Submakefile completely
[14:04:47] <mhaberler> lyx should go as well now
[14:04:58] <mhaberler> delete rules, files
[14:05:12] <psha[work]> wait a bit, i need to compile it again to be sure that it's working now
[14:05:38] <mhaberler> whale of a build with 4 languages
[14:07:20] KimK_afk is now known as KimK
[14:08:01] <psha[work]> not so large though...
[14:08:09] <psha[work]> do you remember why {ini} was needed?
[14:08:28] <mhaberler> ok, the issue as far as I remember
[14:08:31] <psha[work]> unsupported in docbook?
[14:08:35] <mhaberler> yes
[14:08:44] <psha[work]> what's value for docbook then?
[14:08:47] <psha[work]> txt?
[14:08:49] <mhaberler> latex style missing
[14:08:57] <mhaberler> I think, yes
[14:09:40] <psha[work]> so let me leave compilation for a while and move home
[14:10:02] <psha[work]> bbl
[14:10:04] <mhaberler> look at the top of gladevcp.txt:
[14:10:04] -!- psha[work] has quit [Quit: leaving]
[14:12:50] -!- uwe_mobile has quit [Ping timeout: 260 seconds]
[14:20:33] -!- skunkworks__ [skunkworks__!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #emc-devel
[14:35:46] KimK is now known as KimK_afk
[14:38:30] -!- El_Matarife has quit [Quit: Nettalk6 - www.ntalk.de]
[14:49:32] -!- nullie has quit [Quit: Ex-Chat]
[14:53:43] -!- ve7it [ve7it!~LawrenceG@S0106009027972e37.pk.shawcable.net] has joined #emc-devel
[14:56:21] -!- Valen has quit [Quit: Leaving.]
[15:01:48] -!- Jymmm has quit [Remote host closed the connection]
[15:05:08] -!- Calyp has quit [Remote host closed the connection]
[15:09:24] -!- mhaberler has quit [Quit: mhaberler]
[15:31:54] -!- dgarr has quit [Ping timeout: 246 seconds]
[15:34:29] <cradek> http://pastebin.com/10uy7RSf
[15:34:54] <cradek> I get this kind of stuff at the end of a full build, v2.5_branch
[15:35:00] <cradek> is it ... working at all?
[15:57:26] -!- tom3p [tom3p!~tomp@75-150-195-235-Illinois.hfc.comcastbusiness.net] has joined #emc-devel
[15:59:21] <jthornton> wow, I've not seen that before
[16:02:21] -!- e-ndy has quit [Quit: Ex-Chat]
[16:02:28] -!- adb [adb!~Moldovean@178-211-227-200.dhcp.voenergies.net] has joined #emc-devel
[16:16:10] -!- kljsdfhklj has quit [Ping timeout: 252 seconds]
[16:16:44] -!- micges [micges!~ddd@bxl115.neoplus.adsl.tpnet.pl] has joined #emc-devel
[16:17:56] -!- psha [psha!~psha@] has joined #emc-devel
[16:36:43] <tom3p> i made a simple comp like JT's THC.
[16:36:54] <tom3p> when i manually set the Z offset during a G17 circle, i see the steps ramp up, cruise and decellerate.
[16:37:00] <tom3p> What is the top velocity? what is the acc/dec rate?
[16:37:05] <tom3p> I >guess its just the .ini values, but i've guessed wrong before :)
[16:37:06] <tom3p> http://pastebin.com/SsSN5AmE http://imagebin.org/163261
[16:40:02] <skunkworks_> probably the limits that stepgen is set to? (assuming you are using stepgen in this instance)
[16:40:48] <tom3p> yah, i am, just wondering cuz its hard to gauge from halscope.. i could dump a 2" offset into the comp and wham the dro said i was there !
[16:42:11] <tom3p> well, its near time to test hdwr now anyway! the truth will be known. thx
[16:42:24] -!- tom3p [tom3p!~tomp@75-150-195-235-Illinois.hfc.comcastbusiness.net] has parted #emc-devel
[16:51:41] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[17:40:36] -!- ajvazn has quit [Quit: Leaving]
[17:57:04] -!- Loetmichel has quit [Ping timeout: 258 seconds]
[18:03:51] -!- isssy has quit [Quit: Visitor from www.linuxcnc.org]
[18:22:40] -!- kljsdfhklj has quit [Ping timeout: 252 seconds]
[18:38:32] -!- jbunch has quit [Read error: Connection reset by peer]
[18:39:42] -!- isssy has quit [Client Quit]
[18:44:59] -!- jbunch_ has quit [Ping timeout: 258 seconds]
[19:18:10] -!- Jymmm [Jymmm!~jymmm@unaffiliated/jymmm] has joined #emc-devel
[19:26:54] -!- tlab has quit [Ping timeout: 255 seconds]
[19:36:21] -!- jbunch has quit [Ping timeout: 258 seconds]
[19:38:55] -!- Tom_itx has quit [Ping timeout: 260 seconds]
[19:40:09] -!- tom3p [tom3p!~tomp@75-150-195-235-Illinois.hfc.comcastbusiness.net] has joined #emc-devel
[19:45:57] -!- jbunch has quit [Read error: Connection reset by peer]
[19:50:32] -!- jbunch_ has quit [Ping timeout: 258 seconds]
[19:52:48] -!- jbunch has quit [Read error: Connection reset by peer]
[19:58:58] -!- jbunch_ has quit [Ping timeout: 258 seconds]
[20:08:29] Birdman3131 is now known as Really_Long_Nick
[20:08:49] Really_Long_Nick is now known as Birdman3131
[20:18:09] -!- psha has quit [Quit: leaving]
[20:34:17] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #emc-devel
[20:40:45] -!- L84Supper has quit [Ping timeout: 260 seconds]
[20:41:52] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[20:43:02] <andypugh> Well, I did a test. I don't know if it was the test I meant it to be, or if either option was the right test, or what the results mean. But I did do a test.
[20:49:42] -!- maximilian_h has quit [Ping timeout: 255 seconds]
[20:56:39] -!- FinboySlick has quit [Quit: Leaving.]
[21:00:05] <micges> andypugh: any smoke?
[21:03:00] -!- syyl has quit [Ping timeout: 276 seconds]
[21:07:02] -!- danimal_garage has quit [*.net *.split]
[21:16:42] -!- mikegg has quit [Ping timeout: 255 seconds]
[21:20:29] -!- kbarry has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723]]
[21:21:56] -!- danimal_garage has quit [Quit: KVIrc Insomnia 4.0.0, revision: 3900, sources date: 20100125, built on: 2011-03-15 15:32:03 UTC http://www.kvirc.net/]
[21:26:23] -!- syyl_ has quit [Quit: Leaving]
[21:27:24] <andypugh> No, I was just looking at how long rtapi_get_time takes.
[21:31:12] -!- motioncontrol has quit [Quit: Sto andando via]
[21:40:12] -!- |danimal_garage| has quit [Quit: KVIrc Insomnia 4.0.0, revision: 3900, sources date: 20100125, built on: 2011-03-15 15:32:03 UTC http://www.kvirc.net/]
[21:48:44] -!- micges has quit [Quit: Ex-Chat]
[21:53:40] -!- skunkworks__ has quit [Ping timeout: 260 seconds]
[21:54:55] -!- tom3p has quit [Quit: Ex-Chat]
[21:55:12] -!- Fox_Muldr has quit [Ping timeout: 276 seconds]
[21:58:22] -!- danimal_garage has quit [Ping timeout: 246 seconds]
[22:17:44] -!- Birdman3131 has quit [Read error: Connection reset by peer]
[22:22:26] -!- skunkworks_ has quit [Ping timeout: 252 seconds]
[22:25:50] <jepler> cradek: no, I think it indicates something's broken
[22:26:02] <jepler> if you look in the html page on linuxcnc.org, you'll see this:
[22:26:03] <jepler> N.O. CONTACT :images/ladder_action_load.png (Normally Open) When the variable is false the switch is off.
[22:26:12] <jepler> there's text where I think there's supposed to be an image
[22:26:57] <andypugh> jepler: 378nS sounds like a long time for rtapi_get_time to me.
[22:27:05] <jepler> working(?) image: classic_ladder.txt:image::images/Default_Sections_Manager.png[]
[22:27:16] <andypugh> But I guess as it is happening in a wait loop, that might not matter?
[22:27:19] <jepler> not working(?) image: classic_ladder.txt: - N.O. CONTACT image:images/ladder_action_load.png[] (Normally Open)
[22:27:23] <jepler> so is it a missing colon?
[22:28:15] <jepler> andypugh: did you post a link to your test code?
[22:28:29] <andypugh> I posted the test code.
[22:28:34] <jepler> ah, found it
[22:31:27] <jepler> andypugh: 384ns is not bad, that's 1/3 the time to do an inb/outb on an isa device
[22:32:00] <andypugh> In that case, I will probably use it to keep the code transparent.
[22:32:08] <jepler> ok.
[22:32:10] <andypugh> get_tsc is 24nS
[22:32:44] <andypugh> Though, I am reminded of a secondary question. How does stepgen know that it can send a high pulse without sending a low?
[22:33:22] <jepler> by setting stepspace to 0
[22:33:31] <andypugh> Ah.
[22:33:34] <andypugh> Of course.
[22:33:41] <andypugh> <slaps forehead>
[22:33:45] -!- Connor has quit [Read error: Connection reset by peer]
[22:33:55] <jepler> this tells stepgen that asserting the step signal for one cycle means 1 step, instead of one rising edge..
[22:35:02] <jepler> so I think that if you do something similar to that test program, but try to count the ns taken by rtapi_delay(1), you'll see that it's absoutely terrible
[22:35:48] <jepler> and that maybe if you change it to call rt_busy_sleep instead, it'll not suck
[22:37:42] -!- factor has quit [Read error: Connection reset by peer]
[22:38:15] -!- i_tarzan has quit [Ping timeout: 252 seconds]
[22:38:38] <andypugh> rtapi_delay(1) lasts 126 to 408nS
[22:39:37] <jepler> huh, I expected much worse
[22:39:53] <jepler> what's rtapi_delay(1000) take?
[22:39:59] <andypugh> Quite a short sample.
[22:40:41] <jepler> (I guess rtapi_delay(1) will pass 0 to udelay..)
[22:42:13] <andypugh> rtapi_delay(1000) lasts 1154 to 2153nS
[22:44:31] <jepler> so the "reset" timing will consist of two calls to rtapi_get_time and at most one call to rtapi_delay, or about 1500ns of overhead for something that typically needs a 5us-10us delay anyway
[22:44:41] <jepler> it seems like this is not rising to the level of being a burden
[22:45:28] <andypugh> where might one find rt_busy_sleep?
[22:46:08] <jepler> I found it by looking in the headers under /user/realtime*
[22:46:08] <jepler> /usr/realtime-2.6.24-16-rtai/include/rtai_sched.h:RTAI_SYSCALL_MODE void rt_busy_sleep(int nanosecs);
[22:47:59] <jepler> /usr not /user/
[22:48:11] <jepler> bbl, I think it's time to make dinner
[22:48:36] <andypugh> include "rtai_sched.h"; works. You did the groundwork
[22:48:45] <jepler> nonono
[22:48:48] <jepler> well, maybe
[22:49:06] <jepler> if you want to test the behavior of rt_busy_sleep, that's sure the easy way to do it
[22:49:39] <andypugh> rt_busy_sleep(1) is 130-190nS
[22:50:05] <jepler> but for a shipping component you would not be doing the right thing to call it, because you should use the rtapi layer (portable to different rtos) instead of the rt_ layer (only for rtai)
[22:50:43] <andypugh> OK.
[22:50:56] <andypugh> There isn't much point in optimising wait loops :-)
[22:51:31] <jepler> instead, once we establish that rt_busy_sleep is better than udelay, we'd change the call in rtai_rtapi.c
[22:51:47] <jepler> then every user (of which there is just one right now, plus your driver) gets the benefit of the improved delay
[22:52:10] <jepler> if the one delay typically delays 100ns too long and the other one delays 1000ns too long, then it is worth changing the implementation..
[22:53:22] <andypugh> busy_sleep(1000) varies between 1050 and 1420nS. But is typically quite a lot more consistent.
[22:53:53] <andypugh> I guess I should get a screen-grab of each for the mailing list?
[23:06:47] -!- Guest813 has quit [Quit: Visitor from www.linuxcnc.org]
[23:08:19] KimK_afk is now known as KimK
[23:19:16] -!- Calyp has quit [Quit: Leaving]
[23:27:04] <KimK> cradek: , jepler: Oops, did I screw up some images (or image links)? Thanks for finding the errors, shall I fix them, since this was likely my fault? (Or have I bothered you enough already and I should stay out of it, lol!)
[23:33:17] -!- sumpfralle has quit [Read error: Connection reset by peer]
[23:55:56] <andypugh> Right, I think I have the driver re-coded.
[23:57:00] <andypugh> I have no idea at all how to test the "reset" function. It would be quite hard if I did have the hardware, as it would need the use of a scope, but without the hardware?
[23:57:51] <andypugh> Anyone fancy having a look before I send it to someone who does have the hardware, but no scope and about 3 weeks EMC2 experience?
[23:58:55] <andypugh> (Though I like to think it was quite a positive 3 weeks, as he got a new driver for his unsupported hardware in 2 days, for free, neither of which he was expecting)