Jump to content
OMRON Forums

Felix

Members
  • Posts

    14
  • Joined

  • Last visited

1 Follower

Felix's Achievements

Apprentice

Apprentice (3/14)

  • Conversation Starter
  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Curt, attached is a plot showing the instantaneous change of the commanded velocity when I issue the "hold" command followed by the "abort" command. As you can see, both my AbortTa and AbortTs for this motor have rather large values to demonstrate that AbortTa and AbortTs are not being adhered to for this case. Thank you, Felix
  2. Curt, that is what I had thought first but is not the case. I have set my AbortTa and AbortTs to very high values and have confirmed that they work as intended when I issue an "abort" command only. The instantaneous change of the commanded velocity only occurs when I first issue a "hold" command followed by a "abort" command. Regards, Felix
  3. On our PowerPMAC system (Firmware 1.5.8.0) we notice the following behavior when executing a motion program where one of the motors is defined as a spindle using the ->s0 construct. When we are executing a motion program with the spindle running at speed and issue a hold command, the linear axes come to a a stop with the spindle still running as expected. If the hold command is followed at any time by a abort command the spindle desired velocity instantaneously changes to zero causing the spindle motor to fault with a fatal following error fault. Preceding the abort command with a quit command does not change this behavior. I believe that this is not the intended behavior for a abort command with a coordinate system where one of the motors is executing as a spindle. Is there anything I am missing? Thank you, Felix
  4. I second Dave's observation. We also heavily use send statements for debugging in our code and have run into the same issues. We had to resort to guarding our send statements by a if (DoSend) send 1,.... construct. Regards, Felix
  5. You can set these elements both from within a program/plc as well as from the terminal. Just remember to set Sys.WpKey to $aaaaaaaa prior to writing to the elements. Regards, Felix
  6. When assigning EtherCAT slaves to the ECAT.IO structure I have run into problems when the resulting IO structure has non continuous indexes. The following code fragment will result in a configuration which works perfectly. I can observe the value of ECAT[0].IO[1].Data changing as expected. However, if I change ioIndex to 10 prior to initializing the second slave, as indicated by the comment below, ECAT[0].IO[10].Data does not update. master = 0; ioIndex = 0; ECAT[master].IO[ioIndex].Slave = 0; ECAT[master].IO[ioIndex].Index = $6000 ECAT[master].IO[ioIndex].SubIndex = $1 ECAT[master].IO[ioIndex].BitLength = 16 ECAT[master].IO[ioIndex].Input = 1; ioIndex = 1; //CHANGE THIS TO 10 for second run i = 0; while( i < 2) { ECAT[master].IO[ioIndex].Slave = 3; index = $6000 + i*$10; ECAT[master].IO[ioIndex].Index = index; ECAT[master].IO[ioIndex].SubIndex = $11; ECAT[master].IO[ioIndex].BitLength = 32; ECAT[master].IO[ioIndex].Input = 1; ioIndex = ioIndex + 1; i = i + 1; } ECAT[master].IOCount = ioIndex; call timer(0.1); ECAT[master].Enable = 1; Is it possible to assign slaves to ECAT.IO in such a manner that the resulting ECAT.IO structure is not continuous or am I missing something? I am currently working on an initialization routine for a project with about 100 EtherCAT modules and want to make sure I understand the mapping of slaves to ECAT.IO before getting too far. Thank you, Felix
  7. Do you have any documentation available for the PowerPMAC EtherCAT option? Thank you, Felix
  8. Brad, I believe the proper syntax for configuration of a single master with redundancy is MASTER0_DEVICE="00:50:C2:12:C1:XX" MASTER0_BACKUP="00:50:C2:12:C1:XY" However, it appears that IgH has not yet implemented this functionality as querying the state of the ethercat module always results in a status of waiting for the Backup Port. This post in the etherlabs forum seems to indicate this as well: http://lists.etherlab.org/pipermail/etherlab-users/2010/000868.html Regards, Felix
  9. Felix

    Ethercat

    Is there any information available on how a PowerPMAC with EtherCAT looks like? Where are the EtherCAT ports located and are you able to retrofit an existing PowerPMAC with EtherCAT Ports? Thank you, Felix
  10. [quote] A few points: 1. Even when you are using arctanenable the compare is based on timers. It is not practical to sample the A to D for every subcount. [/quote] 1) I understand that the encoder sampling frequency is determined by setting Gate[3].EncClockDiv which is set to zero in our case to give us an encoder sampling frequency of 100Mhz. With the encoder sampling at this high of a frequency and a axis that is moving sufficiently slow we should be able to sample the encoder signals fast enough to allow for auto increments less than 4096... [quote] 2. Because this is based on timers a reversal without a quadrature edge will cause a problem. The vast majority of people who will use this will only be going one direction but if the CompAdd is less than or equal to 2 cts a reversal might cause a problem. [/quote] 2) I am not sure I am following you here since we are using a sin/cos encoder and therefore have no quadrature counts. When we are using the position compare feature with auto increment we are moving in one direction only (as a matter of fact for testing we simply jog the axis) so there should be no problems with regards to reversal of direction. Furthermore from what I understand of the way the position compare functions we are fundamentally dealing with a simple comparison of the actual position to the CompA and CompB values. Assuming that the encoder is sampled once per encoder clock cycle and therefore the arctan calculation is also executed once per encoder clock cycle there should be no reason for the position not to function with auto increment values much smaller than 4096 if the axis does not move further than the auto increment in one encoder clock cycle. If the A/D converter can not function at this high of a frequency then what is a realistic limit? [quote] 3. The system is designed so that you can compare at a subcount accuracy. What I mean is that you can auto increment 10.3 counts but if you want subcount intervals (increment 0.3 counts) things will get tricky because of point 2 above. Remember that encoder dither is also a reversal and when the increment gets small you must also consider the stablity of the encoder signal. [/quote] 3) I am getting a little bit confused here by your terminology. Do you consider a count an encoder zero crossing (we are dealing with a sin/cos encoder) or are you talking about intervals smaller than 1/4096 quadrature count? Dither should not really matter for the position compare feature as long as the dither frequency and magnitude are such that the encoder sampling can keep track of the dither. [quote] To test your system do the following. 1. Setup the CompA and CompB ahead of your motor. Give enough distance that the motor will be at constant speed when you jog that direction. 2. Because you are not bracketed you must write to the initial state Gate3[0].Chan[2].EquWrite 3. Now Jog the motor and see that the auto increment starts working. On my system, moving the motor by hand, I can get my increment to 512. Let me know what you can get. [/quote] Using your setup, the smallest increment I have observed working was 2048. However it only worked for a few seconds before the position compare output stopped. Furthermore if I increase the speed of our axis the smallest increment I can get to work is 4*4096 which amounts to triggering once per quadrature count/zero crossing of the sin/cos encoder. For smaller increments at high speeds the position compare is not consistent. The position compare either stops all together or the pulses become distorted meaning that the duty cylce and frequency changes. It appears that for these smaller increment the position compare feature can not keep up. Here are some numbers for you to consider. The encoder we are using has 23600 lines per revolution and for high speed testing we are turning the motor at 2400rpm. For an auto increment of 4*4096 this leads to a frequency of about 3.8MHz out of the position compare output. In other words, we are no where near the advertised limit of 100MHz for the position compare output. Comments and thoughts? Thank you, Felix
  11. What is the lower limit for the auto increment when using the position compare feature on the ACC24E? When using the position compare feature according to the manual all registers are in units of 1/4096 of a quadrature count. Applying the same logic as with the Turbo PMAC the smallest permissible auto increment should be 4 (or 1/1028 of a quadrature count). However when trying use the compare feature with auto increments values less than 4096 (or 1 full quadrature count) the position compare output does not fire reliably. What is the reason for this and how to do you determine the smallest permissible auto increment for a given application? This is the PLC code used to initialize the position compare logic: open plc 18 local tmp; tmp = Gate3[0].Chan[0].ServoCapt; Gate3[0].Chan[0].CompAdd = 4096; Gate3[0].Chan[0].CompA = tmp + Gate3[0].Chan[0].CompAdd*0.25 Gate3[0].Chan[0].CompB = tmp - Gate3[0].Chan[0].CompAdd*0.25 disable plc 18 close Thank you, Felix
  12. When changing the ACC24E3 phase frequency or servo clock divider motor jog commands do not result in the expected speed. After changing the phase frequency from its default value of 9.035kHz to 36.138kHz (9.035kHz*4) the resulting jog speed for i122=500 is 2000cts/msec (500cts/msec*4). The same behavior occurs when changing the servo clock divider. The resulting jog speed appears to always be scaled linear with the change in effective servo clock frequency. In both cases the Sys.ServoPeriod was updated according to the instructions given in the ACC24E manual. Are there any other parameters that I need to change? Here is the PLC code used to change gate array paramters: open plc 7 Sys.WpKey=$AAAAAAAA; Gate3[0].PhaseFreq = 9035*4; Gate3[0].ServoClockDiv = 3; //ServoFreq = PhaseFreq/ServoClockDiv Sys.ServoPeriod = 1000*(Gate3[0].ServoClockDiv + 1)/Gate3[0].PhaseFreq; Sys.WpKey=$55555555; disable plc 7 close Thank you, Felix
  13. The result of a home command for a motor that is connected to the ACC24E3 and uses a sinusoidal encoder for feedback with the arctan extension enabled appears to depend on the number and sequence of home commands given. This is what I have observed: After a home command has been given via the terminal (#1hm) the motor starts moving and reverses direction once it passes the index mark as expected. However, instead of coming to a stop once it reaches the index mark (no home offset is programmed Motor[1].HomeOffset = 0) the motor does not stop but keeps turning until it passes the index mark again after a full revolution of the axis and then comes to a stop about a 1/16rev past the index mark. If another home command is given immediately once the first home move has completed, the axis moves past the index mark, reverses direction passes the index mark again and comes to a stop about 1/8rev past the index mark with out going a full revolution first. If however any axis move command is given before the second home command is issued the axis behavior for the second homing move is identical to the first homing move. In other words, depending on the sequence in which home commands are given the resulting home position is different. In none of the cases described above is the result what I expected, a motor position of zero at the index mark. The encoder index mark is not direction sensitive and is a TTL pulse that is one encoder line wide. The gate array is configured to trigger on the index high (Gate3[0].Chan[0].CaptCtrl = 1) and the arctan evaluation is enabled (Gate3[0].Chan[0].AtanEna = 1). Any suggestions on what may be going on? Thank you, Felix
  14. Attempting to update the Power PMAC firmware the fails due to the following: Kernel has unusable page offset. Contact Delta Tau for kernel upgrade. The complete error log is attached. We are currently using the latest Power PMAC Suite with Version 1.0.0.28 Date: 08/17/2009. Our Power PMAC is currently at Firmware Version 1.0.0.17 Date: 05/07/2009 Could you please provide a solution for this problem? Thank you, Felix
×
×
  • Create New...