MCU switching problem with AC load on relay

Discussion in 'Embedded Systems and Microcontrollers' started by Leorenzo, Jul 27, 2015.

  1. Leorenzo

    Thread Starter New Member

    Sep 21, 2013
    27
    6
    Hi!
    Here is the details of my project.

    Problematic Part:
    I am using a microcontroller to switch a relay with 220VAC load.

    Problem:
    Everything works fine if there are no load connected to the relay but once a load was connected, the switching became strange. Sometimes when the pic sends an ON signal to the relay the relay would momentarily turn on and off again (sometimes does not turn on at all). Also, when the relay did successfully switch the AC load, the MCU sometimes can't turn off the relay by sending OFF signal to the relay.

    Another weird behavior that I encountered is sometimes when the relay is OFF and I plugged in the AC main to the switching pin of the relay, the relay will turn on.

    I've also tested that the circuit behaves differently on different AC outlet. The problem occurs more frequently on some.

    I'm aware that a relay driver is needed when switching with MCU. Attached below is the driver that I used. The LED is just an indicator for the relay's state.

    Steps that I took to solve the problem:
    I added a big 4.7uF bypass capacitor and it seems that improved the performance a bit.
    I added a snubber: 200ohms, 0.1uF (Result: No observable changes)

    [​IMG]

    Most successful attempt is with an electric fan as load

    What do you think could cause this behavior? Thanks in advance! :)
    The relay that I use - http://ph.element14.com/omron-elect...-5dc/relay-spst-no-16a-high-inrush/dp/2213809

    relay driver.PNG
     
  2. DickCappels

    Moderator

    Aug 21, 2008
    2,646
    631
    It is possible that noise from switching of the load is getting into your controller and causing problems. Had that happen once when driving a DC motor with brushes. What fixed is it was to low-pass the control line from the motor drive circuit to the microcontroller (notice the direction of signal flow is toward the controller).
     
  3. Leorenzo

    Thread Starter New Member

    Sep 21, 2013
    27
    6
    Hi DickCappels!

    Thank you for your suggestion. If I understood it correctly, I only need to put a capacitor from the control pin of my MCU to ground for the low pass right? I chose a 0.01uF ceramic capacitor. I had just tested it and while the result seems to be better, the problem still occurs. I don't know if the improvement was the result of the added capacitor or just the random nature of the said problem.
     
  4. MikeML

    AAC Fanatic!

    Oct 2, 2009
    5,450
    1,066
    Post a photo of your set up.

    How close is the 220V wiring to the MCU wiring? Are they bundled together? Try separating the 220V wires as far as possible from everything else.
     
  5. DickCappels

    Moderator

    Aug 21, 2008
    2,646
    631
    MikeML has a good point - that noise can easily be coupled between parallel conductors.

    It was a "L" filter like this: Motor circuit => inductor => capacitor to ground + controller pin. A little resistance in series with the inductor will help keep the filter from ringing too wildly.

    It seems that you are on the right path, so its probably just a matter of experimentation to find the optimum solution.
     
  6. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,018
    What PIC?

    If you are using single bit IO on midrange or baseline - or improperly on 18F, it could easily be an r-m-w (read-modify-write) problem in the noisy environment.
    If you ARE using single bit IO (bcf/bsf) or other r-m-w (e.g. andwf PORTx,F) on midrange, you should shadow your ports i.e. keep a copy of the port image in RAM, bsf/bcf on that image then write it to the port as a byte i.e.

    bsf PORTimage,0
    movf PORTimage,W
    movwf PORT

    or

    PORTimage |= 0x01;
    PORT = PORTimage;

    Don't do:
    bsf PORTx,0
    or
    PORT |= 0x01;

    If you have a PIC with both LATx and PORTx, (18F or enhanced midrange) be SURE that all bcf/bsf and any other r-m-w action on the port references LATx, not PORTx.

    This is a very common problem and the fact that it works without the noisy stuff attached smacks of r-m-w issues. Personally I always shadow ports on baseline/midrange from the get-go.

    Good luck.
     
    Last edited: Jul 27, 2015
  7. Leorenzo

    Thread Starter New Member

    Sep 21, 2013
    27
    6
    @MikeML
    The top and bottom picture of the setup are attached below.
    We also plan on moving the 220VAC trace as far as possible for our new PCB design. We just wanted additional inputs just in case we missed something before we finalize our new design.

    @DickCappels
    Noted. We'll try to add an inductor to the filter and see if it will improve the performance. By the way, what is your preferred values for the resistor,inductor, and capacitor that you mentioned? I'm not really familiar with inductors. Right now we have a 51ohm gate resistance which we thought will be the one to be in series with the inductor. Our setup : MOSFET Gate => Gate Resistance => (still missing inductor) => capacitor to ground + controller pin.

    @JohnInTX
    I'm really interested in this solution since we also have a weird behavior with regards to the different type of switching that we have. 1st type is direct switching. I send something to the pic and and pic decodes it immediately and turns on or off the relay. The 2nd type is scheduled. We send a time for the pic to switch which is stored in the EEPROM and when the time comes, it will switch the relay. The 2nd type is much more reliable than the 1st type.

    The pic that I use is PIC18F25K80. All access to the pin is through LATX. However, I know that when writing to pin, it is better to use LATX than PORTX but in the case of reading a pin, it is better to use PORT? Anyway, I also used LATX in reading the pin in my current code (Since it also worked. I might give PORTX a shot).

    I'm using C language for my code and here is how I toggle the pin
    #define CONTROL_PIN LATBbits.LATB2

    if(on)
    CONTROL_PIN = 1;
    else
    CONTROL_PIN = 0;

    so right now I'm accessing it through the BCF and BSF. I'll try your suggestion so I guess it would look like this
    unsigned char portb_buffer;

    main(){
    portb_buffer= LATB;
    while(1){
    if(on)
    portb_buffer |= 0x04; // since pin2 in my case
    LATB = portb_buffer;
    else
    portb_buffer &=0xFB;
    LATB = portb_buffer;
    }
    }

    Thank you all for your reply!
     
    Last edited: Jul 28, 2015
  8. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,018
    With an 18F, all output changes (including r-m-w) go to LATx. Inputs read PORTx. If you write to PORTx, the corresponding LATx gets also written. Since your C code uses LATB.2, it should generate correct code.

    control_pin_status |= 0x04; // since pin2 in my case
    This is actually r-m-w on LATB (since that's what control_pin_status is define as). I should work OK though. You shouldn't need to shadow the 18F. If you wanted to try it:

    Code (C):
    1. unsigned char LATBimage;
    2.  
    3. initIO()
    4. {
    5. // TRIS and other stuff then..
    6. // Never read the port, init the shadow register at the same time as the port then maintain from there
    7. LATB = LATBimage = INITIAL_VALUE; // init both LAT and shadow reg
    8. }
    9.  
    10. main()
    11. {
    12. LATBimage.2 = 1; // modify shadow then copy to LAT
    13. LATB = LATBimage;
    14.  
    15. if(PORTB.7 == 1) // read the value on the pins of PORTB for an input
    16.   do_this;
    17. else
    18. do_that;
    19. }
    Going to LAT should clear up the port problems without shadowing but give it a try if you want. It might help but I'd be more concerned about switching a sparky load with mechanical contacts so close to the processor. Sorry not to be more help!
     
    Last edited: Jul 28, 2015
  9. Leorenzo

    Thread Starter New Member

    Sep 21, 2013
    27
    6
    @JohnInTX
    I wasn't able to test the code earlier. I'll try to do it tomorrow since I'm at home now. Whatever the result will be, what you said is still informative and I'll keep that in mind for my future projects! Thank you! :).
     
    JohnInTX likes this.
  10. Leorenzo

    Thread Starter New Member

    Sep 21, 2013
    27
    6
    I just wanted to update this thread that I've already solved my problem! Looks like the problem was due to EMI produced by the 220VAC and the fact that it is indeed really close to the microcontroller. Redesigning the board and making sure that the trace of 220VAC line will be far enough to the microcontroller solved the issue. Another minor changes that we did is to add a 250V varistor across the switching contacts of the relay in order to suppress any current surges during switching. Thank you to everyone who posted in this thread! :)
     
  11. JohnInTX

    Moderator

    Jun 26, 2012
    2,338
    1,018
    Thanks for the update. Its always good to know what solved the problem!
    Well done.
     
    Leorenzo and ebeowulf17 like this.
Loading...