Back
[00:00:14] <les> well it was supposed to be rain today...but warm and sunny
[00:00:27] <les> so I may vanish soon...
[00:00:44] <les> golf course is calling...
[00:00:55] <les> also leaves.
[00:01:51] <alex_joni> nice...
[00:01:55] <alex_joni> well.. have fun
[00:02:09] <les> this is the first weekend off I have had in a month
[00:03:31] <alex_joni> then take advantage of it
[00:15:25] <les> ha I have been...just in the office waiting for it to get to 15c outside
[00:15:40] <les> 12 now heh
[00:16:05] <les> Also answering questions on yahoo and newsgroups
[00:16:24] <les> I like to do that when I have time
[00:16:32] <alex_joni> are there any emc-related newsgroups?
[00:16:41] <alex_joni> or just machining ones?
[00:17:17] <les> Cad_cam_edm_dro is hobby cnc specific and has a lot of emc content
[00:17:27] <les> ...a yahoo group
[00:17:50] <les> thousands of members
[00:18:34] <les> I don't mind doing a little free engineering for them....
[00:19:09] <les> because every answer is thousands of emails...each with hyperlinks to my site
[00:19:12] <alex_joni> I think I'm subscribed to cad_cam_edm_dro
[00:19:23] <alex_joni> I didn't visit it in a while
[00:19:40] <les> So I give some free engineering...and get some free advertising
[00:20:16] <les> I am getting 7000 hits/mo on my site and a good bit comes from those groups
[00:21:03] <alex_joni> nice
[00:24:50] <les> Grr this new winxp I had to install has java diabled
[00:25:29] <les> Does not even seem to have it or the firewall won't allow it
[00:25:35] <les> hate winxp
[00:27:37] <alex_joni> SP2?
[00:27:58] <les> yes
[00:28:20] <les> had to get it to test code I wrote for a client that will use it
[00:29:21] <alex_joni> I see...
[00:29:29] <alex_joni> I did have some problems with SP2 myseld
[00:29:47] <alex_joni> my imap connection (on local LAN) went berzerk
[00:29:52] <alex_joni> about 10 seconds before connection
[00:30:40] <alex_joni> finally tracked it down to the auth port, that was blocked on SP2
[00:31:13] <les> I am looking now...I have activex enabled...but java stuff will not run
[00:32:08] <alex_joni> well.. you gotta have a JAVA-VM
[00:32:17] <alex_joni> afaik XP doesn't have one by default
[00:32:27] <alex_joni> they offer their own M$-java-vm
[00:32:33] <alex_joni> but that one's crappy
[00:32:43] <alex_joni> I'd suggest you download a JRE from sun
[00:32:50] <les> need it to look at sat/radar weather to see why it is not raining all day as predicted
[00:33:05] <les> yup just went to the sun site
[00:42:52] <Imperator_> * Imperator_ is waking up
[00:43:10] <Imperator_> Hi all
[00:44:06] <Imperator_> enjoy the wether les here we have 2�C
[00:44:51] <les> cold
[00:45:00] <alex_joni> g'morgen martin
[00:45:09] <alex_joni> here we have around 4�C
[00:45:15] <les> hmmm sun cannot install JRE on xp sp2
[00:45:19] <les> !?
[00:45:29] <alex_joni> :-(
[00:45:45] <alex_joni> then.. download opera with java (www.opera.com)
[00:45:46] <les> has "issues"
[00:45:52] <alex_joni> it's way better than IE
[00:46:11] <les> I will check that out
[00:48:17] <alex_joni> some pages don't show right in Opera thou...
[00:48:28] <alex_joni> but that's a fault of the people who write the pages
[00:48:42] <alex_joni> they don't go by standards... (rather M$ standards)
[00:57:00] <alex_joni> * alex_joni is watching UK Champs in York
[00:57:44] <alex_joni> marbles again...
[00:58:07] <les> jre installed...had to do some activex stuff first
[00:58:34] <les> really slow
[00:58:44] <les> like watching paint dry
[01:00:37] <les> now got the sat wweather animation...
[01:00:48] <les> uh oh...rain is comming
[01:03:29] <les> back in a while...
[01:23:41] <alex_joni> hey steve
[01:24:07] <SteveStallings> hi alex, I see you have been very active with auto config this week.
[01:24:20] <alex_joni> last night actually
[01:24:31] <alex_joni> I did another branch this week
[01:26:12] <SteveStallings> perhaps you should review my comments about packages on the page at
http://linuxcnc.org/EMC-description.html and suggest updates to reflect your work
[01:26:29] <SteveStallings> hi ray
[01:26:44] <rayh> Hi Steve.
[01:27:18] <alex_joni> well... actually right now only make install works
[01:27:24] <alex_joni> there will be a make rpm
[01:27:31] <alex_joni> and some deb-packages
[01:28:05] <alex_joni> but those are not really done
[01:28:13] <alex_joni> paul started on deb-packages
[01:28:29] <alex_joni> and Jonathan Starks on some rpm support
[01:28:54] <SteveStallings> is the intention to have packages that will install real time as well as EMC onto a standard Linux system?
[01:29:19] <rayh> SteveStallings: I looked over that page and it looks good to me. We will soon need to add 2.6 to the Linux versions supported.
[01:29:21] <alex_joni> I don't think so
[01:29:28] <alex_joni> that's way to hard to do
[01:29:48] <alex_joni> ray: for emc?
[01:30:38] <SteveStallings> That is what I thought. So what will be the install sequence when one is able to use one of the packages?
[01:30:46] <rayh> Yes. Paul has a new BDI-3xx that is based on the 2.6 kernel.
[01:31:14] <alex_joni> nice
[01:31:26] <rayh> This install is for EMC2?
[01:31:31] <alex_joni> I know paul's pretty busy lately with the next release
[01:31:34] <alex_joni> ray: yes
[01:32:07] <alex_joni> but it also helps for package creation (binary packages, e.g. rpm)
[01:32:24] <rayh> It is up to Paul, but my preference for 2 would be a BDI inclusion.
[01:32:35] <alex_joni> that's for sure
[01:32:44] <rayh> That is a ways off.
[01:33:25] <rayh> IMO the autostuff is essentially separate from how it will be finally released into the wild.
[01:33:46] <alex_joni> the autoconf kinda figures if the system it analyses is ok enough to use emc2 on it
[01:34:02] <alex_joni> you don't need those tests on a standard BDI
[01:34:12] <alex_joni> but I don't see how they could harm
[01:34:16] <rayh> I missed the start of this so I may well be way off...
[01:34:26] <rayh> No harm. A lot of help as I see it.
[01:34:41] <SteveStallings> I will be a vendor at Cabin Fever in late January, and our local club will be running a CNC demo area again. I will be happy to distribute BDI releases there. With luck I may be running EMC2 as a demo.
[01:35:33] <rayh> Guru level doesn't need auto, but the rest of us developer/testers will be helped a bunch.
[01:35:49] <alex_joni> don't know what you mean with guru level?
[01:35:59] <rayh> As will the BDI folk whenever they make a new package for that distro.
[01:36:24] <rayh> John, Paul, Robin, you...
[01:36:28] <alex_joni> actually autoconf right now provides the ./configure script
[01:36:52] <alex_joni> which analyses the system and outputs Makefile.inc (with all CFLAGS, RTVER, etc.)
[01:37:05] <rayh> SteveStallings: Need me to ship you a bunch of disks.
[01:37:10] <alex_joni> so I don't think anyone can use emc2 without it
[01:37:31] <alex_joni> the HEAD branch of emc2 contains a custom written ./configure script
[01:37:37] <alex_joni> written by paul
[01:37:51] <rayh> I guess I was thinking of those few who built emc2 from the original make and source.
[01:37:51] <alex_joni> but that was way to hard to maintain
[01:38:08] <alex_joni> right now it's pretty simple:
[01:38:09] <jmkasunich> hi guys
[01:38:11] <alex_joni> ./configure
[01:38:13] <alex_joni> make
[01:38:14] <SteveStallings> Ray - I would like to distribute the latest thing available at the time. I can copy disks but don't have access to one of the cool label printers.
[01:38:16] <alex_joni> & run
[01:38:19] <alex_joni> hey John
[01:38:37] <rayh> I've got a couple hundred preprinted.
[01:38:38] <alex_joni> when / if you're happy with the results ... make install
[01:39:51] <rayh> alex_joni: I don't know much about the specifics but it sounds like this is a big step forward.
[01:40:05] <rayh> Mornin John.
[01:40:24] <SteveStallings> hi John
[01:40:52] <alex_joni> rayh: it surely is intended to be... if it's already there... that's a whole different question
[01:40:54] <jmkasunich> looks like an interesting discussion in progress
[01:41:26] <alex_joni> jmk: hi
[01:41:37] <SteveStallings> It started from wanting to update the EMC description on the web site to accurately reflect the status of auto config.
[01:41:45] <jmkasunich> * jmkasunich reads mail
[01:41:45] <Imperator_> Hi John
[01:42:04] <jmkasunich> I wish I was online yesterday - seems Paul Fox was having problems that I could have helped with
[01:42:28] <alex_joni> steve: the autoconf stuff is still in a separate branch... don't think it should go on the page while it is not in the HEAD branch
[01:42:46] <jmkasunich> which brings me to a question I wanted to ask you...
[01:42:53] <jmkasunich> when do you think we should merge it
[01:42:53] <alex_joni> ask ahead
[01:43:02] <jmkasunich> seems to me we're getting pretty close?
[01:43:09] <alex_joni> I see it with 2 possibilities
[01:43:18] <alex_joni> 1. get a lot of people to test it, then merge it
[01:43:33] <alex_joni> 2. merge it and fix what comes up, after people start to test it...
[01:44:36] <jmkasunich> ;-)
[01:45:03] <alex_joni> but I would really want to hear paul's oppinion about the merging
[01:45:14] <jmkasunich> or 1.5: get a few people to test it, then merge it, and fix what comes up as more test it
[01:45:26] <alex_joni> well.. a few people did test it
[01:45:35] <alex_joni> but .. you can count those on your fingers ;)
[01:45:50] <SteveStallings> I will need to build a new EMC2 soon for the show. I will try the new tools. Are there any "instructions"?
[01:45:53] <jmkasunich> I need to do a cvs up and play with it myself
[01:46:04] <alex_joni> try the new branch I did this week
[01:46:11] <alex_joni> autoconf_install_0_1
[01:46:27] <jmkasunich> a branch from a branch?
[01:46:44] <alex_joni> steve: you really are only supposed to do : ./configure && make && scripts/emc.run
[01:46:50] <jmkasunich> SteveStallings: the autoconf stuff works just like the original: ./configure, make, run
[01:46:59] <alex_joni> jmk: yes... ain't it twisted? :-)
[01:47:27] <jmkasunich> the difference is that the original hand-generated (and crufty) ./configure has been replaced by an autotools generated one that does a better job
[01:47:38] <alex_joni> or should ;)
[01:48:03] <SteveStallings> Hey, I don't need any extra help with getting twisted, ample ability on hand already! 8-(
[01:48:04] <alex_joni> well... it does a lot more tests
[01:48:15] <jmkasunich> any particular reason for another branch? That means either you don't get the benefit of the compile farm, or I have to add the new branch to the farm list
[01:48:32] <alex_joni> it doesn't change things on ./configure && make
[01:48:36] <alex_joni> only for make install
[01:49:00] <jmkasunich> I see - we don't do make install on the farm anyway, so I guess it doesn't matter
[01:49:05] <alex_joni> yup
[01:49:27] <alex_joni> but I would love some testing from you... e.g. tell me what you think of it
[01:49:28] <jmkasunich> still - if the config stuff is pretty much working, I think I
[01:49:55] <jmkasunich> I'd rather see it get merged, then continue with the install stuff in the original autoconf branch and merge again when that is working
[01:50:08] <alex_joni> I see...
[01:50:15] <jmkasunich> too many branches can get confusing, IMO
[01:50:18] <alex_joni> problem is...
[01:50:33] <alex_joni> right now the autoconf branch has some make install additions in it
[01:50:39] <jmkasunich> true
[01:50:40] <alex_joni> some I don't like
[01:50:47] <alex_joni> 1. run-in-place is broken
[01:50:48] <jmkasunich> ;-)
[01:51:06] <alex_joni> so I wouldn't want that merged in HEAD
[01:51:08] <alex_joni> right?
[01:51:13] <jmkasunich> right
[01:51:23] <alex_joni> 2 possib.
[01:51:35] <alex_joni> 1. strip away all make install stuff
[01:51:46] <alex_joni> and merge only the autoconf stuff
[01:52:00] <alex_joni> 2. so some more work till the make install is ok
[01:52:04] <alex_joni> and merge that
[01:52:22] <jmkasunich> but the "more work" is in the new branch, yes?
[01:52:33] <alex_joni> actually no...
[01:52:40] <alex_joni> there's less work there
[01:52:41] <jmkasunich> then what is the new branch for?
[01:52:56] <alex_joni> I didn't like the way zwisk did it.. I thought it was too complicated
[01:53:03] <jmkasunich> I see
[01:53:06] <alex_joni> so I did it my way... a lot simpler
[01:53:14] <jmkasunich> have you and zwisk talked about it at all
[01:53:15] <jmkasunich> ?
[01:53:19] <alex_joni> but I still want to discuss it with him, not to miss anything
[01:53:28] <alex_joni> we did exchange some e-mails
[01:53:51] <alex_joni> but he last said he was busy, and I should give it a try, and we'll sync sometime
[01:53:58] <jmkasunich> I like your option 1 (remove make install, then merge)
[01:54:16] <jmkasunich> then work on make install "from scratch"
[01:54:29] <jmkasunich> but I'm really not up to date on where that all stands
[01:54:31] <alex_joni> that's what I did in the new branch
[01:54:53] <jmkasunich> * jmkasunich needs to read the cvs book again
[01:55:08] <jmkasunich> can you merge from your "branch from a branch" all the way back to the head?
[01:55:25] <alex_joni> well.. the branch from a branch is actually a separate branch
[01:55:31] <alex_joni> just like the first one
[01:55:38] <jmkasunich> from the trunk?
[01:55:49] <alex_joni> they are equal
[01:56:19] <alex_joni> work can be merged from either one
[01:56:26] <alex_joni> or from both
[01:56:26] <jmkasunich> ok
[01:58:57] <jmkasunich> I'm just a little concerned about the proliferation of branches - I'd like to hear what paul feels about it
[01:58:57] <alex_joni> * alex_joni joins the club
[01:58:57] <jmkasunich> in the meantime, it shoulds like I should checkout your new branch
[01:58:58] <alex_joni> I think paul is more likely to state that the autoconf ./configure is up to replace the hand-crufted one
[01:59:16] <jmkasunich> I agree - regardless of where we stand on the make install, I think the new configure should be merged as soon as possible
[01:59:49] <rayh> Getting it here now. I can test after a bit on 2.20b, live, and knoppix.
[02:00:48] <alex_joni> ray: either one should work
[02:01:15] <rayh> SteveStallings: Got any clue how many disks you might need for Cabin Fever?
[02:06:05] <SteveStallings> That crowd is just warming up to CNC. Need should be no more than 20. If more ask, I can start making copies. My question is which disk? BDI2.x, RC46, or the new one Paul is working on?
[02:07:01] <rayh> They are printed in Baltimore. I could get some shipped direct.
[02:07:30] <SteveStallings> Hopefully Chris Daniel (aka -thalx) will be running EMC1 and I will be running EMC2.
[02:07:32] <rayh> I
[02:07:46] <rayh> I'd wait for the new. It promises to be great.
[02:08:26] <alex_joni> * alex_joni is eager too to get his hands on the new BDI
[02:10:33] <SteveStallings> Are the printed disks blanks that your burn?
[02:10:45] <rayh> Yes.
[02:10:58] <alex_joni> jmk: say when you got some time, and nerve to test the new branch
[02:11:11] <alex_joni> did you talk to Imperator_ about homing ?
[02:11:21] <SteveStallings> Then I could do the burning at the last minute, just tell me how to get some of the disks.
[02:12:47] <rayh> Email me your address again and I'll get some to you.
[02:13:37] <jepler> good morning folks.
[02:13:53] <jmkasunich> alex_joni: nerve - no problem, time - that's tougher
[02:14:17] <alex_joni> good afternoon jepler
[02:14:33] <jmkasunich> I haven't talked to imperator about homing - I have done zero emc stuff this week except for a couple emails on the list
[02:14:54] <alex_joni> he's still wondering about a hal module
[02:15:04] <alex_joni> for a XX machine
[02:15:12] <jmkasunich> ah
[02:15:41] <alex_joni> he's been talking to les about master-slave joints
[02:15:43] <alex_joni> and such
[02:16:11] <rayh> SteveStallings: got it.
[02:16:44] <alex_joni> I was wondering... how is hal connected to emc ?
[02:16:44] <jmkasunich> I need to clone myself
[02:17:10] <alex_joni> through the /src/emc/hal_intf/ ?
[02:17:18] <jmkasunich> no
[02:17:28] <jmkasunich> but in hindsight, that probably should have been used
[02:17:40] <jmkasunich> or maybe not
[02:17:42] <jmkasunich> ;-)
[02:17:53] <alex_joni> yeah... that clarifies it a bit
[02:17:54] <alex_joni> lol
[02:18:08] <jmkasunich> I don't like the ext interface - the new emc2 motion controller directly accesses HAL pins
[02:18:13] <jmkasunich> (and paremeters)
[02:18:19] <alex_joni> I see
[02:18:29] <jmkasunich> using the ext interface to do it would have just added another layer
[02:18:44] <alex_joni> well then its more likely that the motion controller can tell a hal_module it needs homing
[02:18:44] <jmkasunich> paul and I have debated it back and forth
[02:18:52] <alex_joni> through the ext interface --- no way
[02:19:13] <jmkasunich> I need to review how I did homing in the new motion controller
[02:19:47] <jmkasunich> need to define some conventions for the behavior of a HAL encoder interface (whether hardware or software based)
[02:19:57] <jmkasunich> and then modify the motion controller to work with that
[02:20:58] <alex_joni> sounds like a lot of work
[02:21:00] <jmkasunich> as it stands, when an encoder hits an index pulse, the actual encoder driver does _not_ zero the signal it sends to the HAL, instead the motion controller adds an offset
[02:21:55] <jmkasunich> that is simple and clean, and works well _unless_ you are running at more than one encoder count per servo cycle
[02:22:05] <alex_joni> yeah.. but a HAL module for a XX axis can do it the same way
[02:22:33] <jmkasunich> right - the XX module would strive to make two physical axes look like one logical one
[02:22:45] <alex_joni> tell the motion controller it's a single axis
[02:23:11] <jmkasunich> exactly
[02:23:29] <Imperator_> jep, that works well but homing is the problem
[02:24:02] <Imperator_> im thinking on that the HAL module will make the homing but ..
[02:24:16] <Imperator_> im not shure if that is a clean implementation
[02:24:56] <alex_joni> Imperator_: the HAL module needs to home the second axis
[02:26:07] <Imperator_> while homing the two axis have to move also together. If one hits the home switch it has to do the same procedure like on a single axis. then it has to hit the second home switch. then the axis have to synchronise
[02:26:29] <jmkasunich> I don't think you can do that
[02:26:30] <Imperator_> but ALWAYS both axis have to do the same movement
[02:26:38] <Imperator_> why ?
[02:26:59] <jmkasunich> you just said it - both axis always have to do the same thing
[02:27:08] <jmkasunich> you can't home one at a time
[02:27:47] <alex_joni> how can you make sure the two axis's move at the same time if they are not homed?
[02:28:15] <alex_joni> what if something happened during power-off
[02:28:24] <alex_joni> and they are not synced anymore?
[02:28:33] <jmkasunich> imagine both were in sync, then you did power off
[02:28:39] <Imperator_> if they are not homed i can only command both to do the same
[02:28:46] <jmkasunich> and then you turned one screw part of a turn
[02:28:51] <alex_joni> yup...
[02:28:59] <jmkasunich> you won't be able to turn it much because the machine is stiff, and it won't let you
[02:29:06] <jmkasunich> but say you are 1/4 turn out of sync
[02:29:14] <Imperator_> jep
[02:29:19] <Imperator_> that can happen
[02:29:34] <alex_joni> I think it's like this... during homing both have to do the same thing
[02:29:35] <Imperator_> what's the problem ?
[02:29:43] <jmkasunich> when you home later, you run both axies together, and they remain 1/4 turn out of sync until you get to the end
[02:29:51] <alex_joni> and if both HOME_SIGNALS come, then it's ok
[02:30:07] <alex_joni> if only one comes it should be signaled or treated differently
[02:30:23] <alex_joni> but I don't think you can decide what to do in this case
[02:30:26] <jmkasunich> the XX module must detect that they are not in sync, and it is responsible for syncing them
[02:30:47] <alex_joni> maybe run the two till the home signal for the second comes
[02:30:56] <Imperator_> jep, but first you have to hit both switches
[02:31:02] <alex_joni> then check how far from home it is (from the home on the first)
[02:31:04] <jmkasunich> that doesn't sync them tho - they stay 1/4 turn out of sync
[02:31:17] <alex_joni> if greater than a certain value- e-stop with message
[02:31:29] <rayh> I think this thinking is incorrect. You are only going to home one of the two.
[02:31:35] <alex_joni> if not move the first axis on home (because the second one is already)
[02:31:42] <rayh> The second just has to follow that primary axis.
[02:32:06] <alex_joni> I agree ray, but you have to make sure it's not way off
[02:32:17] <alex_joni> so the whole thing doesn't get broken
[02:32:19] <jmkasunich> rayh: yes - but what if the second one is offset from the first one (skewed)
[02:32:22] <Imperator_> in real the home switches are always on different positions
[02:32:24] <rayh> Trying to allign two 2000 encoder index pulses will not work.
[02:32:57] <alex_joni> rayh: I would disagree on that
[02:33:05] <rayh> The integrator will simply have to mechanically align the two.
[02:33:14] <alex_joni> Imperator_: here's a thought
[02:33:16] <jmkasunich> the two encoders?
[02:33:20] <alex_joni> use abs-encoders
[02:33:25] <alex_joni> on both axes
[02:33:30] <jmkasunich> alex_joni: that
[02:33:34] <alex_joni> not a lot more expensive
[02:33:56] <Imperator_> i have some, but i want to wite the module also for normal incremental encoders Alex
[02:34:22] <alex_joni> don't know if you can for all cases
[02:34:36] <alex_joni> I see abs-encoders the way to eliminate a lot of problems
[02:34:45] <jmkasunich> rayh: you mean the integrator would adjust the machine so it is square (no skew), then manually rotate the encoder wheels until they index, and finally tighten the setscrews?
[02:34:45] <alex_joni> or use power-off-brakes
[02:35:02] <Imperator_> that doesn't solve the problem
[02:35:05] <alex_joni> jmk: I do that on abs-encoders
[02:35:15] <Imperator_> i think that is all not that problem
[02:35:19] <rayh> I would only use the index from one encoder. The other is irrelevant.
[02:35:34] <jmkasunich> how to you keep the machine square then?
[02:35:37] <alex_joni> you really need to make sure they are in sync
[02:35:45] <Imperator_> the question is how to implement that
[02:35:53] <jmkasunich> suppose while it's powered off, someone turns the slave axis by 0.002"
[02:35:59] <alex_joni> maybe after homing drive the axis for one turn in either direction
[02:36:09] <rayh> Sync is simply matching pulse for pulse between the two motors.
[02:36:10] <Imperator_> 1. a HAL module that does it's own homing procedure
[02:36:16] <alex_joni> and check for the home-signal from the second axis, and see what diff you have
[02:36:34] <alex_joni> ray: agreed if the machine can't be moved when switched off
[02:36:44] <jmkasunich> Imperator_: I'
[02:36:46] <jmkasunich> oops
[02:36:50] <Imperator_> 2. add a additional secuence to the existing
[02:36:59] <Imperator_> sequence
[02:37:10] <rayh> Doesn't matter if it is moved.
[02:37:10] <jmkasunich> Imperator_: I'd rather avoid a HAL module that actually knows about homing - keep that in the emc motion module
[02:37:25] <jmkasunich> rayh: huh??
[02:37:35] <rayh> When restarted it homes on the index from one motor while the other matches the motion.\
[02:37:38] <alex_joni> rayh: only one part gets moved
[02:37:55] <alex_joni> so it's not square anymore
[02:38:16] <rayh> No both must move at the same time. That is the nature of the fixed gantry.
[02:38:29] <jmkasunich> right - only one side got moved, it is now 0.002" out of square - if the slave simply matches the master, it will stay out of square by 0.002 forever
[02:38:44] <Imperator_> i think i have to write the sequence i'm thinking on down somewhere otherwise that discassion lasts forever :-)
[02:38:48] <alex_joni> it's not fixed
[02:39:02] <jmkasunich> no gantry is infinitely stiff - if it was, you could use only one screw
[02:39:06] <alex_joni> it's a gantry driven by two motors
[02:40:10] <alex_joni> Imperator_: I agree it can be adjusted by software, but I would really go with abs-servos (a lot safer)
[02:40:10] <sivaraj> Gantry axis will self align itself.you cannot force to have skew
[02:40:33] <rayh> Yea... What he said!
[02:40:36] <alex_joni> that way you can check the skew before moving the gantry
[02:40:51] <jmkasunich> I must respectfully disagree with ray and sivaraj
[02:41:12] <Imperator_> ok if i add something to the existing homing sequences motion has to know that there are two axis. makes this new problems ???
[02:41:15] <SteveStallings> Skew can be forced and will cause premature wear on bearings.
[02:41:21] <jmkasunich> if the gantry is stiff enough that you "can't" skew it, then why bother driving it from both sides?
[02:41:24] <alex_joni> * alex_joni agrees with john.
[02:41:49] <sivaraj> if there is a skew will cause motor to overload
[02:41:55] <sivaraj> so it cannot move
[02:42:02] <jmkasunich> depends on the amount of skew
[02:42:17] <alex_joni> a small skew will just damage things sooner or later
[02:42:47] <jmkasunich> if the stiffness is such that 0.002 of skew will overload the motor, then 0.001 of skew will be 50% of overload, and 0.0005 skew might not be noticed until bearings or screw wear out early
[02:43:18] <alex_joni> * alex_joni leaves for half an hour...
[02:43:31] <Imperator_> if there is skew it will be there until it has hit both home switches. Then the next step is to remove the skew
[02:43:41] <jmkasunich> right
[02:43:59] <alex_joni> yeah but what if the skew that is damages the machine ?
[02:44:08] <rayh> IMO if you try to force both motors to home you will introduce the skew that you are trying to avoid.
[02:44:23] <alex_joni> I think a abs-servo could have prevented that
[02:44:34] <alex_joni> check the two encoders... and see what your skew is...
[02:44:34] <SteveStallings> ... if the system crashes and there is lots of skew, then the first step is to relax the torque to the ganry can be squared enought to move...
[02:44:56] <rayh> The only way round this is motor amp load balancing.
[02:44:58] <Imperator_> then it is in sync and the rest is easy because then you only have to give both axis the same command and whach if they are in sync. If they run out of sync the machine goes to estop
[02:45:09] <sivaraj> most of the CNC's I have seen references only master axis.the slave will just follow it
[02:45:31] <alex_joni> * alex_joni is back in 30 mins.
[02:45:49] <sivaraj> no need to reference the slave axis.
[02:45:53] <Imperator_> don't think so sivaraj
[02:46:11] <SteveStallings> Generalized solution should also take into account systems running stepper motors and NO feedback.
[02:46:20] <rayh> You will get out of banance conditions during accel and decel anyway because it will be nearly impossible to perfectly match the tuning of both systems.
[02:46:30] <Imperator_> no problem Steve
[02:47:00] <jmkasunich> true - and even if they were perfectly matched, moving the Y from one side to the other will change the inertia on each side - the lighter side will respond faster
[02:47:06] <Imperator_> using servos or stepper makes no difference
[02:47:32] <rayh> If you insist that both motors must be homed to eliminate skew then make the gantry swivel at both ends.
[02:47:40] <Imperator_> that is another problem John but i think a small one
[02:48:01] <rayh> Now you can set the squareness of the xy table by rotating one encoder.
[02:48:14] <jmkasunich> yep
[02:49:04] <rayh> Darn this machine design stuff is fun!
[02:49:12] <Imperator_> Hm ?? Don't understand you rayh
[02:49:23] <sivaraj> I have build Gantry machine with Heidenhain syatem but they do not reference the slave.Its work is just follow the master
[02:49:23] <jmkasunich> and to a lesser extent, that is true of every gantry - swiveled ends and perfectly rigid ends are two extremes - but since there is no such thing as perfectly rigid, the swivel thing is a usefull thought experiment
[02:49:46] <Imperator_> The Siemens 840D does it
[02:49:58] <rayh> Imperator_: Don't feel alone. There are not many who do understand me;)
[02:50:10] <Imperator_> :-)
[02:50:31] <rayh> Yes you are correct that many commercial machines have fixed multiple motors and screws.
[02:52:30] <Imperator_> sivaraj: at the Haidenhain controlers you can decide if the slave only follows or if they will be synchronised after homing
[02:52:50] <jmkasunich> I expect that in many (perhaps most) cases you can ignore the issue that we have been talking about, because there is no realistic way to get a skew in the first place - so as long as the slave tracks the master pulse for pulse, there is no problem
[02:53:22] <Imperator_> more or less John
[02:53:41] <jmkasunich> but Steve brought up a good point - suppose it is an XXYZ machine, and Y is all the way at one end
[02:53:50] <jmkasunich> during an X rapid, the tool hits something
[02:53:50] <Imperator_> i think we have to go one step further
[02:54:04] <jmkasunich> one end of X stops right away, then other keeps going a little further
[02:54:51] <Imperator_> the PID controller has to solve that John
[02:54:56] <jmkasunich> hmmmm.... I guess that's only a problem with steppers, if they have encoders, then other slave would just move back into alignment by itself
[02:55:14] <jmkasunich> but with steppers, if the crash causes one side to loose steps, you have skew
[02:55:31] <Imperator_> and with steppers you have to take care that the do the stepps in any case
[02:56:18] <Imperator_> jep that is the problem of the steppers. That's why servos exist
[02:56:27] <jmkasunich> ;-)
[02:56:56] <Imperator_> ok i think we have discussed that. Now where can i implement it
[02:56:59] <rayh> Imperator_: The possibility of either slave or dual master would allow for most any kind of mechanical relationship between the motors.
[02:57:05] <jmkasunich> I think that any XX HAL module should have an parameter called "skew" or "offset" or something like that, that is added to the slave command
[02:58:03] <Imperator_> jep and a few more parameters that is not the problem John
[02:58:17] <rayh> * rayh gotta go. Thanks.
[02:58:57] <Imperator_> ok if i do homing in motion then emc has to know that there are two axis
[02:59:17] <Imperator_> and even in free mode they have to move together
[02:59:33] <Imperator_> how can i do that
[03:00:06] <jmkasunich> why does emc have to know?
[03:00:44] <Imperator_> because i think otherwise the homing can't work, because it is in EMC, or ???
[03:01:15] <jmkasunich> emc would home the one axis - the other would simply track it.
[03:01:24] <Imperator_> or do you mean i have to do both writing a HAL module and adding something to the homing code in EMC
[03:01:26] <jmkasunich> if there is no skew before homing, there would be no skew after homing
[03:01:41] <jmkasunich> nope - no change to emc, just the hal module
[03:02:38] <Imperator_> but i must be able to remove the skew if there is one
[03:03:02] <Imperator_> and i must be able to home both axis
[03:03:13] <Imperator_> to mesure the skew
[03:03:28] <jmkasunich> how would you measure the skew?
[03:04:04] <Imperator_> if i have homed both i know where they are and i know where they should to be
[03:04:42] <jmkasunich> but you can't home them individually - that would (at least temporarily) cause even more skew
[03:05:01] <sivaraj> i think it is difficult to measure skew with rotor encoder.May be linear scales can help
[03:05:27] <Imperator_> even at homing they must move together
[03:05:41] <jmkasunich> yes, exactlly
[03:05:58] <jmkasunich> so if they must move together, how can you possibly home them both?
[03:06:58] <Imperator_> first i search for the switch of the first one, then of the second one
[03:07:09] <jmkasunich> maybe this is a miscommunication issue: when I say "home an axis", I mean the entire process of moving toward a switch, stopping, perhaps backing up and approaching slower, sensing the switch again, and then possibly continuing until you sense an index pulse
[03:07:41] <Imperator_> jep i think also on that all John
[03:08:11] <Imperator_> that has first to be done for the first one, and then for the second one
[03:08:24] <jmkasunich> oh, I think I get it now: you are gonna to two complete homing sequences, first using the switch and index of the first axis, then using the switch and index of the second axis, and moving both motors together
[03:08:27] <Imperator_> that makes it interesting
[03:08:57] <jmkasunich> that makes it ver, very ugly... because either:
[03:08:59] <Imperator_> jep John
[03:09:16] <jmkasunich> 1) emc must "know" it is a dual axis, and home it twice
[03:09:30] <Imperator_> jep
[03:09:31] <jmkasunich> or 2) the HAL module must "know" that emc is homing
[03:09:57] <jmkasunich> part of the modularity of HAL is that they should not have to "know" these things
[03:10:02] <Imperator_> there is the parameter homing or how it is named
[03:10:46] <jmkasunich> emc tells HAL to move the axis, hal moves the axis - HAL doesn't know if the moves are part of homing or part of cutting, and emc doesn't know anything about the axis except that it goes where it's told to
[03:13:15] <Imperator_> jep but there is a parameter or pin (i don't know at the moment) with that the HAL module can know that. But maybe that is not the best way to implement that
[03:16:42] <SteveStallings> JMK - what does the HAL module do now when it encounters a "home" signal during a move?
[03:17:43] <Imperator_> the homing signals are conected directly to emc the HAL modules don't know them
[03:18:01] <jmkasunich> what he said ;-)
[03:18:33] <jmkasunich> but that needs to be revised at least a little bit to handle index pulses better
[03:18:54] <jmkasunich> (the home switch signal still will go directly to the motion controller)
[03:19:49] <SteveStallings> .. so the current homing routines are not within the HAL code, but rather within EMC2 code
[03:20:16] <jmkasunich> exactly
[03:20:28] <jmkasunich> machine tools home, emc2 is a machine tool controler
[03:20:45] <jmkasunich> things like stepgen, encoder, etc, are lower level functions, they don't know about homing
[03:21:03] <Imperator_> i think there are only two posibilitys: 1: write a HAL module that does homing itself. During homing it tells EMC something to keep it quiet
[03:21:16] <Imperator_> 2: to implement it completly in EMC
[03:21:35] <Imperator_> the second way i the clean one i think
[03:24:12] <jmkasunich> 3) write an XX hal module that recognizes EMC's homing sequence and does whatever special things are needed for dual axis
[03:24:23] <Imperator_> or maybe 1.5 emc does the homing. After homing it commands the slave axis to move because of eliminating skew. Then it gives a sync signal to the HAL module.
[03:24:38] <SteveStallings> does the current EMC2 homing rely on the final move to be slow enough that EMC2 can stop on exact index pulse by aborting a move command?
[03:24:52] <jmkasunich> both 2 and 1.5 require EMC to know that it is a dual axis
[03:25:48] <jmkasunich> SteveStallings: no - it only requires that it be slow enough that you get 1 encoder count per servo cycle - the servo can overshoot once the index is detected
[03:26:52] <jmkasunich> see chapter 3.4 of
http://linuxcnc.org/EMC2_Code_Notes.pdf
[03:27:06] <SteveStallings> Sorry, I have not read the code. So the index snapshots an encoder count?
[03:27:23] <SteveStallings> oops, going to read.....
[03:29:58] <alex_joni> * alex_joni is back
[03:30:36] <les> just got back and read the master/slave discussion
[03:30:46] <les> I studied up on it...
[03:31:40] <les> the good controls allow slaving to a virtual axis (commanded position) OR a real axis (actual position)
[03:32:00] <Imperator_> so john you suggest to not change anything on EMC itself. But i think that you agree with me that this would be the cleanest way
[03:32:03] <les> which seems to be the way thing are going...
[03:32:18] <Imperator_> what is the biggest reasoon not to change anything on EMC
[03:32:30] <CIA-9> 03jmkasunich * 10emc2/src/hal/hal.h: fixed some comments so they match the names used in the code
[03:32:50] <sivaraj> this a link to QA on Gantry axis reference with Galil motion card
http://www.galilmc.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=3;t=000141#000000
[03:33:11] <jmkasunich> question: how does emc1 support XXYZ machines
[03:33:31] <les> I guess it does not john
[03:33:46] <jmkasunich> I thought it did?
[03:34:15] <jmkasunich> (maybe not well, but I thought it at least makes an attempt?)
[03:34:24] <les> I am told no...
[03:34:48] <les> which is why I had to use a jackshaft (there were other reasons too)
[03:35:12] <jmkasunich> my reason for not wanting to make the code motion controller "aware" of dual axes is that the motion controller is complicated enough already
[03:35:26] <jmkasunich> s/code/core/
[03:35:47] <Imperator_> ok that is a reason
[03:36:12] <les> simplicity is good...
[03:36:48] <les> I read that the propagation delay for slaving is about 3 servo cycles....
[03:37:15] <alex_joni> I just read through the log...
[03:37:19] <alex_joni> short question
[03:37:20] <jmkasunich> see chapter 3.2 and figure 3.1 in EMC2_Code_Notes.pdf, that drawing can help us communicate I think
[03:37:21] <les> so some might need virtual slaving if thir servo update is not fast enough
[03:37:25] <alex_joni> mainly to John I think
[03:37:38] <alex_joni> what if we would have a HAL module that does the homing
[03:37:43] <alex_joni> so it's abstract to emc
[03:38:01] <alex_joni> this way things could get simlified in the homing procedure
[03:38:27] <jmkasunich> it would be hard to modularize homing
[03:38:27] <alex_joni> have different modules for different types of homing (with index_pulse, withour, with twin-axis, etc)
[03:38:43] <alex_joni> why?
[03:39:01] <jmkasunich> communication with the rest of emc
[03:39:24] <alex_joni> some changes on emc are needed.. agree
[03:39:35] <alex_joni> but it would simplify things in emc
[03:39:42] <jmkasunich> HAL works well for things that can be modeled as "hardware blocks", with signals connecting them to other parts
[03:39:48] <SteveStallings> Would it be reasonable to put most of the magic into HAL but add one command called "deskew" to be issued by EMC2?
[03:39:58] <alex_joni> yes... and this is exactly what I am thinking of
[03:40:07] <alex_joni> right now emc is connected to a hal module
[03:40:14] <alex_joni> with position command, and response
[03:40:19] <alex_joni> right?
[03:40:36] <jmkasunich> right - see fig 3.1 in EMC2_Code_Notes.pdf
[03:40:56] <alex_joni> ok.. now inbetween these to there'll be a homing module
[03:40:56] <Imperator_> not a bad idea Alex because then it is also possible to check if the counting of the incremental impulses is ok. That can be done every time a axis is driving over the home switch. The professionel controllers are doing that
[03:41:07] <alex_joni> with 2 signals to emc
[03:41:15] <alex_joni> emc->hal (DO_HOMING)
[03:41:20] <alex_joni> hal->emc (HOMED)
[03:41:48] <alex_joni> and the hal module takes over driving whatever is connected to his pins until it's homed
[03:41:58] <alex_joni> know what I mean?
[03:42:09] <jmkasunich> results: the GUI would display nothing during homing
[03:42:23] <alex_joni> well the HAL module can update the position
[03:42:31] <alex_joni> so the GUI will display it
[03:42:42] <jmkasunich> if the feedback changes but not the command from emc, then emc will trip on ferror
[03:42:46] <alex_joni> emc will probably need tweaking to not go into e-stop
[03:42:53] <alex_joni> exactly
[03:43:36] <jmkasunich> the ferror could be meters during homing, unless emc is generating the commands
[03:43:46] <SteveStallings> My idea with the "deskew" command is that EMC2 would still be in charge of all homing moves, HAL would "fake" signals so EMC sees only one set, and a "deskew" move would give HAL permission to turn one motor (not two) to allow sync of encoders.
[03:44:06] <jmkasunich> SteveStallings: that's kind of what I was thinking
[03:44:13] <jmkasunich> there are two parts to it, one easy, one hard
[03:44:30] <jmkasunich> easy: provide an offset parameter that moves one motor relative to the other
[03:44:49] <jmkasunich> hard: measure the offset (using index pulses or switches) so you know how to set the parameter
[03:45:17] <jmkasunich> IMHO, the very first measurement of the offset will be made using a precision square and dial indicators
[03:45:32] <les> but the easy one would twist the gantry , no?
[03:45:53] <SteveStallings> I was hoping for no parameters, just make sure the deskew move is long enough. HAL would move only one motor until skew was absorbed, then move both until move completes.
[03:45:56] <jmkasunich> if you told it to apply 0.1" of offset, yet
[03:45:58] <jmkasunich> yes
[03:46:27] <jmkasunich> but suppose your dial indicators and precision square tell you there is 0.0013" of skew
[03:46:30] <alex_joni> you could use that one dinamically
[03:46:38] <jmkasunich> then move one motor by 0.0013" and you are good
[03:46:53] <Imperator_> there must also be a parameter what is the normal difference between the axis. That difference must be mesured onece with dial indicators or something
[03:46:55] <alex_joni> let's say you know you have a side that's more heavy
[03:46:58] <les> electronic version of my cam and follower on one screw?
[03:47:25] <jmkasunich> les: let's not go there yet ;-) (but yes, that offset could be made a function of X)
[03:47:34] <les> right
[03:47:39] <jmkasunich> right now we're only talking about it at the home position
[03:48:09] <jmkasunich> Imperator_: yes - you measure one time to get the baseline offset
[03:48:27] <Imperator_> ok
[03:48:44] <alex_joni> did paul return?
[03:48:54] <jmkasunich> so the trick becomes to measure the current offset, then correct it to make it whatever it should be
[03:48:55] <les> It seems complicated in that the system has to stay reasonably synced when shut down and starting up
[03:49:22] <alex_joni> les: that's why I suggested abs-encoders
[03:49:26] <SteveStallings> Looking at figure 3.2 perhaps we do not need a separate "deskew" command because the move at latch velocity command could be assumed to be a "deskew" move.
[03:49:50] <jmkasunich> _either_ it must stay synced (not move when powered off) _or_ it must be able to measure the skew to correct for it
[03:50:23] <jmkasunich> the first is easy for the software, but very demanding on the hardware
[03:50:43] <les> My machine must be kept tightly synced on or off
[03:50:56] <jmkasunich> your machine is synced by the gears
[03:51:00] <Imperator_> i think the only trick is the implementation of the homing sequence. After homing you can calculate eaily the skew and correct it
[03:51:28] <jmkasunich> but are you saying that the gantry itself is flexible in the skew axis, and depends on the screws to keep the sides synced?
[03:52:31] <les> no, I am just saying that even a tiny loss of sync makes huge racking forces that could damage the bearings
[03:52:58] <jmkasunich> so in other words it is very stiff in the skew axis
[03:53:30] <les> yes...but not stiff enough to drive with one screw!
[03:53:46] <jmkasunich> right
[03:53:56] <Imperator_> but that is not a problem of the controller
[03:54:03] <les> correct
[03:54:05] <jmkasunich> but assuming two motors instead of your gearing and jackshaft,
[03:54:36] <jmkasunich> when powered down, it would be hard to get your machine out of sync, for the simple reason that is it quite stiff, correct?
[03:55:07] <les> right...unless a motor did something funny
[03:55:09] <jmkasunich> if you turned one motor manually, the gantry would backdrive the other motor
[03:55:22] <les> 10kN of force there...
[03:56:03] <Imperator_> the screw is a big gear, you can't backdrive it so easy
[03:56:17] <jmkasunich> but if both motors are at zero amps when you power up the encoders and encoder counter hardware, you can be pretty confident that that skew (and skew loads) are small
[03:56:22] <les> 30 kN*M of possible racking moment
[03:57:11] <les> I hold it to 0.0005" measured
[03:57:52] <jmkasunich> you mean with the jackshaft, and the error correction cam?
[03:58:16] <les> sounds almost like two absolute stops in known places that the gantry parked at would be in order
[03:58:28] <les> jmk: yes as measured
[03:58:36] <les> @25c
[03:58:50] <jmkasunich> ok - but we're not talking about your existing system with jackshafts - we're assuming two motors
[03:59:16] <Imperator_> jep !!!
[03:59:20] <jmkasunich> so if you had two motors, and they were powered down, and somebody came and pushed the gantry such that both motors were backdriven by the ballscrews.....
[03:59:31] <les> drive both sides slowly into hard stops, then sync counters?
[03:59:43] <jmkasunich> you're getting ahead of me
[03:59:58] <jmkasunich> besides, index pulses are as good as hard stops (or better)
[04:00:21] <les> yes
[04:00:24] <jmkasunich> back to my hypothetical situation:
[04:00:57] <jmkasunich> I come along while your machine is powered off, and I push on one side of the gantry, hard enough to move it, both motors turn
[04:01:26] <jmkasunich> there will probably be some skew (0.0002-5) just because I pushed off center
[04:01:52] <jmkasunich> now you power up your counters, and begin running both motors together, count by count
[04:01:55] <les> yes..it backdrives...skew is more
[04:02:46] <jmkasunich> is that skew that I introduced by pushing on the gantry enough to generate damaging forces?
[04:03:23] <jmkasunich> or could you just run both motors together until both hit index pulses and then correct the skew?
[04:03:24] <les> would prob be ok on my machine...but in general many would not backdrive...right?
[04:03:51] <jmkasunich> well if they don't backdrive, then there is no prob - neither motor moves, and it's as if you never turned it off
[04:04:21] <jmkasunich> of course if you turn one screw, and the other can't backdrive, then you could possibly put some serious skew into the machine
[04:04:40] <les> beginning to think index marks must be mechanically synced during the initial machine setup and calibration
[04:04:54] <jmkasunich> not really mechanically
[04:05:19] <jmkasunich> the sw could remember that index 1 is 236 counts away from index 2 when the machine is square
[04:05:30] <Imperator_> jep
[04:05:35] <les> yes
[04:06:24] <jmkasunich> you would square the machine by moving one motor and checking with squares and indicators, then tell it to remember the offset
[04:06:38] <les> ok...
[04:07:05] <jmkasunich> then on a later home it would measure the offset between the two index pulses, compare that to the remembered value, and correct if needed
[04:07:18] <Imperator_> with a gantry machine the user needs some extra care. The controller can't know that a force has brought the gantry axis completly out of sync
[04:08:53] <Imperator_> ok so in conclusion i try to write a HAL module
[04:08:57] <les> I have had couplers slip...but if they don't the calibration need only be done one time
[04:09:25] <Imperator_> or what is your conclusion John ?
[04:10:01] <jmkasunich> Imperator_: the module should get both home switches, (or both index pulses), and only tell emc that the switch has tripped when _both_ have tripped
[04:10:20] <jmkasunich> at the same time, it measures the difference between when the first one trips and the second one trips
[04:10:49] <jmkasunich> that difference is the current offset, it should be compared to the remembered offset (HAL parameter)
[04:11:28] <jmkasunich> if they are different, the command to the slave axis is adjusted to correct the error
[04:11:57] <Imperator_> ok
[04:11:58] <Imperator_> then both switches have to be mechanicaly close together not at both ends of the machine
[04:12:29] <Imperator_> maybe we need then a new command to allow deskewing
[04:12:48] <Imperator_> and a new command to tell the GUI the difference
[04:12:56] <Imperator_> maybe
[04:13:04] <les> will this work if say a coupler slips on one side due to a crash?
[04:13:25] <jmkasunich> if something slips, you'll have to get out the indicators and square again
[04:13:53] <les> because the remembered offset would no longer be valid?
[04:14:21] <Imperator_> ok i will try to do that
[04:14:43] <jmkasunich> right - just like a single screw machine's home position would change if the coupler slips (I'm assuming you are talking about index pulse based systems - if it was switch based, then a slipped coupler wouldn't matter)
[04:14:55] <les> right
[04:15:29] <Imperator_> but anyway the idea of Alex to put the homing code in a HAL module has some advantages
[04:15:55] <Imperator_> even at normal machines
[04:15:58] <les> I am just wondering if an automatic offset correction might be a problem with a slipped component
[04:15:59] <alex_joni> but you got to make sure the overhead to implement it is not too big
[04:16:08] <Imperator_> jep
[04:16:18] <les> prompt if offset has changed?
[04:16:20] <alex_joni> les: depends on your offser reading
[04:16:31] <alex_joni> e.g. offset checking
[04:16:36] <les> yes
[04:16:42] <Imperator_> or maybe we put the homing code in a extra file
[04:16:43] <alex_joni> you would need to have a max_offset
[04:17:03] <alex_joni> kinda like a offset_ferror
[04:17:09] <Imperator_> jep
[04:17:10] <les> yes
[04:17:21] <alex_joni> if it's too big you need to e-stop
[04:17:28] <alex_joni> maybe adjust one PID
[04:17:34] <alex_joni> or whatever
[04:17:48] <Imperator_> yes, have you sean the manual of the siemens controller ??
[04:18:03] <les> and the max ferror DIFFERENCE in normal running
[04:18:42] <jmkasunich> assuming a crash while you were running, and the coupler slipped then, the amps would already be trying to drive the machine into a skew condition (and would probably ferror out)
[04:19:19] <jmkasunich> cycling power would make the system forget the old positions, so when it comes back up, the amps would now be happy, and you could move it home
[04:19:32] <jmkasunich> but when you get home, you'll measure an offset that is not what it should be
[04:19:53] <jmkasunich> I agree that maybe you _don't_ want to automatically force it back to the expected value
[04:20:01] <les> right
[04:20:34] <SteveStallings> JMK - sent some ideas by e-mail, too long for one IRC string
[04:20:40] <jmkasunich> there are actually two steps here, that can be implemented independently in the HAL module
[04:21:24] <alex_joni> * alex_joni sound out that CVS merging is pretty tough
[04:21:29] <alex_joni> * alex_joni found out that CVS merging is pretty tough
[04:21:33] <jmkasunich> 1) only tell EMC that you have hit the switch or index when you have hit _both_, and measure the offset between them, store that value in a HAL param like "measured_offset"
[04:22:07] <les> ok
[04:22:17] <jmkasunich> 2) apply an offset to the command sent to the slave, derived from another HAL parameter, like "command_offset"
[04:22:19] <alex_joni> about 1) can't the module try to reduce the offset?
[04:23:09] <jmkasunich> measureing it is always safe, modifying it may not be if something has slipped
[04:23:18] <alex_joni> or will that automatically be done when emc sets command_offset...
[04:23:18] <les> right
[04:23:38] <les> software does not know what is square and what is not
[04:23:53] <Imperator_> there will be another parameter that tells the module the max offset it corrects automaticaly
[04:24:33] <alex_joni> actually .... no
[04:24:38] <alex_joni> I think of it this way:
[04:24:55] <alex_joni> 1. during home the hal module reports measured_offser
[04:25:19] <alex_joni> (even in other conditions.. let's say everytime it gets index pulses)
[04:26:06] <alex_joni> emc checks measured_offset against a max. value (after substracting the default value, fixed during set-up)
[04:26:35] <alex_joni> if it's greater it e-stops
[04:26:43] <alex_joni> and the user has to decide what to do
[04:26:56] <les> sounds reasonable
[04:27:13] <jmkasunich> so you are proposing that EMC proper _does_ know that this is a dual axis
[04:27:35] <alex_joni> someone needs to watch the max offset
[04:27:49] <alex_joni> and remember the default offset (probably from emc.ini)
[04:28:03] <jmkasunich> well the default could be a HAL parameter
[04:28:30] <jmkasunich> this is a major conceptual issue that we need to decide on - should or should not EMC itself be aware of dual axis?
[04:28:48] <Imperator_> thats the point
[04:28:53] <jmkasunich> if yes, that implies changes througout - all the way from motion controller up to the GUI
[04:29:04] <alex_joni> are there reasons to treat it differently?
[04:29:11] <jmkasunich> but perhaps it can be handled better that way
[04:29:31] <jmkasunich> if not, then all dual-axis stuff is hidden in the HAL, and there is much less widespread work to be done
[04:29:35] <Imperator_> i think that dual axis are a very importend thing. Look at the machines all the guys are building that are mostly dual axis configurations
[04:29:42] <SteveStallings> I think it is best that EMC does not know. We do we stop changing EMC as new special drive issues come up? Wasn't this simplification the original purpose of HAL?
[04:29:46] <Imperator_> but driven by one motor
[04:29:54] <les> very important for us yes
[04:30:00] <jmkasunich> but perhaps it doesn't work as well because there's no way for the HAL to tell the user "hey, my offset is too big"
[04:31:12] <jmkasunich> SteveStallings: perhaps dual axis is one of those things that is at a higher level and _should_ be handled within emc
[04:31:19] <les> I think to be robust a dual has to monitor that stuff
[04:31:38] <jmkasunich> I don't know - my initial thought were very strongly toward handling it entirely within the HAL, but now....
[04:31:40] <alex_joni> jmk: what if the hal module sees the offset is too big and stops moving?
[04:31:54] <Imperator_> other question : is EMC2 still able to drive hexapods ?? Because there are not so many special configurations. One is dual axis and then the hexapods
[04:32:30] <SteveStallings> Could dual XX be treated as a special case of kinematics?
[04:32:42] <jmkasunich> emc2 currently doesn't have the hexapod kins, but so far that is done exactly like emc1, and we should just be able to copy hexapod kins over from emc1
[04:33:00] <Imperator_> is a hexapod only a change in kinematic or has the homing sequence also to be changed
[04:33:15] <alex_joni> afaik only kins
[04:33:23] <alex_joni> you still define all axes
[04:33:26] <jmkasunich> SteveStallings: nope - because kins takes place above the joint controllers - there is no way to force both axes to be homed in sync (or jogged, or any other free mode stuff)
[04:34:02] <Imperator_> jep dual axis have nothing to do with kins
[04:34:20] <jmkasunich> in a hexapod, all axis can be homed (or jogged) independently, the hexapod kins are to the left of figure 3.1, while the HAL stuff is to the right
[04:34:41] <SteveStallings> So how does an overly constrained mechanical system in a hexapod manage to home the struts?
[04:34:44] <Imperator_> are you shure John ??
[04:35:11] <jmkasunich> homing in hexapods is "yucky", to use a technical term
[04:35:13] <jmkasunich> '-)
[04:35:26] <les> staying away from poles...
[04:35:33] <Imperator_> what happens if all axis of a hexapod are at lowest position is it then possible to move one axis to the home swich that my be on the top position ?
[04:35:54] <jmkasunich> I had an exchange with Fred about it some months back - he basiclly said they used a lot of ad-hoc tricks to do it - automatic homing doesn't really work
[04:36:09] <Imperator_> ok
[04:36:34] <Imperator_> so you have not to switch of a hexapod at any position
[04:36:44] <SteveStallings> So back to our special case XX homing...
[04:39:01] <jmkasunich> first and most important question - does EMC know about dual axis or not?
[04:39:11] <jmkasunich> lets list pros and cons
[04:39:49] <alex_joni> pro: provide the user with custom messages when the offset is too big
[04:40:07] <Imperator_> con: lot of work but i hope i can do that
[04:40:26] <Imperator_> pro: clean impementation
[04:40:27] <alex_joni> con: it will modify emc, make it a lot more complicated
[04:40:28] <jmkasunich> pro: there could be a special version of figure 3.1 that understands dual axis and handles everything
[04:40:42] <les> pro: I don't have to spend thousands on mechanical solutions
[04:40:50] <Imperator_> :-)
[04:41:11] <jmkasunich> les: irrelevant - we are talking about _how_ to implement dual axis, not whether to do it
[04:41:20] <les> ok
[04:41:22] <jmkasunich> both ways will save you the mechanics
[04:41:53] <alex_joni> hmmm... you could spend thousands on software solutions... I wouldn't mind ;)
[04:41:54] <Imperator_> pro: maybe it is easyer for users because handling of all that HAL modules is also not that easy
[04:41:58] <jmkasunich> con: (the big one for me) the changes will ripple up thru emc from the motion controller to the config and the user space stuff, including the GUI
[04:42:28] <jmkasunich> it's starting to sound like makeing EMC aware of dual axis is better, but harder
[04:42:50] <Imperator_> jep think also so John
[04:42:56] <alex_joni> simple question: does the user have to know when offset is too big? or an e-stop is enough?
[04:43:21] <Imperator_> estop with a good message why is best
[04:43:23] <jmkasunich> an unexplained e-stop leads to users asking questions on the list
[04:43:28] <les> some descriptive message would be good
[04:44:01] <alex_joni> well...in that case emc has to be aware
[04:44:05] <jmkasunich> I _HATE_ faults/errors that don't give accurate messages
[04:44:31] <alex_joni> some changes have to be made to emc
[04:44:41] <alex_joni> and if those are made... why not go the best way
[04:44:42] <SteveStallings> What about a way for a HAL module to pass a string on errors?
[04:45:07] <jmkasunich> HAL modules can write to the kernel log - that's it
[04:45:46] <les> it must fault out on anything from sliped mechanicals to shorted amps, locked computers, anything that would cause damaging racking
[04:45:46] <alex_joni> how about a NML-aware HAL module?
[04:46:02] <jmkasunich> no, no, a thousand times no!!!
[04:46:22] <alex_joni> * alex_joni thinks jmk doesn't like NML...
[04:46:40] <jmkasunich> hal is all about simple components, like electronic parts interconnected on a PC board
[04:47:08] <jmkasunich> opamps and 7166 chips don't print error messages
[04:47:38] <SteveStallings> Old thinking, our black boxes are getting smarter.
[04:47:39] <alex_joni> well.. there are some counter chips that do...
[04:47:40] <jmkasunich> if something doesn't lend itself to that model, then it shouldn't be implemented as a HAL module
[04:47:51] <alex_joni> anyways...
[04:47:56] <alex_joni> we're drifting
[04:48:13] <jmkasunich> just want to make the point:
[04:48:36] <jmkasunich> a HAL based system should be describable by a drawing showing the modules and their interconnections
[04:48:45] <jmkasunich> no extra hidden stuff like NML messages
[04:48:54] <alex_joni> or other messages
[04:48:57] <jmkasunich> the block diagram _is_ the system
[04:49:22] <alex_joni> well then.. guess EMC has to decide that the offset is to big, and it has to shout that to the user
[04:49:26] <jmkasunich> right - although HAL modules can write to the kernel log, no existing module does so from the realtime code - only from the init code, in the event of an error
[04:49:47] <alex_joni> that's more development debug than runtime debug
[04:49:55] <jmkasunich> right
[04:50:13] <jmkasunich> what we need now is a dual axis version of figure 3.1 from ECM2_Code_Notes
[04:50:17] <alex_joni> don't expect the user to check /var/log/messages to see why his machine went into e-stop
[04:50:20] <SteveStallings> Forcing all error responses into codes that we have thought of in advance is still a problem. New systems will always require new solutions. String reporting can enhance usefulness.
[04:51:06] <jmkasunich> HAL modules should not generate runtime errors - period
[04:51:25] <alex_joni> how about a servo as an example of a module?
[04:51:34] <jmkasunich> op-amps don't generate errors - if the input is out of range, they clamp
[04:51:35] <alex_joni> some servos have serial commands & reporting
[04:51:51] <alex_joni> and they might say ... motor winding problems
[04:52:03] <alex_joni> more usefull than error
[04:52:46] <SteveStallings> Agree that EMC must still "poll" for errors, just want more information.
[04:53:15] <jmkasunich> recall that HAL modules are all executing periodically
[04:53:35] <jmkasunich> are you gonna generate the error message 1000 times a second?
[04:54:32] <SteveStallings> ... gonna have to think about that...
[04:55:37] <Imperator_> maybe in that case we need something like syslog im EMC where modules can send messages
[04:55:45] <jmkasunich> I think of HAL as a sampled system, with signals flowing from block to block... if a signal goes out of range (or some other error condition happens), then output of the block does something logical for as long as the condition persists. When the error condition goes away, the output of the block goes back to normal
[04:56:31] <jmkasunich> faults are not latched, and the blocks are unaware of the state of other blocks - all they know is their inputs, all the affect is their outputs
[04:58:05] <jmkasunich> that's not to say that a block can't have a "fault" output and a "fault reset" input, if you truly want to latch some kind of fault, but that should be rare
[04:58:21] <SteveStallings> Could there be a HAL error reporting device that would latch the output of modules that it was connected to, and then the error reporting device could be polled at a much slower rate?
[04:59:01] <jmkasunich> I'm not convinced that HAL modules should have "errors" that need reporting
[05:00:29] <jmkasunich> if you ask freqmod to generate a step rate that is too high, it doesn't generate an error, it just makes the fastest pulses it can
[05:02:37] <SteveStallings> True, EMC should be the thing deciding if it is an error. But I still see a need to get around having to change the EMC code to report every possible signal for the HAL system. I would prefer that EMC be allowed to sense a signal that indicates a fault and then be able to fetch a string from the HAL environment rather than have to code the string into EMC.
[05:02:40] <Imperator_> i think there are some, for example the encoder counters of professional controllers are reporting that the linear encoder is polluted
[05:03:39] <les> detecting impossible motions?
[05:04:09] <jmkasunich> We definitely aren't looking at HAL the same way
[05:04:50] <SteveStallings> Granted, I'm not playing fair. My expectations are probably getting ahead of what is reasonable.
[05:04:57] <jmkasunich> IMHO, if you can't describe the operation of something pretty darn completely using a block diagram (like those in HAL_Introduction.pdf), then it is NOT a good candidate for a HAL module
[05:05:33] <alex_joni> maybe the things steve wants from HAL could be done in EMC
[05:05:42] <alex_joni> make EMC modular too.. to some extent
[05:05:56] <alex_joni> at least error-checking and reporting & such
[05:07:08] <Imperator_> maybe yes Alex. But the idears of Steve are imortand also
[05:07:13] <jmkasunich> I agree completely that EMC's error reporting could be improved
[05:08:26] <alex_joni> I think HAL is ok the way it is now...
[05:08:35] <alex_joni> a HARDWARE abstraction layer
[05:08:44] <alex_joni> and we could keep it that way
[05:08:47] <Imperator_> there is a lot. I don't think that we have to do that now, but we have to think what we maybe need in some years. Because that we not make chances that will make things impossible in some years
[05:09:47] <Imperator_> I also think HAL is a very good thing.
[05:10:16] <Imperator_> We don't have to kill it by implementing things that don't have to be there
[05:10:45] <les> jmk: is the HAL GPL?
[05:10:49] <jmkasunich> yes
[05:11:01] <les> ok
[05:11:43] <Imperator_> ok back to dual axis:
[05:11:46] <jmkasunich> some key parts of it are LGPL, the intent is to allow non-GPL modules to be written and used in a system with GPL modules
[05:11:53] <Imperator_> how do i have to do it
[05:12:17] <les> jmk: very good
[05:14:14] <jmkasunich> Imperator_: two choices: do it in EMC (control.c to be precise) or do it in HAL
[05:15:11] <jmkasunich> to do it in EMC, take fig 3.1 from EMC2_Code_Notes, and draw a new one that supports dual axis
[05:15:28] <jmkasunich> then figure out how to tell the motion controller at insmod time which axis are dual
[05:15:38] <jmkasunich> (so they can export the extra HAL pins)
[05:16:01] <Imperator_> ok i will check that and i hope to make a precise suggestion next week
[05:16:08] <jmkasunich> and add new fields to the EMC shmem structs (emcmot_Status, etc) to handle things like offset limits, etc
[05:16:15] <jmkasunich> add new NML messages to set those fields
[05:16:27] <Imperator_> how are you drawing that pictures John
[05:16:27] <jmkasunich> add new GUI code to display important stuff
[05:16:30] <jmkasunich> etc, etc, etc
[05:16:37] <jmkasunich> I used something called EasyCad
[05:16:39] <Imperator_> where did i find that NML stuff ?
[05:16:46] <jmkasunich> (similar to AutoCad)
[05:16:51] <Imperator_> ok
[05:17:00] <jmkasunich> don't know anything (much) about NML
[05:17:09] <Imperator_> :-)
[05:17:36] <jmkasunich> to put it simply - I personally _cannot_ implement dual axis the "EMC" way
[05:18:08] <jmkasunich> I could do it in a HAL module, but it would lack some of the features that we have discussed today, like limits on the amount of adjustment
[05:18:24] <alex_joni> jmk: good news...
[05:18:37] <jmkasunich> If it was done the EMC way, probably 20 files would need to be touched
[05:18:47] <jmkasunich> the HAL way, 1 (probably)
[05:19:11] <Imperator_> nice :-)
[05:19:16] <jmkasunich> but the HAL way would have some limitations
[05:19:17] <alex_joni> configure.in and Makefile.inc.in need to be added to trunk, and ./configure needs to be modified
[05:19:26] <Imperator_> enough work for the winter
[05:19:28] <jmkasunich> so we have to decide what is more important - simplicity or features
[05:19:38] <alex_joni> that's all that's needed to get autoconf stuff working
[05:20:07] <jmkasunich> so you are describing something of a "manual merge"?
[05:20:27] <les> as a machine builder my opinion is that it must have the limits-where ever they come from
[05:20:58] <alex_joni> no... I just did a manual test to see what needs to be merged
[05:21:06] <alex_joni> there are more ways of merging
[05:21:27] <alex_joni> complete merging (whole branch)- don't want that because of other stuff (make install & such)
[05:21:44] <alex_joni> single merging (only some files9
[05:23:17] <jmkasunich> whatever works, I guess
[05:23:36] <jmkasunich> at this point, I have so little time to work on EMC, I don't know whether I'm coming or going
[05:23:49] <jmkasunich> I just hope we can avoid even more branches to keep track of
[05:24:42] <jmkasunich> I'd like to see older branches either officially abandoned, or merged back into the trunk, and _then_ make new branches for further work
[05:25:06] <jmkasunich> just my personal opinion, as someone who can barely keep up
[05:25:08] <alex_joni> ok
[05:25:27] <alex_joni> well right now I see following branches:
[05:26:44] <alex_joni> pc_2_6_test
[05:26:44] <alex_joni> lathe_fork
[05:26:45] <alex_joni> jmk
[05:26:54] <alex_joni> ioctl_branching
[05:27:14] <alex_joni> HAL_no_logging
[05:27:23] <alex_joni> autoconf_install_0_1
[05:27:30] <alex_joni> auto_configure_0_1
[05:27:54] <alex_joni> auto_configure_0_2 (this one was created by mistake... don't know how to delete it)
[05:28:03] <alex_joni> these are for EMC2
[05:28:03] <jmkasunich> jmk is dead - I don't even remember what that was
[05:28:08] <jmkasunich> lathefork is active
[05:28:33] <jmkasunich> ioctl is dead, I think
[05:29:04] <jmkasunich> not sure what is in HAL_no_logging
[05:30:14] <alex_joni> you did say some time ago you'll contact sf guys to remove some unused studd
[05:30:16] <alex_joni> stuff
[05:30:27] <alex_joni> or is my memory playing tricks on me?
[05:31:08] <jmkasunich> that was unused top level modules (like emc, rcslib, emc2, etc)
[05:31:26] <jmkasunich> I don't think old branches ever really go away, they just sit there
[05:31:34] <alex_joni> yeah I know... but those are still there
[05:31:56] <jmkasunich> * jmkasunich looks
[05:32:25] <alex_joni> I used the CVS repository browser on SF
[05:32:47] <jmkasunich> emc, rcslib, emc2, and documents, are the four "active" top level modules
[05:33:09] <jmkasunich> emc_HAL and emc2-auto should have been removed - let me check a few things
[05:37:16] <jmkasunich> strange: Paul requested that they do it over a month ago, and they replied that they did:
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1046949&group_id=1
[05:40:22] <Imperator_> Alex you are talking about branches what's that exactly ???
[05:40:50] <Imperator_> don't know anything about that
[05:41:02] <jmkasunich> CVS branches
[05:41:08] <alex_joni> Imperator_: the whole code is in CVS
[05:41:43] <alex_joni> if anyone wants to develop something that could be needed when it's done (e.g. 2.6 kernel support)
[05:41:53] <alex_joni> it is usefull to create a branch
[05:42:10] <Imperator_> how can i do that ?
[05:42:11] <alex_joni> a way to develop in a separate dir
[05:42:25] <Imperator_> because that is maybe good for the dual axis stuff
[05:42:32] <alex_joni> and when it's done you can merge the changes back to the HEAD (or trunk)
[05:42:41] <alex_joni> well... you should read the CVS book ;)
[05:42:52] <Imperator_> oh, the big one
[05:43:07] <alex_joni> but to keep it simple:
[05:43:16] <Imperator_> but that has nothing to do with real folders in the CVS
[05:43:29] <Imperator_> jep say me the command
[05:43:44] <alex_joni> step 1. tag the branch (cvs tag -b new_branch_name)
[05:44:51] <alex_joni> step 2. check out the branch (cvs checkout -r new_branch_name) to another dir
[05:45:04] <alex_joni> step 3. modify the source in the new dir and commit
[05:45:25] <alex_joni> step 4. merge changes back to main branch (that's more complicated than a single command)
[05:45:56] <alex_joni> but.. you need to ask around before doing things like this ;)
[05:46:05] <Imperator_> ok i will do that with the dual axis code
[05:46:20] <alex_joni> I'd ask paul_c first, or any other board-member
[05:46:52] <alex_joni> read:
https://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_5.html#SEC54
[05:47:15] <jmkasunich> if you are taking the "change EMC", by all means do it in a branch (wouldn't hurt to ask Paul too)
[05:48:08] <Imperator_> branches can easyly removed if they are bad
[05:48:15] <Imperator_> ???
[05:48:38] <alex_joni> not really...
[05:48:43] <alex_joni> with support from SF
[05:49:43] <Imperator_> but if they are not merged they don't hurt anybody
[05:50:23] <alex_joni> nope
[05:50:34] <alex_joni> they don't
[05:50:38] <Imperator_> ok
[05:51:07] <Imperator_> I'm happy to have some absolute encoders, because they get expensive at ebay
[05:51:09] <Imperator_> http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&rd=1&item=3852431815
[05:51:24] <Imperator_> 401 EUR was my price
[05:52:01] <les> can get expensive...I design them
[05:52:25] <Imperator_> les: ??
[05:52:34] <les> encoders
[05:53:33] <alex_joni> don't think 100 EUR/piece is expensive
[05:54:16] <Imperator_> i have four of them here but the one with the smal profile, i get them for 50 EUR :-)
[05:54:21] <alex_joni> nice
[05:54:31] <les> no you got a great deal
[05:54:37] <Imperator_> i know they cost over 1000EUR new
[05:54:38] <les> how many bits?
[05:55:07] <Imperator_> that depends on the lenght
[05:55:24] <Imperator_> they have a resolution of 0,1 microm
[05:55:38] <les> what is the smallest distance increment
[05:55:44] <les> haha ok
[05:56:33] <les> and they are absolute, with no homing requiered?
[05:56:53] <les> required
[05:57:16] <Imperator_> you get the serial signals and the incremental analog signals. The analog signals have a increment of 0,02 mm and my Heidenhain card can devide the analog signals by 4096
[05:57:21] <alex_joni> jmk: I just found out that ViewCVS is from the backup CVS server
[05:57:25] <Imperator_> jep les
[05:57:45] <jmkasunich> yeah, but that should only lag behind a max of 24 hours, not 30 days
[05:57:55] <les> hmm 20 bits if 1 meter
[05:57:55] <alex_joni> long hours?
[05:58:43] <les> sorry 24
[05:59:58] <Imperator_> floh: are you the one who is fighting with the Siemens card
[06:01:02] <FloH> yes
[06:02:30] <Imperator_> les: that encoders are vry nice. They have a plastic sheed on it to fix the reading head. So you can move the head only with some force. But if you lay them down on your desk and stamp on the floor you can see the values counting
[06:02:46] <Imperator_> floh: is it working now
[06:03:25] <alex_joni> * alex_joni tried a checkout on emc2-auto and it's still there
[06:03:40] <les> will get pretty high data rates moving at speed
[06:03:53] <alex_joni> who was taking care of the IRC-logs on linuxcnc.org ?
[06:03:56] <Imperator_> jep
[06:04:38] <Imperator_> you get only the position when you ask the encoder
[06:04:46] <FloH> today I installed EMC2, but I always get an errror: motion.c:173: warning: implicit declaration of function `vsnprintf'. Then I commented out this line in motion.c and now its working on my BDI 2.18. Tomorrow I will see more
[06:05:41] <Imperator_> hm i had this error also that is a overflow of the driver, but i think that was solved
[06:05:47] <les> Imperator:serial?
[06:05:53] <Imperator_> jep les
[06:06:06] <Imperator_> oh sorry that was an other error floh
[06:06:57] <alex_joni> vsnprintf should be defined in stdarg.h
[06:07:06] <Imperator_> or there is a other mode then it sends as fast as it can position information independend of the speed
[06:07:20] <alex_joni> btw, warning: is not really an error ;)
[06:09:07] <FloH> it was an error, because i couldnt start emc.run (motion.o defect) or so
[06:09:27] <les> I see...a far cry from the automotive gray code stuff I did
[06:09:56] <alex_joni> gray code is cool.. hard to read thou...
[06:09:58] <jmkasunich> alex_joni: re the IRC logs, that was me
[06:10:18] <alex_joni> need a hand?
[06:10:47] <alex_joni> they seem to be stuck around 26 sept.
[06:10:49] <jmkasunich> yes!
[06:11:08] <jmkasunich> I have logs for each week since then (except today - forgot to start logger)
[06:11:09] <Imperator_> floh: here it runs fine. I have compiled a fresh cvs copy half an hour before
[06:11:27] <alex_joni> I do have for the last month
[06:11:35] <alex_joni> logger_aj, bookmark
[06:11:35] <alex_joni> See
http://193.226.12.129/irc/irc.freenode.net:6667/emc/2004-11-22#T06-11-35
[06:11:45] <jmkasunich> but they need edited (removal of email addys and other confidential info at a minimum - I also removed chitter-chatter that was irrelevant, and misc junk from the IRC servers
[06:11:53] <alex_joni> but timezone is somehow stupid... ;)
[06:12:05] <alex_joni> can you send me some logs to filter out?
[06:12:10] <jmkasunich> sure
[06:12:23] <Imperator_> * Imperator_ is prepaing something to eat
[06:12:31] <alex_joni> * alex_joni awaits e-mail
[06:12:37] <jmkasunich> do you have an account on LinuxCNC.org?
[06:12:42] <alex_joni> nope
[06:12:43] <Imperator_> Imperator_ is now known as Imperator_away
[06:12:45] <SteveStallings> Does alex_joni want an account?
[06:12:58] <jmkasunich> need it to post the IRC logs
[06:13:19] <Imperator_away> floh: here it runs fine. I have compiled a fresh cvs copy half an hour before
[06:14:22] <FloH2> good, I'll download the actual cvs version
[06:15:02] <alex_joni> floh: what version were you using?
[06:16:57] <FloH2> I downoaded it 2-3 weeks ago
[06:19:08] <jmkasunich> alex_joni: october logs on the way
[06:21:02] <CIA-9> 03jmkasunich * 10emc2/src/hal/ (hal_lib.c hal_priv.h utils/halcmd.c): added some pointer range checks as recommended by Paul Fox. Thanks Paul.
[06:21:38] <alex_joni> jmk: I'll modify them
[06:23:17] <jmkasunich> while you're editing, jot down the subjects that were discussed - then you can add them to the brief synopsis in the table
[06:24:30] <jmkasunich> (just FTP linuxcnc.org/EMC_news_history/IRC-logs/index.html, copy the top <tr>....</tr> block, and edit it)
[06:24:47] <jmkasunich> then FTP index.html and the new logs back to linuxcnc.org
[06:25:26] <jmkasunich> and lest I forget - THANK YOU! (I've been feeling very guilty because I've fallen behind)
[06:30:51] <alex_joni> don't mention it ;)
[06:31:13] <alex_joni> but I'm still waiting on the logs
[06:32:20] <jmkasunich> hmmmm... that makes two messages that seem to be hung (I posted to the users list a few minutes ago, and that hasn't appeared either)
[06:32:52] <SteveStallings> John, did you get the two e-mail that I sent?
[06:32:55] <jmkasunich> maybe my ISP is being slow... give it some time (maybe an hour) and then mail me if it still isn't there
[06:33:05] <jmkasunich> SteveStallings: yes, got them
[06:33:23] <jmkasunich> incoming mail seems to be OK (I got Paul's recent post to emcusers, and my own commit message)
[06:34:58] <jmkasunich> I'm gonna go away for a while - I have some parts I need to mill for a paying customer
[06:40:18] <alex_joni> jmk: got the mail
[06:43:40] <les> we are blasting away with emc paying work...but not today
[06:46:33] <Imperator_away> Imperator_away is now known as Imperator_
[06:48:06] <les> good dinner?
[06:48:49] <Imperator_> alex_joni: are you next week on that automatisation fair in N�rnberg
[06:49:21] <Imperator_> jep les :-)
[06:51:11] <alex_joni> don't think so Martin
[06:53:10] <Imperator_> ok
[06:53:34] <Imperator_> are you visiting some fairs in germany ?
[06:53:51] <alex_joni> if I happen to be in germany at that time ;)
[06:54:06] <alex_joni> probably I'll go to the welding fair in Essen
[06:54:21] <les> I did not go to the chicago imts this year
[06:54:43] <les> that is our biggest
[06:54:49] <Imperator_> if you are here Alex, how are traveling ?
[06:54:57] <alex_joni> car usually.. why?
[06:55:03] <Imperator_> woodworking les ?
[06:55:20] <les> no machine tools
[06:55:49] <les> the big woodworking fair is IWF
[06:56:12] <les> hundreds of cnc routers running
[06:56:16] <Imperator_> with the car you are driving not so far away from me through south germany i think
[06:57:17] <alex_joni> We represent actually two companies from germany
[06:57:23] <Imperator_> if you are somewhere around here and if you have time we can drink a beer together
[06:57:35] <alex_joni> one is in Markdorf (near Friedrichshafen..) that's nearer to you
[06:57:41] <Imperator_> jep
[06:57:51] <alex_joni> thanks for the invitation... same way around
[06:58:22] <SteveStallings> Time for me to run.... later....
[06:58:39] <Imperator_> don't have some projects with people in rumenia at the moment :-(
[06:59:35] <alex_joni> jmk: still around?
[07:04:49] <alex_joni> guess not...
[07:05:38] <les> I am in and out while doing laundry....
[07:06:06] <les> also fixing that alesis audio amp...it's a bad relay
[07:07:40] <les> it actually works quite well as a test servo amp
[07:10:31] <alex_joni> * alex_joni is tweaking IRC logs
[07:10:59] <les> It will put out 13 amps at 110v...not bad for an audio amp
[07:14:54] <jmkasunich> alex_joni: just came back for a minute... what's up?
[07:19:32] <jmkasunich> * jmkasunich goes away again
[07:23:18] <robin_sz> hmm, thats what, 1500 watt DC?
[07:25:00] <robin_sz> ok, time to reboot into 'doze :(
[07:25:36] <alex_joni> jmk_when_back: I was wondering about timestamps (some irc logs have them some don't)
[07:48:11] <alex_joni> * alex_joni leaves for a while
[09:33:35] <Imperator_> Ok chiao all
[09:33:47] <Imperator_> was a good discussion today
[09:50:05] <alex_joni> anybody still around?
[09:51:00] <alex_joni> well... guess not...
[09:51:06] <alex_joni> * alex_joni is going to sleep...
[09:51:32] <alex_joni> jmk: I added 2004-10-03 to the IRC-logs page. If it's not ok drop me an e-mail...
[09:51:39] <jmkasunich> hi alex
[09:51:43] <alex_joni> I'll start on the others too these days
[09:51:54] <alex_joni> oh.. you're still around
[09:52:05] <jmkasunich> * jmkasunich takes a look
[09:52:12] <alex_joni> was paul around?
[09:52:28] <jmkasunich> I just got back now - then going back out again
[09:53:06] <jmkasunich> looks good to me
[09:53:30] <alex_joni> ok.. I'll modify the rest and put those up there too... when I'll get to it ;)
[09:53:38] <jmkasunich> re: timestamps - your call as to whether to keep them or delete them
[09:53:43] <alex_joni> I hope in a day or two
[09:53:50] <jmkasunich> no hurry
[09:53:57] <alex_joni> well... the first file had no timestamps- that's why I asked
[09:54:00] <jmkasunich> (after all it's been a month already)
[09:54:03] <alex_joni> the previous one had
[09:54:21] <alex_joni> re: month - that's why I wanna hurry ;)
[09:54:34] <jmkasunich> depends on who's logger captured it, mine doesn't stamp, but I got some of those from paul, and his does timestamps
[09:54:54] <alex_joni> the webpage should really give people the impression that things are under active development
[09:54:58] <alex_joni> which is the case
[09:55:13] <jmkasunich> I really appreciate your help on those - when I started them, I didn't realize how my life would get busy
[09:55:31] <jmkasunich> I'm down to one night of emc a week (none this week)
[09:55:34] <alex_joni> when I find a project that hasn't been updated for a year or so... I consider it twice if it's worth
[09:55:57] <alex_joni> well... I'm sure everyone gets to a point when we have other stuff to do...
[09:56:11] <alex_joni> that's why it's better if there are a lot ofpeople in volved
[09:56:20] <jmkasunich> yep
[09:56:41] <alex_joni> anyways.. if you ever need logs... my logger should be around here
[09:56:46] <jmkasunich> ok
[09:57:01] <alex_joni> logger_aj, bookmark
[09:57:01] <alex_joni> See
http://193.226.12.129/irc/irc.freenode.net:6667/emc/2004-11-22#T09-57-01
[09:57:54] <alex_joni> not sure what timezone he thinks he's on ;)
[09:58:06] <alex_joni> well... I'll go catch some sleep
[09:58:07] <alex_joni> bye
[09:58:18] <jmkasunich> time to make more brass chips here
[09:58:21] <jmkasunich> goodnight
[09:58:32] <alex_joni> paul wasn't around, was he?
[09:58:43] <jmkasunich> never saw him
[09:58:52] <jmkasunich> my client stayed on even while I wasn't here
[09:59:04] <alex_joni> ok... I'll bug him this week ;)
[09:59:19] <alex_joni> guess he's kinda tired of me... :-)
[09:59:47] <alex_joni> * alex_joni plans to merge autoconf stuff to the trunk this week
[09:59:53] <jmkasunich> good to hear that
[10:00:05] <alex_joni> but I want paul's opinion first
[10:00:38] <alex_joni> well... g'night
[10:00:41] <jmkasunich> night
[10:00:54] <jmkasunich> * jmkasunich need to get busy
[11:43:39] <asdfqwega> * asdfqwega opens the doors to let the smoke out
[11:44:12] <asdfqwega> That might sound like something bad happened, but it's actually just the opposite
[11:44:34] <asdfqwega> My new laser is hard at work!
[11:45:08] <asdfqwega> Now I just need some damn ventilation...
[11:45:30] <asdfqwega> (use the laser to make holes in the wall? Hmm...)
[11:46:56] <paul_c> Large hammer ?
[11:51:16] <asdfqwega> "When you have a hammer, all the world looks like a nail"...?
[11:51:25] <asdfqwega> Well, I have a LASER :)
[11:53:21] <asdfqwega> Well, dang...it's working great, but I'm freezing my fiddly bits off
[11:53:31] <paul_c> Does it cut through brick ?
[11:54:01] <asdfqwega> Well, this is only 10W...it'd take a LONG time
[11:55:30] <asdfqwega> This is really great...This laser is certified 10W...and it's working like it's 3-4 times what I had with the old laser
[11:56:56] <asdfqwega> That's the last time I buy an old laser off of eBay ;)
[12:01:24] <asdfqwega> Burning the midnight oil, paul_c/
[12:01:26] <asdfqwega> ?
[12:01:56] <paul_c> nope - ready to pack up and go to bed.
[12:03:56] <asdfqwega> Later, then.
[12:28:38] <CIA-9> 03jmelson * 10emc/src/emcmot/Makefile: add rule for ppmc_pwm.c that had been missing
[12:30:12] <CIA-9> 03jmelson * 10emc/src/emcmot/ppmc_internal.c: remove hardware-specific setup for PCI parallel port to EPP mode
[23:41:31] <alex_joni> good morning paul
[23:42:03] <paul_c> Afternoon Alex
[23:42:28] <alex_joni> ;)
[23:42:47] <alex_joni> * alex_joni was waiting for paul_C
[23:42:54] <alex_joni> got 5 mins for me?
[23:43:23] <paul_c> nope
[23:43:36] <paul_c> can give you 10 ;}
[23:44:22] <alex_joni> wow
[23:44:24] <alex_joni> nice ;)
[23:44:31] <alex_joni> ok.. I'll try to be brief
[23:44:52] <alex_joni> 1. I commited stuff on autoconf_install_0_1 (I'm pretty happy with it)
[23:45:07] <alex_joni> hope some day you'll have time to check it out...
[23:45:20] <alex_joni> 2. regarding autoconf merging back to trunk
[23:45:36] <alex_joni> I talked to jmk yesterday who suggested we should do that.
[23:46:00] <alex_joni> 2.1. do you think autoconf is there yet? or does it need more work (if yes, what would that be)
[23:46:23] <paul_c> autoconf or autoconf_install ?
[23:46:24] <alex_joni> 2.2. I think I need some advice from you (still haven't read the Red book :( )
[23:46:27] <alex_joni> autoconf
[23:46:40] <alex_joni> simply the configure.in, ./configure and the Makefile.inc.in
[23:46:47] <alex_joni> no stuff from make install
[23:47:06] <alex_joni> we should keep that in a branch (or two) for now
[23:47:28] <alex_joni> corect me if I'm wrong: when merging there are 2 possibilities
[23:47:42] <alex_joni> poss.1. merge the whole branch (not really ok in this case)
[23:47:49] <alex_joni> poss.2. merge only some files
[23:48:25] <alex_joni> and finally:
[23:48:40] <alex_joni> 3. I'm updating the IRC-Logs page
[23:48:59] <alex_joni> so if anything's not right there... bug me
[23:50:00] <paul_c> just checking autoconf now..
[23:51:56] <paul_c> It is failing on GTK here...
[23:52:32] <alex_joni> do you have GTK?
[23:52:40] <paul_c> and why is the gcc test being run twice ?
[23:53:03] <alex_joni> well... that was zwisk adition
[23:53:23] <alex_joni> it's pretty a circular dependency
[23:53:41] <alex_joni> you can check for the kernel_ver by compiling a program
[23:56:34] <alex_joni> hmmm... you might have a point there
[23:56:45] <paul_c> So move the RT CC test up...
[23:57:05] <alex_joni> yup...
[23:57:08] <alex_joni> I'll do that in a bit
[23:57:52] <alex_joni> I thought from the way zwisk put it that the Kernelver is needed for checking the compiler used
[23:57:55] <alex_joni> but it's not
[23:59:38] <paul_c> localedir is set wrong