Jump to content
OMRON Forums

leandro.martins

Members
  • Posts

    88
  • Joined

  • Days Won

    6

Everything posted by leandro.martins

  1. Hello Eric I checked the values of the structures and it seems as expected (first image) Using the fft of the plot tool of the IDE, we can see that there are some frequencies that appear in Gate3[1].Chan[0].ServoCapt doesn´t have the same amplitude as the Motor[1].ActPos frequencies (second image) On another hand, when we plot the fft of Gate3[0].Chan[0].ServoCapt and Motor[1].ActPos all the curve is superimposed (third image)
  2. Hello all, I am controlling a direct-drive 3-phase brushless that have 2 encoders, disposed 180 degrees apart from each other. To minimize the eccentricity errors from the encoder's scale, I'm trying to take the average of both to use as position feedback, but when I post-processed the data from Motor[1].ActPos, Gate3[0].Chan[0].ServoCapt (main encoder), Gate3[1].Chan[0].ServoCapt (auxiliar encoder), it seems it is using only the Gate3[0].Chan[0].ServoCapt as the source. //****************************************************************** // Encoder Table - Averaging encoders settings EncTable[31].type = 8 // Addition of two sources EncTable[31].pEnc = Gate3[0].Chan[0].ServoCapt.a // Ch. 1 EncTable[31].pEnc1 = Gate3[1].Chan[0].ServoCapt.a // Ch. 5 EncTable[31].index1 = 0 EncTable[31].index2 = 0 EncTable[31].index3 = 0 EncTable[31].index4 = 0 EncTable[31].index5 = 0 EncTable[31].ScaleFactor = (1/2)*(1/256) //****************************************************************** Is there some point that I'm missing? Tks
  3. Hello Steve As the filedepot is closed and the link is not working, is there any other place with the instructions to import the C API help, or at least a document with the functions documented? thanks in advance
  4. Hello Eric I may have misinterpreted it, but the manual recommends 20kHz and 30kHz is the maximum frequency. Could you confirm if the recommended is 20kHz or 30kHz? Thanks in advance.
  5. Hello, I guess it's necessary to change the values of: Motor[11].pAbsPhasePos Motor[12].pAbsPhasePos For the proper phase commutation If the motor is a stepper without encoder, for example, you will also need to consider the changes in Motor[11].pAbsPos Motor[12].pAbsPos Motor[11].pEnc Motor[12].pEnc Motor[11].pEnc2 Motor[12].pEnc2
  6. Yes, the behavior that a I expect is Motor 8 being killed while the rest remain controllable. The Motor 8 is always in Coordinate System 1. I repeated the tests with simulated motor in another Powerbrick and all the cases results in the expected behavior. Perhaps when the problem occurred some statement could have been missing, I am trying to reproduce the error. Anyway, I will test again with the real motors on the first controller at an opportune time
  7. I am implementing this solution and have tried some similars approaches, but without success Sys.pAbortAll = PowerBrick[0].GpioData[0].a Sys.AbortAllBit = 31 Sys.AbortAllLimit = 5 Coord[0].AbortAllMode = 3 // CS0 dont affected by abortall Coord[1].AbortAllMode = 1 // CS1 motors killed after abortAll 1) &1 #8->I As I can see using Motor[x].Coord, the remaining motors are allocated in the Coord[0] by default, but when Sys.AbortAll=1 all the motors are aborted. Also tried to change the remaining motors of the system to Coord[2] 2) Coord[2].AbortAllMode = 3 // CS2 dont affected by abortall &2 #1->I #2->I #3->I #6->I #5->I And I defined an axis for each motor: 3) Coord[2].AbortAllMode = 3 // CS2 dont affected by abortall &2 #1->A #2->B #3->C #6->X #5->Y but none these attempts worked as I expected. There is something that I am missing? FW 2.5.4.0 CPU PowerPC,APM86xxx
  8. If I undestood correctly, I have some ideas some ideas of what might be happening. Is there an overlap between the scales? If it exists, you can test change the parameters in this region. I suppose the loss happens when the encoder head cannot read any signal, because it is out of scale, not in the changing. You can also check this assumption reading the parameter Gate3.Chan[j].LossCapt (latched value) or Gate3.Chan[j].LossStatus (current status). If I am right, you are probably configuring as below Motor[x].pEncLoss=Gate3.Chan[j].Status.a In these cases i'm used to set Gate3.Chan[j].Status = 0 to clear the failure I hope this helps in some way
  9. Thanks for the answer JeffLowe and curtwilson, Almost all of the stages that we acquire uses Renishaw's external interpolator. We already evaluating to get a Delta Tau sine interpolator. Summarizing, if "count error" flag doesn't get high we don't have to worry about the quality of the sinal acquired. Right?? Our main concearn now is the peak in the PosError, that increases the control effort during this peak. This value of 2000 counts occur only during one clock cycle, and in the Servo Frequency that we're using (20 kHZ), it represents the maximum count rate that the interface of 40 MHz can read. Emphasinzing that this peak is not periodic and only happens in the positive direction movements. We came to consider that it could be a rollover problem, but this hypotesis was discarded plotting the PosError and the ServoCapt register. We tried to set the MaxDelta=32767 and apparently it compensates some of theses peaks, but in some point the response begins to diverge. Some useful information: - CPU: PowerPC,APM86xxx - Firmware: 2.4.0.180 - IDE: 4.2.1.19 What is the possible cause of this peak and is possible to work with the 40 MHz interface since we set properly the MaxDelta?
  10. Hello everyone, We have a rotary stage with the following setup: - AC Brushless motor with 18 poles; - Sensor hall; - Incremental encoder (sinusoidal); with interpolator x20k 40 MHz; - EncClockDiv = 0 (100 MHz). We already did the Manual Phasing procedure to find the PhasePos on the encoder index and we're able to use the sensor hall for the commutation. A good stability performance was achieved, but during the jog it apresents a strange behavior. In the positive jogs a peak of 2000 counts occur in the PosError. Trying to find the reason we discover that the LossCapt bit is always 1, even if we set to 0 in the terminal. The plot with the LossCapt together with the LossStatus show us that the LossStatus gets high many times before the LossCapt rise up. We also did some teste with a interface of x20k 10 MHz, and with the EncClockDiv = 2 (25 MHz) the 2000 counts in the PosError doesn't happens anymore. Does anyone have any suggestions for what may be happening? Thanks in advance. Leandro Martins
×
×
  • Create New...