Ooo, robin's here! Lessee...it should be 10AM over there... * asdfqwega waves to robin_sz Advice to everyone - don't drink strong stimulants when doing soldering on circuits :) Very SMALL circuits Like trying to thread a needle with a jackhammer * robin_sz waves to asdfqwega meep? yup. paul_c: how is your physics? so if you have a leverm and apply a force, the resultant moment is F x l, right? sounds about right... so ... whats wrong with this then? http://zattevrienden.realroot.be/depanneren.htm a) He didn't have any outriggers down s/down// b) failed to take in to account the wieght of the water... c) he's Irish? (its in connemara ..) I thnk it was OK while he was lifting slightly forward over the cab a little, but as he swung it 90> to the side ... * alex_joni waves hi alex quiet today... hey les... it's pretty early I guess... well it was supposed to be rain today...but warm and sunny so I may vanish soon... golf course is calling... also leaves. nice... well.. have fun this is the first weekend off I have had in a month then take advantage of it ha I have been...just in the office waiting for it to get to 15c outside 12 now heh Also answering questions on yahoo and newsgroups I like to do that when I have time are there any emc-related newsgroups? or just machining ones? Cad_cam_edm_dro is hobby cnc specific and has a lot of emc content ...a yahoo group thousands of members I don't mind doing a little free engineering for them.... because every answer is thousands of emails...each with hyperlinks to my site I think I'm subscribed to cad_cam_edm_dro I didn't visit it in a while So I give some free engineering...and get some free advertising I am getting 7000 hits/mo on my site and a good bit comes from those groups nice Grr this new winxp I had to install has java diabled Does not even seem to have it or the firewall won't allow it hate winxp SP2? yes had to get it to test code I wrote for a client that will use it I see... I did have some problems with SP2 myseld my imap connection (on local LAN) went berzerk about 10 seconds before connection finally tracked it down to the auth port, that was blocked on SP2 I am looking now...I have activex enabled...but java stuff will not run well.. you gotta have a JAVA-VM afaik XP doesn't have one by default they offer their own M$-java-vm but that one's crappy I'd suggest you download a JRE from sun need it to look at sat/radar weather to see why it is not raining all day as predicted yup just went to the sun site Hi all enjoy the wether les here we have 2°C cold g'morgen martin here we have around 4°C hmmm sun cannot install JRE on xp sp2 !? :-( then.. download opera with java (www.opera.com) it's way better than IE I will check that out some pages don't show right in Opera thou... but that's a fault of the people who write the pages they don't go by standards... (rather M$ standards) * alex_joni is watching UK Champs in York marbles again... jre installed...had to do some activex stuff first really slow like watching paint dry now got the sat wweather animation... uh oh...rain is comming back in a while... hey steve hi alex, I see you have been very active with auto config this week. last night actually I did another branch this week 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 hi ray Hi Steve. well... actually right now only make install works there will be a make rpm and some deb-packages but those are not really done paul started on deb-packages and Jonathan Starks on some rpm support is the intention to have packages that will install real time as well as EMC onto a standard Linux system? 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. I don't think so that's way to hard to do ray: for emc? That is what I thought. So what will be the install sequence when one is able to use one of the packages? Yes. Paul has a new BDI-3xx that is based on the 2.6 kernel. nice This install is for EMC2? I know paul's pretty busy lately with the next release ray: yes but it also helps for package creation (binary packages, e.g. rpm) It is up to Paul, but my preference for 2 would be a BDI inclusion. that's for sure That is a ways off. IMO the autostuff is essentially separate from how it will be finally released into the wild. the autoconf kinda figures if the system it analyses is ok enough to use emc2 on it you don't need those tests on a standard BDI but I don't see how they could harm I missed the start of this so I may well be way off... No harm. A lot of help as I see it. 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. Guru level doesn't need auto, but the rest of us developer/testers will be helped a bunch. don't know what you mean with guru level? As will the BDI folk whenever they make a new package for that distro. John, Paul, Robin, you... actually autoconf right now provides the ./configure script which analyses the system and outputs Makefile.inc (with all CFLAGS, RTVER, etc.) SteveStallings: Need me to ship you a bunch of disks. so I don't think anyone can use emc2 without it the HEAD branch of emc2 contains a custom written ./configure script written by paul I guess I was thinking of those few who built emc2 from the original make and source. but that was way to hard to maintain right now it's pretty simple: hi guys ./configure make 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. & run hey John I've got a couple hundred preprinted. when / if you're happy with the results ... make install alex_joni: I don't know much about the specifics but it sounds like this is a big step forward. Mornin John. hi John rayh: it surely is intended to be... if it's already there... that's a whole different question looks like an interesting discussion in progress jmk: hi It started from wanting to update the EMC description on the web site to accurately reflect the status of auto config. * jmkasunich reads mail Hi John I wish I was online yesterday - seems Paul Fox was having problems that I could have helped with 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 which brings me to a question I wanted to ask you... when do you think we should merge it ask ahead seems to me we're getting pretty close? I see it with 2 possibilities 1. get a lot of people to test it, then merge it 2. merge it and fix what comes up, after people start to test it... " ;-)" but I would really want to hear paul's oppinion about the merging or 1.5: get a few people to test it, then merge it, and fix what comes up as more test it well.. a few people did test it but .. you can count those on your fingers ;) I will need to build a new EMC2 soon for the show. I will try the new tools. Are there any ""instructions""? I need to do a cvs up and play with it myself try the new branch I did this week autoconf_install_0_1 a branch from a branch? steve: you really are only supposed to do : ./configure && make && scripts/emc.run SteveStallings: the autoconf stuff works just like the original: ./configure, make, run jmk: yes... ain't it twisted? :-) the difference is that the original hand-generated (and crufty) ./configure has been replaced by an autotools generated one that does a better job or should ;) Hey, I don't need any extra help with getting twisted, ample ability on hand already! 8-( well... it does a lot more tests 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 it doesn't change things on ./configure && make only for make install I see - we don't do make install on the farm anyway, so I guess it doesn't matter yup but I would love some testing from you... e.g. tell me what you think of it still - if the config stuff is pretty much working, I think I 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 I see... too many branches can get confusing, IMO problem is... right now the autoconf branch has some make install additions in it true some I don't like 1. run-in-place is broken ;-) so I wouldn't want that merged in HEAD right? right 2 possib. 1. strip away all make install stuff and merge only the autoconf stuff 2. so some more work till the make install is ok and merge that but the ""more work"" is in the new branch, yes? actually no... there's less work there then what is the new branch for? I didn't like the way zwisk did it.. I thought it was too complicated I see so I did it my way... a lot simpler have you and zwisk talked about it at all ? but I still want to discuss it with him, not to miss anything we did exchange some e-mails but he last said he was busy, and I should give it a try, and we'll sync sometime I like your option 1 (remove make install, then merge) then work on make install ""from scratch"" but I'm really not up to date on where that all stands that's what I did in the new branch * jmkasunich needs to read the cvs book again can you merge from your ""branch from a branch"" all the way back to the head? well.. the branch from a branch is actually a separate branch just like the first one from the trunk? they are equal work can be merged from either one or from both ok I'm just a little concerned about the proliferation of branches - I'd like to hear what paul feels about it * alex_joni joins the club in the meantime, it shoulds like I should checkout your new branch I think paul is more likely to state that the autoconf ./configure is up to replace the hand-crufted one I agree - regardless of where we stand on the make install, I think the new configure should be merged as soon as possible Getting it here now. I can test after a bit on 2.20b, live, and knoppix. ray: either one should work SteveStallings: Got any clue how many disks you might need for Cabin Fever? 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? They are printed in Baltimore. I could get some shipped direct. Hopefully Chris Daniel (aka -thalx) will be running EMC1 and I will be running EMC2. I I'd wait for the new. It promises to be great. * alex_joni is eager too to get his hands on the new BDI Are the printed disks blanks that your burn? Yes. jmk: say when you got some time, and nerve to test the new branch did you talk to Imperator_ about homing ? Then I could do the burning at the last minute, just tell me how to get some of the disks. Email me your address again and I'll get some to you. good morning folks. alex_joni: nerve - no problem, time - that's tougher good afternoon jepler I haven't talked to imperator about homing - I have done zero emc stuff this week except for a couple emails on the list he's still wondering about a hal module for a XX machine ah he's been talking to les about master-slave joints and such SteveStallings: got it. I was wondering... how is hal connected to emc ? I need to clone myself through the /src/emc/hal_intf/ ? no but in hindsight, that probably should have been used or maybe not ;-) yeah... that clarifies it a bit lol I don't like the ext interface - the new emc2 motion controller directly accesses HAL pins (and paremeters) I see using the ext interface to do it would have just added another layer well then its more likely that the motion controller can tell a hal_module it needs homing paul and I have debated it back and forth through the ext interface --- no way I need to review how I did homing in the new motion controller need to define some conventions for the behavior of a HAL encoder interface (whether hardware or software based) and then modify the motion controller to work with that sounds like a lot of work 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 that is simple and clean, and works well _unless_ you are running at more than one encoder count per servo cycle yeah.. but a HAL module for a XX axis can do it the same way right - the XX module would strive to make two physical axes look like one logical one tell the motion controller it's a single axis exactly jep, that works well but homing is the problem im thinking on that the HAL module will make the homing but .. im not shure if that is a clean implementation Imperator_: the HAL module needs to home the second axis 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 I don't think you can do that but ALWAYS both axis have to do the same movement why ? you just said it - both axis always have to do the same thing you can't home one at a time how can you make sure the two axis's move at the same time if they are not homed? what if something happened during power-off and they are not synced anymore? imagine both were in sync, then you did power off if they are not homed i can only command both to do the same and then you turned one screw part of a turn yup... you won't be able to turn it much because the machine is stiff, and it won't let you but say you are 1/4 turn out of sync jep that can happen I think it's like this... during homing both have to do the same thing what's the problem ? when you home later, you run both axies together, and they remain 1/4 turn out of sync until you get to the end and if both HOME_SIGNALS come, then it's ok if only one comes it should be signaled or treated differently but I don't think you can decide what to do in this case the XX module must detect that they are not in sync, and it is responsible for syncing them maybe run the two till the home signal for the second comes jep, but first you have to hit both switches then check how far from home it is (from the home on the first) that doesn't sync them tho - they stay 1/4 turn out of sync if greater than a certain value- e-stop with message I think this thinking is incorrect. You are only going to home one of the two. if not move the first axis on home (because the second one is already) The second just has to follow that primary axis. I agree ray, but you have to make sure it's not way off so the whole thing doesn't get broken rayh: yes - but what if the second one is offset from the first one (skewed) in real the home switches are always on different positions Trying to allign two 2000 encoder index pulses will not work. rayh: I would disagree on that The integrator will simply have to mechanically align the two. Imperator_: here's a thought the two encoders? use abs-encoders on both axes alex_joni: that not a lot more expensive i have some, but i want to wite the module also for normal incremental encoders Alex don't know if you can for all cases I see abs-encoders the way to eliminate a lot of problems 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? or use power-off-brakes that doesn't solve the problem jmk: I do that on abs-encoders i think that is all not that problem I would only use the index from one encoder. The other is irrelevant. how to you keep the machine square then? you really need to make sure they are in sync the question is how to implement that suppose while it's powered off, someone turns the slave axis by 0.002"" maybe after homing drive the axis for one turn in either direction Sync is simply matching pulse for pulse between the two motors. 1. a HAL module that does it's own homing procedure and check for the home-signal from the second axis, and see what diff you have ray: agreed if the machine can't be moved when switched off Imperator_: I' oops 2. add a additional secuence to the existing sequence Doesn't matter if it is moved. Imperator_: I'd rather avoid a HAL module that actually knows about homing - keep that in the emc motion module rayh: huh?? When restarted it homes on the index from one motor while the other matches the motion.\ rayh: only one part gets moved so it's not square anymore No both must move at the same time. That is the nature of the fixed gantry. 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 i think i have to write the sequence i'm thinking on down somewhere otherwise that discassion lasts forever :-) it's not fixed no gantry is infinitely stiff - if it was, you could use only one screw it's a gantry driven by two motors Imperator_: I agree it can be adjusted by software, but I would really go with abs-servos (a lot safer) Gantry axis will self align itself.you cannot force to have skew Yea... What he said! that way you can check the skew before moving the gantry I must respectfully disagree with ray and sivaraj ok if i add something to the existing homing sequences motion has to know that there are two axis. makes this new problems ??? Skew can be forced and will cause premature wear on bearings. if the gantry is stiff enough that you ""can't"" skew it, then why bother driving it from both sides? * alex_joni agrees with john. if there is a skew will cause motor to overload so it cannot move depends on the amount of skew a small skew will just damage things sooner or later 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 * alex_joni leaves for half an hour... if there is skew it will be there until it has hit both home switches. Then the next step is to remove the skew right yeah but what if the skew that is damages the machine ? IMO if you try to force both motors to home you will introduce the skew that you are trying to avoid. I think a abs-servo could have prevented that check the two encoders... and see what your skew is... ... 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... The only way round this is motor amp load balancing. 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 most of the CNC's I have seen references only master axis.the slave will just follow it no need to reference the slave axis. don't think so sivaraj Generalized solution should also take into account systems running stepper motors and NO feedback. 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. no problem Steve 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 using servos or stepper makes no difference If you insist that both motors must be homed to eliminate skew then make the gantry swivel at both ends. that is another problem John but i think a small one Now you can set the squareness of the xy table by rotating one encoder. yep Darn this machine design stuff is fun! Hm ?? Don't understand you rayh I have build Gantry machine with Heidenhain syatem but they do not reference the slave.Its work is just follow the master 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 The Siemens 840D does it Imperator_: Don't feel alone. There are not many who do understand me;) :-) Yes you are correct that many commercial machines have fixed multiple motors and screws. sivaraj: at the Haidenhain controlers you can decide if the slave only follows or if they will be synchronised after homing 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 more or less John but Steve brought up a good point - suppose it is an XXYZ machine, and Y is all the way at one end during an X rapid, the tool hits something i think we have to go one step further one end of X stops right away, then other keeps going a little further the PID controller has to solve that John 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 but with steppers, if the crash causes one side to loose steps, you have skew and with steppers you have to take care that the do the stepps in any case jep that is the problem of the steppers. That's why servos exist ;-) ok i think we have discussed that. Now where can i implement it Imperator_: The possibility of either slave or dual master would allow for most any kind of mechanical relationship between the motors. 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 jep and a few more parameters that is not the problem John * rayh gotta go. Thanks. ok if i do homing in motion then emc has to know that there are two axis and even in free mode they have to move together how can i do that why does emc have to know? because i think otherwise the homing can't work, because it is in EMC, or ??? emc would home the one axis - the other would simply track it. or do you mean i have to do both writing a HAL module and adding something to the homing code in EMC if there is no skew before homing, there would be no skew after homing nope - no change to emc, just the hal module but i must be able to remove the skew if there is one and i must be able to home both axis to mesure the skew how would you measure the skew? if i have homed both i know where they are and i know where they should to be but you can't home them individually - that would (at least temporarily) cause even more skew i think it is difficult to measure skew with rotor encoder.May be linear scales can help even at homing they must move together yes, exactlly so if they must move together, how can you possibly home them both? first i search for the switch of the first one, then of the second one 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 jep i think also on that all John that has first to be done for the first one, and then for the second one 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 that makes it interesting that makes it ver, very ugly... because either: jep John 1) emc must ""know"" it is a dual axis, and home it twice jep or 2) the HAL module must ""know"" that emc is homing part of the modularity of HAL is that they should not have to ""know"" these things there is the parameter homing or how it is named 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 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 JMK - what does the HAL module do now when it encounters a ""home"" signal during a move? the homing signals are conected directly to emc the HAL modules don't know them what he said ;-) but that needs to be revised at least a little bit to handle index pulses better (the home switch signal still will go directly to the motion controller) .. so the current homing routines are not within the HAL code, but rather within EMC2 code exactly machine tools home, emc2 is a machine tool controler things like stepgen, encoder, etc, are lower level functions, they don't know about homing 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 2: to implement it completly in EMC the second way i the clean one i think 3) write an XX hal module that recognizes EMC's homing sequence and does whatever special things are needed for dual axis 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. 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? both 2 and 1.5 require EMC to know that it is a dual axis 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 see chapter 3.4 of http://linuxcnc.org/EMC2_Code_Notes.pdf Sorry, I have not read the code. So the index snapshots an encoder count? oops, going to read..... just got back and read the master/slave discussion I studied up on it... the good controls allow slaving to a virtual axis (commanded position) OR a real axis (actual position) 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 which seems to be the way thing are going... what is the biggest reasoon not to change anything on EMC 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 question: how does emc1 support XXYZ machines I guess it does not john I thought it did? (maybe not well, but I thought it at least makes an attempt?) I am told no... which is why I had to use a jackshaft (there were other reasons too) my reason for not wanting to make the code motion controller ""aware"" of dual axes is that the motion controller is complicated enough already s/code/core/ ok that is a reason simplicity is good... I read that the propagation delay for slaving is about 3 servo cycles.... I just read through the log... short question see chapter 3.2 and figure 3.1 in EMC2_Code_Notes.pdf, that drawing can help us communicate I think so some might need virtual slaving if thir servo update is not fast enough mainly to John I think what if we would have a HAL module that does the homing so it's abstract to emc this way things could get simlified in the homing procedure it would be hard to modularize homing have different modules for different types of homing (with index_pulse, withour, with twin-axis, etc) why? communication with the rest of emc some changes on emc are needed.. agree but it would simplify things in emc HAL works well for things that can be modeled as ""hardware blocks"", with signals connecting them to other parts Would it be reasonable to put most of the magic into HAL but add one command called ""deskew"" to be issued by EMC2? yes... and this is exactly what I am thinking of right now emc is connected to a hal module with position command, and response right? right - see fig 3.1 in EMC2_Code_Notes.pdf ok.. now inbetween these to there'll be a homing module 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 with 2 signals to emc emc->hal (DO_HOMING) hal->emc (HOMED) and the hal module takes over driving whatever is connected to his pins until it's homed know what I mean? results: the GUI would display nothing during homing well the HAL module can update the position so the GUI will display it if the feedback changes but not the command from emc, then emc will trip on ferror emc will probably need tweaking to not go into e-stop exactly the ferror could be meters during homing, unless emc is generating the commands 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. SteveStallings: that's kind of what I was thinking there are two parts to it, one easy, one hard easy: provide an offset parameter that moves one motor relative to the other hard: measure the offset (using index pulses or switches) so you know how to set the parameter IMHO, the very first measurement of the offset will be made using a precision square and dial indicators but the easy one would twist the gantry , no? 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. if you told it to apply 0.1"" of offset, yet yes but suppose your dial indicators and precision square tell you there is 0.0013"" of skew you could use that one dinamically then move one motor by 0.0013"" and you are good 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 let's say you know you have a side that's more heavy electronic version of my cam and follower on one screw? les: let's not go there yet ;-) (but yes, that offset could be made a function of X) right right now we're only talking about it at the home position Imperator_: yes - you measure one time to get the baseline offset ok did paul return? so the trick becomes to measure the current offset, then correct it to make it whatever it should be It seems complicated in that the system has to stay reasonably synced when shut down and starting up les: that's why I suggested abs-encoders 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. _either_ it must stay synced (not move when powered off) _or_ it must be able to measure the skew to correct for it the first is easy for the software, but very demanding on the hardware My machine must be kept tightly synced on or off your machine is synced by the gears i think the only trick is the implementation of the homing sequence. After homing you can calculate eaily the skew and correct it but are you saying that the gantry itself is flexible in the skew axis, and depends on the screws to keep the sides synced? no, I am just saying that even a tiny loss of sync makes huge racking forces that could damage the bearings so in other words it is very stiff in the skew axis yes...but not stiff enough to drive with one screw! right but that is not a problem of the controller correct but assuming two motors instead of your gearing and jackshaft, when powered down, it would be hard to get your machine out of sync, for the simple reason that is it quite stiff, correct? right...unless a motor did something funny if you turned one motor manually, the gantry would backdrive the other motor 10kN of force there... the screw is a big gear, you can't backdrive it so easy 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 30 kN*M of possible racking moment I hold it to 0.0005"" measured you mean with the jackshaft, and the error correction cam? sounds almost like two absolute stops in known places that the gantry parked at would be in order jmk: yes as measured @25c ok - but we're not talking about your existing system with jackshafts - we're assuming two motors jep !!! 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..... drive both sides slowly into hard stops, then sync counters? you're getting ahead of me besides, index pulses are as good as hard stops (or better) yes back to my hypothetical situation: 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 there will probably be some skew (0.0002-5) just because I pushed off center now you power up your counters, and begin running both motors together, count by count yes..it backdrives...skew is more is that skew that I introduced by pushing on the gantry enough to generate damaging forces? or could you just run both motors together until both hit index pulses and then correct the skew? would prob be ok on my machine...but in general many would not backdrive...right? well if they don't backdrive, then there is no prob - neither motor moves, and it's as if you never turned it off of course if you turn one screw, and the other can't backdrive, then you could possibly put some serious skew into the machine beginning to think index marks must be mechanically synced during the initial machine setup and calibration not really mechanically the sw could remember that index 1 is 236 counts away from index 2 when the machine is square jep yes you would square the machine by moving one motor and checking with squares and indicators, then tell it to remember the offset ok... 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 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 ok so in conclusion i try to write a HAL module I have had couplers slip...but if they don't the calibration need only be done one time or what is your conclusion John ? 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 at the same time, it measures the difference between when the first one trips and the second one trips that difference is the current offset, it should be compared to the remembered offset (HAL parameter) if they are different, the command to the slave axis is adjusted to correct the error ok then both switches have to be mechanicaly close together not at both ends of the machine maybe we need then a new command to allow deskewing and a new command to tell the GUI the difference maybe will this work if say a coupler slips on one side due to a crash? if something slips, you'll have to get out the indicators and square again because the remembered offset would no longer be valid? ok i will try to do that 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) right but anyway the idea of Alex to put the homing code in a HAL module has some advantages even at normal machines I am just wondering if an automatic offset correction might be a problem with a slipped component but you got to make sure the overhead to implement it is not too big jep prompt if offset has changed? les: depends on your offser reading e.g. offset checking yes or maybe we put the homing code in a extra file you would need to have a max_offset kinda like a offset_ferror jep yes if it's too big you need to e-stop maybe adjust one PID or whatever yes, have you sean the manual of the siemens controller ?? and the max ferror DIFFERENCE in normal running 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) 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 but when you get home, you'll measure an offset that is not what it should be I agree that maybe you _don't_ want to automatically force it back to the expected value right JMK - sent some ideas by e-mail, too long for one IRC string there are actually two steps here, that can be implemented independently in the HAL module * alex_joni found out that CVS merging is pretty tough 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"" ok 2) apply an offset to the command sent to the slave, derived from another HAL parameter, like ""command_offset"" about 1) can't the module try to reduce the offset? measureing it is always safe, modifying it may not be if something has slipped or will that automatically be done when emc sets command_offset... right software does not know what is square and what is not there will be another parameter that tells the module the max offset it corrects automaticaly actually .... no I think of it this way: 1. during home the hal module reports measured_offser (even in other conditions.. let's say everytime it gets index pulses) emc checks measured_offset against a max. value (after substracting the default value, fixed during set-up) if it's greater it e-stops and the user has to decide what to do sounds reasonable so you are proposing that EMC proper _does_ know that this is a dual axis someone needs to watch the max offset and remember the default offset (probably from emc.ini) well the default could be a HAL parameter this is a major conceptual issue that we need to decide on - should or should not EMC itself be aware of dual axis? thats the point if yes, that implies changes througout - all the way from motion controller up to the GUI are there reasons to treat it differently? but perhaps it can be handled better that way if not, then all dual-axis stuff is hidden in the HAL, and there is much less widespread work to be done 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 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? but driven by one motor very important for us yes 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"" SteveStallings: perhaps dual axis is one of those things that is at a higher level and _should_ be handled within emc I think to be robust a dual has to monitor that stuff I don't know - my initial thought were very strongly toward handling it entirely within the HAL, but now.... jmk: what if the hal module sees the offset is too big and stops moving? 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 Could dual XX be treated as a special case of kinematics? 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 is a hexapod only a change in kinematic or has the homing sequence also to be changed afaik only kins you still define all axes 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) jep dual axis have nothing to do with kins 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 So how does an overly constrained mechanical system in a hexapod manage to home the struts? are you shure John ?? homing in hexapods is ""yucky"", to use a technical term '-) staying away from poles... 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 ? 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 ok so you have not to switch of a hexapod at any position So back to our special case XX homing... first and most important question - does EMC know about dual axis or not? lets list pros and cons pro: provide the user with custom messages when the offset is too big con: lot of work but i hope i can do that pro: clean impementation con: it will modify emc, make it a lot more complicated pro: there could be a special version of figure 3.1 that understands dual axis and handles everything pro: I don't have to spend thousands on mechanical solutions :-) les: irrelevant - we are talking about _how_ to implement dual axis, not whether to do it ok both ways will save you the mechanics hmmm... you could spend thousands on software solutions... I wouldn't mind ;) pro: maybe it is easyer for users because handling of all that HAL modules is also not that easy 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 it's starting to sound like makeing EMC aware of dual axis is better, but harder jep think also so John simple question: does the user have to know when offset is too big? or an e-stop is enough? estop with a good message why is best an unexplained e-stop leads to users asking questions on the list some descriptive message would be good well...in that case emc has to be aware I _HATE_ faults/errors that don't give accurate messages some changes have to be made to emc and if those are made... why not go the best way What about a way for a HAL module to pass a string on errors? HAL modules can write to the kernel log - that's it it must fault out on anything from sliped mechanicals to shorted amps, locked computers, anything that would cause damaging racking how about a NML-aware HAL module? no, no, a thousand times no!!! * alex_joni thinks jmk doesn't like NML... hal is all about simple components, like electronic parts interconnected on a PC board opamps and 7166 chips don't print error messages Old thinking, our black boxes are getting smarter. well.. there are some counter chips that do... if something doesn't lend itself to that model, then it shouldn't be implemented as a HAL module anyways... we're drifting just want to make the point: a HAL based system should be describable by a drawing showing the modules and their interconnections no extra hidden stuff like NML messages or other messages the block diagram _is_ the system well then.. guess EMC has to decide that the offset is to big, and it has to shout that to the user 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 that's more development debug than runtime debug right what we need now is a dual axis version of figure 3.1 from ECM2_Code_Notes don't expect the user to check /var/log/messages to see why his machine went into e-stop 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. HAL modules should not generate runtime errors - period how about a servo as an example of a module? op-amps don't generate errors - if the input is out of range, they clamp some servos have serial commands & reporting and they might say ... motor winding problems more usefull than error Agree that EMC must still ""poll"" for errors, just want more information. recall that HAL modules are all executing periodically are you gonna generate the error message 1000 times a second? ... gonna have to think about that... maybe in that case we need something like syslog im EMC where modules can send messages 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 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 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 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? I'm not convinced that HAL modules should have ""errors"" that need reporting 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 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. i think there are some, for example the encoder counters of professional controllers are reporting that the linear encoder is polluted detecting impossible motions? We definitely aren't looking at HAL the same way Granted, I'm not playing fair. My expectations are probably getting ahead of what is reasonable. 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 maybe the things steve wants from HAL could be done in EMC make EMC modular too.. to some extent at least error-checking and reporting & such maybe yes Alex. But the idears of Steve are imortand also I agree completely that EMC's error reporting could be improved I think HAL is ok the way it is now... a HARDWARE abstraction layer and we could keep it that way 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 I also think HAL is a very good thing. We don't have to kill it by implementing things that don't have to be there jmk: is the HAL GPL? yes ok ok back to dual axis: 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 how do i have to do it jmk: very good Imperator_: two choices: do it in EMC (control.c to be precise) or do it in HAL to do it in EMC, take fig 3.1 from EMC2_Code_Notes, and draw a new one that supports dual axis then figure out how to tell the motion controller at insmod time which axis are dual (so they can export the extra HAL pins) ok i will check that and i hope to make a precise suggestion next week and add new fields to the EMC shmem structs (emcmot_Status, etc) to handle things like offset limits, etc add new NML messages to set those fields how are you drawing that pictures John add new GUI code to display important stuff etc, etc, etc I used something called EasyCad where did i find that NML stuff ? (similar to AutoCad) ok don't know anything (much) about NML :-) to put it simply - I personally _cannot_ implement dual axis the ""EMC"" way 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 jmk: good news... If it was done the EMC way, probably 20 files would need to be touched the HAL way, 1 (probably) nice :-) but the HAL way would have some limitations configure.in and Makefile.inc.in need to be added to trunk, and ./configure needs to be modified enough work for the winter so we have to decide what is more important - simplicity or features that's all that's needed to get autoconf stuff working so you are describing something of a ""manual merge""? as a machine builder my opinion is that it must have the limits-where ever they come from no... I just did a manual test to see what needs to be merged there are more ways of merging complete merging (whole branch)- don't want that because of other stuff (make install & such) single merging (only some files) whatever works, I guess at this point, I have so little time to work on EMC, I don't know whether I'm coming or going I just hope we can avoid even more branches to keep track of I'd like to see older branches either officially abandoned, or merged back into the trunk, and _then_ make new branches for further work just my personal opinion, as someone who can barely keep up ok well right now I see following branches: pc_2_6_test lathe_fork jmk ioctl_branching HAL_no_logging autoconf_install_0_1 auto_configure_0_1 auto_configure_0_2 (this one was created by mistake... don't know how to delete it) these are for EMC2 jmk is dead - I don't even remember what that was lathefork is active ioctl is dead, I think not sure what is in HAL_no_logging you did say some time ago you'll contact sf guys to remove some unused studd stuff or is my memory playing tricks on me? that was unused top level modules (like emc, rcslib, emc2, etc) I don't think old branches ever really go away, they just sit there yeah I know... but those are still there * jmkasunich looks I used the CVS repository browser on SF emc, rcslib, emc2, and documents, are the four ""active"" top level modules emc_HAL and emc2-auto should have been removed - let me check a few things 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 Alex you are talking about branches what's that exactly ??? don't know anything about that CVS branches Imperator_: the whole code is in CVS if anyone wants to develop something that could be needed when it's done (e.g. 2.6 kernel support) it is usefull to create a branch how can i do that ? a way to develop in a separate dir because that is maybe good for the dual axis stuff and when it's done you can merge the changes back to the HEAD (or trunk) well... you should read the CVS book ;) oh, the big one but to keep it simple: but that has nothing to do with real folders in the CVS jep say me the command step 1. tag the branch (cvs tag -b new_branch_name) step 2. check out the branch (cvs checkout -r new_branch_name) to another dir step 3. modify the source in the new dir and commit step 4. merge changes back to main branch (that's more complicated than a single command) but.. you need to ask around before doing things like this ;) ok i will do that with the dual axis code I'd ask paul_c first, or any other board-member read: https://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_5.html#SEC54 if you are taking the ""change EMC"", by all means do it in a branch (wouldn't hurt to ask Paul too) branches can easyly removed if they are bad ??? not really... with support from SF but if they are not merged they don't hurt anybody nope they don't ok I'm happy to have some absolute encoders, because they get expensive at ebay http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&rd=1&item=3852431815 401 EUR was my price can get expensive...I design them les: ?? encoders don't think 100 EUR/piece is expensive i have four of them here but the one with the smal profile, i get them for 50 EUR :-) nice no you got a great deal i know they cost over 1000EUR new how many bits? that depends on the lenght they have a resolution of 0,1 microm what is the smallest distance increment haha ok and they are absolute, with no homing requiered? required 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 jmk: I just found out that ViewCVS is from the backup CVS server jep les yeah, but that should only lag behind a max of 24 hours, not 30 days hmm 20 bits if 1 meter long hours? sorry 24 floh: are you the one who is fighting with the Siemens card yes 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 floh: is it working now * alex_joni tried a checkout on emc2-auto and it's still there will get pretty high data rates moving at speed who was taking care of the IRC-logs on linuxcnc.org ? jep you get only the position when you ask the encoder 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 hm i had this error also that is a overflow of the driver, but i think that was solved Imperator:serial? jep les oh sorry that was an other error floh vsnprintf should be defined in stdarg.h or there is a other mode then it sends as fast as it can position information independend of the speed btw, warning: is not really an error ;) it was an error, because i couldnt start emc.run (motion.o defect) or so I see...a far cry from the automotive gray code stuff I did gray code is cool.. hard to read thou... alex_joni: re the IRC logs, that was me need a hand? they seem to be stuck around 26 sept. yes! I have logs for each week since then (except today - forgot to start logger) floh: here it runs fine. I have compiled a fresh cvs copy half an hour before I do have for the last month 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 can you send me some logs to filter out? sure * Imperator_ is prepaing something to eat * alex_joni awaits e-mail do you have an account on LinuxCNC.org? nope Imperator_ is now known as Imperator_away Does alex_joni want an account? need it to post the IRC logs floh: here it runs fine. I have compiled a fresh cvs copy half an hour before good, I'll download the actual cvs version floh: what version were you using? I downoaded it 2-3 weeks ago alex_joni: october logs on the way jmk: I'll modify them while you're editing, jot down the subjects that were discussed - then you can add them to the brief synopsis in the table (just FTP linuxcnc.org/EMC_news_history/IRC-logs/index.html, copy the top .... block, and edit it) then FTP index.html and the new logs back to linuxcnc.org and lest I forget - THANK YOU! (I've been feeling very guilty because I've fallen behind) don't mention it ;) but I'm still waiting on the logs 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) John, did you get the two e-mail that I sent? maybe my ISP is being slow... give it some time (maybe an hour) and then mail me if it still isn't there SteveStallings: yes, got them incoming mail seems to be OK (I got Paul's recent post to emcusers, and my own commit message) I'm gonna go away for a while - I have some parts I need to mill for a paying customer jmk: got the mail we are blasting away with emc paying work...but not today Imperator_away is now known as Imperator_ good dinner? alex_joni: are you next week on that automatisation fair in Nürnberg jep les :-) don't think so Martin ok are you visiting some fairs in germany ? if I happen to be in germany at that time ;) probably I'll go to the welding fair in Essen I did not go to the chicago imts this year that is our biggest if you are here Alex, how are traveling ? car usually.. why? woodworking les ? no machine tools the big woodworking fair is IWF hundreds of cnc routers running with the car you are driving not so far away from me through south germany i think We represent actually two companies from germany if you are somewhere around here and if you have time we can drink a beer together one is in Markdorf (near Friedrichshafen..) that's nearer to you jep thanks for the invitation... same way around don't have some projects with people in rumenia at the moment :-( jmk: still around? guess not... I am in and out while doing laundry.... also fixing that alesis audio amp...it's a bad relay it actually works quite well as a test servo amp * alex_joni is tweaking IRC logs It will put out 13 amps at 110v...not bad for an audio amp alex_joni: just came back for a minute... what's up? hmm, thats what, 1500 watt DC? ok, time to reboot into 'doze :( jmk_when_back: I was wondering about timestamps (some irc logs have them some don't) hi alex I'll start on the others too these days oh.. you're still around * jmkasunich takes a look was paul around? I just got back now - then going back out again looks good to me ok.. I'll modify the rest and put those up there too... when I'll get to it ;) re: timestamps - your call as to whether to keep them or delete them I hope in a day or two no hurry well... the first file had no timestamps- that's why I asked (after all it's been a month already) the previous one had re: month - that's why I wanna hurry ;) depends on who's logger captured it, mine doesn't stamp, but I got some of those from paul, and his does timestamps the webpage should really give people the impression that things are under active development which is the case I really appreciate your help on those - when I started them, I didn't realize how my life would get busy I'm down to one night of emc a week (none this week) when I find a project that hasn't been updated for a year or so... I consider it twice if it's worth well... I'm sure everyone gets to a point when we have other stuff to do... that's why it's better if there are a lot ofpeople in volved yep anyways.. if you ever need logs... my logger should be around here ok bye time to make more brass chips here goodnight paul wasn't around, was he? never saw him my client stayed on even while I wasn't here ok... I'll bug him this week ;) guess he's kinda tired of me... :-) * alex_joni plans to merge autoconf stuff to the trunk this week good to hear that but I want paul's opinion first * asdfqwega opens the doors to let the smoke out That might sound like something bad happened, but it's actually just the opposite My new laser is hard at work! Now I just need some damn ventilation... (use the laser to make holes in the wall? Hmm...) Large hammer ? ""When you have a hammer, all the world looks like a nail""...? Well, I have a LASER :) Well, dang...it's working great, but I'm freezing my fiddly bits off Does it cut through brick ? Well, this is only 10W...it'd take a LONG time 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 That's the last time I buy an old laser off of eBay ;)