Input Noise

Hi, I am having a lot of trobbles with one of the inputs on a PIC18F4550. Everytime I connect an encoder from a AC motor the PIC seems to get a mind of its own and randomy turns on relays, outputs serial data, resets itself etc.. The encoder is currently connected to the PIC through an opto but shares the same power as the PIC. It has 3 wires (VDD, GND and OUTPUT) and requires 5v to operate. Because of this it is not truly isolated from the rest of the circuit.

I have tried shileding the wire with a metal conduit but did not help. I also shielded the 3 phase cable from the AC Drive Unit to the AC Motor and it also did not help. I have also placed 0.01 uF caps between every incoming wire and GND but also did not help.

It seems to only be this one sensor that is giving problems when the motor is engaged.

Any suggestions would be greatly appreciated.

Thanks.

It sounds to me like the PIC itself is not bypassed properly. Make certain that you have several .1uF caps very close to the chip across the supplies. Also make sure that you have some bulk capacitance ( > 100uF) close to the chip. You may need several.

Two other things to watch for: The crystal needs to be very close to the PIC.
The MCLR line needs to be short, and pulled to VCC with a 4.7K (or so) resistor.

At least in my experience, some chips are more prone to noise problems than others. I have had issues with 18F452's but none with 18F8720's (in basically the same circuit) for example.

Thanks Charles,

I do have several .1uF caps throuout th PCB and I am also using a temperature compensated Crystal Oscillator which is as close as physically possibe to the PIC.

The problem I am having seems to only be with the one sensor. If not connected then everything works as expected.

I was suspecting that the AC Invertor or the AC motor were creating some EMI that caused problems with the sensor.

I am using is a Geartooth Hall Effect sensor which is embeded in the gearbox on the output of the motor. It is very close to the motor itself. I don't know if this makes any differense or not.

I would just provide a separate power source for my opto. It's pretty much
useless for isolation with a common power source.

If your AC motor is far away enough to not couple noise into your controller
circuit, and you have the opto on its own "isolated" power, you shouldn't
have any problems.

Thanks Bruce,

What would be the easiest way to build the circuit with a separate power supply for the optos yet still only have one PCB. I guess I would have to also power the sensor using that same power source.

The final PCB will be mounted in a metal enclosure with 2 ac power inputs. 1 is 16v AC for the main board and the other is 24v AC for an Optical beam sensor.

The 16v AC is converted to DC through a full wave bridge rectifier and then regulated to 5v and 12v through 2 voltage regulators. The 5v is used for the PIC and all logice ICs, the 12v is for the relays and to power external RS485 devices.

There is a total of 3 inputs to the PIC. The first is the Encoder from the gearbox, the second is the Optical beam sensor, and the last is a relay output from the AC Drive Invertor for fault detection.

I have also found the 18F4550 very sensitive on the pins when reading in simple high or lows, especially when using in motor applications.

If I run the same the code on say a 18F452 or 16F877 then not a problem, bu t as said the 18F4550 is very sensitive along with a few other quirks.

To get around this problem I doubled up of the sensing.

In other words, if I was was watching for a pin to go high within the code I would sample it, give it a short pause of say 100 us and and re-sample before breaking off to my routine. This seems to of ironed out the interference picked up by this chip.

Regards

Sean.

Hi Sean,

Did you have your PIC reset itself or do any unusual things?

All my inputs are interrupt driven, maybe this is also a problem.

I am going to try changing it to a PIC18F452 to see if it helps.

Thanks.

Quote:

What would be the easiest way to build the circuit with a separate power supply for the optos yet still only have one PCB

Just design your board with two separate power planes, and power supply
input terminals.

Separate DC power supply's input to two separate regulators on the same
PCB.

|..P.S. input A.............P.S. input B]
|--[+-]------------------[+-]-----|
|..PIC side........<..out.[]..input..<..| AC connections on outer edge
|.....................<..out.[]..input..<..| optos in center of board close
|..one PCB........<..out.[]..input..<..| to controller ins/outs

TIPS:

Keep AC traces (if any) as short as possible, and located on the far edge
away from the controller side of the board.

Make the bottom layer under the "controller side" a large ground plane with
decoupling caps at all power connection points.

Do not cross-over traces from one side to the other. Noise will couple from
one PCB trace to another right through your PCB substrate.

If you have any mechanical relays on either board, consider MOV's (metal
oxide varistors) across the relay contacts to snub contact spark/discharge.

I've done a number of boards like this without any glitches. All for large
motors & heavy appliances being controlled or monitored by the PIC.

Im my experience, I've noticed that all of the 18F series and most 16F "A"
series are all more succeptible to noise than older non "A" series 16F parts.

Quote:

a mind of its own and randomy turns on relays, outputs serial data, resets itself etc

That definitely sounds like a serious noise problem, but it may also be the
input you're using. Does it throw a fit if you connect this same input to
any other signal?

Which input are you using?

I am using PORTB.0 for the encoder, i am using interrupts to capture the pulses.

The relays do not control the motor directly but instead drive an AC Drive Inverter which creates the 3 Phase 330V AC required by the motor. The relays are the G5V-1 micro relays and are being driven by a ULN2003.

Interrupts alone can cause seriously erratic behaviour depeding on your
program structure & how you're handling things getting in/out of the int
handler.

I would still look at isolation, but it may also have something to do with your
interrupts. Can you post your interrupt handler?

Here is the interrupt handler:

Code:

'------------------------------------------------------------------------------- ' Interrupt Handler '------------------------------------------------------------------------------- DISABLE INTERRUPT ' No interrupts past this point Main_Interrupt_Handler: '--------------------------------------------------------------------------- ' PortB.0 Interrupt, Motor RPM Counter '--------------------------------------------------------------------------- IF INTCON.1 = 1 THEN IF Calibrating = 1 THEN Total_Pulses = Total_Pulses + 1 ELSE IF System_Calibrated = 1 THEN New_Position_Counter = New_Position_Counter + 1 IF New_Position_Counter >= (Pulses_Per_Position + Temp_Pulses) THEN SELECT CASE Current_Direction CASE Forward_Dir Current_Position = Current_Position + 1 IF Current_Position > Total_Positions THEN Current_Position = 1 ENDIF CASE Reverse_Dir Current_Position = Current_Position - 1 IF Current_Position = 0 THEN Current_Position = Total_Positions ENDIF END SELECT DEBUG 13, 10, "[ Position Change ] Current Position: ", DEC Current_Position, 13, 10 New_Position_Counter = 0 Temp_Pulses = 0 ENDIF ENDIF ENDIF INTCON.1 = 0 ENDIF '--------------------------------------------------------------------------- '--------------------------------------------------------------------------- ' PortB.1 Interrupt, Position 1 Sensor '--------------------------------------------------------------------------- IF INTCON3.0 = 1 THEN DEBUG 13, 10, "[ INTERRUPT ] Home Position Detected", 13, 10 Pos1Found = 1 New_Position_Counter = 0 Temp_Pulses = 0 Current_Position = 1 INTCON3.0 = 0 ENDIF '--------------------------------------------------------------------------- '--------------------------------------------------------------------------- ' PortB.2 Interrupt, Fault Relay Input '--------------------------------------------------------------------------- IF INTCON3.1 = 1 THEN DEBUG 13, 10, "[ INTERRUPT ] AC Invertor Fault Detected", 13, 10 AC_Fault_Detected = 1 INTCON3.1 = 0 ENDIF '--------------------------------------------------------------------------- '--------------------------------------------------------------------------- ' USART Receive Interrupt '--------------------------------------------------------------------------- IF PIR1.5 = 1 THEN 'DEBUG 13, 10, "[ INTERRUPT ] USART Receive", 13, 10 HSERIN [RS485_B0] SELECT CASE RS485_B0 CASE RS485_STX RS485_Receiving_Data = 1 RS485_Bytes_Received = 0 FOR i = 1 TO RS485_Buffer_Size RS485_Data_Buffer[i] = 0 NEXT CASE RS485_ETX RS485_Receiving_Data = 0 RS485_To_Address = RS485_Data_Buffer(0) RS485_Command = RS485_Data_Buffer(1) RS485_Parameter.HighByte = RS485_Data_Buffer(2) RS485_Parameter.LowByte = RS485_Data_Buffer(3) RS485_From_Address = RS485_Data_Buffer(4) RS485_Parameter = RS485_Parameter - 10 CASE ELSE IF RS485_Receiving_Data = 1 THEN RS485_Data_Buffer(RS485_Bytes_Received) = RS485_B0 RS485_Bytes_Received = RS485_Bytes_Received + 1 ENDIF END SELECT PIR1.5 = 0 ENDIF '--------------------------------------------------------------------------- IntDone: RESUME ' Return to main program ENABLE INTERRUPT '-------------------------------------------------------------------------------

This looks OK to me except for PIR1.5 = 0.

The USART receive interrupt flag bit can only be cleared by reading RCREG
until the buffer is empty. You're reading this only once in your int handler.

If you receive more than a single byte of data it can cause problems. I would
test the flag again before exiting this particular int handler sub-routine.

I don't think this is causing the problem you're seeing, but it could be one if
you're expecting PIR1.5 = 0 to clear the USART interrupt flag.

What happens if you remove the encoder, and replace it with a push-button
switch?

Does pressing the switch to simulate the encoder logic on the int0 input pin
work?

If it works then I would have to suspect an isolation problem.

Bruce, putting the switch works fine so I also suspect its an isolation problem. I am going to try your sujestions and build a second power supply.

I finally got it fixed.

It turns out that the conduit I was using is made of aluminum not steel and for some reason it was not good enough to shield the 3 phase power cables to the motor. I changed it to steel and it works fine now.

I also fixed the isolation problem thanks to your sugestions Bruce.

Thanks everyone.