Jump to content
OMRON Forums

andreef

Members
  • Posts

    9
  • Joined

  • Last visited

Everything posted by andreef

  1. Eric, thanks for the pointers. I found that blended moves were enabled for this coordinate system. Attached are the two profiles with blending enabled and disabled. When disabled my timing calculations, submitted move times and Motor[].Desired.Time would finally match. Here comes the big however, we are running this with an external time base to synchronize to a master clock that also defines our camera triggers. From the reference manual I get that disabling blending is doing the same as a dwell 0 in which case I lose synchronization to the external time base? By doing this I do in fact see a drift of about 2ms from one move to the next relative to my camera trigger. I guess I'll have to go back to blended moves. Is there any guidance on how to calculate the TMs for my moves and zero moves so that they fit inside a fixed time interval P? My motion program structure looks like this: / dwell at the start position for P X(currentPos) TM(P) TA(0) TD(0) TS(0) while(steps left) rtState == 0; X(currentPos+stepSize) TM(50) TA(50) TD(50) TS(0) rtState == 1; // now dwell for the rest of P X((currentPos) TM(P-100) TA(0) TD(0) TS(0)
  2. I am using motor programed for a linear TM move profile that is synchronized to an external camera/trigger and I came across some timing issues that I don't quite understand. I'm stepping my stage by a fixed step size, dwell for some time, step, dwell,... In tuning mode the motor would happily move the chosen step size in about 100ms (TA=50 and TS=0). My motion program would start with a zero move for dwelling X(absPos) TM(dwellTime) TA(0) TD(0) TS(0) then do the following absolute linear moves in a loop where the absPos would increase by the fixe step size. X(absPos) TM(100) TA(50) TD(50) TS(0) this is then followed by a zero move for dwelling X(absPos) TM(dwellTime) TA(0) TD(0) TS(0) I'm also using a separate plc to measure the move times of the stage. This is defined as the motor not moving anymore and the position error smaller than a threshold. if (Motor[motornum].DesVelZero == 1 && abs(Motor[motornum].PosError) <= feThresh ) These moves as monitored would take a total of about 190ms which is slower than expected. And here are the things I don't understand. 1. I noticed some stable offset in my timing which can only be caused by the first zero move dwell. For tests I replaced this by a dwell(dwellTime) and my offset would move. Does a zero move actually require time with TM=TA=TS=0? 2. Does a zero move set .DesVelZero to 0? This together with with the first point could explain why the move takes longer than expected. 3. The actual move time is also not entirely clear. At some point I found that .InvAmax and .InvDmax could limit my acceleration for a linear move and that helped some. From the step response tuning I know the stage can complete the move fast. If I use my linear move with TM=0 X(absPos) TM(0) TA(50) TD(50) TS(0) then this would take about 160ms. The step size for my moves is such that I should end up in a triangular profile (stepSize 4. Later I am planing on increasing the step size and should end up in a trapezoidal regime. For this timing/synchronization I was calculation a total move time of Ta/2 + Td/2 + TM where TM = stepSize/maxVelocity. Will I find timing differences with this as well? Thanks for the help in advance
  3. We have an application where we use 4 absolute encoders (32bits) on a rotating stage. The goal is to combine the 4 readings to achieve maximum precision (remove random translation of the rotation axis). We use type 2 ECTs to read the raw data with full 32 bit precision Acc84E[5].SerialEncCtrl=$63010B Acc84E[5].Chan[0].SerialEncCmd=$2114A0 // 32 bit 2bit status and 6bit polynom Biss C encoder EncTable[19].type=2; // 24+8 bit read entry; EncTable[19].pEnc = Acc84E[5].Chan[0].SerialEncDataA.a // address of lower 24 bit EncTable[19].pEnc1 = Acc84E[5].Chan[0].SerialEncDataB.a // address of upper 8 bits EncTable[19].index1=0; EncTable[19].index2 = 0; EncTable[19].ScaleFactor = 1.; EncTable[19].MaxDelta = 50000 * 256; This creates a conversion table which is signed 32 bits. Is there a way to make this 64 bit? When going forward and adding the four tables together using type 8 ETCs and scaling it by 1/4 we have the problem of the table rolling over and creating discontinuities (jump from 2^31-1 to -1*2^32) at an interval of 90 degrees (in units of the rotating stage). I know that for the ongoing operation only the delta Position value is relevant and I should be fine. However the 90 degree ambiguity creates issues with the absolute power on position. I was thinking of using the high 8 bits of one of the encoders and the lower 24 bits of the ECT where the 4 encoders are combined as my power up position info. Any thoughts on how to best implement the power on absolute position if the ETCs cannot be used as 64 bit?
  4. Thank you Jeff, that seems exactly what I was looking for. Andre
  5. Thanks Charles for the responding so quickly. I was aware of the two ETCs for position and velocity but I think that is not quite what I am after. The two encoders read the same track but are mounted diametrically so that we can use the two position readings to compensate for eccentricity of the rotating disk.
  6. We are integrating a high precision rotation stage into our existing system. The encoder system uses two 32bit Renishaw RESOLUTE read heads (BISS C protocol) to improve accuracy. We plan to use an ACC-84E card. First, we are interested if two read heads can actually be used simultaneously as a feed back to a single axis. And secondly we are wondering if anybody has done something similar and could provide some guidance. - Andre
  7. Thank you Steve. That helps. I was not aware that all the different commands write to the Gate3.Chan[j].Pfm register.
  8. Hi I'm fairly new to DeltaTau motion controllers so please forgive my possibly simple questions. I have to use an ACC-24E2S card to control stepper motors via an external amplifier. I configured the system for step&direction out put with the encoder loop closed internally as there is no separate encoder according to the basic setup that was posted here in the forum. This allowed me to drive the motor with the online jog commands. When I scoped the pulse train on the Phase D output of the card, I found a frequency of 32kHZ which is way to fast for our application. In reading the reference manuals, I thought that Gate3[0].Chan[0].Pfm together with Gate3[0].PfmClockDiv should control the frequency of the pulse train. Which it didn't. Luckily I found that the online jog command is solely governed by the Motor[x].JogSpeed variable which has a default value of 32 mu/ms and hence the 32kHz. I then moved on to create a simple linear coordinate system with one motor and writing a simple motion program that moves the motor absolute to a position, waits a couple of seconds and then returns. Here I found that the default speed seems to be 1 coordinate system unit per second no matter what the value for the PFM or jogspeed is. Entering a different speed F5 changes the speed accordingly. Now I'm wondering if and when the values for Gate3[0].Chan[0].Pfm and Gate3[0].PfmClockDiv will affect the frequency of my pulse train to the amplifier? Any answers will be greatly appreciated Thank you - Andre
×
×
  • Create New...