gmschoon

With a clean install of Power PMAC IDE 2.2.0.39 and a new "empty" project, there are build errors thrown for the background C program "capp1.c". These errors are linked to the following "#ifndef" in "gplib.h": #if !defined(__QNX__) && !defined(WIN32) #include #include "eip.h" #include "ethernetip.h" #include "networkhandler.h" #endif These includes (ethernetip/eip) did not exist in the IDE version 1.6 we had been previously using, so we don't have immediate need for them. We will likely remove these includes to get around the errors, but maybe there are better suggestions? Thanks

Sounds good. We shall create a phase routine assigned to the enabled virtual motor, and experiment with the number of averaging samples. We would likely go for effective "voltage mode" control, however, accurate torque control is critical for our application. What we could do is reduce the forward path gain pair relative to Ipbgain, which would bring performance closer to that of voltage mode control. Also, just to confirm (apologies for the slight inquiry deviation), given that any filtering effectively delays the current feedback, Motor[x].AdvGain should likely be nonzero & defined as a function of the filter number of samples. According to the manual, this would normally only be done for commutation frequencies exceeding 1kHz. Thanks

We are using the Power PMAC configured for direct PWM control of Geo Drives, and are looking for ways to reduce electrically induced torque ripple, possibly by filtering current feedback. A similar issue was previously discussed in a now closed thread, however attempted with a background plc routine: http://forums.deltatau.com/showthread.php?tid=756 Our phase routines are executed at 16kHz, with the servo loop at 1kHz. This means we have effectively 16 current samples between each new IqCmd, however, any processing of current feedback values degrades performance of the current loop by the latency factor introduced (<16 samples). If we implement a moving average filter on the direct & quadrature axis feedback currents (<16 samples), this could/should assist in removing random noise, while minimally impacting the servo step response. Implementing the moving average filter on the current feedback effectively means that phase commutation must be performed manually in the phase routine, as IdMeas & IqMeas will not be used directly in closing the current loop. Any thoughts on this approach? I imagine that for the relative short moving average length, any gains may be insignificant or not worth the custom phase routine development.

Based on the data we have collected, we have not been able to identify much of a correlation between IGBT temperature and offset of the A, B phase current sensors. As the IGBT temp sensor is (presumably) part of the integrated IGBT module attached to the heat-sink, and the current sensing is performed on two separate PCB's which are largely thermally independent, this result is likely unsurprising. We are currently performing an iterative offset nulling routine, which works well; however when the motors are enabled continuously for extended periods of time the offset drifts. Rather than stop the motors to calibrate offset, we would rather establish a mathematical relation as you mentioned. If we could place a temp sensor on the current sensor board, the correlation would likely be better than that using IGBT temp data.

Unfortunately, torque feedback is not an option. Indeed, as we are not performing commutation using hysteresis current control, the BW is not an issue. However, sending effective torque commands still exists in the form of rotor translated Iq (Id can be ignored unless flux control is desired), which will contain a sinusoidal component correlating to measured phase current offset and rotational velocity. We could attempt to thermally isolate the existing current sensors, but perhaps the level of intrusion required to perform such would better invested into a well designed 3-phase external sensor array. Ideally, I would design an entirely new inverter using SiC FET's with 3-phase current sensing to allow higher switching frequencies and remove current offset. As regards motor design, tighter tolerances in the placement of rotor magnets and stator layout would naturally be better.

Thanks for the quick response. We had been examining the possibility of using any temperature/current offset relation to mitigate the effects of drift from the two current sensors (Ia, Ib). The principle issue is that most drives typically employ sensing of two of three motor phases, with the third phase current being inferred from the two measurements. Necessarily, this assumes a balanced 3 phase system, and any offset in the two measured phases propagates through the calculation of Ic. Again, while this is not an issue for many applications, we have requirements for precise torque control, primarily at very low velocities. As you suggest, we could attach a temp probe to the current sensing device, and we shall try to track down the current sensor module manufacturer to determine any established temperature response. We also thought that it would be more effective to create an external current sensor module that measures all phases using integrated hall sensors (Allegro MicroSystems, etc), as this would solve almost entirely the problem of sensor offset. Possibly DT would be willing to create (or assist in creation of) such a sensor module?

We are attempting to establish a relationship between IGBT temperature & phase current sensor offset on Geo direct PWM amplifiers/drives. Thus far, data we have collected does not suggest much of a correlation between IGBT temperature and the current sensor offset. While one would typically expect sensor offset to be a partial function of temperature, we are not sure about phase current sensor to IGBT proximity on the Geo direct PCB. If anyone is familiar with board layout, such information would be most helpful. Thanks.