#emc | Logs for 2004-11-15

Back
[00:00:29] <Imperator_> jep that with the new language is a problem, but if it is easyer with phyton, than it makes sense
[00:01:31] <jepler> I think Python is much easier to code than C or C++, but that's only an opinion.
[00:03:16] <Imperator_> I don't know phyton, i had only sometimes a look on some phyton scripts for me it was not so easy to understand.
[00:04:13] <Imperator_> but without a closer look on the language i can't say anything
[00:05:57] <les> back...
[00:06:07] <les> noy familiar with python
[00:06:11] <les> not
[00:06:32] <les> but looks like a great project jepler
[00:06:37] <jepler> thanks
[00:07:39] <les> I had to just learn a new scripting language for DAQFactory data aquisition
[00:08:00] <les> for some industrial testers I have to make
[00:08:40] <les> using steppers with encoders...
[00:10:04] <les> I wonder if it is a python derivative
[00:10:27] <les> the code is compiled
[00:12:02] <jepler> Python is bytecompiled (like Javal without JIT)
[00:12:07] <jepler> er, Java
[00:13:00] <les> I picked that data aq ap because it supported USB devices...and Linux...and was cheap
[00:13:10] <les> very poorly documented though
[00:13:54] <les> (but the authors are always by their phones)
[00:15:26] <les> jepler is way ahead having just developed the new Javal language though :)
[00:16:45] <jepler> I have a coworker named Javal, and I must talk about him more often than that hyped language
[00:17:16] <les> haw
[00:21:26] <alex_joni> hello
[00:24:05] <Imperator_> hi alex
[00:24:41] <Imperator_> * Imperator_ south africa was great
[00:24:50] <alex_joni> nice to hear that
[00:25:03] <alex_joni> any safari experiences?
[00:25:29] <Imperator_> a smal one, on a game park, and we have found the lions
[00:25:46] <Imperator_> sometimes they hide completly
[00:26:55] <Imperator_> they walked next to our car, that was great
[00:27:24] <alex_joni> nice ...
[00:27:43] <alex_joni> any news on the lion mens?
[00:27:56] <Imperator_> :-)
[00:28:01] <Imperator_> they are finished
[00:28:37] <Imperator_> one is for a museum in paris i think and one for New York
[00:34:19] <alex_joni> cool...
[00:34:31] <alex_joni> * alex_joni is reading through the logs from yesterday...
[00:34:38] <alex_joni> so you want to build a XX machine?
[00:38:14] <alex_joni> jepler: nice work...
[00:43:21] <Imperator_> jep, at the moment i look how Heidenhaim and siemens are doing that
[00:43:53] <alex_joni> will this be a portal?
[00:44:08] <alex_joni> or two different X axis's
[00:45:43] <Imperator_> a portal, or better a ganry axis
[00:46:23] <alex_joni> so same motors, same ratio on both X'es?
[00:46:42] <Imperator_> jep
[00:46:58] <alex_joni> then ... why don't you drive just one? and mirror the other one?
[00:47:08] <alex_joni> what kind of servos do you want to use?
[00:47:30] <Imperator_> you mean wirering it with the HAL ?
[00:48:02] <alex_joni> no.. I mean wireing it externally
[00:48:12] <alex_joni> 1 X axis for HAL
[00:48:13] <Imperator_> the problem is homing, because you have to bring the axis in sync after switching the machine on
[00:48:30] <alex_joni> well... they should be in sync at all time
[00:49:00] <alex_joni> maybe use breaks when the machine is switched off
[00:49:27] <Imperator_> you mean by electronic ?? My drives don't have this function
[00:50:39] <alex_joni> what kind of drives?
[00:50:43] <Imperator_> i think that all is not that big deal, but i have to find the right way to implement it
[00:50:56] <Imperator_> Siemens Simodrives 610
[00:51:05] <Imperator_> analog servo drives
[00:51:20] <alex_joni> so you drive them with voltage? -10/10 V ?
[00:51:25] <Imperator_> and i have linear encoders for all axis
[00:51:26] <Imperator_> jep
[00:51:44] <alex_joni> I see... then not :(
[00:52:04] <Imperator_> ebay is great, we have now some Heidenhain linear encoders on with 1700mm and one with 2200mm
[00:52:13] <alex_joni> how much?
[00:52:18] <alex_joni> the 2200 mm one?
[00:54:06] <Imperator_> 220 EUR each
[00:54:22] <Imperator_> Ls603C
[00:54:27] <alex_joni> nice...
[00:54:32] <alex_joni> vrey cheap
[00:54:34] <alex_joni> very
[00:54:41] <Imperator_> hope that they are working :-)
[00:54:49] <alex_joni> :-)
[00:55:20] <les> would be great for a fast rack and pinion machine
[00:56:00] <alex_joni> yup.. maybe too precise...
[00:56:00] <Imperator_> Les: what's that ????
[00:56:11] <alex_joni> those are usually 10 microns or less
[00:56:20] <les> haha
[00:56:27] <Imperator_> 10 microns
[00:56:41] <alex_joni> maschine mit zahnrad
[00:56:46] <alex_joni> rack & pinion
[00:57:11] <les> really...the fastest is rack...but you need to have rack registration errors in the feedback loop
[00:57:12] <Imperator_> ah Zahnstinge ???
[00:57:19] <Imperator_> Zahnstange
[00:57:23] <alex_joni> yup
[00:57:45] <alex_joni> les: how do you mean that?
[00:57:46] <les> I have seen them with several METERS per second travel
[00:57:50] <Imperator_> a ball screw makes less problems
[00:58:15] <alex_joni> Imperator_: yes, but it can get VERY expensive on long joints
[00:58:18] <Imperator_> they are making up to 120m/min with ball screws
[00:58:19] <les> yes ballscrews are much easier...but much more inertia
[00:58:33] <alex_joni> 120m/min = 2m/s
[00:58:39] <alex_joni> pretty much...
[00:58:46] <les> that is fast
[00:58:54] <alex_joni> don't know how that looks on a 3m axis...
[00:58:54] <Imperator_> if you have very long spindels you are turning the nut
[00:59:22] <les> I looked into spinning nut closely
[00:59:30] <alex_joni> les: how is that rack registration error you're talking about?
[00:59:38] <les> expensive transmission
[01:00:06] <les> Alex: errors in the tooth profile of the rack.....
[01:00:15] <Imperator_> the nice thing is that at such speeds the balls in the ball srews reach supersonic speed
[01:00:20] <alex_joni> and you remember, monitor those?
[01:00:21] <les> with linear scales they can be corrected
[01:00:25] <Imperator_> that sounds not so nice
[01:00:49] <les> supersonic...wow
[01:01:14] <alex_joni> les: any examples who does that?
[01:01:25] <les> I had calculated the angular velocity of the balls in a router spindle at 24,000 rpm
[01:01:34] <les> yes let me find a link...
[01:01:48] <alex_joni> was jmk around?
[01:01:54] <Imperator_> no
[01:02:00] <Imperator_> only the logger
[01:02:06] <alex_joni> I see..
[01:02:26] <Imperator_> John ..... wake up :-)
[01:02:59] <Imperator_> ....
[01:03:06] <Imperator_> still sleeping
[01:03:39] <alex_joni> lol... it's still early in the us
[01:03:51] <alex_joni> anybody has a TNG around?
[01:03:51] <Imperator_> jep
[01:04:02] <les> http://www.andantex.com/preload.html
[01:04:14] <les> precision cnc racks...
[01:04:24] <alex_joni> must be a fortune
[01:04:26] <les> can be used with rotary encoders...
[01:04:47] <les> but linear encoders correct for tooth profile wear
[01:05:06] <les> alex: yes $$$$$$$$$ too much for me
[01:05:13] <Imperator_> :-)
[01:05:23] <les> I could build them but still too much
[01:05:30] <Imperator_> Alex you mean the redhat based BDI ?
[01:05:36] <alex_joni> I used split pinion systems
[01:05:44] <alex_joni> Imperator_: yes
[01:06:11] <les> hardened rack?
[01:06:20] <Imperator_> Redhat 7.2 ore something, that is my EMC installation, what do you want to know
[01:06:48] <alex_joni> les: 15m axis on a robot system
[01:06:53] <alex_joni> not built by me... ;)
[01:07:01] <alex_joni> I just installed it...
[01:07:05] <les> wow
[01:07:59] <les> biggest I did was 7 meters
[01:08:11] <les> smallest 25 mm travel
[01:08:15] <alex_joni> the company I work for (CLOOS.de)
[01:08:22] <alex_joni> did a bigger one...
[01:08:34] <alex_joni> let me check the numbers (don't wanna lie to you...)
[01:09:05] <les> the 7 meter one was just a pick and place gantry...just moved boxes and stuff
[01:09:24] <alex_joni> these are all +/- 0.1 mm precision
[01:09:34] <les> the 25 mm one was voice coil drive and could do 100G 3 axis
[01:10:18] <alex_joni> X=72000, Y=2x16000mm, Z=4000mm, X'=2500mm
[01:10:54] <alex_joni> 72m is pretty big ;)
[01:11:31] <les> anyway...the rack systems can outperform just about anything out there xcept linear motors
[01:15:20] <alex_joni> I agree on that
[01:15:32] <alex_joni> * alex_joni has no experience with linear motors....
[01:16:29] <les> not much with me either...costs too much
[01:18:48] <alex_joni> * alex_joni doesn't like that cost too much... like software ;)
[01:21:30] <Imperator_> same here
[01:34:53] <alex_joni> * alex_joni has gotta go... but he'll be back :)
[01:43:27] <paul_c> Yo Ray
[01:44:52] <rayh> Hi Paul.
[01:45:06] <rayh> Have we got a discussion going?
[01:45:40] <paul_c> Did have one about an XXYZ setup
[01:46:07] <rayh> With servos or steppers.
[01:46:23] <paul_c> Also have had a little bit of discussion about a python based backplotter (3D) for emc2
[01:46:51] <rayh> Thought you didn't like python!
[01:47:19] <paul_c> not by me...
[01:47:33] <paul_c> jepler has been working on it..
[01:47:45] <rayh> What would be the advantages?
[01:48:17] <paul_c> able to GPL the code
[01:48:55] <paul_c> in the future, use the vtk toolkit for solid modeling
[01:49:48] <paul_c> Python could be used to test new G codes before being coded for emc propper
[01:50:19] <rayh> We could gpl the code. It's just you and me that wrote it.
[01:50:44] <rayh> oops poor English there.
[01:51:10] <paul_c> nope - The stuff jepler has done is based on emcplot3d design
[01:51:58] <rayh> Solid modeling would be nice. Dan has looked at varcon and other projects.
[01:53:15] <rayh> The filtering of g-code would be a great help to folk that are working from cam.
[01:53:42] <rayh> Hi Steve.
[01:53:49] <jepler> anyway, if some brave soul wants to try it, or just look at the source, the latest version is here: http://craie.unpy.net/~jepler/rs274py-0.9.3.tar.gz
[01:54:19] <jepler> You'll need Python 2.2 or 2.3 and PyOpenGL
[01:54:42] <SteveStallings> Yawn... hi Ray.
[01:54:58] <SteveStallings> Coffeeeeeeee
[01:55:08] <jepler> I wouldn't say it's based on emcplot3d (though I have read emcplot3d source, and contributed some patches through cradek)
[01:55:43] <paul_c> based=the basic idea of a standalone app
[01:55:51] <rayh> jepler: Got any screen shots? I'm py illiterate.
[01:56:37] <jepler> rayh: http://craie.unpy.net/~jepler/rs274py-gplot.png http://craie.unpy.net/~jepler/rs274py-gplot-live.png
[01:57:12] <paul_c> Talking of screen shots....
[01:57:27] <rayh> Thanks. Going there now. My link is s l o w.
[01:57:58] <jepler> paul_c: I just want to be clear that rs274py is "clean" code that can be safely licensed under the GPL, not subject to the emcplot3d license
[01:58:03] <paul_c> BDI-3.xx - Have a desire for a series of 500x325 images to use in the final stages of install..
[01:58:24] <rayh> Wow. Nice looking mascot.
[01:58:29] <paul_c> jepler: Any C/C++ code in it ?
[01:59:21] <jepler> paul_c: the live plot code uses a small C++ program that prints the position of the mill on stdout
[01:59:48] <jepler> http://unpy.net/cgi-bin/viewcvs.cgi/rs274py/emcshow/emcshow.cc?rev=1.1&content-type=text/vnd.viewcvs-markup
[01:59:57] <paul_c> but no C/C++ used for plotting ?
[02:00:25] <rayh> Just got an email from Art Haas. He says;
[02:00:33] <rayh> I'm pleased to announce the eighteenth development release of PythonCAD,
[02:00:47] <rayh> a CAD package for open-source software users. As the name implies,
[02:00:47] <rayh> PythonCAD is written entirely in Python.
[02:00:58] <jepler> paul_c: no. once the file is parsed, it's converted into an OpenGL display list, so the navigation is very fast
[02:02:05] <jepler> paul_c: the parsing step can take a long time, though (only about 1kline/sec on a 2.4GHz PC)
[02:02:17] <paul_c> I would say that you are probably free of emcplot3d licence restrictions then.
[02:04:54] <les> I notice that emc1 kinda blinks out for a while when I load large gcode files...often a minute or so
[02:05:09] <les> but my files are many Mbytes
[02:05:30] <paul_c> how much memory have you got ?
[02:05:58] <les> not enough I'm sure...64M
[02:06:12] <rayh> This is a tickle problem. We need to add a continue while loading.
[02:06:12] <SteveStallings> Ray - PythonCAD is not mentioned on LinuxCNC page. Got a link or comments?
[02:06:36] <paul_c> learath: probably getting bogged down with swapping stuff out to disk.
[02:06:43] <paul_c> les: probably getting bogged down with swapping stuff out to disk.
[02:06:51] <les> the wait is not a big problem...but the open file window goes away and leaves a blank there...
[02:07:00] <les> no big deal though
[02:07:00] <rayh> http://www.pythoncad.org/
[02:07:59] <rayh> Right. It is purely my problem with the code. We didn't see bif files during the writing.
[02:08:06] <jepler> I'm in a different league than you guys. A "big" file is maybe 10k lines of code
[02:08:12] <rayh> big big...
[02:09:00] <jepler> most files are a few thousand lines at most
[02:09:13] <rayh> When I load the "heart" test program for Sherline, the screen freezes, mill starts moving, and about a minute later the display catches up.
[02:09:50] <paul_c> * paul_c gets bogged down with multiple kernel compiles...
[02:10:04] <rayh> Gotta read the relevant section in my tickle books and fix both the tkemc and mini code.
[02:10:51] <jepler> if you have long-running code and want the screen to repaint but don't want the user to be able to click buttons etc, you want to call "update idletasks" from time to time.
[02:11:40] <rayh> In regards to the python and pyopengl -- It seems to me that we are quickly multiplying the number of packages that must be installed in order to run a complete system.
[02:13:08] <rayh> How do we feel about, requiring tickle, tclx, gtk, python, and pyoopengl...
[02:14:20] <paul_c> Python is already on the BDI disk.
[02:14:27] <jepler> paul_c: which version?
[02:14:44] <rayh> 2.3.3 on Live
[02:14:48] <cradek> hi all
[02:14:50] <jepler> hi chris!
[02:15:02] <rayh> 2.3.2 on the Knoppix I'm using.
[02:15:17] <les> hello Chris
[02:15:41] <rayh> 2.3.3 on suse.
[02:16:03] <jepler> 2.2.x and newer are good for rs274py right now
[02:16:04] <rayh> jepler: How can I check on the pyopengl?
[02:16:21] <jepler> rayh: python -c 'import OpenGL' will fail if you don't have it
[02:16:23] <paul_c> python on the BDI-2.xx will be a vintage version
[02:17:09] <jepler> The big problem with pyopengl is that it's usually a battle to get it to work right with tk
[02:17:55] <cradek> I thought it was only a battle in windows, or have I forgotten?
[02:18:29] <rayh> Seems to be there on Live.
[02:18:44] <jepler> cradek: the togl extension won't build into an rpm, because it requires that DISPLAY be set but rpmbuild deliberately removes it from the environment.
[02:18:57] <jepler> it may not be a problem for a non-rpm installation
[02:19:21] <rayh> Also there on Knoppix. Not on the SuSE I've got.
[02:19:25] <SteveStallings> PythonCAD added to links at LinuxCNC.
[02:19:41] <jepler> rayh: PyOpenGL is on Live and Knoppix?
[02:20:05] <rayh> Thanks Steve.
[02:20:28] <jepler> does this also work: python -c 'import OpenGL.Tk' ?
[02:20:35] <rayh> I don't have a clue how capable pythonCAD is yet.
[02:22:28] <SteveStallings> Looks like it still lacks a output format suitable for CAM, but hey, it's all scripts. 8-)
[02:22:44] <les> no dxf?
[02:23:00] <SteveStallings> Only Postscript at the moment.
[02:23:02] <rayh> No pytk on knoppix.
[02:23:59] <les> hi john
[02:24:00] <rayh> Not on Live either.
[02:25:08] <danfalck> good morning guys
[02:25:11] <jmkasunich> hi ray
[02:25:55] <cradek> jepler: I get a font problem on my home machine - here's a screenshot
[02:26:33] <rayh> John. Good to "see" you.
[02:26:44] <rayh> Hi Dan.
[02:26:53] <paul_c> * paul_c adds pyopengl & pytk to the list
[02:26:53] <danfalck> hi Ray
[02:27:20] <paul_c> hey Dan - Did you shoot the cat in the end ?
[02:27:34] <rayh> Which end?
[02:27:41] <les> ??? haw
[02:27:43] <danfalck> not yet
[02:28:01] <danfalck> my cat walked all over my keyboard when I was away from IRC
[02:28:25] <danfalck> Robin was handing me a fish to slap it with while I was away
[02:28:43] <les> use that cat walking detection program?
[02:28:46] <rayh> Oh. I remember Terry Ritter build a "cat" filter, cause his was always doing that.
[02:28:54] <SteveStallings> Surely all is forgiven as long as he didn't step on the CAPSLOCK key.
[02:29:06] <danfalck> he didn't luckily
[02:29:19] <danfalck> check Tuesday's log
[02:29:27] <jepler> cradek: strange, I changed it to use the same options.py file as toolpath. does toolpath's gcode display screen have the same problem?
[02:29:36] <rayh> I wonder what the probability of it hitting rm -rf * would be.
[02:30:42] <danfalck> Ray, I'm going to visit Hal May today.
[02:31:00] <danfalck> I'll take my camera and try the interview thing
[02:31:18] <cradek> jepler: checking...
[02:31:22] <danfalck> he converted an engraving machine to EMC
[02:31:36] <rayh> jepler: I'm still looking at your screen shots. Can you change the rate at which the code is read in and displayed.
[02:32:02] <rayh> danfalck: Sounds great. Get the scoop for us.
[02:32:06] <cradek> jepler: no, all of toolpath looks nice
[02:32:23] <paul_c> danfalck: I would like some good "Made with EMC" shots to use for the next BDI CD
[02:32:45] <jepler> rayh: The whole file is read in before anything is displayed
[02:33:15] <rayh> I believe that we should be able to get some "Made with EMC" shots from David Munro as well.
[02:33:26] <les> I have plenty
[02:33:30] <rayh> And Les!
[02:33:51] <les> many commercial products
[02:34:13] <paul_c> They don't need to be high res - 500x325 will be fine
[02:34:59] <les> I am putting up an examples gallery page soon...all pictures will be web resolution
[02:35:16] <rayh> We could get the version of chips that Tony made at Smithy.
[02:35:19] <danfalck> paul_c: I will
[02:35:52] <paul_c> * paul_c can get a photo of Tony's Chips
[02:36:17] <danfalck> cradek: sorry for taking so long to get screenshots on the webpage
[02:36:27] <danfalck> still have some things to work out
[02:36:33] <jepler> cradek: ah, toolpath overrides the font for text widget in the options file
[02:36:46] <danfalck> Steve and I talked the other day about updating the fron page
[02:36:51] <cradek> danfalck: no problem
[02:37:09] <Imperator_> jmkasunich: Hi John
[02:37:24] <les> already have a few up....this is all emc
[02:37:26] <jmkasunich> hi Imp
[02:37:28] <les> http://lmwatts.com/signwp.html
[02:37:32] <Imperator_> im thinking on how to do the ganry axis
[02:37:33] <cradek> danfalck: because of its license, except for simple bugfixes I'm done with emcplot3d
[02:37:59] <Imperator_> i think you are right the best is may be to write a new HAL module
[02:38:07] <les> I was also still thinking about the xxyz
[02:38:33] <Imperator_> Heidenhain makes it also with a master and a slave
[02:38:41] <cradek> jepler: easy fix?
[02:38:53] <Imperator_> i have to look what siemens does also
[02:38:55] <les> yes...it is crucial to slave it
[02:39:03] <jepler> cradek: yeah. let me know if it looks right after you cvs update
[02:39:04] <jmkasunich> I can think of two ways to do it, don't know which is better:
[02:39:26] <les> i.e. just sending two axes the same motion commands does not work well with servos
[02:39:30] <jmkasunich> 1) master/slave: emc sends commands to master, the hal module makes the slave track the master
[02:39:32] <rayh> Tony's also got a relief carving of the states of Michigan and Wisconsin.
[02:39:56] <jmkasunich> 2) peer - emc sends commands to both axis (thru a hal module that serves as a "splitter/combiner")
[02:40:23] <les> 1 is preferred
[02:40:28] <jmkasunich> seems that (2) could avoid a lag between one side and the other
[02:40:38] <cradek> jepler: yep
[02:40:40] <Imperator_> i think a comination of both is best
[02:40:59] <les> the two xx will see diferent motional impedance and will have different ferror
[02:41:00] <paul_c> Hey Les - Can I use http://lmwatts.com/signwp_files/image008.jpg on the next BDI CD ??
[02:41:03] <Imperator_> at homing the slave follows the master, until homing is finished ...
[02:41:14] <rayh> How about home for XX?
[02:41:20] <les> take all the pictures you want Paul
[02:41:45] <jmkasunich> gotta go for a little while - sorry
[02:42:08] <Imperator_> then both acting like 2) and the HAL module is only a splitter and takes care that the difference between the two axis is below a limit
[02:43:04] <les> why not just slave it for all values?
[02:44:15] <Imperator_> because then the slave is always behind the master
[02:44:58] <Imperator_> and it is easy i take a PID for each axis, and a hal module gives them both the same input
[02:45:07] <les> it is with my jackshaft too....it's a mechanical transmission line
[02:45:55] <les> master/slave group delay could be made very small
[02:46:46] <les> otherwise when y+z is at one end that end has big Ferror...the other end does not see it and gets ahead
[02:47:10] <les> at high speeds it could be substantial
[02:47:16] <les> like mm
[02:47:33] <rayh> les: Nice work you've got on display!
[02:47:59] <Imperator_> les: do you think that or do you know that ??
[02:48:14] <les> thanks ray...I have much more (industrial products that I will post later
[02:49:06] <les> Imperator: hmm... I think I know that....having watched ferror behavior moving big masses a lot
[02:49:41] <Imperator_> how are you watching to them ?
[02:50:42] <les> logs and ferror estops...we had a code error with that stuff until recently so I was watching it closely
[02:51:30] <Imperator_> but you have only one servo for your ganry axis, right ?
[02:52:30] <les> right...but if I extrapolated the restoring forces and imagined that as a racking moment...
[02:52:36] <les> it would be nasty
[02:53:45] <les> not enough to break things...but bad for bearings for sure
[02:54:38] <les> 1 Kn*m ++ on the gantry
[02:54:40] <Imperator_> hm, ok
[02:55:04] <les> this is with a 500 Kg gantry though
[02:55:31] <les> running at an average 6 cm/second cutting
[02:55:36] <Imperator_> is your gantry axis about 500kg ???
[02:55:39] <les> much faster rapids
[02:56:34] <les> yes...the EFFECTIVE mas is 1000 Kg due to the moment of the dual ballscrews and jackshaft
[02:56:50] <les> it really adds up
[02:56:53] <Imperator_> ups
[02:57:13] <Imperator_> how bis are your servos ?
[02:57:27] <Imperator_> how big are your servos ?
[02:57:37] <les> pretty big....Sems
[02:57:58] <les> 1200 in oz+
[02:58:18] <les> whatever that is in NM
[02:59:05] <Imperator_> 8,5Nm
[02:59:19] <les> here is a picture of them
[02:59:23] <les> http://lmwatts.com/forsale.html
[03:00:37] <les> 140V 26 amp peak... (i use a lower voltage though)
[03:01:22] <les> 3.6 KVA peak I guess
[03:02:02] <Imperator_> nice
[03:02:04] <les> oh...heh...and I have sold them all
[03:02:16] <les> (partner has more)
[03:02:52] <Imperator_> i have some siemens Simodrive with about 1kW
[03:03:21] <les> that is enough for quite a large machine
[03:03:33] <les> depending on speed
[03:04:24] <Imperator_> think so, they have a torce of about 3Nm=420oz but for acceleration you can overlod them by three or four
[03:04:42] <les> btw I get just about a 1:1 mech. impedance match with those motors and the gantry/shafts
[03:05:15] <les> Yup servos are great for big accel
[03:05:23] <Imperator_> what do you mean ?
[03:06:03] <Imperator_> ah ok i have it
[03:06:15] <les> I run as low as I can on accel to get the job done and prevent wear and tear, but in general high speeds will require high Accel
[03:06:23] <Imperator_> you mean the interna of the motor is the same than of the load
[03:06:46] <les> I can do about 1 G theoretically but it is violent
[03:06:56] <Imperator_> :-)
[03:06:57] <les> yes 1:1 inertia match
[03:07:22] <les> although inertia matching is not all that critical
[03:07:26] <Imperator_> thats the optimum
[03:07:37] <Imperator_> in theorie
[03:07:43] <les> yup
[03:08:32] <Imperator_> the problem is we still don't have some ball screws, we need two with about 2000mm lenght
[03:08:45] <Imperator_> for the gantry axis
[03:09:03] <les> I use HIWIN 25 mm
[03:09:22] <les> come in 2.5 meter lengths with 2 nuts
[03:09:26] <les> 2.5
[03:09:32] <les> not 25 haha
[03:09:42] <Imperator_> i this lenght that is only a thin wire
[03:10:05] <Imperator_> 2.5 inches ?
[03:10:13] <les> A slender ratio of 50:1 gets tough
[03:10:33] <les> 25mm x 2.5 mter
[03:10:47] <les> but that is a little slender
[03:10:55] <les> I have less travel
[03:10:58] <Imperator_> hm that is a smal spindel for that lenght
[03:11:37] <Imperator_> i think 32mm or 40mm is best for our 1700mm travel
[03:11:56] <les> 2 meters fixed/fixed will need to be abour 35-40mm diam for a reasonable critical speed
[03:12:11] <Imperator_> jep
[03:12:26] <les> running fixed/fixed helps a lot
[03:12:38] <Imperator_> we want to have a maximum speed of about 3000-5000 mm/min
[03:12:57] <les> pitch?
[03:13:12] <Imperator_> 5mm is best i think
[03:13:30] <Imperator_> or maybe 10mm
[03:13:35] <les> so 1000 rpm max?
[03:13:41] <Imperator_> jep
[03:13:54] <les> sounds in the ball park
[03:14:18] <Imperator_> :-)
[03:15:45] <les> right now I am spindle power limited so I don't get to go so fast
[03:16:15] <les> need about 5 KW spindle to fully use the speed
[03:16:49] <les> only have 1.8
[03:17:48] <les> will mount bigger Perske or Colombo when I get the chance and $
[03:21:05] <les> I see an error in the sem motors specs I have
[03:21:17] <les> accel is in the wrong units
[03:21:43] <les> should be 7100 radians/s^2
[03:22:10] <les> (I just copied them from the SEM site)
[03:23:22] <danfalck> * danfalck is away: going out to the shop...
[03:23:45] <les> later dan
[03:29:40] <les> I am going to try to figure out this blog think I just set up so I can easily get more emc pictures for paul
[03:29:48] <les> software is B2
[03:29:58] <les> don't know how to use it yet
[03:31:26] <rayh> Speaking of blogs, Infoworld just came out in favor of wiki.
[03:32:40] <les> mine is here:
[03:32:44] <les> http://lmwatts.com/v-web/b2/
[03:32:54] <les> just haven't set anything up
[03:34:15] <les> it eats up one of my 3 databases at my webhost I think
[03:42:03] <jmkasunich> * jmkasunich is back
[03:42:24] <jmkasunich> les: I was reading what you said about one end falling behind (larger ferror) because of inertia
[03:42:37] <jmkasunich> however, I don't see how that favors the master/slave aproach
[03:43:14] <jmkasunich> true, if the master side has higher inertia, then it is an advantage, since the slave will track the real (lagging) position of the master
[03:43:27] <jmkasunich> but if the slave has the higher inertia, things will actually be worse
[03:45:37] <SteveStallings> But couldn't the side with the higher inertia change based on where the machining head was?
[03:45:51] <jmkasunich> exactly - which is why master/slave has a problem
[03:46:08] <jmkasunich> with master/slave, skew = slave ferror
[03:46:35] <jmkasunich> with peer, skew = fabs ( drive_1_ferror - drive_2_ferror )
[03:47:09] <les> let me think about that...
[03:48:13] <les> if slave has higher inertia than the master it will estop on ferror before racking forces get too big
[03:48:54] <jmkasunich> I didn't think it was a matter of
[03:48:56] <jmkasunich> oopds
[03:49:01] <jmkasunich> of 'too big'
[03:49:04] <les> if you send identical motion commands (as done in steppers) there would be no protection in racking moments with servos
[03:49:18] <jmkasunich> you are trying to minimize skew, not just keep it below some limit
[03:49:41] <jmkasunich> it wouldn't be just blindly sending the same command to both servos
[03:50:02] <jmkasunich> there would need to be a module that accepted a single command, and sent two commands out to the two drives
[03:50:02] <les> How would you do it?
[03:50:11] <les> ok
[03:50:23] <jmkasunich> probably something like drive1cmd = maincmd+trim
[03:50:30] <jmkasunich> drive2cmd = maincmd-trim
[03:50:44] <jmkasunich> where trim is use to sync the two
[03:50:52] <les> hmmm
[03:50:58] <jmkasunich> (and could also be used to compensate for screw errors)
[03:51:16] <jmkasunich> each drive would then have it's own PID
[03:51:17] <les> screw matching is needed for sure
[03:51:57] <les> but how do you control different Ferror?
[03:52:31] <jmkasunich> * jmkasunich ponders mainfb = ( drive1fb+drive2fb ) /2; trimfb = drive1fb-drive2fb
[03:53:10] <jmkasunich> trimfb would be used to control trimcmd, perhaps
[03:53:26] <les> I could be wrong but I think most controls send master actual position as the slave motion command
[03:53:44] <jmkasunich> mainferror = mainfb - maincmd (or reversed, I dunno how the sign goes offhand)
[03:54:01] <les> galil has a bunch of stuff about this
[03:54:31] <les> right...and it's signed
[03:54:58] <jmkasunich> if you are building hardware drives (galil), then you need one to be a master and one to be a slave, (either that, or you have to add another box to serve as the splitter)
[03:55:19] <les> they are doing it soft
[03:55:24] <jmkasunich> I would argue that they choose master/slave for hardware and implementation reasons, not because it's better
[03:55:28] <les> let me see if I can find that
[03:56:01] <jmkasunich> didn't know that (they are doing it soft)
[03:56:34] <les> I think master/slave with carried axis (y+z) position squared ff on xx is the way
[03:56:48] <les> still checking
[03:57:44] <jmkasunich> I agree about y+z dependent ff (when needed for peak performance), but I'd rather see the drives treated as peers
[03:58:34] <jmkasunich> as I see it, there is nothing about the machine or drives that should make you treat one side differently than the other
[03:58:51] <jmkasunich> it would be different if the machine was asymettrical, and one drive was truly just a helper
[03:59:19] <jmkasunich> master/slave is inherently assymetrical
[04:00:54] <les> http://www.galilmc.com/support/appnotes/optima/note2440.pdf
[04:01:01] <les> there is one bit...
[04:01:09] <les> but there is a vedeo too
[04:01:27] <les> yes it is assymetrical
[04:01:42] <les> due to control law integration
[04:01:53] <les> but it can be made arbitrarily small
[04:02:03] <jmkasunich> just seems to me that you should drive a symmetrical machine symmetrically
[04:02:24] <jmkasunich> "arbitrarly small" is a theoretical term
[04:02:42] <les> that would eliminate control lags
[04:02:53] <jmkasunich> requiring arbitrarly large amounts of computing HP (for sampling rate increases, etc)
[04:03:18] <les> It just means with fast enough servo updates it can be made acceptable
[04:03:25] <les> haha typing the same thing
[04:04:05] <les> but at routinely used several thousand updates/sec it could be awfully small!
[04:04:28] <les> a few encoder counts?
[04:04:38] <les> less with feedforward
[04:04:45] <jmkasunich> the symmetrical approach should give smaller skew for _any_ sampling rate, since skew = the difference between the two ferrors, instead of the slave ferror
[04:05:27] <les> hmm
[04:05:56] <jmkasunich> with the load centered, skew would be zero (in theory)
[04:06:20] <les> I think of Ferror as a fourth order system
[04:06:52] <les> it would be unless it hit a pole pair in the racking qaxis (zz)
[04:10:05] <les> Reading that Galil apnote I se that they implement a software clutch when gears are changed!
[04:10:21] <les> let's see what else they have
[04:11:11] <rayh> * rayh Gotta run and feed the extended fam.
[04:14:13] <les> have to register to see the video but it's worth it
[04:18:16] <alex_joni> g'evening
[04:18:51] <jmkasunich> hi alex
[04:19:08] <alex_joni> hey john...
[04:19:12] <alex_joni> what's cooking?
[04:19:21] <jmkasunich> mu-shu port
[04:19:23] <jmkasunich> mu-shu pork
[04:19:35] <jmkasunich> yummy
[04:19:44] <alex_joni> hmmm... yummy
[04:19:44] <alex_joni> ;)
[04:19:53] <alex_joni> all I have to say is:
[04:19:58] <alex_joni> Go Higgins...
[04:20:06] <jmkasunich> ?
[04:20:20] <alex_joni> he's playing in the final right now
[04:20:23] <alex_joni> snooker...
[04:21:52] <jmkasunich> how'd you find my test channel last night?
[04:22:48] <alex_joni> well... I did a whois jmkasunich
[04:23:01] <jmkasunich> ah...
[04:23:07] <alex_joni> hope I didn't spoil anything... :-?
[04:23:11] <jmkasunich> nope
[04:23:34] <jmkasunich> I'm having fun with TCP sockets
[04:23:56] <jmkasunich> a distraction from stuff I should be doing for emc, but fun
[04:24:46] <jmkasunich> I'm hoping to be able to have the compile farm slots report their results on IRC (and possibly lurk watching for CIA messages, to cut down lag time)
[04:25:04] <alex_joni> I see ... ;)
[04:25:06] <alex_joni> nice...
[04:25:09] <alex_joni> got 5 mins?
[04:25:12] <jmkasunich> sure
[04:25:18] <alex_joni> I'd like to debug smthg on BDI-TNG
[04:25:29] <alex_joni> I really HATE it failing after 2 weeks...
[04:25:38] <alex_joni> It should be long running
[04:25:46] <alex_joni> do you have a BDI-TNG running?
[04:25:50] <jmkasunich> agreed - let's see if we can fix irt
[04:25:55] <jmkasunich> yes, this box is TNG
[04:26:08] <jmkasunich> * jmkasunich switches to a clear desktop
[04:26:23] <alex_joni> ok... let me open the code...
[04:26:42] <jmkasunich> * jmkasunich does cvs up on autoconf branch
[04:26:43] <les> i'll be doing some searching on tandem axes while you do that john
[04:26:50] <jmkasunich> ok
[04:26:53] <alex_joni> hi les...
[04:27:25] <paul_c> * paul_c makes a commit
[04:27:29] <jmkasunich> les: can you mail the links you find instead of posting them here? I'm pretty busy today, I'll try to catch up on the reading later
[04:27:41] <alex_joni> hello paul
[04:27:49] <paul_c> Hi Alex
[04:28:14] <alex_joni> you like snooker?
[04:28:27] <paul_c> marbles ?
[04:28:49] <alex_joni> lol
[04:28:57] <alex_joni> jmk: any time you're ready...
[04:29:17] <paul_c> * paul_c switches to another screen..
[04:29:29] <jmkasunich> * jmkasunich is ready
[04:29:59] <alex_joni> ok, check out /etc/redhat-release
[04:30:12] <alex_joni> cat /etc/redhat-release 2>/dev/null | head -n 1
[04:31:06] <jmkasunich> Red Hat Linux release 7.2 (Enigma)
[04:31:24] <alex_joni> now that's strange...
[04:31:26] <jmkasunich> (the file contains _only_ that one line)
[04:31:44] <jmkasunich> an Enigma?
[04:31:45] <alex_joni> paul said it would be "BDI-TNG Linux release 7.2 (minbar)"
[04:32:35] <jmkasunich> both this box and the farm slot are the same
[04:32:58] <alex_joni> :( ... there goes the BDI-TNG hack...
[04:33:35] <alex_joni> problem is... realtime-config (that's the script from rtai-24.1.x)
[04:33:42] <alex_joni> checks on the kernel source dir
[04:34:09] <jmkasunich> * jmkasunich wonders why this isn't a problem with the old emc2?
[04:34:18] <alex_joni> and if it doesn't find a .configure it complains that the kernel source tree isn't configured
[04:34:41] <alex_joni> well... mainly because there are a LOT more tests on autoconf, then on the old emc2
[04:34:54] <jmkasunich> ok
[04:34:58] <alex_joni> emc2's ./configure assumed a lot of stuff
[04:35:04] <alex_joni> now we try to check most of them
[04:35:18] <alex_joni> maybe in time all will be checked
[04:35:23] <jmkasunich> so what info is this particular test checking for?
[04:35:34] <alex_joni> anyways... the proper way to do things, is to ask the rt-script
[04:35:46] <alex_joni> for CC, LINUXDIR, CFLAGS & such
[04:36:00] <alex_joni> realtime-config (for rtai-24.1.x)
[04:36:08] <alex_joni> rtai-config (for rtai-3.x)
[04:36:15] <alex_joni> rtl-config (for rtlinux)
[04:36:27] <jmkasunich> where does that script live again?
[04:36:41] <alex_joni> it usually gets found by ./configure
[04:36:46] <alex_joni> somewhere in /usr
[04:36:56] <alex_joni> most likely in /usr/realtime
[04:37:05] <alex_joni> but on most systems (rtai is not installed)
[04:37:14] <alex_joni> so it's still in /usr/src/rtai/foo
[04:37:37] <alex_joni> problem is... that script is checking the kernel source dir
[04:37:49] <alex_joni> which has been cleaned up before the BDI-TNG release
[04:38:04] <alex_joni> which is the proper way to do...
[04:38:06] <jmkasunich> usr/src/rtai/scripts/realtime-config here
[04:38:12] <alex_joni> yup
[04:38:43] <alex_joni> try /usr/src/rtai/scripts/realtime-config --dump
[04:39:02] <jmkasunich> Kernel source tree not configured!
[04:39:07] <alex_joni> yup...
[04:39:17] <alex_joni> the script checks /usr/src/linux for .configure
[04:39:37] <alex_joni> which isn't found (because of a make clean inside the source tree)
[04:39:51] <alex_joni> but... that's the way on all BDI-TNG
[04:40:13] <jmkasunich> so seems like we have two problems
[04:40:15] <alex_joni> so I thought in case the system is a BDI-TNG ... we can skip that, and assume some things
[04:40:22] <jmkasunich> 1) detecting BDI-TNG
[04:40:38] <jmkasunich> 2) setting the right values when BDI-TNG is detected
[04:40:57] <jmkasunich> the redhat-release was an attempt at (1)
[04:41:15] <alex_joni> 1) would have been easy if /etc/redhat-release would state BDI-TNG smthg
[04:41:24] <jmkasunich> * jmkasunich tries to find another way of doing (1)
[04:41:24] <alex_joni> but it doesn't... so we need an alternative
[04:41:45] <alex_joni> 2) is already done
[04:41:54] <Imperator_> les: http://filebase.heidenhain.de/doku/oma_controls/OMA_Controls_2/jh/tnc/2805x0xx/gb/thb407.pdf
[04:43:20] <jmkasunich> hmm.... how about uname -v?
[04:43:27] <jmkasunich> #1 Sat Oct 12 19:48:51 BST 2002
[04:43:38] <les> ...rading that link
[04:43:42] <les> rading
[04:43:49] <les> bad key!!
[04:44:46] <alex_joni> what does uname state?
[04:45:10] <jmkasunich> uname -v returns '#1 Sat Oct 12 19:48:51 BST 2002' on all BDI-TNG boxes (I think)
[04:45:24] <jmkasunich> that's the date when Paul built it
[04:45:25] <alex_joni> hmmmm
[04:45:44] <jmkasunich> paul_c: are there multiple versions of BDI-TNG floating around out there?
[04:45:44] <alex_joni> hmm.. that's a hack...
[04:45:52] <alex_joni> but I think a better one to be found
[04:45:55] <jmkasunich> very hacky
[04:45:59] <Imperator_> les: page 174
[04:46:05] <les> ok
[04:47:31] <les> taking a while....
[04:47:48] <les> but I am gettin the skinny on tandem axix control
[04:47:57] <les> from several links
[04:48:11] <jmkasunich> les - please forward links
[04:48:15] <alex_joni> jmk: what does uname -a state?
[04:48:33] <les> ok
[04:48:50] <jmkasunich> Linux ics1 2.4.18-rtai #1 Sat Oct 12 19:48:51 BST 2002 i686 unknown
[04:48:55] <jmkasunich> ics1 is my hostname
[04:49:27] <alex_joni> hmmm.. the build time relies on the kernel loaded
[04:49:36] <alex_joni> not good
[04:49:56] <les> http://www.motionvillage.com/training/handbook/motioncontrol/gearicam.html
[04:50:10] <jmkasunich> why? all we're trying to do is check if this is a TNG box
[04:50:11] <les> ( elecronic gearing)
[04:50:37] <alex_joni> hmmmm
[04:50:55] <jmkasunich> or do you want it to work even if they booted a different kernel?
[04:50:59] <Imperator_> ok now i will search for the most complicated way ! For the most complicated solutions there is a special page www.siemens.de ;-)
[04:51:02] <alex_joni> don't really know... gotta debate this with paul
[04:51:18] <alex_joni> I don't really want it to work on a different kernel
[04:51:30] <alex_joni> bc then it's just like any other system
[04:51:44] <alex_joni> so it has to obey some rules in order to work
[04:51:54] <alex_joni> BDI-TNG will be a unique exception
[04:52:33] <jmkasunich> there isn't anything more unique than "#1 Sat Oct 12 19:48:51 BST 2002"
[04:52:57] <jmkasunich> you can add a comment "
[04:53:14] <jmkasunich> "jmk came up with this ugly hack, not me!" if you want ;-)
[04:53:22] <alex_joni> lol
[04:53:38] <jmkasunich> falls apart if paul released more than one version tho
[04:53:40] <alex_joni> let me commit, and maybe you can test it.. and we'll see
[04:53:44] <alex_joni> I know
[04:54:06] <alex_joni> what makes me wonder is that paul said /etc/redhat-release would contain BDI-TNG
[04:54:18] <alex_joni> guess he has a newer version of TNG
[04:54:19] <alex_joni> ;)
[04:54:26] <les> I am finding master slave seems to be most used for tandem axes
[04:54:27] <jmkasunich> calling paul_c..... where is paul? ;-)
[04:54:43] <alex_joni> * paul_c switches to another screen..
[04:54:46] <paul_c> fighting with devfs
[04:54:56] <les> the method John mentions is often called "slaving to a virtual axis"
[04:55:10] <jmkasunich> time to fight with alex and I for a few mins?
[04:55:19] <les> sure
[04:55:23] <les> haha
[04:55:36] <les> me or paul?
[04:55:39] <jmkasunich> paul
[04:55:41] <les> haw
[04:55:44] <les> aw shoot
[04:55:48] <paul_c> * paul_c reaches for the 12 bore
[04:55:59] <les> wnat mine?
[04:56:03] <jmkasunich> need quite a load to get transatlantic range on that
[04:56:04] <les> want
[04:56:10] <les> bluh
[04:56:28] <jmkasunich> anyway... are there more than one version of BDI-TNG in circulation?
[04:56:45] <paul_c> shouldn't be
[04:56:50] <les> mmm 15,000 mph muzzle velocity should do it...60 degree elevation
[04:57:04] <alex_joni> jmk's doesn't have BDI-TNG in /etc/redhat-release
[04:57:14] <jmkasunich> atmospheric exit and re-entry will be a bitch
[04:57:58] <les> can shoot a regular bullet into orbit on the moon...but I digress
[04:58:00] <jmkasunich> cat redhat-release gives "Red Hat Linux release 7.2 (Enigma)"
[04:58:03] <Imperator_> i think electronic gearing is another thing. We don't have to look where one axis is to slave the other. We know where both have to be at any time
[04:58:22] <les> ready to talk more about it...
[04:58:50] <Imperator_> electronic gearing is ofen used in automatisation
[04:58:53] <jmkasunich> les: I want to solve this specific problem with Alex first before I get into anything general
[04:59:04] <les> ok fine
[04:59:19] <les> solve away
[04:59:25] <alex_joni> jmk: guess we're pretty stuck without paul
[04:59:29] <paul_c> would suggest grepping for RH release Ver-7.2 OR BDI-TNG
[04:59:39] <jmkasunich> paul_c: was wondering about checking uname -v as a check for TNG
[05:00:00] <paul_c> cat /proc/version
[05:00:11] <jmkasunich> same thing
[05:00:27] <jmkasunich> I take that back
[05:00:30] <paul_c> what is it in full ??
[05:00:39] <jmkasunich> cat /proc/kernel/version is the same as uname -v
[05:00:43] <paul_c> cut'n'paste please
[05:00:54] <jmkasunich> Linux version 2.4.18-rtai (root@Gariboldi) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Sat Oct 12 19:48:51 BST 2002
[05:01:12] <paul_c> Grep for Gariboldi
[05:01:34] <jmkasunich> cat /proc/sys/kernel/version is:
[05:01:39] <jmkasunich> #1 Sat Oct 12 19:48:51 BST 2002
[05:01:41] <alex_joni> that's your machine paul?
[05:01:49] <jmkasunich> what is Gariboldi? your box?
[05:01:51] <paul_c> It was the host, yes
[05:01:56] <alex_joni> where you built the TNG?
[05:02:00] <paul_c> yup
[05:02:01] <alex_joni> Gariboldi it is
[05:02:08] <jmkasunich> yep - that sounds good
[05:02:18] <jmkasunich> thanks paul
[05:02:25] <alex_joni> yup.. thanks paul
[05:02:29] <paul_c> If anyone complains, we encourage an upgrade
[05:02:33] <alex_joni> ok
[05:02:44] <paul_c> * paul_c is working on a replacement
[05:02:52] <jmkasunich> BDI-3.xx?
[05:02:57] <paul_c> yup
[05:03:01] <jmkasunich> cool
[05:03:08] <jmkasunich> * jmkasunich sets aside a farm slot
[05:03:12] <paul_c> anaconda with Debian packages
[05:03:27] <alex_joni> still 14 cd's?
[05:03:36] <jmkasunich> I hope not!
[05:03:39] <paul_c> jmkasunich probably doesn't want to do that just yet
[05:03:48] <jmkasunich> hopefully runs on moderate hardware
[05:03:50] <paul_c> alex_joni: 15
[05:04:12] <paul_c> what was the CPU spec on the slots ?
[05:04:17] <alex_joni> nice :D
[05:04:19] <jmkasunich> 200MHz
[05:04:21] <jmkasunich> 128M ram
[05:04:24] <paul_c> Hmmm...
[05:04:27] <jmkasunich> (note that the farm doesn'
[05:04:32] <jmkasunich> doesn't run X)
[05:04:43] <jmkasunich> X = pig
[05:05:06] <paul_c> What exactly is the processor ?
[05:05:10] <alex_joni> jmk: you can run X-apps through ssh...
[05:05:13] <jmkasunich> KDE and the like = bigger pig
[05:05:26] <jmkasunich> CPU is vanilla Pentuim, I think
[05:05:33] <alex_joni> to test TkEMC
[05:05:36] <jmkasunich> maybe Pentium-MMX
[05:05:36] <alex_joni> or such...
[05:05:38] <paul_c> hint: cat /proc/cpuinfo
[05:06:04] <jmkasunich> Pentium
[05:06:16] <jmkasunich> bogomips 398.13
[05:06:58] <paul_c> is there a tsc on the flags line ?
[05:06:58] <jmkasunich> family 5, model 2, stepping 12, modelname Pentium 75-200
[05:07:09] <jmkasunich> yes
[05:07:16] <jmkasunich> that mean timestamp counter?
[05:07:28] <jmkasunich> _all_ pentuims have the TSC
[05:07:31] <paul_c> might run this kernel then...
[05:08:09] <paul_c> Not all 586 processors have a tsc
[05:08:16] <jmkasunich> sounds like you're trying to drag me kicking and screaming into the late 1990's
[05:08:35] <jmkasunich> _all_ intel pentiums do - I dunno about AMD, etc
[05:09:05] <paul_c> Linux version 2.6.9-adeos (root@Babylon-117) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #1 Sun Nov 14 12:46:09 GMT 2004
[05:09:45] <jmkasunich> shiny and new
[05:09:51] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/ (configure.in configure): changed the hack to find BDI-TNG. This will be known as the Gariboldi hack ;). It basicly checks /proc/version to see if the kernel was build on Gariboldi, the machine PC used for making the BDI-TNG
[05:09:57] <paul_c> It's the Cyrix & Geode processors that are the pain...
[05:10:18] <alex_joni> * alex_joni has a Geode processor....
[05:10:23] <alex_joni> GX1
[05:10:29] <alex_joni> @ 300 MHz
[05:11:18] <jmkasunich> the TSC is the neatest thing since sliced bread for RT freaks like me - I long ago decided that I wouldn't buy a CPU without it
[05:12:14] <jmkasunich> I used to use Watcom C, which had nice inline assembly - I was a code tweaker
[05:13:37] <jmkasunich> alex_joni: still doesn't work
[05:14:00] <paul_c> alex_joni: http://issaris.homelinux.org/~takis/projects/rtai/list.php - Download the CD and run it on the Geode
[05:14:01] <jmkasunich> only 1 "Kernel source tree not configured!" instead of 3
[05:14:12] <alex_joni> GX1 does in fact have a TSC at MSR 10
[05:14:58] <alex_joni> jmk: not on the farm... right`?
[05:15:11] <jmkasunich> I tried it on this box
[05:15:14] <alex_joni> ok
[05:15:22] <alex_joni> try the following
[05:15:29] <jmkasunich> farm is working on it, give it a minute or two
[05:15:45] <jmkasunich> (it always checks all the trees, that takes longer)
[05:15:50] <alex_joni> BDITNG=`cat /proc/version 2>/dev/null | grep Gariboldi`
[05:16:18] <alex_joni> if test -n "$BDITNG"; then ; echo "foo"; fi
[05:17:50] <jmkasunich> if test -n "$BDITNG"; then echo "foo"; fi
[05:17:54] <jmkasunich> the test works
[05:18:01] <jmkasunich> (says foo)
[05:18:07] <jmkasunich> * jmkasunich looks at configure
[05:18:31] <alex_joni> look at configure.in
[05:18:40] <alex_joni> line 199
[05:18:52] <alex_joni> ./configure is just generated from configure.in
[05:18:52] <paul_c> * paul_c disappears for Tea.
[05:19:12] <jmkasunich> when is configure generated?
[05:19:49] <les> i'm still here with imperator (I think) queued up for next discussion
[05:19:59] <les> eating lunch
[05:20:35] <alex_joni> everytime autoconf is run
[05:20:48] <alex_joni> usually I generate it whenever I commit configure.in
[05:20:56] <jmkasunich> and when is autoconf run? normal users don't run it, right?
[05:21:02] <alex_joni> nope
[05:21:14] <alex_joni> autoconf gets run only once
[05:21:21] <alex_joni> in order to produce ./configure
[05:21:31] <alex_joni> and ./configure can then be used on all systems
[05:21:42] <alex_joni> to check system-specifics
[05:21:48] <jmkasunich> ok, got it
[05:22:09] <jmkasunich> the realtime-config script is apparently being called _before_ the Gariboldi test (once)
[05:23:38] <alex_joni> yes... but that is ok
[05:23:50] <alex_joni> $RTS --prefix
[05:24:09] <alex_joni> the test should be run after that
[05:24:20] <jmkasunich> farm results are online
[05:24:33] <alex_joni> I've seen that... but they are pretty vague
[05:24:38] <alex_joni> not your fault...
[05:25:24] <alex_joni> anyways... let's see where it's failing
[05:25:33] <jmkasunich> looking for version.h
[05:25:38] <alex_joni> before that
[05:25:44] <alex_joni> KERNELDIR doesn't get set
[05:25:58] <alex_joni> KERNELDIR is the kernel dir
[05:26:10] <alex_joni> read from .buildvars for BDI-TNG
[05:26:22] <alex_joni> usually it's read from realtime-config
[05:28:20] <jmkasunich> what should KERNELDIR be on tng? /usr/src/rtai or something?
[05:28:33] <alex_joni> I guess /usr/src/linux
[05:29:11] <alex_joni> but it doesn't get set
[05:29:21] <alex_joni> so it gets set to /home/john/
[05:29:54] <alex_joni> * alex_joni is happy: Higgins has won (9:5) over Maguire
[05:32:22] <Imperator_> * Imperator_ back again
[05:35:09] <alex_joni> jmk: is there a /usr/src/rtai-24.1.10/.buildvars
[05:35:42] <jmkasunich> yes
[05:35:51] <jmkasunich> and there is a LINUXDIR line in it
[05:36:14] <jmkasunich> but the cat | grep | sed | awk thing that is supposed to set KERNEL is returning nothing
[05:37:00] <alex_joni> hmmm... strange
[05:37:05] <jmkasunich> the awk part is failing
[05:37:08] <alex_joni> I took that from emc2 ./configure
[05:37:46] <alex_joni> is the sed part working?
[05:38:17] <jmkasunich> yes (sort of) - isn't really needed, since the line in .buildvars doesn't have spaces around the '='
[05:38:28] <jmkasunich> output of cat/grep/sed is:
[05:38:43] <jmkasunich> LINUXDIR=/usr/src/linux
[05:38:53] <jmkasunich> * jmkasunich checks the awk part
[05:40:04] <alex_joni> awk should split the text it gets ($1) by '=' into the array A
[05:40:21] <alex_joni> and it then prints out A[2] which should be the part after =
[05:41:01] <jmkasunich> found the prob
[05:41:11] <jmkasunich> '{split($1,A,"="); print A[2]}'
[05:41:24] <alex_joni> hmmm... really?
[05:41:38] <jmkasunich> the file has A2, not A[2]
[05:42:34] <jmkasunich> seems like {foo;bar} and {foo}{bar} are equivalent in this case, but I think {foo;bar} is the preferred way for two statements that should execute in sequence
[05:42:46] <alex_joni> ok...
[05:42:55] <alex_joni> a2 fails here, a[2] works
[05:42:57] <alex_joni> :(
[05:43:14] <jmkasunich> simple typo, it happens
[05:43:42] <alex_joni> echo "foo=bar" | awk '{split($1,A,"="; print A2}' fails
[05:43:54] <alex_joni> echo "foo=bar" | awk '{split($1,A,"="; print A[2]}' prints bar
[05:44:05] <jmkasunich> right - the A2 vs A[2] is the problem
[05:44:47] <jmkasunich> the other thing ( ; instead of {} ) doesn't matter in this case, but is bad awk form, cause it does matter in other cases
[05:44:48] <alex_joni> I have GNU Awk 3.1.1 (gawk)
[05:45:09] <jmkasunich> A2 is just a variable, A[2] is the second element of array A
[05:45:26] <alex_joni> but it is A[2] in the commit... right?
[05:45:31] <jmkasunich> nope
[05:45:45] <alex_joni> wtf, why not?
[05:45:49] <alex_joni> it sure is here...
[05:46:19] <jmkasunich> I was looking at configure... in configure.in, it is A[2], but in configure, it's A2
[05:46:28] <jmkasunich> dunno why - but configure is what matters
[05:46:53] <alex_joni> ok... I got it
[05:47:01] <alex_joni> autoconf replaces A[2] with A2
[05:47:04] <alex_joni> silly me
[05:47:06] <alex_joni> forgot about that
[05:48:31] <jmkasunich> you have to quote it or something to make autoconf leave it alone?
[05:48:50] <alex_joni> I'm commiting now
[05:51:09] <alex_joni> slow connection here ... sorry
[05:51:26] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/ (configure.in configure): fixed a small bug. A[2] got changed by autoconf to A2, now it's A[[2]] so it gets A[2] in the end. The same must be applied for all [] that need to remain in ./configure
[05:52:30] <jmkasunich> * jmkasunich kicks off the farm
[05:53:04] <jmkasunich> configure seems to have worked on this box
[05:53:27] <alex_joni> nice
[05:54:04] <jmkasunich> make in progress
[05:54:43] <alex_joni> jmk: slot4 is still making problems
[05:54:49] <alex_joni> with the ftp update
[05:55:09] <jmkasunich> ?
[05:56:19] <alex_joni> on http://www.linuxcnc.org/compile_farm/
[05:56:42] <jmkasunich> ok, make on bdi-tng stopped with make[2]: *** No rule to make target `/home/John/emcdev/emc2auto/lib/ulapi.o', needed by `/home/John/emcdev/emc2auto/bin/iosh'. Stop.
[05:56:45] <alex_joni> slot4 (BDI-Live), last build 11/11/04 15:54:20
[05:57:02] <alex_joni> ok... had that before ...
[05:57:28] <alex_joni> * alex_joni is waiting for the farm to get there
[05:57:31] <jmkasunich> it seems to have stopped a couple days ago - I restarted yesterday, but it needs to see a commit before it compiles
[05:57:39] <alex_joni> I see...
[05:57:44] <jmkasunich> slot 4 is compiling now
[05:57:45] <alex_joni> 2 commits today... :-?
[05:57:48] <alex_joni> I see...
[05:58:19] <alex_joni> earlier slot2 & 3 changed the status, but slot 4 didn't
[05:58:31] <jmkasunich> might have been before I restarted it
[05:58:44] <jmkasunich> the farm needs more work - right now the main loop is simply "
[05:59:02] <jmkasunich> while true ; do run_farm ; sleep 3600 ; done
[05:59:35] <alex_joni> I see...
[05:59:38] <jmkasunich> run_farm is the script that does one attempt (cvs up on all trees, compile if changes)
[05:59:58] <jmkasunich> but sometimes the process that is running the overall loop dies
[06:02:57] <jmkasunich> wow - slot 4 has been building for 14 minutes
[06:03:02] <jmkasunich> slot 3 is done now
[06:03:24] <jmkasunich> failed after 8 minutes
[06:04:01] <alex_joni> * alex_joni is debugging
[06:04:08] <jmkasunich> slot 2 succeeded in 7 minutes
[06:04:08] <alex_joni> seems some rtai headers are not found
[06:04:50] <alex_joni> still a KERNELDIR issue I think
[06:06:28] <alex_joni> can you test smthg before I commit?
[06:06:32] <jmkasunich> sure
[06:07:00] <alex_joni> add RTDIR=/usr/src/rtai-24.1.10 to configure.in around line 204
[06:07:10] <alex_joni> then run autoconf
[06:07:16] <alex_joni> and ./configure && make
[06:08:12] <jmkasunich> what is the commmand line for autoconf?
[06:08:18] <jmkasunich> just "autoconf"?
[06:08:24] <alex_joni> just autoconf
[06:08:32] <alex_joni> in the same dir with configure.in
[06:08:38] <alex_joni> it knows what to look for ;)
[06:08:49] <jmkasunich> multiple error messages:
[06:08:55] <jmkasunich> configure.in:304: AC_PROG_CPP was called before AC_PROG_CC
[06:09:08] <alex_joni> what autoconf are you using?
[06:09:18] <jmkasunich> dunno - never used it before
[06:09:21] <jmkasunich> * jmkasunich checks
[06:09:34] <jmkasunich> 2.13
[06:10:06] <jmkasunich> want me to put that line directly into configure to test it?
[06:10:12] <jmkasunich> (skip the autoconf step)
[06:10:14] <alex_joni> yeah
[06:10:51] <alex_joni> I did commit... so you can take it from CVS...
[06:10:56] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/configure.in: did a check on RTDIR in order to make it work with BDI-TNG
[06:12:38] <alex_joni> configure is on it's way too...
[06:12:52] <alex_joni> don't know why cvs commit didn't commit both files... :-?
[06:13:09] <jmkasunich> you sure there was a change to configure?
[06:13:11] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/configure: did a check on RTDIR in order to make it work with BDI-TNG
[06:13:18] <alex_joni> yeah I'm sure... ;)
[06:13:23] <jmkasunich> ;-)
[06:13:37] <jmkasunich> slot 4 finally finished
[06:13:38] <alex_joni> but I did run autoconf on another terminal
[06:14:13] <jmkasunich> make in progress
[06:14:31] <alex_joni> ok...
[06:14:45] <jmkasunich> sessions like this really motivate me to get my compile farm irc bot working
[06:16:17] <alex_joni> I have an irc bot ...
[06:16:23] <alex_joni> maybe you can modify it...
[06:16:36] <alex_joni> but it's in perl :(
[06:17:08] <alex_joni> logger_aj, help
[06:18:47] <jmkasunich> I'm working in C, don't know perl
[06:18:52] <alex_joni> ;)
[06:18:54] <alex_joni> me neither ...
[06:19:38] <jmkasunich> besides I need to be able to interact with scripts (for example, send messages from script to irc channel, or run a script when certain messages (CIA ones) appear on the channel
[06:20:11] <jmkasunich> ok, make failed on this box, same spot
[06:20:19] <alex_joni> :(
[06:20:21] <jmkasunich> make[2]: *** No rule to make target `/home/John/emcdev/emc2auto/lib/ulapi.o', needed by `/home/John/emcdev/emc2auto/bin/iosh'. Stop.
[06:20:29] <alex_joni> how is RTDIR ?
[06:20:38] <alex_joni> at the begin?
[06:20:54] <jmkasunich> scrolled off the screen
[06:21:22] <jmkasunich> you want to know the value of RTDIR during ./configure? or during make?
[06:22:33] <alex_joni> you can read it from Makefile.inc
[06:22:57] <jmkasunich> ok
[06:23:20] <jmkasunich> holy bloat, batman! ./configure is 9220 lines long!!
[06:23:28] <alex_joni> yup
[06:23:40] <alex_joni> that's why I like modifying configure.in
[06:23:53] <jmkasunich> RTDIR in Makefile.inc is /usr/src/rtai-24.1.10
[06:23:59] <alex_joni> that's 670 lines long... I can still keep track of those
[06:24:09] <alex_joni> hmmm... then I need the output from the farm to see what's failing
[06:24:27] <alex_joni> and ULFLAGS?
[06:24:55] <alex_joni> should have a -I/usr/src/rtai-24.1.10/include
[06:25:09] <alex_joni> could you check that there's a rtai.h there ?
[06:25:14] <jmkasunich> in Makefile.inc?
[06:25:44] <jmkasunich> Makefile.inc: ULFLAGS = -Wall -g -I$(INC_DIR) -I/usr/src/rtai-24.1.10/include -I. -DULAPI -O2 -DLOCALE_DIR=\"$(localedir)\" -DPACKAGE=\"$(package)\"
[06:26:04] <alex_joni> yup... seems ok
[06:26:16] <alex_joni> last thing... I set /usr/src/rtai-24.1.10 manually
[06:26:25] <alex_joni> hope there's a /include there
[06:26:31] <jmkasunich> and there is a rtai.h in /usr/src/rtai-24.1.10/include
[06:26:55] <alex_joni> ok... then... I dont know.. still waiting on the farm to compile the latest CVS
[06:27:08] <alex_joni> it finished the previous one...
[06:27:12] <alex_joni> but not the last one
[06:27:27] <jmkasunich> guessing about 7 more minutes for slot 3
[06:28:08] <jmkasunich> what results do you want to see?
[06:28:52] <jmkasunich> I just found some errors when it was making motion.o
[06:29:15] <alex_joni> I am curious about results in /src/rtapi
[06:29:19] <alex_joni> motion.o ?
[06:29:28] <jmkasunich> from motion.c
[06:29:35] <jmkasunich> motion.c:655: `key' undeclared (first use in this function)
[06:29:52] <jmkasunich> motion.c:876: `base_period_nsec' undeclared (first use in this function)
[06:30:08] <jmkasunich> I really miss the original emc2 ./configure silent
[06:30:26] <alex_joni> yup... guess you know more about that....
[06:30:26] <jmkasunich> make fills the screen with crap, it's hard to see the error messages
[06:30:53] <alex_joni> I can add that in a sec
[06:31:20] <jmkasunich> ahh, found some more
[06:32:12] <jmkasunich> rtai_rtapi.c:149: `__this_module' undeclared (first use in this function)
[06:32:51] <jmkasunich> "__this_module" is almost certainly coming from some system header that isn't getting included
[06:34:11] <jmkasunich> here is the command line from the successfull compile of rtai_rtapi.c on the TNG farm slot (old build system):
[06:34:12] <jmkasunich> kgcc -c -I/home/John/farm/emc2head/include -I/usr/src/rtai-24.1.10/include -I. -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE -DRTAPI rtai_rtapi.c -o /home/John/farm/emc2head/src/.rt_tmp/rtai_rtapi.o
[06:34:38] <jmkasunich> here is the corresponding line from the autoconf branch attempt (that has errors):
[06:34:39] <jmkasunich> egcs -c -I/home/John/emcdev/emc2auto/include -I/usr/src/rtai-24.1.10/include -I. -D__KERNEL__ -DRTAI=1 -DRTAPI rtai_rtapi.c -o /home/John/emcdev/emc2auto/src/.rt_tmp/rtai_rtapi.o
[06:35:57] <jmkasunich> one thing that jumps out at me - no -DMODULE
[06:36:19] <alex_joni> yup...
[06:36:43] <alex_joni> check RTFLAGS in Makefile.inc
[06:37:01] <jmkasunich> would it help if you had Makefile.inc from the old branch on my TNG box?
[06:37:37] <jmkasunich> autoconf branch Makefile.inc: RTFLAGS = -D__KERNEL__ -DRTAI=1
[06:37:53] <alex_joni> neah...
[06:38:28] <jmkasunich> old branch Makefile.inc: RTFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE
[06:39:30] <jmkasunich> slot 3 is done
[06:41:01] <alex_joni> I think the awk stuff is failing again
[06:41:08] <alex_joni> in configure.in on line 201
[06:42:30] <alex_joni> could you test that line?
[06:42:42] <jmkasunich> yep
[06:43:38] <alex_joni> would ./configure --with-make-silent be ok ?
[06:43:46] <jmkasunich> sure
[06:44:04] <jmkasunich> actually quiet would be better than silent
[06:46:01] <CIA-3> 03paul_c 07auto_configure_0_1 * 10emc2/ (configure configure.in): Changed the way CFLAGS is split out from buildvars - = occurs in two places, and the cut was likely to fall over..
[06:46:48] <jmkasunich> * jmkasunich tries pauls fix
[06:47:51] <jmkasunich> looks promising in Makefile.inc
[06:49:29] <jmkasunich> make proceeding
[06:49:39] <jmkasunich> saw this, which seems strange:
[06:49:45] <jmkasunich> egcs -c -I/home/John/emcdev/emc2auto/include -I/usr/src/rtai-24.1.10/include -I. RTFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-tr igraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march= i586 -DMODULE -DRTAI=1 -DRTAPI cubic.c -o /home/John/emcdev/emc2auto/src/.rt_tm p/cubic.o
[06:49:55] <jmkasunich> egcs: cannot specify -o with -c or -S and multiple compilations
[06:50:40] <jmkasunich> still fails
[06:50:42] <alex_joni> what's that RTFLAGS in there?
[06:51:05] <jmkasunich> RTFLAGS = RTFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE -DRTAI=1 RTFLAGS := -I$(INC_DIR) -I/usr/src/rtai-24.1.10/include -I. $(RTFLAGS) -DRTAPI
[06:51:15] <alex_joni> strange...
[06:51:18] <jmkasunich> (from Makefile.inc - pauls fix)
[06:52:06] <jmkasunich> there are two lines - IRC doesn't handle the line break well
[06:52:12] <jmkasunich> RTFLAGS = RTFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE -DRTAI=1
[06:52:16] <jmkasunich> RTFLAGS := -I$(INC_DIR) -I/usr/src/rtai-24.1.10/include -I. $(RTFLAGS) -DRTAPI
[06:54:55] <alex_joni> * alex_joni is checking out pauls fix
[06:55:21] <jmkasunich> hmmm - rtapi didn't get built at all
[06:55:32] <jmkasunich> the very first actual compile command was:
[06:55:40] <jmkasunich> Compile 'rtai_rtapi.c' to tmp dir using realtime C rule
[06:55:46] <alex_joni> yup...
[06:55:51] <jmkasunich> egcs -c -I/home/John/emcdev/emc2auto/include -I/usr/src/rtai-24.1.10/include -I. RTFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-tr igraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march= i586 -DMODULE -DRTAI=1 -DRTAPI rtai_rtapi.c -o /home/John/emcdev/emc2auto/src/. rt_tmp/rtai_rtapi.o
[06:56:05] <jmkasunich> egcs: cannot specify -o with -c or -S and multiple compilations
[06:56:23] <jmkasunich> it failed - and that was all that happened in the rtai directory, it went on to HAL stuff
[06:56:26] <jepler> jmkasunich: looks like the problem is the space in "-march= i586" ?
[06:56:51] <alex_joni> neah.. that's from IRC pasting
[06:57:21] <jmkasunich> yeah, there was a line wrap in the terminal window there
[06:58:15] <jmkasunich> is there any way we can make make quit on the first error?
[06:59:57] <alex_joni> should be...
[07:00:08] <jmkasunich> just noticed something:
[07:00:32] <jmkasunich> in the compile command line: .... -I. RTFLAGS-D__KERNEL.....
[07:00:44] <jmkasunich> oops: .... -I. RTFLAGS=D__KERNEL.....
[07:00:53] <jmkasunich> that RTFLAGS= shouldn't be there
[07:00:59] <alex_joni> yeah.. that's what I was talking about
[07:01:06] <alex_joni> <alex_joni> what's that RTFLAGS in there?
[07:01:07] <jmkasunich> oh
[07:01:16] <alex_joni> it's from the sed paul did
[07:01:20] <jmkasunich> * jmkasunich didn't understand the first time
[07:01:28] <alex_joni> sed s/CFLAGS/RTFLAGS/
[07:01:46] <alex_joni> it was ok.. but now RTFLAGS doesn't get echo'ed to Makefile.in
[07:01:49] <alex_joni> it gets replaced
[07:02:03] <alex_joni> so I guess it should be sed s/CFLAGS=//
[07:02:37] <alex_joni> can you cat me the grep CFLAGS from .buildvars?
[07:03:31] <jmkasunich> you mean cat /usr/src/rtai-24.1.10/.buildvars | grep CFLAGS?
[07:03:36] <alex_joni> yep
[07:03:54] <alex_joni> I wanna know if it's CFLAGS=foo, or CFLAGS = foo
[07:04:10] <jmkasunich> no spaces
[07:04:17] <jmkasunich> CFLAGS=-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -march=i586 -DMODULE
[07:04:46] <jmkasunich> * jmkasunich puts some "echo"s in the configure
[07:06:59] <jmkasunich> * jmkasunich agrees that the sed should be s/CFLAGS=//
[07:08:00] <jmkasunich> appears to be working better
[07:08:18] <alex_joni> on it's way...
[07:08:20] <jmkasunich> compiled rtai_rtapi.c OK, make progressing
[07:08:40] <alex_joni> this is so bad to debug (with no BDI-TNG here ... :()
[07:09:44] <CIA-3> 03alex_joni 07auto_configure_0_1 * 10emc2/ (configure configure.in Makefile.inc.in): added --with-make-quiet option to ./configure, cleaned up ./configure --help output, and hopefully fixed a BDI-TNG issue
[07:12:05] <jmkasunich> alex is my hero (--with-make-quiet works!!!)
[07:12:13] <alex_joni> lol
[07:12:33] <jmkasunich> it is _so_ much easier to see if errors happen that way
[07:12:40] <alex_joni> it only adds an "s" to the Makefile.inc ;)
[07:13:13] <alex_joni> you can do ./configure --silent ... (you know that, don't you ?)
[07:13:26] <jmkasunich> no
[07:13:44] <jmkasunich> I only knew the silent option we added to the old emc2 configure
[07:13:51] <alex_joni> try ./configure --help
[07:13:52] <jmkasunich> compile worked!
[07:13:57] <alex_joni> NICE!!!!!!!
[07:14:07] <alex_joni> from the latest CVS?
[07:14:11] <jmkasunich> yes
[07:14:22] <alex_joni> great... I can sleep in peace now :D
[07:14:42] <jmkasunich> farm results should be available in about 10 mins
[07:14:52] <jmkasunich> (my box is faster ;-P
[07:15:01] <alex_joni> :P
[07:15:07] <alex_joni> same here
[07:15:09] <jmkasunich> 600MHz P3
[07:15:17] <alex_joni> I have a Geode 300 MHz at work for emc
[07:15:49] <alex_joni> and an Athlon XP 1600+ here (1400 MHz)
[07:15:55] <jmkasunich> nice
[07:16:04] <alex_joni> some difference ;)
[07:16:29] <alex_joni> building a complete rtai+kernel+emc took a few days on the Geode
[07:16:36] <alex_joni> lol
[07:16:45] <jmkasunich> ouch
[07:17:03] <alex_joni> but once it's built (the kernel & modules & such)
[07:17:14] <alex_joni> it gets done pretty fast
[07:17:43] <alex_joni> I only did that in the beginning... I installed the same kernel on my laptop (2.66 GHz p4)
[07:17:52] <alex_joni> and compiled on that one in half an hour :D
[07:19:21] <jmkasunich> someday I'd like to have a modern system... but I'd probably have to pay for it - that's no fun ;-)
[07:20:18] <alex_joni> lol... at least you don't have to pay for software
[07:20:31] <alex_joni> I bought 10 M$ Office at work
[07:20:37] <jmkasunich> ouch
[07:20:37] <alex_joni> at 300 EURO each...
[07:20:53] <alex_joni> I could have gotten a lot of HW on that money
[07:21:08] <jmkasunich> yep
[07:21:45] <alex_joni> * alex_joni gotta write a report...
[07:22:07] <alex_joni> and I have absolutely no urge to do that...
[07:22:25] <jmkasunich> when I get all the kinks out of the farm scripts and sw, I'm gonna make it available to others - maybe we can get some faster systems set up
[07:23:34] <alex_joni> I could set up a PC for compiling from CVS
[07:23:50] <jmkasunich> one that you can leave powered and connected all the time?
[07:24:55] <alex_joni> yes
[07:24:59] <jmkasunich> cool
[07:25:23] <jmkasunich> the farm stuff is designed to be distributed - doesn't really have to be all in one rack like it is here
[07:25:42] <alex_joni> I actually have one right now... it's the gateway
[07:25:48] <alex_joni> but it's pretty slow ;)
[07:25:56] <alex_joni> P75 with F00F bug :F
[07:26:00] <alex_joni> :D
[07:26:11] <jmkasunich> only requirements are developer cvs access (to avoide the anonymous checkout delay) and an account at linuxcnc.org for FTPing results
[07:26:42] <jmkasunich> I wonder if Steve S. can set up an account just for the farm, with rights only in that one directory tree for better security
[07:27:32] <jmkasunich> hmmm.... SteveStallings is lurking here... hello Steve... anybody home?
[07:27:34] <jmkasunich> ;-)
[07:28:20] <alex_joni> if I remember it correctly last time there was some problem so no more accounts could be added
[07:31:57] <alex_joni> I see that slot3 compiled cleanly
[07:34:33] <alex_joni> hey ray
[07:34:40] <jmkasunich> hi ray
[07:34:40] <rayh> Hi alex.
[07:34:48] <rayh> John.
[07:34:58] <rayh> You guys working away here?
[07:35:56] <jmkasunich> actually we just finished fixing an annoying problem on BDI-TNG compiles
[07:36:16] <rayh> What is it.
[07:36:34] <alex_joni> well.. it's BDI-TNG specific...
[07:36:35] <jmkasunich> just some config info that was preventing compiles from going smoothly
[07:36:52] <alex_joni> ./configure is getting some values from realtime-config
[07:37:09] <alex_joni> which is complaining that the linux kernel source dir is not configured
[07:37:16] <rayh> Okay. I've not tried a tng compile recently.
[07:37:30] <jmkasunich> this is in the autoconf branch
[07:37:32] <alex_joni> because of the BDI-TNG install (which includes a clean kernel source dir)
[07:37:50] <rayh> How is the configuration stuff going?
[07:37:59] <jmkasunich> well, IMO
[07:38:06] <alex_joni> so we had to make a workaround specific for BDI-TNG ...
[07:38:10] <jmkasunich> alex and zwisk have both been doing great work
[07:38:20] <jmkasunich> which reminds
[07:38:22] <alex_joni> kinda in different directions for a while ;)
[07:38:26] <jmkasunich> which reminds me
[07:38:38] <jmkasunich> ray - remember a couple weeks ago we talked about using trackers?
[07:38:52] <rayh> Yes And we voted to do it.
[07:38:55] <jmkasunich> I've updated that page based on suggestions
[07:39:07] <jmkasunich> I think it's time to make a public announcement
[07:39:19] <jmkasunich> IIRC we volunteered you for that ;-)
[07:39:36] <rayh> Okay. I saw that you'd put a feature request or some kind of change in there.
[07:39:46] <alex_joni> there are still some issues open ... about install dirs and install ways
[07:40:13] <jmkasunich> when did you last look at it ray? (I did nothing for a while - until Tuesday of this week I think)
[07:40:41] <jmkasunich> alex_joni: I almost look at autoconf and make install as two different projects - related, but distinct
[07:40:42] <rayh> I just saw one come by. Didn't save the report but reporting is working.
[07:41:01] <jmkasunich> when was that?
[07:41:08] <alex_joni> well... I did too
[07:41:28] <alex_joni> but I guess it's now in the same tag...
[07:41:54] <rayh> Didn't save it.
[07:42:37] <les> jmk: let's talk about xxyz another time...
[07:42:40] <rayh> Allright I'll work on the public announcement for a bit here. Will show the results and we can comment on it.
[07:43:01] <alex_joni> les: you were still waiting?
[07:43:17] <alex_joni> sorry it took us so long....
[07:43:31] <les> naw...I was working on the "help" section of a gui
[07:43:48] <les> alsso cleaned out a chimney
[07:44:18] <alex_joni> nice ;)
[07:44:23] <rayh> SteveStallings: If I get you the info, can we put a page on linuxcnc.org that describes the way that the EMC project uses bug and feature trackers?
[07:44:44] <les> but I do have to give jmk some numbers on virtual vs actual master/slave stuff
[07:45:08] <alex_joni> jmk: hear that?
[07:45:26] <les> but I want imperator to be around at the time
[07:45:37] <les> it was his request
[07:46:45] <les> It can be topic for next sunday or something
[07:47:05] <les> but is very important both for tandem axis and lathe threading
[07:47:53] <alex_joni> ok then...
[07:48:02] <alex_joni> guess I'll call it a day ;)
[07:48:18] <alex_joni> I'll set lurk mode for another hour or so, then go to sleep
[07:48:28] <les> ok...guess you got some stuff done
[07:49:17] <les> haw I am a hardware guy on a software channel...
[07:49:31] <alex_joni> yeah... finally... that was bugging me for the last weeks (unfortunately I have no BDI-TNG installed, so I couldn't check stuff)
[07:49:33] <les> but ended up writing a little code today anyway
[07:49:41] <alex_joni> I'm a hardware guy myself...
[07:49:48] <alex_joni> but I do some software occasionally
[07:50:22] <les> I just do math and mechatronics
[07:50:27] <les> a little software
[07:50:57] <les> very little as far as linux
[07:51:10] <alex_joni> nice...
[07:51:20] <alex_joni> * alex_joni needs more knowledge in that field...
[07:51:54] <les> Ha ha we will talk about laplace transforms of gantries later...
[07:52:39] <jmkasunich> * jmkasunich was away a bit
[07:52:58] <les> you must be pooped out
[07:53:41] <alex_joni> * alex_joni kinda remembers what a laplace transform is...
[07:53:57] <les> I am too a bit...working 7 days has to end for me...soon!
[07:54:38] <alex_joni> jmk: got my message?
[07:58:33] <a70camaro> connection dead? anybody see me?
[07:59:12] <les> you are here...I see you!
[07:59:13] <alex_joni> I can see you
[07:59:18] <rayh> Yep a70
[07:59:33] <alex_joni> when in doubt.. you can always send a message to yourself
[07:59:43] <alex_joni> you can see the roundtrip like that
[08:00:16] <les> oh...I sent a message to Paul on private chat...another emc machined part...
[08:00:21] <jmkasunich> alex_joni: what message?
[08:00:25] <les> have a look...
[08:00:30] <a70camaro> ive been fighting all day with connection stalling out or getting dropeed completely
[08:00:38] <les> http://lmwatts.com/v-web/b2/
[08:01:59] <jmkasunich> rayh: you asked steve about posting a page about trackers, etc, on linuxcnc.org - it is already there
[08:02:28] <jmkasunich> http://www.linuxcnc.org/Boardofdirectors/trackers.html
[08:05:47] <rayh> Good.
[08:06:37] <jmkasunich> alex_joni: you still awake?
[08:06:46] <rayh> I'll point folk to that page.
[08:08:31] <alex_joni> jmk: yup
[08:08:45] <jmkasunich> take a look at: http://sourceforge.net/tracker/index.php?func=detail&aid=1053349&group_id=6744&atid=356744
[08:08:54] <jmkasunich> are you willing to be the coordinator for that?
[08:09:32] <jmkasunich> sure
[08:11:33] <les> ?
[08:12:01] <les> talking to yourself!?
[08:12:04] <les> haha
[08:12:13] <jmkasunich> was supposed to be in another window
[08:12:25] <jmkasunich> private isn't
[08:12:46] <jmkasunich> be back soon
[08:12:49] <les> I think it needs to be miller time for you
[08:13:01] <les> ah...it is
[08:13:02] <alex_joni> lol
[08:13:07] <alex_joni> jmk got confused
[08:13:23] <alex_joni> the coordinator stuff was for me...
[08:13:25] <les> i get very confused often
[08:13:31] <alex_joni> but I'm still opening the page
[08:14:24] <alex_joni> hello back
[08:14:34] <alex_joni> of course I can coordinate that...
[08:14:40] <alex_joni> what does that imply?
[08:15:23] <jmkasunich> nothing beyond what you are already doing... but your name will appear under "assigned to", and I don't want to do that unless you are OK with it
[08:15:41] <alex_joni> I am ok with that ;)
[08:15:53] <jmkasunich> this is really strange - I used to be able to do /msg foo, and it would open another window, now it wont
[08:16:26] <les> works ok in the mirc I use
[08:17:23] <les> I was forced to do win xp this week because my customers use it
[08:17:27] <les> hate it
[08:17:46] <alex_joni> les: lol
[08:20:44] <les> Ihave to write aps for the sales team...and they all have win xp or 2000 on their laptops
[08:21:06] <alex_joni> still better than 95 & such ;)
[08:21:53] <les> well I was using 98 but constant file system destroying crashes
[08:22:08] <alex_joni> not good... :)
[08:22:23] <les> win xp/2000 perhaps a little better
[08:22:25] <les> but...
[08:22:57] <les> constant Microsoft ads pop up...and it phones home to Redmond
[08:24:21] <les> install an ap...and it says: warning: this application is not Microsoft Logo approved...do not install this
[08:24:22] <alex_joni> what pop up?
[08:24:30] <les> gawd
[08:24:33] <alex_joni> I use it on a linux gateway...
[08:24:52] <alex_joni> well.. I don't really read that stuff...
[08:25:12] <les> so I write stuff and then the installer says not to use it...
[08:25:15] <les> great
[08:25:34] <rayh> Just sent a draft of the proposed public email to the board list.
[08:30:08] <jmkasunich> rayh: looks good to me, does this need a vote or anything - IMHO, you can just send it right now
[08:32:24] <rayh> Right. I think that I'll send a followup to the developers with the link to the full description of trackers at sf.
[08:32:32] <rayh> https://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1
[08:38:07] <rayh> Okay. I'll release the draft into the wild.
[08:46:21] <les> ray, is it gettin too cold for sunday evening brats on thr grill?
[08:46:40] <les> I have to be up that way soon
[08:47:33] <les> below freezing even in n georgia now in the morning
[08:48:31] <les> time for me to head to south fl soon...
[08:55:38] <rayh> Been about 18f in the mornings here.
[08:56:17] <rayh> les: you go south?
[09:05:11] <alex_joni> jmk: got the notification about the tracker
[09:05:30] <jmkasunich> ok - thanks for letting me know it works
[09:06:14] <jmkasunich> new trackers will be sent to the developers list, but changes go only to the originator, the assigned person, and anyone who has posted comments to the tracker
[09:06:14] <alex_joni> one question thou... when will it be closed?
[09:06:33] <jmkasunich> when you think it's done
[09:06:41] <alex_joni> I mean.. who decides that the job is done...
[09:06:46] <alex_joni> I do?
[09:07:04] <alex_joni> hmmm ;) .. ok :D
[09:07:05] <jmkasunich> it's assigned to you - that kind of makes you the boss of it ;-)
[09:07:47] <jmkasunich> you should be able to change things like the status and resolution
[09:08:12] <jmkasunich> I think if you try to change the status to closed, it actually sets it to pending and sends a message to the originator, to give them a change to reply
[09:08:29] <jmkasunich> after some time (a week, IIRC), it changes to closed if there has been no reply
[09:08:37] <alex_joni> I see...
[09:08:44] <alex_joni> I changed status to works-for-me
[09:09:31] <jmkasunich> well it still needs some tweaks, doesn't it?
[09:10:06] <jmkasunich> might want to add a comment instead, something like "started a while ago, and about 90% working" or whatever you think
[09:10:11] <alex_joni> hmmm.. mostly from the install stuff
[09:10:25] <alex_joni> but.. this is again based on what we really want
[09:10:33] <alex_joni> right now it's done like this...
[09:10:45] <alex_joni> ./configure alters Makefile.inc
[09:11:01] <alex_joni> and ./configure is generated by autoconf from configure.in
[09:11:27] <alex_joni> there is no automake support, or any other autotool support beside autoconf
[09:11:39] <alex_joni> I don't think other support is needed
[09:12:00] <alex_joni> but... I don't know if anybody else wouldn't want to see such support in there....
[09:12:43] <jmkasunich> why don't you put words like what you just said in a comment to the tracker
[09:12:54] <jmkasunich> then go ahead and mark it finished and close it
[09:12:54] <alex_joni> ok... I can do that
[09:13:10] <jmkasunich> how's that for easy - assigned and finished in the same day!
[09:13:51] <alex_joni> lol... it still needs testing on a lot of different platforms...
[09:14:03] <alex_joni> I'd like to close it after testing...
[09:14:22] <jmkasunich> BTW, developers don't need to wait for the board to assign them to a tracker (in fact I hope they don't). Any developer (I think) can assign themselves to a tracker and work on it
[09:15:44] <alex_joni> hmmm... let me try that
[09:18:10] <alex_joni> nope... can't assign myself to make tgz
[09:18:11] <alex_joni> :(
[09:19:53] <jmkasunich> try it now
[09:25:01] <alex_joni> it worked...
[09:25:29] <SteveStallings> Steve is back. Sorry all the config stuff put me to sleep. John, Ray, do you still need anything?
[09:25:54] <rayh> I'm okay, Steve.
[09:26:06] <jmkasunich> one question
[09:26:49] <SteveStallings> yes?......
[09:26:59] <rayh> Jon and Alex. You might follow up my posts with one to the developers that they can accept tasks and how to do it.
[09:26:59] <jmkasunich> can you create accounts on the linuxcnc server that are restricted to FTP access to a single directory or directory tree?
[09:27:46] <SteveStallings> Yes, we already have some like that.
[09:27:48] <jmkasunich> I'd eventually like to be able to have other people running the same compile farm scripts on different machines
[09:28:21] <jmkasunich> they all would need access to the /compile_farm/* tree, but should have no access anywhere else, in case they are compromized somehow
[09:28:41] <jmkasunich> a single user ID for compile farm use would be good
[09:30:08] <SteveStallings> The way it works it they get read access to the site, write access to only the specified tree. They have to cd to to the correct point before they can write.
[09:30:58] <alex_joni> just the way it's done right now... right john?
[09:32:34] <jmkasunich> that works
[09:33:00] <jmkasunich> and they have no other access besides FTP?
[09:33:57] <alex_joni> http- but readonly if I get steve right...
[09:34:07] <Imperator_> les: here is a very good link for the gantry axis
[09:34:10] <Imperator_> http://www3.ad.siemens.de/doconweb/pdf/840D_0704_E/840D_FB3.pdf?p=1#page=1&view=FitBH,0&pagemode=none
[09:34:15] <jmkasunich> sounds good
[09:36:18] <SteveStallings> Setup in process. Hang while I test....
[09:38:26] <alex_joni> guess this will be a long night...
[09:38:32] <alex_joni> I just started on that report... :(
[09:39:07] <cradek> I think using the sf bug and request trackers is a great idea
[09:39:37] <alex_joni> hey cradek
[09:39:49] <cradek> hello
[09:39:59] <alex_joni> nice work from jepler...
[09:40:10] <cradek> yeah he's pretty smart.
[09:40:35] <alex_joni> one short thing I would like in emcplot3d (if you still want to do this...)
[09:40:40] <cradek> he can program circles around me. so my time is best spent trying to get him interested in a project instead of doing it myself.
[09:40:48] <cradek> shoot
[09:40:56] <alex_joni> when in live preview
[09:41:14] <alex_joni> I don't really like how the blue gets drawn over the white
[09:41:25] <alex_joni> know what I mean?
[09:41:31] <jmkasunich> put it in a tracker! ;-)
[09:41:33] <cradek> well, yes and no
[09:41:36] <cradek> It's a feature
[09:41:45] <cradek> tell me what you would rather it do
[09:42:25] <alex_joni> well.. I would rather see that the white (what was drawn initially) gets deleted when the blue path gets drawn
[09:42:41] <alex_joni> right now they are kinda drawn one on top of the other
[09:42:46] <cradek> that's not really possible within the current framework
[09:42:49] <alex_joni> and if you rotate, zoom, etc
[09:43:00] <alex_joni> you see some white dots and some blue ones mixed...
[09:43:10] <cradek> yeah it's a bit ugly
[09:43:13] <cradek> the problem is this:
[09:43:21] <alex_joni> well if it's complicated... skip it ;)
[09:43:23] <cradek> the white lines represent the ideal path (exactly specified by the program)
[09:43:35] <alex_joni> * alex_joni just deleted the tracker
[09:43:55] <cradek> the blue lines are a connected series of dots that are made by periodically polling the current machine position
[09:44:09] <cradek> so they may or may not line up. Most often they don't exactly line up.
[09:44:14] <alex_joni> I see... say no more...
[09:44:21] <cradek> the blue line is only an approximation of the program
[09:44:49] <cradek> fwiw, I agree it's kind of ugly but I can't do much about it.
[09:45:10] <alex_joni> you could say the white is the programmed position
[09:45:18] <alex_joni> and the blue is the actual position ;)
[09:45:43] <cradek> it's not a bug since it's in the documentation!
[09:45:45] <cradek> hahaha
[09:46:02] <Imperator_> chiao folks
[09:47:50] <alex_joni> rtfm
[09:47:52] <alex_joni> ;)
[09:48:05] <alex_joni> f=fine :)
[09:50:58] <SteveStallings> OK, new LinuxCNC user set up for /compile_farm and I will be contacting JMK and alex_joni directly.
[09:54:48] <alex_joni> not really working...
[09:55:13] <alex_joni> guess it's ok if you talk to JMK only...
[09:56:16] <SteveStallings> Not working as in chat failed or as in you are not currently engaged in things to go the the farm results?
[09:56:30] <alex_joni> well.. DCC failed
[09:56:50] <alex_joni> and I am not really engaged in farm results right now (John is...)
[09:57:14] <SteveStallings> I was wondering why I got no response from either of you. John, did you get chat request?
[10:05:19] <alex_joni> guess he didn't
[10:06:23] <SteveStallings> Typical, connection goes to crap and you don't realize it until you get booted.
[10:07:35] <alex_joni> well.. john's back
[10:07:40] <jmkasunich> SteveStallings: your dcc chat request came up, but didn't work, and in fact seems to have thrown my irc client for a loop
[10:08:11] <jmkasunich> did you just do /msg jmkasunich? because the behavior here wasn't the normal one for that
[10:08:24] <jmkasunich> in any case, you can just send the info by mail
[10:08:58] <jmkasunich> I was asking if it was possible/practical to do, not that it needed done immediately (but thanks for the quick action anyway!)
[10:11:02] <rayh> * rayh gotta run play.
[10:12:31] <SteveStallings> John, I did it now because if I don't it may not get done. 8-)
[10:12:42] <jmkasunich> I know how that goes ;-)
[10:13:30] <alex_joni> me too ;)
[10:13:44] <alex_joni> but trackers are usefull to keep track of things :)
[10:13:52] <SteveStallings> My attempt to chat was from mIRC (windows client) using DCC chat.
[10:17:41] <jmkasunich> not /msg?
[10:18:55] <SteveStallings> Not familiar with that method. Let try it with my client.
[10:19:08] <alex_joni> DCC chat is not very spread on other IRC clients
[10:19:27] <alex_joni> on mIRC you can simply double click a user from the user-list
[10:19:38] <alex_joni> and you have a private chat (separate window)
[10:20:46] <SteveStallings> The slash msg did the same thing and seems to be working now. Think it was just a quirk.
[10:21:27] <alex_joni> nope.. the /msg thing does the same that double clicking does...
[10:21:35] <alex_joni> the DCC chat is a different story...
[10:21:57] <alex_joni> DCC chat sends the messages directly from a machine to the other
[10:22:06] <alex_joni> not through the IRC network
[10:22:08] <SteveStallings> Got the idea, DCC is less standardized.
[10:22:32] <alex_joni> it is standardized, don't know if it's implemented on all IRC clients
[10:22:45] <alex_joni> DCC send is on most (to send/receive files)
[10:27:51] <alex_joni> anybody heard of skill-based manufacturing ?
[10:29:06] <SteveStallings> Not here. Meaning?
[10:29:28] <jmkasunich> smells like dinner is just about finished - later guys
[10:30:09] <alex_joni> production units with embedded knowledge about their skills being able to interact in order to solve a given
[10:30:09] <alex_joni> manufacturing task.
[10:30:14] <SteveStallings> Gee Paul responds to the strangest things. 8-)
[10:30:46] <alex_joni> maybe jmk reminded him that he was hungry....
[10:31:06] <alex_joni> on the other hand... it's midnight at paul's place... so I guess he was tired
[10:32:18] <SteveStallings> Well I got my nap while you guys were discussing autoconfig, on the other hand I am getting hungry too.
[10:33:28] <alex_joni> paul_c: back?
[10:33:54] <paul_c> a reboot
[10:34:11] <alex_joni> anaconda needed a reboot?
[10:34:22] <paul_c> nah
[10:34:25] <alex_joni> snakes usually need one this time a year ;)
[10:34:29] <alex_joni> lol
[10:34:44] <alex_joni> did you get to use that email addy?
[10:34:53] <paul_c> not yet
[10:35:17] <paul_c> lemme check something..
[10:35:23] <alex_joni> sure...
[10:35:48] <alex_joni> * alex_joni shuts down his devel box...
[10:36:08] <paul_c> Didn't set up an addy did we.
[10:36:55] <alex_joni> well... I did set you an addy up...
[10:37:24] <paul_c> what was the address again ?
[10:38:01] <alex_joni> paul@juve.ro
[10:41:00] <alex_joni> * alex_joni is thinking about adding a tracker for the ini stuff
[10:41:50] <alex_joni> I mean the fix so that programs can find configs in the same dir as the inifile specified
[10:53:57] <alex_joni> ok... I'm running very low on battery...
[10:54:26] <alex_joni> it's almost 3 am here... gotta catch some sleep...
[10:54:28] <alex_joni> bye guys
[11:24:24] <jmkasunich> * jmkasunich needs to get off IRC and concentrate on code
[12:04:34] <jepler> If emcplot3d / rs27py gplot could find the line number currently being executed, it would be possible to display the parts after that line in white and the parts before using the live plot data. but I don't know if this data is accessible or not.
[12:05:03] <jepler> this also presents a problem because it would require the OpenGL displaylist to be rebuilt each frame, or you could switch to a vertex array setup instead
[12:07:55] <jepler> class EMC_TASK_STAT has 3 fields concerned with the line number, so this may turn out to be possible.
[12:08:04] <jepler> I'll put it on a TODO list
[12:08:19] <cradek> yeah the task controller can show the line (I added it to xemc in my tree)
[12:08:57] <cradek> I guess they all know how to highlight it so this is no new news
[12:10:01] <jepler> So when you added the "highlight" stuff you changed it all to use GL_LINES instead of GL_LINE_STRIP, right?
[12:10:08] <cradek> yes
[12:10:15] <cradek> sorry, but it was so easy
[12:10:25] <jepler> It didn't seem to affect performance much
[12:10:52] <cradek> I didn't compare it, but it seems fine
[12:10:54] <jepler> if everything is GL_LINES then it would be "easy" to switch to a vertex array and still keep good performance at redraw time
[12:11:10] <cradek> cool
[12:11:45] <jepler> but the easiest way to use vertex arrays is to use Numeric / numarray
[12:12:11] <cradek> ick, another dependency
[12:12:27] <cradek> but oh well, it's easy to install
[12:13:58] <jepler> yeah
[12:14:03] <cradek> looks like you want emcStatus->task.currentLine
[12:14:09] <jepler> until the day I want to package this for windows
[12:14:13] <jepler> yeah, that sounds right
[12:14:20] <jepler> see you tomorrow...
[20:44:58] <alex_joni> g'day gents
[22:51:18] <les> morning
[22:54:13] <alex_joni> hello les
[22:54:36] <les> cold here
[22:54:48] <alex_joni> really cold?
[22:55:06] <alex_joni> 39 here
[22:55:15] <les> 26F here
[22:55:29] <les> pretty cold for georgia
[22:55:53] <alex_joni> 26 is pretty cold ;)
[22:56:21] <les> it gets colder here due to altitude and cold air damming
[22:56:56] <alex_joni> I see...
[22:57:03] <alex_joni> any news on the XX ?
[22:57:55] <les> well I thought about it and put some numbers on the group delay of a master/slave
[22:58:23] <les> it would be about 2 complete servo cycles
[22:58:47] <les> = 4 servo updates
[22:59:22] <les> that would be miniscule for some machines and significant for others
[22:59:54] <les> I have found what other motion control do....
[23:00:42] <les> when assigning e-gearing one has the choice of either real axes as masters or virtual
[23:00:59] <les> real slaves to the actual position
[23:01:20] <les> virtual slaves to the commanded position
[23:01:39] <les> I think that is the best way to do it
[23:02:43] <alex_joni> I see...
[23:02:53] <les> I also think that for a gantry an estop on yaw amount abs(ferrorx1-ferrorx2) is a must
[23:03:11] <alex_joni> define yaw...
[23:03:47] <les> rotation in zz for an xyz machine
[23:04:04] <les> or just that abs() I just wrote
[23:04:14] <alex_joni> I see...
[23:05:17] <les> if mistuned the two ferrors could easily be huge and in opposite directions
[23:06:13] <les> so virtual axis slaving with estop on the abs() term would be a good thing
[23:06:19] <alex_joni> aha... even if small, but in opposite directions
[23:06:43] <les> but perhaps not small if near a pole
[23:06:48] <alex_joni> it's bad...
[23:06:54] <les> or just mistuned
[23:07:06] <alex_joni> I agree that some abs(on difference is needed)
[23:07:31] <alex_joni> but... it could need some scaling
[23:07:39] <alex_joni> lets say the 2 axis are not equal
[23:07:50] <les> that would help for folks that couldn't stand the group delay of real axis slaving
[23:07:53] <alex_joni> or are we talking only about identical joints?
[23:08:23] <les> otherwise just up the servo update until the delay is not a problem
[23:08:43] <les> really any slaved joints
[23:08:56] <les> like threading on a lathe
[23:09:32] <les> an example is my machine
[23:09:38] <alex_joni> got a pic?
[23:09:51] <les> servo update is at 2 kHz
[23:10:20] <les> so group delay would be 2 ms
[23:10:40] <les> or .002 in at 1 in/sec
[23:10:46] <les> a bit much
[23:11:01] <les> getting a link to machine pictures...
[23:12:21] <les> http://lmwatts.com/cnc.html
[23:13:54] <les> so I would need servo update of about 10kHz for good electronic gearing of tandem axes
[23:14:32] <les> or use virtual with the abs() term estop
[23:14:55] <alex_joni> 10 kHz is pretty much
[23:15:32] <les> yes...although not a big problem with emc if in a modern box
[23:15:59] <les> my old P3 200 could not do it
[23:16:37] <alex_joni> P1 i guess...
[23:16:52] <les> I think the jackshaft was the best way to go at the time
[23:17:04] <les> it was just very expensive
[23:17:22] <les> but no racking
[23:17:33] <alex_joni> what servos do you use?
[23:17:44] <les> well less than 0.0005 with the cam ballscrew matching
[23:17:56] <les> these:
[23:18:08] <alex_joni> STG with analog ?
[23:18:20] <les> http://lmwatts.com/forsale.html
[23:18:29] <les> yes stg 2 analog
[23:19:03] <alex_joni> I see you have some rails for sale :)
[23:19:16] <les> just a broker....
[23:19:44] <les> Guy I know in chicago has a good fraction of a kilometer of them
[23:19:53] <les> but is very hard to deal with
[23:20:15] <les> I think I am going to stop selling them
[23:20:19] <alex_joni> well.. as much as I would like some.. it's too far from me...
[23:20:36] <les> ohio?
[23:20:44] <alex_joni> east-europe :))
[23:20:52] <les> oh haha
[23:21:12] <les> well HIWIN rails are good and low priced
[23:21:19] <alex_joni> yeah I know...
[23:21:34] <alex_joni> not so sure about buying.. yet
[23:21:39] <alex_joni> but I will get there eventually
[23:21:42] <les> almost as cheap as our surplus ones
[23:22:16] <les> I have gone through 100 meters or so of rails in the past couple years
[23:22:32] <les> it's some money
[23:23:47] <alex_joni> I imagine...
[23:23:59] <alex_joni> but it's worth it...
[23:24:04] <les> as soon as I get a break I need to retro a bridgeport with emc
[23:24:13] <les> I need another mill
[23:24:30] <les> looking for one now
[23:25:10] <les> one really need multiple machines to be productive
[23:25:52] <alex_joni> don't know about that... not mut production here ;)
[23:26:05] <alex_joni> * alex_joni is really tired...
[23:26:33] <les> got a call about a series II for sale about 30 miles away...like new condition...
[23:26:49] <les> but it had been left out in the rain!!!
[23:27:49] <les> ha...take a rest...I have to get to the shop and get started
[23:30:32] <alex_joni> I stayed up till 4 a.m. last night
[23:31:52] <les> wow
[23:33:11] <les> I just am getting tired of working 7 days
[23:33:11] <alex_joni> now I'm waiting to go home (and go to sleep9
[23:33:22] <alex_joni> I can imagine...
[23:33:24] <les> the economy here is getting better
[23:33:42] <les> I do this machine design stuff for a living...
[23:34:06] <les> this is an encoder I designed here:
[23:34:53] <les> http://lmwatts.com/v-web/b2/
[23:35:03] <les> it is going into production
[23:35:12] <alex_joni> economy is getting better here too...
[23:35:41] <alex_joni> nice pet ;)
[23:36:09] <les> ha...took that right by the house
[23:37:08] <alex_joni> cute...
[23:37:42] <alex_joni> nice encoder...
[23:37:56] <alex_joni> how many impulses / rev ?
[23:38:45] <les> it has an abssolute analog output
[23:39:01] <les> but is programmed by a serial link
[23:39:13] <les> it is for a car
[23:39:37] <les> materials cost only $2.70
[23:40:41] <alex_joni> so it's more a tacho then an encoder... right?
[23:40:45] <les> I designed the circuit to work from -40c to +85
[23:41:03] <les> it is a throttle position sensor
[23:41:27] <les> I do digital ones too
[23:42:16] <alex_joni> great
[23:42:46] <les> so emc is being used to prototype high volume car parts
[23:43:41] <les> right now I have been working on robotic testers for this device
[23:44:04] <les> must get out to th shop now though...have to ship one today
[23:45:25] <alex_joni> well.. don't wanna hold you back...
[23:45:36] <les> be back on later
[23:46:12] <les> I have to test the software once more before I ship it
[23:46:20] <les> later