acarder

I have a set of kinematics that is setup to have two modes. In mode 1 (P1338 = 2), I have a complicated relationship where I am not able to determine the commanded position based on the axis positions, so I use the last commanded position in the forward kinematics. In mode 2 (P1338 = 3), the kinematics are linear, but I use the motors current position to calculate the Q vars since these axes are always absolute. Here is the problem: When I start a program in the mode 1 of my kinematics and try to switch over to mode 2, I never get the right starting point when I start commanding the axes. I switch the mode with a p variable, issue a pmatch surrounded by dwells, and then command the axes to go to zero. If I have been in mode 1 and the axes are not at zero to begin with, then the machine does not go to zero. If I am using the actual axis positions to generate the starting commands (Q Vars) in forward kinematics and I issue a pmatch, what could possibly affect the kinematics? It seems as though a hidden command from the last kinematic mode is affecting the outcome. I have already checked my position bias (Mx64) and compensation correction (Mx69). If I run my routine when my last program was ran in my mode 2 kinematics, everything works great. Inverse Kinematics: IF(P1338 =2) CalculationA = Complicated relationship depending on commanded A/B and direction machine is heading CalculationB = Complicated relationship depending on commanded A/B and direction machine is heading P5 = CalculationA*Scale P6 = CalculationB*Scale ENDIF IF(P1338 = 3) P5 = Q1*Scale P5 = Q2*Scale ENDIF Forward Kinematics: IF(P1338 =2) ;Since my machine is not moving at the time forward kinematics are ran, I cannot know what command caused the current position, so I use the last commanded P5 and P6 Q1 = P5/Scale Q2 = P6/Scale ENDIF IF(P1338 = 3) ;I can't seem to trust the last commanded, so I use the current position as my start (my A/B axes are always absolute) Q1 = M562/(32*I508)/Scale Q2 = M662/(32*I608)/Scale ENDIF My routine to zero out some axes if I start in mode 1 (P1338 = 2) kinematics... DWELL20 P1338 = 3 ;Switch to direct command of A/B axes DWELL20 COMMAND "PMATCH" DWELL20 ABS RAPID A0 B0 DWELL1000 P1338 = 2 ;Switch to complicated kinematics DWELL20 COMMAND "PMATCH" DWELL20 Any insight would be very useful, Thanks Adam

I6800 = 5895 I6801 = 0 I6802 = 4 I8 = 2 I10 = 4193066 MI992 = 5000 MI998 = 4

I have an ethernet ultralite running Yaskawa sigma 5 drives/motors (torque mode). I am trying to reduce buzzing/vibration by putting in some deadband settings, but they do not seem to work. I am following the manual and I have roughly 10 counts of following error while sitting idle and buzzing. So I set Ixx64 to -12 and Ixx65 to 640. I would expect this to reduce my buzzing when I am sitting, but it seems to make no change. I am not using the extended servo algorithm. Is my problem in the yaskawa? If I reduce Ixx30 by 20%, the resonance goes away, but the dynamic performance is much poorer. Thanks, Adam

Sina, If I am running trajectory calcs in a background PLC and I have a lookahead buffer, can I am assume my calculations on trajectory will be behind by the lookahead amount? I had originally planned on using the inverse kinematics Q variables and a last known axis location (stored during the last iteration of inverse kinematics) to compute a point to point trajectory in which to calculate path normals from and ultimately command some motors. Obviously there are some special exceptions when you first start running and after pmatch etc. Is there a better way to do this without running into problems with lookahead? Thanks, Adam

Is there a built in function to determine the X-Y-Z components of the systems current trajectory without doing the calculation myself in kinematics? I have a set of kinematics that command a 5-axis head based on a few external parameters, the trajectory, and a normal to this. Thanks, Adam

Curt, your solution would work well, but unfortunately I am running custom software that manages tool offsets and position bias for individual programs. Therefore, the Mx64 variables get changed a lot after homing. I have currently decided to kill the motor, set Mx62 to my desired position , and J/ it afterward. This works well and if done in a PLC after homing does not skip a beat. Still a bit hack, but it allows me to get around some Ix26 limitations.

Does anyone know how I might set the position of a motor after homing to a non-zero value without going to zero first? I have a 5-axis head with a home limit near one of the over travels and the amount of home offset to actually get to the zero position will saturate Ix26 many times over. I would like to home close to the over travel and then call that position say 90°. I am already putting a small program in my homing routine to get to my physical zero, but it seems kind of hack. Thanks, Adam

I have a Eth Ultralite Controller with 2 macro ICs and I am having trouble configuring the second IC. I am using ACC85 with Yaskawa drives and the ACC85 manual does a good job describing the setup of the first IC, but the steps for the second are unclear and none of the appropriate values will actually change for me (I6890 etc. just reverts to the value it was when I try to set it). Are there some application notes or a better manual for setting up slave MACRO ICs? Secondary question, if I do get the setup correct, how do I address nodes on the slave IC from the terminal? For node 0 on the master I might ask for MS0,MI23, what would it be for the first node on the slave? Thanks, Adam