Alexey Starikovskiy pravi: > 20.04.2010 18:07, Slavko Kocjancic пишет: > >> Alexey Starikovskiy pravi: >> >> >>> Main problem seems to be that you need to make sure you don't increase skew >>> between linked axis while homing or working. >>> >>> >>> >> Just that.! The homing as is doesn't increase the skew (if parameters >> are correct) >> >> > Bold statement, do you have any proof for it? Or can you list > all parameter mistakes, which could lead to increase in skew? >
Not yet. I have gantry machine as buid in progress. >> >> >>> Hoping that it's small enough and machine can cope with it could be >>> expensive. >>> >>> >>> >> The skew itself is problem. If appears then something is already very >> bad. As I tested on my unfinished machine if I fix the one side rock >> solid and pull another side with 500N force the gantry is skewed les >> than 1mm. So if I assume than my stepper can put max 500N force on >> gantry the max skew is 1mm. If My gantry hit some obstacles and is >> skewed more than 1mm then there are NO WAY to unskew that with homming >> procedure alone. As motors are NOT STRONG ENOUGHT to move such skewed >> gantry at all. So the home procedure can make unskew only if it's small. >> (and to do proper the gantry should move slow and home switch must have >> short "backlash". >> >> > This might be true for your one gantry. What about all other gantries? > In general if gantry is twisted to much the motor will stall! And if gantry is twisted there are something wrong in system and need user attention! >> Not so long ago I want to have report on (re)homming how far from home >> axis was. That's should be just fine here too. If Home is not same then >> you have gantry skew. And gantry skew can be removed in most cases only >> by hand intervention as skewed gantry make big force and stall mottors. >> >> >> >>> Second problem, it should still look as one axis to interpreter and gui. >>> >>> >>> >> I was thinking that gantry kins already do that. >> Wasnt?!? >> >> > No, there is some experimental setup with unapplied patch if I'm not > mistaken. > IMHO, all axis are independent, and all home switches too. > That's bad. I was thinking that this is already done. Long ago I solve problem like this (it's TurboCNC based) but that' doesn't matter. The both motor's uses same Step/Dir (whatever). There are one relay DPDT. The relay coil is under program control. (can be manual too) So when Home is applied the both motors goes to home position but in reality only motor1 limit is wired to computer. When home sequence is finished the relay is switched and home procedure repeated. But when relay is switched the one contact dissable motion of motor1 (can use drive enable or just cut step pin) and the other contact rewire limit switch of motor2 to be used. That thing work's well. Of course when motor2 alone is homed the twist is introduced in lenght of limit switch 'backlash'. All switches I use have les than 1mm backlash so twist is not big. (and that machine is big oxy/acitelene (4 meters by 8 meters) and the gantry is very easy twised by 2 cm) if gantry kins doesn't do the job then this approach can be implemented entirely by hal. (not needs relay) just both limits (separated) and enable output (can be gated in hal too) Slavko. ------------------------------------------------------------------------------ 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-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
