El jue, 20-09-2007 a las 09:13 -0400, John Kasunich escribió: > jros wrote: > > Yesterday we did our first trial with the new kinematics. > > > > It was really exciting!! :) > > > > But there was a shuden movement at the start of the homing sequence. > >
Well, we are dealing with the finishing touches. We've achieved to elmininate the the mentioned PUM when we tried to do the homing sequence. We think that too much time was being consumed in the Newton-Raphson iteration at the start of the HOMING sequence, so we have doubled EMC period to do the computations, an the PUM, has magically diapeared. (In fact to debug, after the real kinematical computations we tried to return the values of trivkins and the pum where present, so a the thing was a too expensive to compute kinematics -more on this latter-) I think that this afternoon (in spanish time), you will be able to see some videos at http://imac/parallel/dis_img.php (only motion) We have see that HOMING can be a source of problems in parallel machines. Being a parallel machine HOMING is fundamental unless you have absolute encoders. The problem is that you can not control the trayectory used for homing as you don't know where the machine is at the start. It can happen that the tayectory tries to reach a unreacheable point of the PKM's working space (as we have detected in our case -fortunatelly the machine stopped-). For our case we know that if the head is aproximatelly centered homing is not a mayor problem. So we use to center it manually. We use simultaneous homing of all the guides. As each joint trigers the upper swith limit, it continues to the new commanded position, intead of waiting for all joints to reach the switch, and then procceed to the home referenced position. So the trayectory is quite caotical. Nevertheless the final position is OK. It would be nice if such a feature could be implemented (nevertheless we can live without it) We have found a very interesting feature, you can write to a file your position (I know you knew but we didn't), when the machine stops, and the read it again when it starts, so HOMING problems would theoreticaly disappear if we move the machine to 0,0,0,0,0,0, and the we home it (for us cartesian --x,y,z,a,b,c-- and joint's --j1,j2,j3,j4,j5,j6-- zero is the same, we have ajusted this in our kinematics deliveratelly). But we've got a new PUM. If the above reasoning for PUM is correct, the problem is: Only joint coordinates are writen and again readed at start, then head position in "cartesian" space is not know and a new newton iteration iteration must be done. This is a special an tricky iteration, because "cartesian" values at the start would be taken (I hope) 0,0,0,0,0,0, that do not in correspondence to actual joint coordinates, so a bigger number of iterations happens, and then the PUM. I hope that writing "cartesian" coordinates along with joint coordinates at exit, and reading them back at the start, will allow the kinematics to be solved in fewer iterations if any at all (because we know the cartesian solution to our nonlinear problem). Another question related to this is: if we dont use at all that feature of EMC, when EMC starts, and if your encoders are not absolute, what is the vaue for joints an xyzabc (cartesian coordinates)?. We adjusted our kinematiks to be 0,0,0,0,0,0 for both joints and cartesian coordinates, so that at most two newton-raphson iterations happen (to avoid at most a no controlled number of newton raphson iteration in direct kinematics). Perhaps, EMC does not initialize those values as we think an then, a bigger number of iteratons were made on the start of HOMING, an then the previous mail PUM reason gets fully explained. If that where the case, we would be able to recover our previus shorter EMC period, if we can assure that 0,0,0,0,0,0 initial state for joint and cartesian coordinates is used from the start (if not overrided because we read this values from the file detailed above). Any thoughts about this are wellcomed Thank to all, nevertheless Javier & Aitor PD: We are making control in torke, because we think this allows to put all the meet in EMC (our drives allow velocity control also, but we think is not that elegant to use that configuration). Is this OK, or is there some reason to preffer velocity control over torke control? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
