From: Cliff B. <cbl...@po...> - 2010-04-20 20:33:02
|
Yes I have seen this home scheme used on other controllers and most use offset home switches. One thing I have seen everyone do is have both motors do the same thing until both homes are known then apply the offset stored in software. Marc Bodmer wrote: > Hi Cliff > > I can short tell you how we do it on our waterjet cutting > machines at work. I work for a waterjet cutting machine > manufacturer, developing our own cnc software. > > Each gantry axis has it's home switch. There is an adjustable > configuration value for the offset distance between those 2 > switches. > > Homing sequence: > > 1. Positioning speed until both of the 2 gantry axis home switches > tripped (sequentially), then stop the gantry. > > 2. The gantry is now moved with homing speed in the other direction. > > 3. After the first switch (now in the other direction) trips > again, the hardware is put in a homing state wich means after the next > reference mark comes it will save the position into a register. > > 4. The machine still continues moving until the same happens on the > second switch (on the other gantry axis). > > 5. Homing motion stops and the gantry is adjusted (deskewed?). > This means one axis motor corrects it's position deviation in respect > to the configured home switch offset. > > 6. Positoning move to home position > > Our motors are pretty strong and can offset the 2 gantry axis > easily. If the correction would be more than 20mm we expect > a unsers input to make the gantry adjustment to be sure it's > really wanted (gantry length is 3500mm). > > On the other hand the strong mechanics can handle big position > offsets between the 2 axes (see above, 20mm). > > I don't know whether or how this maps to emc2. Just wanted > to give you an idea how others (we) do it. Our homing is not generic, > since it's optimized for our machines only. > > Good luck with this, good you are taking initiative to improve > that. Hope it helps. > > thanks. > > Marc > > Am Dienstag, den 20.04.2010, 02:07 -0700 schrieb Cliff Blackburn: > >> Thats one thing I'm not totally positive about yet, but from how it >> looks in the source I can use home_offset on one the second joint to >> correct skew, leaving the first at zero. >> >> For instance.. >> >> Distance between homes switches is 2in. >> >> INI Specifies >> Joint0, home_offset = 0 >> home = 0 >> Joint1, home_offset = -2in >> home = 0 >> >> Both linked joints will travel towards home switch. Joint0 trips first, >> puts Joint1 in follow mode. After joint0 completes it's home it loads >> its position with 0(home_offset) then it moves to home.. (which will >> just be a bit of overshoot) >> >> After Joint0 stops, Joint1 starts homing and Joint0 goes into follow mode.. >> They both travel towards joint1 home. After Joint1 completes its home >> it's loaded with -2(home_offset). Because Joint0 was following it should >> also be at -2 as well.. so they are now both loaded with -2 for position. >> >> On second thoughts It might be better to stop homing joint0 at the >> HOME_FINAL_MOVE_START state instead of HOME_FINISHED.. Then start homing >> joint1.. after they are both this far and loaded with their home_offset >> values they stop following each other and both drive to their HOME >> positions and at the end of the move any skew should be corrected? right? >> >> I guess I need to add another error check to make sure both joints HOME >> value is the same. >> >> Thats what I was thinking about, I'm still new to EMC so not sure if >> this will work the way I'm thinking. >> >> Alex Joni wrote: >> >>> HI Cliff, >>> >>> looks good so far. >>> What happens when both are homed, but the home position is different (slight >>> skew). >>> Does it get corrected? Does the offset get remembered? >>> (At least that's what I think happens if one joint _always_ follows the >>> other one during homing). >>> >>> Regards, >>> Alex >>> >>> >>> ----- Original Message ----- >>> From: "Cliff Blackburn" <cbl...@po...> >>> To: <emc...@li...> >>> Sent: Tuesday, April 20, 2010 10:11 AM >>> Subject: [Emc-developers] Coordinated Gantry Homing by Linked Joints >>> >>> >>> >>> >>>> I started working on a modification to homing.c so you can home a gantry >>>> style machine properly I have started working on it but have more work >>>> before i find how many bugs I created in the process. It adds a option >>>> to link 2 joints together. The joints will home themselves one at a time >>>> while maintaining the same velocities. Quite a few commercial machines >>>> can do this out of the box and I think EMC should too. >>>> >>>> Ideally I don't want to touch what already works and think the best >>>> solution is to introduce custom homing modules (simple, gantry, >>>> crazymach) which can do coordinated motion if needed. Although this >>>> seems like the most configurable + ideal way it's also is the most work >>>> :( This way *seems* simple with minimal changes. >>>> >>>> This is the basic plan so far.....What do you think, good/bad idea? is >>>> it useful to anyone? or should I go a completely different method. >>>> >>>> Plan >>>> - Add a HOME_LINK_JOINT property to the joints. This property defines >>>> which joint is linked linked to it. >>>> - It will at all times will insure both joints move together. (Const vel >>>> at least) >>>> - The first joint to come into contact with it's switch will put the >>>> second into a HOME_LINK_WAIT waiting state. >>>> - While the second is in the waiting state the first will complete it's >>>> home and follow all of it's moves. >>>> - The move following is done in the home_start_move() funtion >>>> - Once the first joint has come to a complete stop after homing it will >>>> be sent to HOME_FINISHED state. >>>> Now it will set the second joints state to HOME_START >>>> - The second joint will now follow the first until it also hits the >>>> HOME_FINISHED state >>>> - The joints will check each other see they are both completed and sets >>>> the HOMING flag off and HOMED true...etc... >>>> >>>> Error Checking >>>> - Must check all velocities, accels, etc.. are equal between joints, if >>>> not it's a warning and use the smallest values from the two. >>>> - Joints which are linked must have the same home_sequence. If not it is >>>> a critical error and quit >>>> - Joints can only link to 1 other joint, and that joint can only link >>>> back to the orig. (e.g. cannot link 3 or have some kinda chain.. >>>> Simplicity) >>>> >>>> Requirements >>>> - Make minimal changes to the homing configuration. >>>> - Don't break working home procedures...! >>>> - Allow all current home methods even if the 2 linked joints use a >>>> different procedure. >>>> - Up to user to specify home offset values to adjust for table skew and. >>>> - Doesn't matter which joint homes first >>>> - Always stay in sync. >>>> - An error in one will trip the other >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Emc-developers mailing list >>>> Emc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/emc-developers >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc...@li... >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Emc-developers mailing list >> Emc...@li... >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > |