piefum
-
Posts
140 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Downloads
Posts posted by piefum
-
-
Are axis 3 and 4 mechanically coupled? their position response look very similar. Are these axis on air bearings? If they are, are we certain that these harmonics are not caused by air pressure?
the 6 axis form an Hexapod, so yes, they are all mechanically coupled. However, the joints at the extremities of each actuator are "floppy" to avoid mechanical interferences between axis.
-
I faced a similar problem twice with a heidenhain sincos encoder that was used in a UMAC with Control Techniques SLM system (the encoder was sampled and converted in SLM format with some dedicated adapters) and both the times I could see huge spikes on the actual position.
And both times the system had power supply problems, so check for noise in the power supplies
thanks a lot. Next week I will be on site and I am preparing some tools to investigate the power supply of the encoder.
BTW, I have just received this measure (figure attached), gathered at 2250Hz, of the encoder readings, while the actuators are in open loop (no current flowing into motors).
It is clear that the measure on actuators 1, 2, 5 and 6 have a noise of few bits, and this is fine.
Actuators 3 and 4 however presents this strange armonics, in amplitude 10x the noise on the other axes. Do you think this is related to the missing counts? This behavior is not repeatable and it seems it affects all the axes.
-
Hi Sina
In addition to the possibility of electrical noise passing through the voltage conversions and power supplies, I can think of one more explanation for this problem.
Is it possible that we are not sampling the incremental signal on the sinusoidal encoder fast enough and we are loosing counts? Have you tried increasing the encoder sample clock? You can try this by setting MI993 from default value of 2258 to a value of 2256 which increase the sampling clock from 10MHz to 40MHz. If the position discrepancy is caused by missing counts, it would be mitigated by this change.
thanks for the info. I can manage to implement this later this week.
Anyway, it is possible to know the exact flowchart of the sin-cos encoder sampling implemented in the GeoMacro? We are interested in the oversampling theory of the endat 2.1 reading.
I would like also to understand why the sin-cos signal is not reset every time it sees the real mark of the encoder between counts. I expected that the maximum drift of the encoder is less than a real mark of the encoder itself; in my case, the drift is way much higher (1/5 of an encoder turn).
thanks
gigi
-
Hi All
I have an issue on an heidenhain Endat2.1 encoder.
As you may know, this kind of encoder contains an absolute track (transferred digitally to the GeoMacro) and an incremental track (sin-cos, 1Vpp).
During runtime, I can read both variables:
- the loop is closed on the incremental track, so I can get Mx62 for that track
- Mi920 contains the endat reading of the encoder
Usually, I would expect that these the difference between these 2 tracks is more or less the difference of the resolution of the 2. That is almost always true, apart when I am moving; I could think that, during motion, the difference is higher because the Mi920 is updated at a lower frequency, because is not used in servocycle.
Unfortunately, sometimes happens that the difference of the two tracks is amazingly high, leading to motor phasing problems (other than repositioning problems, of course).
I talked to Heidenhain, and they told me that this behavior could come from a bad power supply: the encoder must be strictly powered at 5V +/- 5%, otherwise the incremental encoder could loose counts. This seems coherent with the fact that the actuator is now running on-site, where the power plant is 30 years old, and I never noticed this kind of feature in my laboratory, where the plant is 5 years old.
The question for you is: can a bad source from power plant make the 5V dc unstable at level of the primary feedback? I use a traco switching to generate the 24Vdc for the GeoMacro. Do you think it is possible that a big noise in the 220Vac can pass through the 24Vdc switching and through the GeoMacro circuitry that transform 24Vdc to 5Vdc?
thanks a lot
gigi
-
A few more items. You should be using d:$9E as this is the integrated error. There are no read only registers just perhaps the servo puts a value quickly back in the register. Error residual means the fractional part of the error.
When you set i163=0 you will clear $9E. When you replace i163 the integrator starts from zero. You can test this by placing a small gain in i133 once $9E has a large value. Set i163=0 then back to its value. You will see $9E slowly change from zero based on the position error.
ok, thanks, I can try later this.
As we discussed in the office about this problem, i believe something else is happening. Each time the blue line finaly stops increasing is when there is a jump on the red. It looks like something is sticking and then releasing.
Sorry, I forgot to mention that this particular test has been performed with the backlash compensation ON (however, the one that I showed you last week was OFF); the little jump that we can see here on the red line is the backlash comp kicking in; however, the effect of "gaining" errors (or similar) is independent from the backlash comp, the behavior is the same with the backlash comp OFF.
Then when it goes unstable the values on red and blue seem to get somehow out of phase which is what will happen when you drive the system with a large integrator and the integrator goes unstable. My feeling is that your system is being driven mostly by integrator and not much by proportional gain. Then something happens and the response of the integrator which must wind up and wind down and this happens too slow (as is normal in such a configuration) and it goes unstable.
Ok, understood. As you suggested last week, I took some time to re-tune the controller. Yesterday I came up with a new PID gains, where I drive the actuator mostly via proportional and feedforward, with less integral action. So far, (~10h of continuous motion), the actuator does not see any degradation on the steps. Hope this will solve that issue.
Thanks a lot for your kind help
gigi
-
Just to add to what Steve said. Setting ixx63=0 will zero the integrator. Setting ixx33=0 will freeze the integrator at the current value.
I understand that ixx63 = 0 set to 0 the output of the integrator and ixx33=0 freeze the integrator. But what I would like to test is to reset the input of the integrator (ixx63 reset also the input?)
I am currently running the tests and something strange appears: it seems that this strange behavior is accumulating during time. You can clearly see from the attached plots: the red line is the actual position, the black line is the commanded position and the blue line is my external reference. You can see that the overshoot at the end of the step is increasing and, at some points, it triggers the oscillations. During this test, I tried to set ixx63=0 and then again to its nominal value, hoping that this will clear the variable that is accumulating, but nothing changes.
-
Hi All
I am having a strange problem on an actuator. My actuator is a positioner, so its work is to move from a position to another (the motion time is ~1 sec), wait 30 s to 1 min and then restart.
Occasionally, after few minutes (or hours) that the actuator is performing such motions, it does not arrive correctly at the target position, but start to oscillate. We don't think is a temperature effect, because the temperatures of the actuator or the motor are only at +1.5 deg C than the environment.
In the attached plots you can see the position and the current flowing into the actuator, gathered at 2250 Hz. The blue line (actual position) of the position plot is a bit misleading: the mean value is centered to the target value (green line).
We have few candidates to this effect:
1) friction: we are developing some different models in order to replicate this effect, but at the moment none of them is working
2) saturation: is there some variable in the PID loop that can saturate and lead to effects like this one? The Integral Gain of this loop is quite high (i133=120000), as well as the the resolution of the encoder (131 counts per micron). Because the oscillations starts after some hours of operation, I think it could be a saturation on the integral path of the PID that can trigger events like that. Moreover, I can add that the frequency of these oscillations depends on the Integral Gain (the lower the gain, the lower oscillations frequency).
Is there a way to reset the register (in case it exists) that contains the integrated following error? I would like to try to set the integrated error to 0 when I am waiting in position in close loop for the 30seconds, avoiding too much integration in the waiting phase of my duty cycle.
I found the register "X:$000xA0/20 Motor PID integrated error residual", but apparently it is read-only.
Any suggestions?
thanks
gigi
-
The issue follows the motor though different channels and as of this morning different tuning setups. I'm going to continue trying some new things and get in touch with the motor reps.
Once I had a similar issue; my problem was a bad cable shielding: everything seemed fine if measured with the ohm-meter, but one motor was behaving differently from the others (that were exactly the same).
Then, I changed cable and connector for that motor (without removing it from the actuator) and the problem disappeared.
-
I have 6 AC Motors controlled by a geobrick all the motors are the same. This exact same setup has been used on a previous job and all the motors work fine. Today I was running all the motors to their zero position and applying the brake and turning them back off. When I started with the 5th motor i noticed a clicking sound that increased with speed. After checking the motor mechanically I believe it maybe electrically based. How would you go about checking this. All motors were phased and tuned with the same method and parameters respectively.
did you try to swap the motors? Does the problem follow the driver's channel or the motor?
-
Hi Steve
Check that you are not writing to the MARO Flag Register (X/Y$3440) as pointed to by I125 for motor 1. This location is where MACRO places the actual hardware flag information.
I don't write in $3440 registers; does an eventual write there cancel the status of the LED in front of the GeoMacro?
Does this happen for any other motors?
Actually, in about 10 hours of work, I had the problem only on that channel/motor. The customer says that sometime it happens on other motor, but I'm not sure they are looking at the same problem I am investigating.
thanks!
gigi
-
Hi All
I am having a strange Amp Fault on my Hexapod system.
My current setup is:
- UMAC cpu w/ Macro accessory board over RJ45
- No. 3 Geo Macro (GMH152) that controls the six actuators of the hexapod
Sometimes, when I am in close loop, I get an Amplifier Fault on a motor channel (Amplifier Fault Error, bit 3 on Y:$C0) without any other error on the Geo Macro (the LED on the GeoMacro is fix to 0 and the control word MI4 does not report error) or Macro Ring (no faults on the ring).
This error triggers appears almost randomly when I am in close loop: it can trigger both when I am moving at high speed, slow speed or even stilling a position (with very small currents flowing into the motor).
Do you have any idea on where I can read what triggered the Amp fault?
thanks
gigi
-
Hi All
how can I retrieve data recorded via the GATHER function using a circular buffer (i5000 =1 ) ?
It seems that the LIST GATHER can not be used to retrieve the data from the circular buffer, so what instructions shall I use?
thanks
gigi
-
[quote='majidy' pid='389' dateline='1272390157'] If buffer is full and wrap around is disabled no data will be gathered, but by enabling wrap around the data will over written to the existing buffer. Note that “List Gather” does not work when wrap around is enabled, so data should be read manually the same way as described in the above example. To enable the wrap around I5000 should be set to 1 or 3. [/quote] since the LIST GATHER command does not work with wrapped gathered data (i5000=1), isn't there any other command that does this job? I would prefer to not go deep in retrieving infinite Mvariables.
-
Hi All
is it available a simulink model that represents the PI current loop coupled with the PID loop of an actuator?
thanks
gigi
-
Hi All
I have a couple of questions about the PMAC Tuning Pro2 and in general on how to better tune the PI loop of the motor
First, my setup is a UMAC that controls a GeoMacro GMH152. The Motor to tune is a torquer motor.
1) is there away to tune the PI loop, other than the step response? I would like to inject white noise to the motor, if possible.
2) about the PI current loop tuning: I don't think the time scale of what the PMAC Tuning records is correct. My servo loop runs at 2250Hz, and if I look at the data gathering setup variable (i5049) during the test, it tells me that the clock divider is 1, so the data gathered from the PMACTunign should be 2250Hz, not the 9kHz supposed by the PMACTuning. This is consistent to what I saw on the performances of my actuator, but not on what the PMACTuning tells about the rise time and the badwidth of the motor. Am I missing something?
Thanks
gigi
-
The correct descriptions of the registers is as follows:
X:$000xB8/38 Motor commanded quadrature current
Y:$000xB8/38 Motor commanded direct current
X:$000xB9/39 Motor actual quadrature current
Y:$000xB9/39 Motor commanded direct current
I'm sorry... but I can't understand: this is again a typo or Y:$B8 and Y:$B9 are the same (commanded direct current) ?
-
3. Direct PWM Control
In this method, the actual (measured) quadrature current is available which is scaled based upon a 16-bit DAC where the data is in upper 16 bits of the register is in full ADC scale on the amplifier. This register can be located in the PMAC memory map titled “Y:$000xB9/39 Motor actual quadrature current (0 for microstep)”.
Full quadrature output from PMAC represents current output equivalent to full ADC reading of the amplifier.
Torque Output of the Motor = (Motor actual quadrature current (16-bit Signed) / 2^15) * Amplifier Full ADC Current Rating * Motor’s Torque Constant
Hi Sina
I have some problem about the reading of the actual and commanded current at the motor.
My setup is: UMAC CPU + GeoMacroDrive 15R2.
At the moment, I am computing in a PLC program the actual RMS current inside my motor following the instruction on document "Calculating Equivalent Motor RMS Currents" that the guys at DeltaTau Switzerland give us. This is almost consistent on what you write before, except that I use both Y:$000xB9 and X:$000xB9 to compute the RMS current inside the motor (and the Y:$B9 is always near zero).
Now I want to read both the actual current and the commanded current at high frequency (using the gathering instructions), in order to compute the transfer function of my system and see how my filtering is behaving on the hardware.
So, the questions are:
1) the X:$000xB9 value is described in the Turbo SRM as "Motor commanded direct current", but actually I am using it as the ADC reading (so as "Actual" value, not "Commanded"). Is that a typo on the doc or simply a misundestaing on my side?
2) in case, where is the "Commanded" current to the motor (to compare wrt to the "Actual") ?
3) I want to use the gathering functionality to record the above specified variables. At the moment, I am reading the X:$B9, and this reading is consistent with what I was reading via the aforementioned PLC, except that there is a scaling factor that I cannot undertand (1/96/32 * 10). Am I losing some gathering conversion factor?
many many thanks
gigi
-
[quote='Sina' pid='390' dateline='1272390615'] The following document explains how to decode the data in gather buffer: [/quote] Hi, thanks for the document. However, it seems this procedure does not work for 48 bit float values. This is what I am doing: Variable to gather = P2000 = 0.1 I500x = $C067D0 ($C to gather float values + xxxxx address) The gathered value I get from the UMAC is (hex) 6666666667FC. I use your instructions to decode this hex value, and I get the following int values: Mantissa = 1717986918 Low = 6 Exp = -3 The value, before multiplying (1<
Hi
To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real".
it is not completely clear to me in what scale is the "Max Change (LSB)" parameter in the ECT setup: it is encoder counts? 1/16 encoder counts? anything else? I am looking at the TURBO PMAC USER MANUAL (Sept 12, 2008) but I cannot find the answer...
thanks
gigi
Hi All
In reply to Brad, I am using a UMAC with 3 GeoMacros connected via RJ45.
The encoder is a Heidenhain EQN425, that has Endat 2.1 feedback (absolute serial plus sin/cos).
Usually these types of errors occur when the position feedback data is transferred numerically to PMAC, as a parallel or serial word. If noise causes a bit to be read wrong, PMAC can think there is a huge position error. For example, if bit 15 is flipped, that causes a 32K count error.
I thought the same, even if the difference in the following error was not exactly 32768. Moreover the "manual" following error trap was working, so I think this is the proof that the error is only a noise somewhere in the path (between encoder and geomacro or geomacro and UMAC).
To counter this, we have "filtered" reads for this kind of data in the encoder conversion table that allow you to specify a "maximum change" value (from one servo cycle to the next) that you will regard as "real". If the data read in a cycle creates a change from the previous cycle that is bigger than your threshold, PMAC will discard it and calculate a substitute position that uses the same change (velocity) as in the previous cycle. You should set your threshold slightly greater than the maximum true velocity you expect to see.
ok, thanks a lot!
I have never used this kind of filtering inside the ECT... I can test this tomorrow and see if this can help.
thanks a lot for your help!
Gigi
Try a non solid state device (real switch) to test. This could indicate a borderline conductivity or current draw issue on this channel.
I just tried shorting all the input ports to VCC or GND: it works on PLIM1, MLIM2 and PLIM2, but not on the MLIM1.
Hi All
I think I have a noise issue on a Hexapod system that has been just put on field. This problem was never detected at my laboratory.
The problem is that I have a bad encoder reading once in a while (every few min) and this is causing a triggering of fatal following error, stopping the machine in an error state.
I assume that the error comes from noise because if I read at high frequency the foll err (using pmacPlotPro with gather period = 1), I see that the following error is almost constant at few counts, and then immediately it jumps to 30000 counts (triggering the fatal foll err).
I had this kind of problem a few years ago and I solved this by disabling the following error in the UMAC (Ixx11 = 0) and writing my own PLC that controls for the following error, halting the system only if the following error is outside the permitted range for 2 consecutive readings.
Is there a way to have this kind of control directly on the umac, without passing my own PLC?
Do you have any other idea on how to filter this encoder reading?
thanks
gigi
Hi All
I am having problem with one Geo Macro GM15-2 that we bought a couple of years ago.
I am using one of the GeoMacro that was intended to be a spare: this GM has been successfully used only for few hours in June 2011, than has been put aside.
I resuscitated this driver in order to test the spare actuator unit, and now I have some issue regarding the PLIM and MLIM input of GM channel #1.
It seems that the MLIM1 is insensible to any signal connected to it: the same signal that engage or disengage the PLIM1, MLIM2 and PLIM2, is not doing anything on MLIM1.
Do you have any idea on how to operate or better understand what is happening on this connector?
thanks
gigi
The ACC-U8 (or any Umac Backplane card) would be covered as a CE certified product covered by the certificate found in the UMAC Sytem manual.
The ACC-66E does not have a certifcate but its circuitry is identical to the ACC-65E so I do not see any problems with it causing any issues when you certify your machine. I believe the ACC-66E was released after we performed our official CE certification tests.
The Geo MACRO drive has not been CE certified by Delta Tau. Use standard CE machine wiring techniques (CE filters, shielding to GND, etc..) for power and motor/encoder/IO wiring and you should be AOK.
thanks a lot!
ciao!
gg
Endat 2.1 + GeoMacro: voltage stability
in Turbo PMAC
Posted
correct for the GeoMacro; the CPU is a TURBO UMAC CPU.
ok, thanks a lot. In attach you can find the I-var configuration as well as the 3 GeoMacros conf files.
UMACcfg.zip