piefum

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

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.

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 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

ok, thanks, I can try later this. 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. 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

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

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.

did you try to swap the motors? Does the problem follow the driver's channel or the motor?

Hi Steve I don't write in $3440 registers; does an eventual write there cancel the status of the LED in front of the GeoMacro? 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

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) ?

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 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). 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). 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

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

thanks a lot! ciao! gg