Hot!16F628A pulling RA3 low causes RA4 to dip low for a few seconds?

Page: 12 > Showing page 1 of 2
Author
kevinbinder
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2018/04/09 09:53:36
  • Location: 0
  • Status: offline
2018/04/09 14:14:40 (permalink)
0

16F628A pulling RA3 low causes RA4 to dip low for a few seconds?

Hello to all. This is my first post as I have always found answers as others have had similar issue, but this time I'm stumped. Hoping someone can help.
 
I am using RA3 and RA4 to monitor 2 hall sensors on a mechanism (Home position and extended positions of the mechanism).
 
However I have disconnected the sensors and replaced with buttons to exclude the sensors as a problem. Both RA3 and RA4 have their own pull up to 5v. Each then has a normally open push button to ground (replacing the sensors).
 
Without the code running, if I monitor the RA3 or RA4 ports with a voltmeter I get clean transitions from 5v to 0v.
 
With the code running I still always get clean transitions on RA3 when RA3 button is pressed, and clean on RA4 when RA4 button is pressed.
 
Now the weird bit...
 
If I monitor RA4 and press RA3 (sic) button then RA4 voltage remains at 5v (as would be expected) however...
 
If monitor RA4 and press button RA3 (sic) and if the code is looping looking for RA3 transition then RA4 dips close to 0v and then takes about 4 seconds to rise back to 5v. This is then causing further code to pre trigger.
 
I have done a few tests and this only seems to happen when the code as actually monitoring RA3. If the code is elsewhere then this does not happen.
 
I do not have access to a scope at home, but this dip can be clearly seen on a decent digital voltmeter.
 
Anybody got any idea why this may be happening?
 
RA3 and RA4 are both configured as inputs.
07h is written to the CMCON register to turn off the comparators.
VRCON is turned OFF (Tried on and off).
Interrupts not set up.
I have tried all 4 possible combinations for Option Reg bits 4 and 5.
 
Can't think of anything else to try?
 
Any help will be very much appreciated.
Thanks, Kevin
 
#1

24 Replies Related Threads

    jack@kksound
    code tags!
    • Total Posts : 2892
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/10 11:23:34 (permalink)
    0
    If you are doing bit manipulations on other bits (as outputs) in PORTA then possibly you are experiencing RMW effects. Post your code and we won't need to guess quite so much (hopefully).
    #2
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/10 13:17:47 (permalink)
    0
    RMW can't affect input pins.
    No mention has been made if the code is in C, or in ASM.
    My guess it is in ASM, and a bank selection mistake has been made in the code.
    As already noted, we can only guess when you do not post the code.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #3
    jack@kksound
    code tags!
    • Total Posts : 2892
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/10 13:23:22 (permalink)
    0
    RMW can't affect input pins.

    Yes of course, without any schematic or code I was working toward a possible wiring error combined with possible RMW, truely a guess in the dark (And probably not a very good guess at that!).
    #4
    kevinbinder
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/04/09 09:53:36
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/11 03:01:08 (permalink)
    0
    Hi folks.
    Thanks for the responses.
     
    To keep things simple I have replaced the solenoids and motor with leds (just in case of inductive issues from the coils) and the sensors with push buttons.
     
    The notes in the code tell how each pin is wired. The code as it currently stands is below.
     
    This circuit is part of larger system, but I have rebuilt this portion on veroboard and have it on the bench to tinker with. In this form the issue seems to have disappeared, so I am wondering about external noise being an issue - although the rest of the circuitry is shut down. The two inputs for the sensors take a fairly torturous path to their connector on the pcb, so maybe I need to rethink that.
     
    If anyone has any other ideas, or comments on my code (coding is definitely not high on my skill set) please let me know. Any comments gratefully received.
    Cheers
    Kevin
     
    ;**********************************************************************
    ; Filename: Hammer 1v0.asm
    ; Date: Mar 2018
    ; Author: Kevin Binder
    ; http://www.kevinbinder.co.uk
    ; Compiled on MPLAB 8.92
    ; Controls hammer mechanism
    ; Fires solenoid to release hammer (ball) to hit rail, fires second solenoid to then retract the cord, preventing the ball making a second strike
    ; Slide mechainism then engages the cord and lifts the hammer ready for the next strike
    ; PIC16F628A use internal 4 mHz clock
    ;**********************************************************************

    LIST p=16f628A, R=DEC ; LIST DIRECTIVE TO DEFINE PROCESSOR
    INCLUDE "p16F628A.inc" ; PROCESSOR SPECIFIC VARIABLE DESIGNATION
    ERRORLEVEL -302 ; SUPPRESS 302 FROM THE LIST FILE

    ; The parameter _INTRC_OSC_NOCLKOUT makes the PIC use the internal 4 MHz RC oscillator. This means, that RA6 and RA7 are available for I/O.
    ; The reset function of pin 4 (RA5) can be disabled and the pin configured as an input pin. This is done by specifying _MCLRE_OFF in the _config line.

    __CONFIG _CP_OFF & _LVP_OFF & _BOREN_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTOSC_OSC_NOCLKOUT

    CBLOCK 0x20 ; START OF GP REGISTERS
    COUNT1
    COUNT2
    COUNT3
    ENDC

    ORG 0x000 ; PROCESSOR RESET VECTOR

    ; THE CMCON REGISTER IS LOAD WITH A VALUE OF 07 FOR ALL PORT A PINS TO FUNCTION AS DIGITAL I/O.
    MOVLW 0x07 ; TURN COMPARITOR OFF
    MOVWF CMCON
    BSF STATUS,RP0 ; RAM bank 1
    MOVLW b'00011001' ; PORTA
    MOVWF TRISA
    MOVLW b'00000000' ; PORTB
    MOVWF TRISB
    ; MOVLW b'11100000'
    ; MOVWF OPTION_REG
    ; MOVLW B'00000000' ;DISABLE VRCON
    ; MOVWF VRCON

    BCF STATUS,RP0 ; RAM bank 0

    ; PORT A ALLOCATION
    ; A0 INPUT FROM MAIN PROCESSOR TO INDICATE CORD RELEASE - ACTIVE LOW
    ; A1 NOT USED - SET AS HIGH OUTPUT
    ; A2 OUTPUT TO HAMMER RELEASE SOLENOID - ACTIVE HIGH TO OPTO COUPLER
    ; A3 INPUT FROM CARRIAGE EXTENDED SENSOR - ACTIVE LOW FROM HALL EFFECT
    ; A4 INPUT FROM CARRIAGE HOME SENSOR - ACTIVE LOW FROM HALL EFFECT
    ; A5 NOT USED - SET AS HIGH OUTPUT
    ; A6 OUTPUT TO CORD TENSION SOLENOID - ACTIVE HIGH TO OPTO COUPLER
    ; A7 NOT USED - SET AS HIGH OUTPUT
    ; PORT B ALLOCATION
    ; B0 OUTPUT TO CARRIAGE MOTOR BRIDGE DRIVER - 0 = HOME 1 = EXTENDED
    ; B1 OUTPUT TO CARRIAGE MOTOR BRIDGE DRIVER - 1 = HOME 0 = EXTENDED
    ; B2 NOT USED - SET AS HIGH OUTPUT
    ; B3 NOT USED - SET AS HIGH OUTPUT
    ; B4 OUTPUT TO HAMMER LAMP ON CONTROL PANEL - ACTIVE HIGH
    ; B5 NOT USED - SET AS HIGH OUTPUT
    ; B6 NOT USED - SET AS HIGH OUTPUT
    ; B7 NOT USED - SET AS HIGH OUTPUT
    ; PORT A DESIGNATIONS
    FIRE EQU 0x00 ; PORT A INPUT 10K PULL UP - RELEASE HAMMER SIGNAL FROM MAIN PROCESSOR OR PUSH BUTTON ACTIVE LOW
    HAMMER EQU 0x02 ; PORT A OUTPUT - SET HIGH TO RETRACT THE HAMMER SOLENOID (RELEASE THE HAMMER) DIRECT TO OPTO COUPLER VIA 220R
    TENSION EQU 0x06 ; PORT A OUTPUT - SET HIGH TO RETRACT THE TENSION SOLENOID (RETRACT CORD) DIRECT TO OPTO COUPLER VIA 220R
    CAREX EQU 0x03 ; PORT A INPUT 10K PULL UP - LOW WHEN CARRIAGE EXTENDED
    CARHOME EQU 0x04 ; PORT A INPUT 10K PULL UP - LOW WHEN CARRIAGE HOME
    ; PORT B DESIGNATIONS
    MOTOR1 EQU 0x00 ; PORT B OUTPUT - MOTOR DRIVE 0 = HOME 1 = EXTENDED DIRECT TO OPTO COUPLER VIA 220R
    MOTOR2 EQU 0x01 ; PORT B OUTPUT - MOTOR DRIVE 1 = HOME 0 = EXTENDED DIRECT TO OPTO COUPLER VIA 220R
    HAMLITE EQU 0x04 ; PORT B OUTPUT - SET HIGH TO LIGHT LAMP DIRECT TO OPTO COUPLER VIA 390R

    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    MAIN ; INITIALISE
    BCF PORTA,HAMMER ; RELEASE THE HAMMER SOLENOID
    BCF PORTA,TENSION ; RELEASE THE TENSION SOLENOID

    BCF PORTB,MOTOR1 ; TURN OFF THE MOTOR DRIVE
    BCF PORTB,MOTOR2

    BCF PORTB,HAMLITE ; TURN OFF THE HAMMER LIGHT
    CLRF COUNT1
    CLRF COUNT2
    CLRF COUNT3

    ; SET ALL UNCONNECTED PINS HIGH
     BSF PORTA,1
     BSF PORTA,5
     BSF PORTA,7
     
     BSF PORTB,2
     BSF PORTB,3
     BSF PORTB,5
     BSF PORTB,6
     BSF PORTB,7
     
    XXXXX
    CLRF COUNT1 ; DELAY ABOUT 2 SECONDS TO ALLOW VARIOUS POWER SUPPLIES TO SETTLE
    CLRF COUNT2
    MOVLW .10
    MOVWF COUNT3
    CALL DELAY3
    BSF PORTA,HAMMER ; RETRACT THE HAMMER PIN
    CALL HOME ; MOVE CARRIAGE TO HOME POSITION
    CALL EXTEND ; MOVE CARRIAGE TO EXTENDED POSITION
    BCF PORTA,HAMMER ; RELEASE THE HAMMER PIN TO ENGAGE WITH CORD
    CALL HOME ; MOVE CARRIAGE TO HOME POSITION HAMMER NOW IN LIFTED POSITION
    GOTO XXXXX ; LOOP BACK UNTIL ISSUE RESOLVED
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    MAINLOOP
    MLLP1 BTFSC PORTA,FIRE ; HAS A FIRE SIGNAL BEEN RECEIVED FROM EITHER THE MAIN MICRO OR THE PUSH BUTTON?
    GOTO MLLP1 ; NO CONTINUE TO WAIT
    BSF PORTA,HAMMER ; YES, SO RETRACT THE HAMMER SOLENOID RELEASING THE HAMMER
    CLRF COUNT1
    CLRF COUNT2
    CALL DELAY2 ; DELAY APPROX 1/5 SECOND BEFORE FIRING THE TENSION SOLENOID
    BSF PORTA,TENSION ; RETRACT THE TENSION SOLENOID TO PREVENT HAMMER BOUNCE
    CALL EXTEND ; MOVE CARRIAGE TO EXTENDED POSITION

    BCF PORTA,HAMMER ; RELEASE THE HAMMER SOLENOID
    CALL HOME ; MOVE CARRIAGE TO THE HOME POSITION TAKING THE HAMMER CARD WITH IT
    BCF PORTA,TENSION ; RELEASE THE TENSION SOLENOID
    GOTO MLLP1 ; GO AGAIN
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    HOME ; MOVE THE CARRIAGE TO THE HOME POSITION AND THEN STOP
    ; CLRF COUNT1 ; DELAY ABOUT 1 SECONDS
    ; CLRF COUNT2
    ; MOVLW .05
    ; MOVWF COUNT3
    ; CALL DELAY3
    BCF PORTB,MOTOR1 ; MOVE CARRIAGE TO HOME POSITION
    BSF PORTB,MOTOR2
    LP1 BTFSC PORTA,CARHOME ; HAS THE CARRIAGE REACHED THE HOME POSITION? (MAGNET SENDS LINE LOW)
    GOTO LP1 ; NO - KEEP MOVING
    BCF PORTB,MOTOR1 ; YES - STOP THE MOTOR
    BCF PORTB,MOTOR2
    RETURN
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    EXTEND ; MOVE THE CARRIAGE TO THE EXTENDED POSITION AND THEN STOP
    ; CLRF COUNT1 ; DELAY ABOUT 1 SECONDS
    ; CLRF COUNT2
    ; MOVLW .05
    ; MOVWF COUNT3
    ; CALL DELAY3
    BSF PORTB,MOTOR1 ; MOVE CARRIAGE TO EXTENDED POSITION
    BCF PORTB,MOTOR2
    EXLP1 BTFSC PORTA,CAREX ; HAS THE CARRIAGE REACHED THE EXTENDED POSITION? (MAGNET SENDS LINE LOW)
    GOTO EXLP1 ; NO - KEEP MOVING
    BCF PORTB,MOTOR1 ; YES - STOP THE MOTOR
    BCF PORTB,MOTOR2
    RETURN
    ;26-FEB-2018;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;26-JAN-2007;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;DELAYS
    DELAY1
    decfsz COUNT1,F ;DECREMENT, IS IT ZERO?
    goto DELAY1 ;NO SO GO AGAIN
    return ;YES, SO RETURN TO CALL

    ; Delay2 causes a delay of up to 197.6mS (approx), depending on initial value placed
    ; in count2 before call is made. (In multiples of 772uS, as it uses delay1)
    DELAY2
    call DELAY1
    decfsz COUNT2,F ;DECREMENT, IS IT ZERO?
    goto DELAY2 ;NO SO GO AGAIN
    return ;YES, SO RETURN TO CALL

    ; Delay3 causes a delay of up to 50.6 SECONDS (approx), depending on initial value placed
    ; in count3 before call is made. (In multiples of 197.6mS, as it uses delay2 and delay1)
    DELAY3
    CALL DELAY2
    DECFSZ COUNT3,F ;DECREMENT, IS IT ZERO?
    GOTO DELAY3 ;NO SO GO AGAIN
    RETURN ;YES, SO RETURN TO CALL
    ;26-JAN-2007;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    FINISH
    END
     

    Attached Image(s)

    #5
    PStechPaul
    Super Member
    • Total Posts : 2093
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/11 12:51:45 (permalink)
    0
    Your circuit has some major problems:

    The optoisolator probably has turn on and turn off delays in the order of 2-20 uSec, perhaps even slower with a 10k load. The gate capacitance of the MOSFETs will also slow down the PWM signals, especially turn-on of the lower NMOS, and turn-off of the upper PMOS, so that they will be in a linear region for quite a while, and both will be ON during switching. Also, you are driving the gates to 24 volts, which is usually beyond the absolute maximum of most devices.
     
    You should use a high-low MOSFET driver which will allow the use of NMOS for all four bridge devices. Something like an IRS2001 or LM5109 would be good.

     
    #6
    Antipodean
    Super Member
    • Total Posts : 1667
    • Reward points : 0
    • Joined: 2008/12/09 10:19:08
    • Location: Didcot, United Kingdom
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/11 14:08:30 (permalink)
    0
    PStechPaul
    Your circuit has some major problems:
    ...
    The optoisolator probably has turn on and turn off delays in the order of 2-20 uSec, perhaps even slower with a 10k load. The gate capacitance of the MOSFETs will also slow down the PWM signals, especially turn-on of the lower NMOS, and turn-off of the upper PMOS, so that they will be in a linear region for quite a while, and both will be ON during switching. Also, you are driving the gates to 24 volts, which is usually beyond the absolute maximum of most devices.
     
    You should use a high-low MOSFET driver which will allow the use of NMOS for all four bridge devices. Something like an IRS2001 or LM5109 would be good.


    Not only that but the solenoid protection diodes should be wired from the output to the +24V instead of ground.
     
    Then the two signals that are being complained about are in the same loom as the motor and solenoid connections, so any high impulse signals from those will get into the PIC without any interference suppression.
     
    Also as already mentioned you DO have potential RMW problems as you have both outputs and inputs on the one port. I haven't worked through the code to see if outputs are driven by changing the LAT register or the PORT register.

    Do not use my alias in your message body when replying, your message will disappear ...

    Alan
    #7
    jack@kksound
    code tags!
    • Total Posts : 2892
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/11 14:59:55 (permalink)
    +2 (2)
     I haven't worked through the code to see if outputs are driven by changing the LAT register or the PORT register.

    16F628A is an older pic without LATx registers, only PORTX.
    #8
    PStechPaul
    Super Member
    • Total Posts : 2093
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/11 21:44:31 (permalink)
    +2 (2)
    Here is a simulation of the OP's bridge circuit:

    And here is an improved version:


     
    #9
    jean claude
    New Member
    • Total Posts : 24
    • Reward points : 0
    • Joined: 2015/12/14 08:40:32
    • Location: FRANCE
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/12 06:26:46 (permalink)
    0
    for the pic16f628a, RA5 is input only= MCLR
    #10
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/12 06:42:32 (permalink)
    0
    jcw
    for the pic16f628a, RA5 is input only= MCLR

    So?
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #11
    mbrowning
    Just a Member
    • Total Posts : 1147
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/12 07:50:24 (permalink)
    0
    qɥb
    jcw
    for the pic16f628a, RA5 is input only= MCLR
    So?

    I believe jcw was commenting on the OP's schematic, which has RA5 labeled as "OUTPUT" even though it is routed only to the PICkit header.



    Oh well - there's always next year
    #12
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/12 13:15:37 (permalink)
    0
    mbrowning
    ...
    I believe jcw was commenting on the OP's schematic, which has RA5 labeled as "OUTPUT" even though it is routed only to the PICkit header.

    I think you're right. Wasn't at all obvious from the terse post.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #13
    PStechPaul
    Super Member
    • Total Posts : 2093
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/12 13:17:25 (permalink)
    +1 (1)
    The schematic also shows NMOS for all devices, but the top ones must be PMOS. There is a note about P channel reversed, whatever that means. The method I show for the bridge has four states:
     
    1. All off, load floating
    2. UL and LR on, load forward
    3. UR and LL on, load reverse
    4. All on (error condition)
     
    Looking at the code, it appears that the bridge is not using PWM, but just an ON/OFF forward or reverse drive. In that case, the states would be:
     
    1. RB0 and RB1 off: LL and LR on, load shorted
    2. RB0 on and RB1 off: UL and LR on, load forward
    3. RB0 off and RB1 on: LL and UR on, load reverse
    4. RB0 and RB1 on: UL and UR on, load shorted
     
    On a slower timescale, it works OK, but there is a high current shoot-through on transitions. I used a 1 ohm internal resistance for the source and a 10 uF capacitor to limit the source current, but the current through the MOSFETs is pretty high.
     


     
    #14
    kevinbinder
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/04/09 09:53:36
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/13 02:32:03 (permalink)
    +1 (1)
    Hi again.
     
    Thanks to all.
    In response to the various comments (all very welcome)...
    Regarding the mosfets - their are high voltage devices with 30 volt gate capability. 2x P type, 2x N type. The comment written on the circuit regarding them being reversed can be ignored - it was a reminder for me to edit the PCB.
     
    They are not PWM switching. They only drive the motor one way or another so speed is not an issue. They are either off or fully on for a few seconds. I understand them being in their linear region during the optos transition time but this is only during a single transition to being fully on or off, so I cannot see any issue. I have used this scheme before without any noticeable heating of the mosfets.
     
    Although commented out on the posted listing, there are delays before switching on the motor in either direction, so shoot through should not occur.
     
    However, I do take the point of using a mosfet driver. In hindsight this would definitely be a better option and would simplify mosfet choice. I will definitely be doing this on the final version. Thanks for that.
     
    A5 is only used for mclr, Please ignore the output legend.
     
    Well spotted on the back emf diodes. I hadn't noticed that! However I did not fit them to the pcb, I fitted them directly across the solenoid coils, where they should be, and correctly wired straight across the coil.
     
    Point taken on the looming and current spikes in the loom. I have now fitted optocouplers at the micro end driven by the hall effect sensors to help clean up the lines. This seems to have solved my issues. I think that on the next version I will move all the power electronics down on to the mechanism and opto couple the drive from the main micro. Not really sure why I didn't do this from the start.
     
    However When I was trying to sort this problem on the mechanism, I had disconnected the motor and solenoids and replaced them with lamps, so I would not have thought they would be any problem with noise...
     
    You have all given me lots to think about and to go googleing. Many thanks for your wise words. It is good to learn.
    Many many thanks for your help.
     
    Kevin
     
     
    #15
    PStechPaul
    Super Member
    • Total Posts : 2093
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/13 12:14:38 (permalink)
    0
    A time delay will not avoid shoot-through. As the gate voltage changes during switching, there will be a time of perhaps a few microseconds where both devices are fully ON. The optos do not provide isolation, and may as well be replaced with NMOS or NPN transistors, either of which would be much faster. An inductor on the common sources of the PMOS devices might limit the shoot-through current and also isolate the supply to reduce noise and component stress.

     
    #16
    kevinbinder
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/04/09 09:53:36
    • Location: 0
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/15 01:27:20 (permalink)
    0
    PStechPaul,
     
    Thanks again.
    Yes I see what you mean regarding shoot-through. Its obvious once its made clear (and sunk in to my limited brain capacity!).
    Your time is very much appreciated. What I do is a means to an end and working alone (as far as the electronics is concerned) makes it difficult to learn at times. There is no one else with me to bounce things off and try to understand better. I have no formal training in this field so it is  struggle at times.
     
    Whilst I don't want to hog your time, I would appreciate a little advise regarding mosfet bridges. There are lots of circuits on the net but it is obvious that most of them do not seem to be dealing with this shoot-through effect, presumably they just get away with it as the components are rated above the psu capabilities or there are some other limiting factors.
     
    What is the best way to deal with this? Are any of the driver chips set up to prevent this?
     
    An alternative would be for me to use four processor lines and drive each quadrant separately (via drivers as already advised - and therefore N types throughout), there by giving me full control of the timing. But I wonder what the state of the four lines will be at first power up?
     
    Any advise would be gratefully received.
     
    Thanks
    Kevin (a very grateful dabbler)
     
     
    post edited by kevinbinder - 2018/04/15 02:36:35
    #17
    Antipodean
    Super Member
    • Total Posts : 1667
    • Reward points : 0
    • Joined: 2008/12/09 10:19:08
    • Location: Didcot, United Kingdom
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/15 05:11:27 (permalink)
    0
    kevinbinder
    What is the best way to deal with this? Are any of the driver chips set up to prevent this?

    There are driver chips around that can do this, but you would be better off using a PIC with a PWM that is designed for this purpose. The PWM hardware generates the neccessary gap between the two pulses so that you don't get shoot through.
     
    I haven't gone investigating, but look through the Microchip selectors for chips with PWM hardware designed as motor drivers, IIRC there are some in the 16F1xxx family.
     
     

    Do not use my alias in your message body when replying, your message will disappear ...

    Alan
    #18
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/15 05:20:50 (permalink)
    0
    "Dead time" is the magic term you should be searching for...
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #19
    PStechPaul
    Super Member
    • Total Posts : 2093
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: 16F628A pulling RA3 low causes RA4 to dip low for a few seconds? 2018/04/15 13:43:10 (permalink)
    0
    There are ways to eliminate shoot-through by means of circuit design as opposed to dead time between two separate drive signals from the PIC. Here is an example:
    http://www.aldinc.com/pdf/cd_23006.0.pdf
     
    I also made some simple modifications to my simulation that eliminates shoot-through:
     

     
    You could also use a bridge driver that replaces all the discrete components. Here is one from Microchip, with two full bridge drivers:
    http://ww1.microchip.com/...n/DeviceDoc/22259C.pdf
     
    Similar to the venerable L293 and L298 drivers, often used for stepper motors:
    https://www.sparkfun.com/products/9479
     
    Or this single full bridge driver from TI:
    http://www.ti.com/lit/ds/symlink/drv8829.pdf
     
    These devices also incorporate dead time and logic to avoid shoot-through and allow for free-wheeling or shorted connection to the motor or solenoid.
     
    The usual Hi-Lo MOSFET drivers for NMOS devices use a charge pump derived from the PWM signals. They won't work for simple ON/OFF/REV drives, unless you supply a separate supply above the positive rail for gate drive.
     

     
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 4.5