Post production noise removal

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys, gonna need some advice on this one.

I got a dual 10A motor controller board driving a 3meter (10') tracking parabolic antenna at work. The system have been taken out of service and put inside a upcoming tourist attraction.

The motors are 2kW brushed DC motors, originally they would take 90VDC at 22A, that is for max 1sec. The coil resistance is somewhere along 0.5-1ohm, including wire resistance. I`m running it at 12V, supplied by a switch mode PSU, at peak the motors draw about 10amps each. Nominal current peaks at 2.5A due to imbalance and friction(the thing have been outside for 35 years), otherwise about 1.5A.

My job is to get it up and running in a safe manner so that it fakes a real mission, basically moving along a fixed pattern whenever the simulator tells it to. So far the project have been a bit bumpy, but it is now working, kind of. I have no problem driving it along one or both axis continuously, but when i try to drive it X seconds along one, then swap direction or do anything else, it seems the MCU is not running.

I don`t have time to work up a new PCB for this one, and I would really appreciate advice on noise removal which can be done on the finished circuit.

Thanks in advance,
Kim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot to say, i'm using 33khz pwm. The waveforn looks very good though...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you reverse direction you need to allow the motor to stop, then reverse it. Otherwise you'll draw a large current and probably cause the psu to hiccup.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers Kartman, the H-Bridge I`m using should take care of the current limiting and specifically says that I could change directions without worry, the psu is good for 16.5A, close to twice the stall current. I will try to see if a pause makes any difference though, as the datasheet was not very good I might have misinterpreted something. From the tests I have done so far the timers and PWM generation is still running just fine in the MCU as the motor keeps running. If the PWM stopped the motor would either run faster or stop completely.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it have a brake mode?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes it does Bob. That is another thing to try out ;)

Here is the datasheet http://www.onsemi.com/pub_link/Collateral/STK681-332-E-D.PDF

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using the BOD on the micro?
(Set it as high as possible, but below the Vcc value)

Can you output any debugging info on an LCD, or LED?

Goal would be to read the register that says whether or not a BOD reset occurred.

This would help to determine if the micro's power supply dropped during the motor's change of state.

If the other devices attached to the micro can tolerate the micro running a bit under the normal Vcc voltage, you could also feed the micro's V+ through a diode to the micro. On the micro's side of the diode put a big cap, 470 uF, 1000 uF, whatever.

Now, if the power supply has a brief brown out the cap will supply power to the micro to keep it running properly. Likewise, a negative going "glitch" or "spike" on the V+ rail will get blocked by the diode. The Vcc also needs the normal 0.1uF by-pass caps on the Vcc/ground Pin pairs, and the AVcc/ground pin pair.

What else is connected to the micro, (I/O with long wires to the I/O pins?)?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd guess you need to protect the micro's power supply. Perhaps just hang some more microfarads on it? It's amazing what microfarads can solve!

The largest known prime number: 282589933-1

Without adult supervision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doc: Yes the BOD is enabled, I dont really need it so could just turn it off, but at 2.7V I guess it`d be better to actually deal with the noise than to rely on the MCU to work at that amount of fluctuations. Regards debugging I did think of that when designing so I do have the possibility to solder on a MAX232 and get serial comms with it.

I like the idea of separating the supplies using a diode, need to look into how easily that can be implemented.

Other connections are 4 relay drivers, standard BJT low side drivers. They are not in use at the moment.
There is also four level converters for connecting other inpurs, one of which would be the start sequence signal. These are not in use right now.
There is also some tracks running from the electrical limit relays to the MCU, but they are cut off due to the famous "someone" who forgot to add level converting...

Torby: I do already have a 1000uF on the 12V line, but i guess adding a few on the 5V side might help. Maybe solder them right onto the MCU-pins?

All bypassing caps have been placed as close as physically possible to the relevant pins, no more than 5mm from pin to cap so that should be ok.

Really looking forward to get this project done, been a bit of trouble to say the least :P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do the H-bridges and motors each work in both directions, with a simple test?

(I know you said you can't reverse directions)

Can each H-Bridge and motor be turned on and off, in the same direction, with a delay between turning them on and off?

Do the H-bridges and a direction signal and a PWM input? Have you scoped the direction control signal to make sure it is solid in each direction?

Would it be possible to substitute a car 12 V light bulb for each motor, a lighter and less inductive load, for initial testing?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, both axis work in both directions. Have not really tried turning them on and off as you mentioned. I`ll give that a try too when back at work on monday.

Changing the load is very easy, everything is using clamp terminal blocks with connectors so as easy as pulling them out and inserting bulb/led or whatever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few more thoughts, at least until somebody else chimes in:

It would be nice to determine, with certainty, if the problems are hardware, software, power supply, or motor in origin.

I mentioned isolating the micro's power supply above, or running it from a separate battery for testing for now.

With an LED on the PWM channels, and the direction signals, one would to be able to watch them fade up and down, in both directions, with a "simple" test program. One could also watch the signals on an O'scope, and make sure they match your expectations.

This helps to confirm that the code is running as expected, I/O pins configured correctly, ISRs aren't trashing the output signals, etc.

Next add the H-Bridges, but without the heavy, inductive load motors. LEDs might be a little too light a load for testing. That's why I suggested a car's light bulb, (brake light, for example), as I believe you are running a 12 V system. Again, it is a lighter, much less inductive load.

Watch to see if the bulbs fade up and down as expected, being powered in both "directions".

The power supply should be rock solid with the above, as it is operating under a very light load. (Check the spec for the power supply and make sure there is not a Minimum load requirement!).

It would be nice to test the motors and power supply separately, without the H-Bridge circuitry. If the motors, gear drives, and power supply can handle full on and full off without needing the PWM to ramp it up, then I would test them with heavy duty relay turning them on and off. This validates running the motors at 12 V instead of 90 V, and validates the power supply's ability to handle the peak and steady state currents.

Again, watch the power supply with an O'scope to see if it is browning out, (sagging), or if it is maintaining its output.

Look closely at the H-Bridge circuitry, also, and see if any of its components will lock up / fail to function properly if its power supply brown outs, (sags).

Finally, put it all together. If it works up to this point, then one has to also consider EMI from the motor, as well as brown outs and conducted spikes on the power rails.

Protecting from EMI can be harder to detect and protect. One has to look at the physical wires connecting the micro, the H-Bridge, the user interface, etc., and see which could be acting as antennas to bring in the radiated signal to the system. Using twisted wires inside shielded cabling can work wonders to help eliminate this. Putting the circuitry inside metal enclosures, (Faraday cages), can help.

Oh well, just a few ideas to bounce around and thing about.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the thorough reply JC, very much appreciated.

I`ll get to testing and experimenting tomorrow and see if I can find a solution.

Probably go through with adding the shielded wires, they are already present but the shield is not connected. I`m gonna change to a lab PSU for the testing, don`t feel too confident with the switch mode currently in use as I have noted some noise frequencies not generated on the PCB. Add some caps to the 5V to the logic and MCU rails.

The EMI should be rather low considering it is an antenna after all, originally it had S-band to P-band downconverters in close proximity to the drive lines. The S-band RF-cables runs parallel to the elevation motor wires. Here is a picture of it: http://www.rocketrange.no/wp-content/files/OnlineArchive/previews/1291522775.jpg It is the one to the right. Amazing piece of engineering for it`s time(1976).

I`ll keep you updated on the status tomorrow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very cool photo.

I have, on my project list, doing a Moon tracking antenna for trying to do a 5 W VHF moon bounce communications.

Unfortunately, there aren't enough hours in the day, given my other jobs.

Probably just as well, as mechanics is definitely not my strong point, and this project is equally motors and gears as well as lots of math, and a little bit of bit banging.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That sound like an interesting little project, could maybe use a rpi with camera to do optical tracking.

Got the antenna to work now, stupidly it was a very logical coding problem.
The code i was running was similar to this

while(1)
{
    Motor_Up();
    _delay_ms(1000);
    Motor_Down();
}

At the late friday hours I failed to see the obvious that Motor_Down() would only switch on and off due to the lacking delay(at 190khz). That also explains that mysterious noise component that i thought could be the switch mode PSU.

Thanks for all the input though, been another learning experience :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, FYI, it would only be correct for you to use 'stupidly' in the above if you NEVER found the problem!
The best software people I have ever worked with are great at debugging code. They are also the ones putting the bugs into the code! It would only be bad if they did not find them. So, do not beat yourself up too much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad to hear you have it working!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jaydhall, not really beating myself for that one. This whole project have really been full of it. Had several hardware bugs to fix, and the documentation on such old hardware is not always easy to follow, spent 3-4days just to find where different wires actually went. Then a day and a half to adjust 4 limit switches. Don`t get me wrong though, it has been a fun project, just a bit time limited for the amount of unknowns in the equation.