Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[e*clipse]

Originally Posted by thingstodo

We use a megger on motors to see if there are ground faults, resistance line to line to see if the phases are balanced - if the phases are shorted part-way through the resistance won't match ... that's about it. Once or twice we've checked insulation with a hi-pot. Sorry for the jargon - I can look up the *REAL* names of the instruments if you like

No worries on that - I actually have a hi-pot tester - it seemed like a good idea to get something like that when I'm messing w/ 650vdc.

To measure small resistance on large motors we use a ducter. It is an ohm-meter that uses higher current to measure small resistance. 1 amps or 10 amps. The probes are sharp and there are two for + and two for -, so you get a reading on 'corrosion' as well.

The vendor that we use to rewind our motors uses this RLC type of equipment as well as partial-discharge .. a method of measuring insulation breakdown.

Hmm, so it seems the RLC type of equipment ( which basically injects a frequency to measure capacitance, inductance, and resistance) would be very appropriate for this motor control stuff we're doing. After all, we are forcing the stuff to work at various frequencies, not DC.

I did find a cheaper version of the BK precision device - the 875B. It does appear to work in the ranges we're interested in, however the frequency it injects is 1kHz. The more expensive versions allow higher and lower frequency measurements and connection to a PC through a USB port.

As I mentioned - our industrial controllers do their own tuning. It's a 5 minute process when we change a motor to tune to the new motor and away it goes. It just means I have to drive to site some evenings and weekends when motors fail in production ...

Nope

Thanks for getting back on that!

E*clipse

[e*clipse]

Paul,

What programmer/debugger are you using?

I'm trying to get my ICD2 to work with MPLAB IDE v8.92 and it won't install the USB driver.

Do you use something else? I'm getting ready to turn it into a frizbee.

- E*clipse

[thingstodo]

Originally Posted by e*clipse

What programmer/debugger are you using?

I can answer that one - PICkit 3. I tried using something else to start and when you start with no 'known working' pieces .. it's hard to identify what is wrong!

[thingstodo]

Update for Sep 18

foc test 20 power up

hit '2'<Enter>, amps go from 0.1 to 1.2 (AC amps to the motor). Voltage phase to phase around 8 or 8.5VAC. command 'a'<Enter> gives voltages for a couple of waves and currents for a couple of waves, then a speed of +00000 rpm. But it's not turning, so I guess that's accurate.

Hit '2'<Enter> 9 more times. Current rises to 13.5. Voltage 12 VAC. The motor shaft is turning now. 'a'<Enter> gives a bunch of values. RPM is -00004. That seems too slow?

Hit '2'<Enter> 2 more times. Current rises to 16. Voltage 16 VAC. The motor shaft is turning quite well now. 'a'<Enter> gives a bunch of values. RPM is still -00004. That is DEFINITELY too slow.

Hit '2'<Enter> 1 more time. Current rises to 17.3. Voltage 16.5. The motor shaft is turning better and faster. 'a'<Enter> gives a bunch of values. RPM is down to +00000. That is wrong.

I spy my temporary fix on the encoder - the wire has slipped off. Press '1'<Enter> 13 times to get the current down to 0.1 and fix the encoder signal again. Run the encoder wiring further from the motor, and across the 24V DC/Dc converter to see if that changes things.


Hit '2'<Enter> 11 times. Current rises to 14.8. Voltage 12.5. The motor shaft is turning about once in 2 or 3 seconds. 'a'<Enter> gives a bunch of values. RPM is +00052. Good! The rpm may be reporting 2X actual. once in 2 seconds is 30 rpm, once in 3 seconds is 20 rpm. 52 rpm should be almost one rev per second.

Hit '2'<Enter> 4 times. Current rises to 20.6. Voltage 14.5. The motor shaft is turning smoothly. 'a'<Enter> gives a bunch of values. RPM is +00577. I'm not sure if that's right. I'd believe 280. The motor shaft is not spinning 10 revolutions per second.

Hit '2'<Enter> 3 times. Current rises to 25.3. Voltage 22. The motor shaft is turning smoothly. 'a'<Enter> gives a bunch of values. RPM is +01818. Then we hit some sort of problem. The motor rpm is no longer consistent - speeds up and slows down. Interference from the DC/Dc converter?

Hit '2'<Enter> 1 time. Current rises to 24-26 but is not consistent. Voltage 50 and fluctuating. The motor shaft is turning faster and slower. 'a'<Enter> capture voltage and current. RPM has dropped to +01410. The speed will be different each time I type 'a'.

Try 'a' again. Current not consistent. Voltage not consistent. The motor shaft is still turning faster and slower, you can feel regen on the motor houseing. 'a'<Enter> looks the same as last time, and so does the current. RPM has risen to +02036.

Try 'a' again. Current is not consistent. Voltage not consistent. The motor shaft is still turning faster and slower, you can feel regen on the motor houseing. 'a'<Enter> looks the same as last time, and so does the current. RPM has dropped to +02028.

Hit '2'<Enter> 2 times. Try 'a' again. Current 26 but is not consistent. Voltage 35 - 55? and not consistent. The motor shaft is still turning faster and slower, you can feel regen on the motor houseing. hold the motor down to the mount and it sometimes goes faster for a short time. 'a'<Enter> looks the same as last time, and so does the current. RPM has dropped to +01931.

Try 'a' again. RPM has risen to +02786.

Try 'a' again. RPM has fallen to +02797.

Shut down the test - need a better signal from the encoder. Shielded instrument cable, proper connector on each end, shield tied to power supply - on the power supply side.

I just read an email from Paul, with a new hex file. I'm not sure what the change was - I epxect that my encoder, or my encoder wiring, or both, are causing these problems that I am seeing.

My encoder is a 21 mm diameter connector, male pins on the encoder, male bolt thread on the connector. So I need a female 21 mm diameter connector with female pins to mate to it. The encoder connector built into the Siemens motor is the same diameter and has the same number of pins ... 12 ... interesting. I'll see what I can find online over the weekend, and at our local electronics store on Monday.

Split foc test 20 into 4 files to fit within files upload limit.

EDIT: add video links
Sep 18 1 - power up without encoder signal https://youtu.be/ytYXP-T6oEM
Sep 18 2 - power up with encoder signal - hunting https://youtu.be/z8oQQWzfYjc
Sep 18 3 - pictures of motor faceplate, encoder, connectors https://youtu.be/CpmoVyA5S8M

[MPaulHolmes]

I had messed up on the output for that first hex file. It wasn't just putting out Va and Ia, but also several other variables all overwriting each other I think. It's interesting about the RPM. I think once and for all that we need to confirm the number of pole pairs. I think next you should do that '2'<enter> thing again a few times (with the newest hex file loaded) and then hit 'a' just to see the RPM. Maybe so it's going close to 60RPM (according to the display). Try
num-pole-pairs 4

before running the test. If the real rpm was half of what was displayed, maybe we have the wrong number of pole pairs programmed in?

[thingstodo]

Originally Posted by MPaulHolmes

It's interesting about the RPM. I think once and for all that we need to confirm the number of pole pairs. I think next you should do that '2'<enter> thing again a few times (with the newest hex file loaded) and then hit 'a' just to see the RPM. Maybe so it's going close to 60RPM (according to the display). Try
num-pole-pairs 4

before running the test. If the real rpm was half of what was displayed, maybe we have the wrong number of pole pairs programmed in?

I'll get that done Sunday night or Monday morning.

I was going to experiment with the encoder cable for a few minutes. Put the signal on my scope - A and B - and watch what happens to the signal as the speed increases. When there is a problem, add some aluminum foil around the cable and use an alligator clip to tie it to 0V on the 24V dc/dc. Does it help or not? I'm interested in what is happening - I've never actually looked at hi frequency noise from a controller before. All I've ever wanted to do so far is get rid of it and move on with whatever I was doing

I think the pinout for the encoder built into the motor is on the EVTV web site - maybe they have the part number for the connector as well!

[MPaulHolmes]

I think I've got a really good filtering scheme for sensorless at 0.5Rev/sec up to 15,000rev/sec. It fits so well with the nature of the noise in the motor. The faster the motor, the more the waveforms look like fairly well behaved sine waves. The slower the motor, the more the waveforms look like crap. But the slower the motor, the longer the period and the more severe you can filter the signal. The goal is to find the derivative of the noisy current waveform. Well, it only looks random. Even at near zero rpm, that thing is a sine wave, if you do enough filtering. The trouble is, the filtered signal lags behind the one you want. Also, the magnitude is squashed just a bit. But in general, the RPM doesn't change super super fast. I mean, not microseconds fast. So, you find the shifted and scaled "peak of the last half cycle" and width of the last half cycle, and use that to construct a sine wave that is shifted back in time, and scaled up. YOu now know how the true sine wave looks like. You don't have to depend on the old news filtered sine wave. You can then take the derivative of the corrected sine, which then gives the derivative of what's happening right now! No lag! will post simulation pics soon.

[thingstodo]

Originally Posted by MPaulHolmes

I think I've got a really good filtering scheme for sensorless at 0.5Rev/sec up to 15,000rev/sec.

That's quite the range .. all wrapped up in one scheme!

It fits so well with the nature of the noise in the motor. The faster the motor, the more the waveforms look like fairly well behaved sine waves.

Matches what I've seen on industrial stuff. Control is good from 10ish Hz on up to 400 Hz

The slower the motor, the more the waveforms look like crap.

Yep

But the lower the motor, the longer the period and the more severe you can filter the signal. The goal is to find the derivative of the noisy current waveform.

OK. I sort-of follow.

Well, it only looks random. Even at near zero rpm, that thing is a sine wave, if you do enough filtering. The trouble is, the filtered signal lags behind the one you want. Also, the magnitude is squashed just a bit.

I guess that makes sense. Filtering can grab the sine wave out of the noise.

But in general, the RPM doesn't change super super fast. I mean, not microseconds fast. So, you find the shifted and scaled "peak of the last half cycle" and width of the last half cycle, and use that to construct a sine wave that is shifted back in time, and scaled up.

So do you need to cut off the filtering when you get up above a certain speed? Do you have the CPU cycles to filter at above 1000 rpm.

YOu now know how the true sine wave looks like. You don't have to depend on the old news filtered sine wave. You can then take the derivative of the corrected sine, which then gives the derivative of what's happening right now! No lag! will post simulation pics soon.

The algorithmn makes sense. It also sounds like a lot of work - filtering, taking the period, calculating the filter offset, calculating the peak, figuring out where the last half-wave WAS and where the next one WILL BE.

If you can cram all of that into the CPU you have - that's AWESOME!

[thingstodo]

Originally Posted by thingstodo

I'll get that done Sunday night or Monday morning.

Well, it got done Monday night. Late, as usual.

I was going to experiment with the encoder cable for a few minutes. Put the signal on my scope - A and B - and watch what happens to the signal as the speed increases. When there is a problem, add some aluminum foil around the cable and use an alligator clip to tie it to 0V on the 24V dc/dc.

Didn't get to that part as yet.

I think the pinout for the encoder built into the motor is on the EVTV web site - maybe they have the part number for the connector as well!

Getting a connector to fit this encoder will be a bit more of a challenge than I thought.. more on that tomorrow.

[MPaulHolmes]

Cutting off filtering above a certain speed is the neat part. Each time the period gets cut in half, you cut the severity of the running average in half. Higher speed signals are cleaner, so you aren't really compromising anything. So, waveforms with half-periods greater than 16384/10000 seconds get a running average of
CurrentAverage = (1023*currentAverage + newNoisyCurrent)/1024.

Waveforms with half-periods greater than 8192/10000 seconds get a running average of
CurrentAverage = (511*currentAverage + newSlightlyLessNoisyCurrent)/512.

...
cut in half
cut in half
...

Waveforms with half-periods greater than 16/10000 seconds (get a running average of
CurrentAverage = (1*currentAverage + newcurrent)/2.

Anything with a half-period less than 16/10000 sec gets no filtering. But that works out to friggen 18750 RPM (electrical RPM)! The required shifting and scaling of the filtered signal in order to obtain the secret original is the exact same for all. Cut period in half, and cut filtering in half cancels itself out. The only tradeoff is less filtering on signals that are cleaner anyway!