Resetting problem

greencardigan

Senior Member
I've pulled apart one of my old projects to make a few changes but have run into a few problems.

This is the original circuit.



And i'm adding this to replace the batteries and power a 24V motor.



I'm having 2 problems.

1. The diodes on the new board are getting hot when the motor is running. I'm using a 6A diode on the +ve power line and a 3A diode across the motor.

The power supply is a variable voltage 100W laptop power supply and i'm PWMing the power to the motor at 4kHz.

The motor should be only drawing 3 or 4 amps so I wouldn't have thought the diodes would get hot.


2. This second problem is more interesting. My program keeps resetting when the motor is running.

With the power supply set on 18V, it rarely resets. But when set on say 22V, it resets sooner. The higher the supply voltage the sooner it seems to reset.

If i disconnect the download cable, it doesn't reset itself at all. Even at higher voltages.

Is this something to do with the serial input pin?? How can I stop it resetting?
 

sghioto

Senior Member
greencardigan,

If the motor is drawing 3 to 4 amps then diode D1 is dissipating 2 to 3 watts of power. If the diode is physically small then it can get hot. May need to mount the diode on a heat sink or use larger diodes.
Your reset problem maybe related to the higher motor current at higher power supply voltages but I'm not familiar with the 18X as to why the problem doesn't exist when the download cable is removed.

Steve G.
 

westaust55

Moderator
Diode Heating Problem

concur with sghioto.

You need to look at the datasheet for the diode.

Here is some data for a particular 6Amp diode by way of example:
PX6007 6A 1000V Diode
Maximum Average Forward Rectified Current TA=55 = 6.0_A
Maximum Forward Voltage at 6.0 ADC = 1.0 V

Typical Thermal Resistance (Note 2) R_JA 20 degC/W (Junction to Ambient)
Typical Thermal Resistance (Note 2) R_JL 4 degC/W (Junction to Lead)

Thermal resistance from junction to ambient and from junction to lead at 0.375"(9.5mm) lead length P.C.B. mounted with 1.1×1.1”(30×30mm) copper pads
Assuming a forward volt drop of 0.8V at 3 to 4 amps, some copper pads on the PCV like those mentioned above and an operating temperature of 70degC, then at approx 2.8 - 3 Amps the heat dissipation would be around 2.25 Watts.
 

westaust55

Moderator
That happens to be the exact diode I have given data for.

Yes, each time the FET turns off, the free wheeling diode "shunts" the energy from the motor winding to prevent over voltage spikes damaging the circuit.
 

leftyretro

New Member
Here's the data sheet. http://www.jaycar.com.au/products_uploaded/p600a.pdf

I suppose i could remove the diode completely. I'd just have to make sure I got the polarity of the supply right.

Would the diode across the motor be getting hot due to the motor switching off repeatedly?
I suspect maybe your diode across the motor is wired backward causing high current flow from the 24vdc power supply which in turn is causing the other diode to heat up with the increased current flow. Check it out, The cathode end of the motor diode should wire to the +24 and the anode towards the FET as your drawing shows properly.

Lefty
 

greencardigan

Senior Member
I suspect maybe your diode across the motor is wired backward causing high current flow from the 24vdc power supply which in turn is causing the other diode to heat up with the increased current flow. Check it out, The cathode end of the motor diode should wire to the +24 and the anode towards the FET as your drawing shows properly.

Lefty
I've checked once but will check again when I get home.
 

greencardigan

Senior Member
I'2. This second problem is more interesting. My program keeps resetting when the motor is running.

With the power supply set on 18V, it rarely resets. But when set on say 22V, it resets sooner. The higher the supply voltage the sooner it seems to reset.

If i disconnect the download cable, it doesn't reset itself at all. Even at higher voltages.

Is this something to do with the serial input pin?? How can I stop it resetting?
I'm more interested in solving this problem though. Would putting some bigger caps somewhere help??
 

westaust55

Moderator
I suspect maybe your diode across the motor is wired backward causing high current flow from the 24vdc power supply which in turn is causing the other diode to heat up with the increased current flow. Check it out, The cathode end of the motor diode should wire to the +24 and the anode towards the FET as your drawing shows properly.
If the fly wheeling diode were connected in reverse the motor would not operate at all.
 

leftyretro

New Member
If the fly wheeling diode were connected in reverse the motor would not operate at all.
I agree but there should be no current flowing through the motor diode at all, so if it's getting hot then current is flowing through it and it's either wired backward or the +24V power is wired with the wrong polarity.

Lefty
 

westaust55

Moderator
I agree but there should be no current flowing through the motor diode at all, so if it's getting hot then current is flowing through it and it's either wired backward or the +24V power is wired with the wrong polarity.

Lefty
See the second sentence in post 5
 

leftyretro

New Member
See the second sentence in post 5
I do understand the function of the diode there but there usually isn't enough energy in the spikes to cause heating in a 3 amp diode. I guess we will all just have to wait and see what the final cause and solution is.

Lefty
 

westaust55

Moderator
I'm more interested in solving this problem though. Would putting some bigger caps somewhere help??
While it seems to be related to voltage fluctuations/spikes when the motor starts, the fact that it is apparently only when the serial download cable is connected is a little puzzling.


I tend to use (personal preference):
at C1 a 470uF electrolytic
at C2 a 22uF tantalum

You could also try a 0.1uF ceramic or similar capacitor across the motor terminals.

Do you have a resistor between PICAXE physical pin 9 (PWM/Output 3) and the FET transistor? As a suggestion suggest say a 2.2 kOhm if nothing currently used - not a big issue if it is even 4.7 kOhm.
 

BeanieBots

Moderator
It's not just "spikes" that are caught by the flyback diode. At 50% duty the current can be the same as the forward motor current so heating is to be expected.
That current also needs to go somewhere. The power supply must be able to 'absorb' that power as well as supply it.

As for resetting only with power cord, this could either be lead pickup or possibly a ground loop. If both the PC and your supply are grounded, there could be very large currents flowing down the 0v line.

EDIT: More about the catch diode.
A lightly loaded motor is almost a pure inductor. When used with PWM, the circuit is identical to a boost converter with its output connected to its input. See diagram in link below. Under these conditions, the average current in the catch diode will be the same as the average current in the motor. Your supply caps need to cope with this amount of current as well as prevent excessive voltage ripple.
http://www.powerdesigners.com/InfoWeb/design_center/articles/DC-DC/converter.shtm
 
Last edited:

greencardigan

Senior Member
Thanks for the helpful info.

I've removed the 6A diode from inline with the supply and placed it in parallel with the 3A diode across the motor. They are no longer getting hot.

Somehow this has stopped the resetting problem also???? Any ideas why?
 

jglenn

Senior Member
I speculate that your motor "catch" diode was not rated properly, when you added the second one it reduced transients being generated at shutoff.

You should try a fast recovery diode for that application, I can find some part numbers, but I tend to us USA suppliers. Assuming the motor driver ground is beefy, and goes right to the power supply - input. The chip ground must be run separately to the same place. Never daisy chain high current returns with control circuit grounds.

The input diode is not rqrd, as long as you don't hook up backwards, but if you need it, try a schottky diode, on voltage is about .2 or .3V, less dissipation.

One more thing, if you have a scope, hook it across the motor and look at the waveform. You will probably see some scary spikes, even with the catch diode. Some like to use a "snubber" circuit, an R and C in series, across the motor. This is useful for solenoids you want to rapidly operate, as the catch diode actually slows turnoff time, the snubber grabs the energy instead of the diode for high speed ops.
 

BeanieBots

Moderator
As mentioned earlier, whatever the catch diode "catches", has to go somewhere. With the series diode in place, there's nowhere for it to go except to "spike" the power rail.
 

jglenn

Senior Member
Beanie: The diode across the motor coil, or any coil, channels the current during the off time back thru the coil, I have never seen it affect the bus. Some call it a "freewheeling rectifier", and chopping fast will heat it unless a fast recovery diode. A small 1A, glass one is the 1N4935. I've used the bigger MUR1540, TO220 size. Some work on invertors at Westinghouse showed how switching freq can increase heating, you can actually tailor the FET gate drive with a small resistor and sometimes a magnetic bead.

My impression was that the series diode on the B+ input was for reverse protection, but I agree it would isolate buss transients from whatever is feeding it.
 

jglenn

Senior Member
There is a case where that will happen. If you have a PM motor, and you do braking in an electric vehicle, or the motor is driven externally somehow faster than it was running, it will generate a voltage higher than the buss. So I see what you mean about the B+ feed diode isolating from that.
 

BeanieBots

Moderator
@jglenn,
Read the information given in the document I posted a link to.
In particular, the section which explains how a voltage booster works.
Connect the output of the booster to its own input and then compare that circuit to a PWM motor drive with catch diode.

Then add a diode between supply and the motor drive and tell me what type of circuit you now have. (hint: voltage booster, which also powers the PICAXE).
 

jglenn

Senior Member
I read the doc, am familiar with buck and boost conv. Was talking about just straight dc motor pwm, a switching fet, N channel, grounded source, motor from drain to B+, fast diode across the motor. That is a bit different from the boost circuit, the diode is not directly across the coil, even if you connect the output to the input. But I do see a vague similarity to your idea of "extra" power being fed back to the input of either circuit under certain conditions.

There is a guy called Dimension Engineering here in Ohio that makes motor controls for bot's, claims to have a new topology where "the regenerated motor current is fed back to the battery" to increase efficiency. Sounds bizarre to me, would have to see schematic, as all my experience has been with traditional arrangements. You WANT the flyback current to go only back into the motor, for smooth operation. The inductance of the coil filters it, continuous conduction is good. As you indicated, this power untamed can cause transients elsewhere in the circuit. I made a control that ran at 60V, up to 400A into an electric series motor, at first was blowing holes in TO3 cans, a 4" blue jet of flame shot out, used to be an NPN junction. Don't learn transistor design in the high power mode, too expensive. :(
 

Dippy

Moderator
The theory seems sound. Certainly whenever I've tried it I get good results.
Must admit I've never scoped the power rail. i tend to have a cap at the rail near the motor power connection.

Perhaps someone could 'scope it, esp with various motors and various manly power supplies.
No point arguing. Don't talk ... eat :)

I think I shall look into a MOSFET circuit to replace the flyback (or whatever you wish to call it) diode, so we an have b-all voltage drop. For PSUs, not motors. Sorry, the old cerebellum went off at a tangent there.
 

BeanieBots

Moderator
There is a guy called Dimension Engineering here in Ohio that makes motor controls for bot's, claims to have a new topology where "the regenerated motor current is fed back to the battery" to increase efficiency.
Don't know where he's been hiding but the rest of us have been doing that since around 1960. Not a particularly new technology!
 

jglenn

Senior Member
So it is just regenerative braking, I thought was some new circuit trick.

***Sabertooth is the first synchronous regenerative motor driver in its class. The regenerative topology means that your batteries get recharged whenever you command your robot to slow down or reverse.***

When are robot people going to get serious, and use brushless motors like we have in Eplanes? I have a motor the size of a spool of thread that can put out almost a half a horsepower, peak rating. Better yet, lets see some brushless motor wheel motors, maybe with a planetary gear.



http://images.google.com/imgres?imgurl=http://img.alibaba.com/photo/50437321/Integrative_Brushless_Bicycle_Motor.jpg&imgrefurl=http://cnjzdj.en.alibaba.com/product/50098292/50437321/Integrative_Brushless_Bicycle_Motor.html&usg=__m5cPcs98QyP23tOAYNPfpd11HzI=&h=360&w=360&sz=32&hl=en&start=12&um=1&tbnid=c3lEV0CjuRnPlM:&tbnh=121&tbnw=121&prev=/images?q=picture+of+brushless+motor+wheel+motor&um=1&hl=en&sa=G
 

BeanieBots

Moderator
When are robot people going to get serious, and use brushless motors like we have in Eplanes? I have a motor the size of a spool of thread that can put out almost a half a horsepower, peak rating. Better yet, lets see some brushless motor wheel motors, maybe with a planetary gear.
As one who does both, I'll answer that.
When brushless+ESC+LiPo is the same price as Brushed+ESC+Pb.

To be honest, they are converging now, so probably quite soon.

Many robots are made from 'scrap' and/or what is lying around.
There's not a great deal of brushless RC stuff 'lying around' yet.
Also, ever tried making a brushless ESC? Not impossible but not for the faint hearted either. A brushed ESC is an absolute doddle in comparison.
 

alphamike27

New Member
Resets

At 4kHz, th programming lead my be acting as an antenna, see if it resets when running, but without the motor connected.

Is the programming lead lead just hanging in on its own, or is the PC connected?

Kindest regards

alan
 

jglenn

Senior Member
Beaniebot: The brushless motors and lithium batts are coming down in price every day. These guys are hard to beat, just use the rapid shipping or your package might get lost. (Hong Kong).

http://www.hobbycity.com/hobbycity/store/uh_index.asp

Yes I tried to make a brushless ESC, a remarkable failure since I have made normal controls from scratch to 20HP. Used a raw pic chip to synthesize the 3 phase waveform, had the 3 FET bridges running fine. But it only ran at one speed, and the motor got hot. I do not understand how they do what they call "timing", this is adjustable on premium controls. Nobody uses hall sensors on the motors for planes, this is common in industry. There is some way they track the rotor, from the back emf perhaps. Considering you can buy 10A brushless ESC for about $10, it was a fruitless exercise. I have had mixed luck repairing blown up ones from a club I am in, best to not run them at the rated power, and get some airflow over the board.

I may be flying a PICAXE on an Eplane in the spring. Toying with very simple autopilots, no GPS.......................yet. :D
 

greencardigan

Senior Member
Old thread, new life.

Hi All,

Sorry to bring this old thread back to life.

I've started having problems with this circuit/program again.

The program crashes unexpectantly after it has been running ok for 20 minutes or so. After resetting, it crashes soon after the program powers up the fan and heater. It is crashing without the programming cable connected this time.

I have included my code this time (see attachment). It seems to crash when inside the loop that turns the SSR on and off (switching the mains power to some heating elements).

Program crash seems to always occur when in this loop.
Code:
for z = 1 to 100
	if z > PID then
		low ssr
		low ssr_led
	else
		high ssr
		high ssr_led
	endif
	pause 6
next z
I'm getting way out of my depth with this diagnostics stuff. :(

Any help appreciated.
 

greencardigan

Senior Member
Full Code

The code was too long to put put here complete so I have removed the initial SYMBOl statements etc.

Code:
INIT:

counter = 0		'increases each PID period (1 second)
counter2 = 0	'counter for profile selection and setpoint updates
cracks = 0		'counter for 1st and 2nd cracks
roastlevel = 0	'adjustment for roast end temp

pwmout 3, 255, 1023	'set fan to full for a while to get going
pause 200			'pause to give fan time to start


do						'LOOP FOR PROFILE SELECTION
	if input_button1 = 1 then	'Waits in this loop until button1 is pressed
		do
		loop while input_button1 = 1	'debounce
		pause 200
		exit
	endif
	if input_button2 = 1 then	'increase counter2 if button2 is pressed
		inc counter2
		pause 200
		if counter2 > 2 then	'reset counter2 if > 2
			counter2 = 0
		endif
	endif
	
	if counter2 = 0 then		'show which profile is selected
		high manual_led
		low ssr_led
	elseif counter2 = 1 then
		low manual_led
		high ssr_led
	else
		high manual_led
		high ssr_led
	endif

	readadc10 manual_val, fanspeed 	'read value for fan speed
	if fanspeed < 350 then
		fanspeed = 0
	endif
	pwmout 3, 255, fanspeed			'set manual fan speed. Fan will go to auto when roasting starts
		 
loop

low manual_led

do						'LOOP FOR PROFILE CUTOFF TEMP ADJUSTMENT
	if input_button1 = 1 then	'Waits in this loop until button1 is pressed. Then starts roast
		do
		loop while input_button1 = 1	'debounce
		pause 200
		exit
	endif
	if input_button2 = 1 then	'increase counter2 if button2 is pressed
		do
		loop while input_button2 = 1	'debounce
		pause 200
		inc roastlevel
		if roastlevel > 5 then	'reset roastlevel if > 5 ie max 5 degrees adjustment
			roastlevel = 0
		endif
		
		if roastlevel <> 0 then	
			for z = 1 to roastlevel
				pause 200
				high manual_led
				pause 200
				low manual_led
			next z
		endif
 
	endif
	
loop

if counter2 = 0  then						'adjust cutoff temp
	if manual_switch = 0 then				'having manual_switch down will give negative adjustment
		roastlevel = profile1cutoff + roastlevel
	else
		roastlevel = profile1cutoff - roastlevel
	endif
elseif counter2 = 1 then
	if manual_switch = 0 then
		roastlevel = profile2cutoff + roastlevel
	else
		roastlevel = profile2cutoff - roastlevel
	endif
elseif counter2 = 2 then
	if manual_switch = 0 then
		roastlevel = profile3cutoff + roastlevel
	else
		roastlevel = profile3cutoff - roastlevel
	endif
endif

roastlevel = roastlevel + 1		'will cut off roast when setpoint reaches roast level + 1. ie. temp gets to previous setpoint

if manual_switch = 1 then		'manual_switch must be returned to off otherwise manual instead of PID
	for z = 1 to 20			'gives warning if manual_switch is on. Time to switch it off if desired
		high manual_led
		pause 200
		low manual_led
		high ssr_led
		pause 200
		low ssr_led
	next z
endif

sertxd("Roast Temp Cutoff = ",#roastlevel)
'end

if counter2 = 0 then			'Send selected profile
	sertxd ("Profile 1",13,10)
	counter2 = 0			'set eeprom location for start of profile 1 storage
elseif counter2 = 1 then
	counter2 = 85			'set eeprom location for start of profile 2 storage
	sertxd ("Profile 2",13,10)
else
	counter2 = 170			'set eeprom location for start of profile 3 storage
	sertxd ("Profile 3",13,10)
endif

sertxd ("Time Setpoint Temp PID FanSpeed Cracks",13,10)	'Send column headings


poke INT_lsb, 0
poke INT_msb, 128	'set initial pid value to 32768.  i.e. false zero

pwmout 3, 255, 1023	'set fan to full for a while to get going
pause 200			'pause to give fan time to start



'#########################################################################################

MAIN:

if manual_switch = 1 then		'Manual temp control
	high manual_led
	gosub GETMANUALVAL
	gosub GETTEMP
	gosub SETFANSPEEDHEATING
	sertxd ("- - ",#t, " ", #PID, " ", #fanspeed, #13,10)
else						'Or PID Control
	low manual_led
	z = counter // 15
	if z = 0 then			'Every 15 seconds update setpoint
		read counter2, sp
		inc counter2
	endif

	if sp = 0 or sp = roastlevel then		'At end of profile send completed message
		sertxd ("Roast Profile Completed",13,10)
		gosub COOLBEANS
		end				'END PROGRAM after cooling
	endif
	
	if input_button2 = 1 then	'Send terminated message if button2 is pressed during roast
		sertxd ("Roast Terminated",13,10)
		gosub COOLBEANS
		end				'END PROGRAM after cooling
	endif

	gosub DOPID				'RUN PID ROUTINE
	
	gosub SETFANSPEEDHEATING	'changes fan speed based on current temp
	
	sertxd (#counter," ",#sp," ",#t," ",#PID, " ", #fanspeed)		'Send serial data
	

	
	if input_button1 = 1 then	'Add to serial data if button1 is pressed during roast
		high manual_led
		if cracks = 0 then
			sertxd (" FirstCrack")
		elseif cracks = 1 then
			sertxd (" SecondCrack")
		else
			sertxd (" Crack")
		endif
		inc cracks
	endif


	sertxd (13,10)	'Add carriage return and line feed to serial data
	

	inc counter		'Increase loop counter			
		
endif


for z = 1 to 100				'Manual PWM with 1 second period (adjust pause at end of main routine to get 1 sec period)
	if z > PID then
		low ssr
		low ssr_led
	else
		high ssr
		high ssr_led
	endif
	pause 6
next z

high ssr					'Keep output high while doing PID calcs
high ssr_led


pause 45					'Adjust to get timing right on PID mode (1 sec PWM period)


goto main

'#########################################################################################


DOPID:		'PID CALCULATIONS

gosub GETTEMP	'Get temp reading from thermocouple

peek INT_lsb, b4	'read old int value into PID w2 (PID)
peek INT_msb, b5
if PID > 49000 then
	PID = 49000
else
	PID = PID
endif

if t <= sp then	'for negative errors
	
	b0 = sp - t	max 65 	'error
	
	w3 = Ki * b0 * dt max INT_MAX	'INTEGRAL..........................
	PID = PID + w3 max PID_MAX	'Add new int value to previous int value		
	poke INT_lsb, b4			'store new int value w2
	poke INT_msb, b5
			
	w3 = Kp * b0 max PRO_MAX	'PROPORTIONAL......................
	PID = PID + w3 max PID_MAX	'Int + Pro
	
else 'for positive errors

	b0 = t - sp	max 65		'error
	
	w3 = Ki * b0 * dt max INT_MAX	'INTEGRAL.........................
	PID = PID - w3 min PID_MIN	'subtract new int value to previous int value	
	poke INT_lsb, b4			'store new int value w2
	poke INT_msb, b5
	
	w3 = Kp * b0 max PRO_MAX	'PROPORTIONAL....................
	PID = PID - w3 min PID_MIN	'Int + Pro
	
endif
poke PRO_lsb, b6				'store pro value w3
poke PRO_msb, b7

'goto SKIPDER

peek pt, b0
if t > b0 then 'temp increasing
	w3 = t - b0
	w3 = w3 * Kd max DER_MAX	'DERIVATIVE ......................
	PID = PID - w3 min PID_MIN	'int + pro + der
elseif t < b0 then 'temp decreasing
	w3 = b0 - t
	w3 = w3 * Kd max DER_MAX	'DERIVATIVE ......................
	PID = PID + w3 max PID_MAX	'int + pro + der
else
	w3 = 0 'no derivative part
endif
poke DER_lsb, b6				'store der value w3
poke DER_msb, b7

poke pt,t					'store current temp as previous temp

SKIPDER:

if PID <= 32678 then
	PID = 0
else
	PID = PID - 32678			'convert to range 1-20000
	PID = PID / 200			'convert to range 1-100
endif

'PID = 100

'peek INT_lsb, b6
'peek INT_msb, b7
'sertxd("INT: ",#w3,13,10)
'peek PRO_lsb, b6
'peek PRO_msb, b7
'sertxd("PRO: ",#w3,13,10)
'peek DER_lsb, b6
'peek DER_msb, b7
'sertxd("DER: ",#w3,13,10)
'sertxd("PID: ",#w2,13,10)

'pause 4000

return


'#########################################################################################


GETTEMP:	'Manual SPI

high cs
low sck
	
low cs
	
w3 = 0
for z = 1 to 16
	high sck
	w3 = w3 * 2 + miso
	low sck
next z

high cs

w3 = w3 / 8
t = w3 / 4


'sertxd (#w3, 13, 10)

return

'#########################################################################################


GETMANUALVAL:	'Reads POT instead of thermocouple in manual mode

readadc10 manual_val, PID

'sertxd (#PID,13,10)

PID = PID + 1024

PID = PID / 20			'Convert adc value into the range approx 50 - 100


return


'#########################################################################################


COOLBEANS:

low ssr				'Turn SSR off
low ssr_led
for counter2 = 1 to 240			'About 4 minutes cooling time
	high manual_led
	pause 250
	low manual_led
	pause 250
	high manual_led
	pause 250
	low manual_led
	pause 250
	
	gosub GETTEMP
	sertxd (#t, " ",#counter2 ,13,10)
	if t < 40 and counter2 > 60 then	'end cooling if beans are < 40 deg. But minimum 1 min cooling
		pwmout 3, 0, 0
		low 3
		exit
	endif
	
	gosub SETFANSPEEDCOOLING
	
next counter2

if t < 50 then
	pwmout 3, 0, 0
	low 3
else
	goto COOLBEANS
endif


return

'#########################################################################################


SETFANSPEEDHEATING:


fanspeed = sp * fanconstant2 / fanconstant3			'set fan speed based on current setpoint
fanspeed = fanconstant1 - fanspeed * 4 max maxfanspeed

pwmout 3, 255, fanspeed

return

'#########################################################################################


SETFANSPEEDCOOLING:


fanspeed = t * fanconstant5 / fanconstant6			'set fan speed based on current temp
fanspeed = fanconstant4 - fanspeed * 4 max maxfanspeed

pwmout 3, 255, fanspeed

return
 

BeanieBots

Moderator
Noise problems are always difficult to find.
As a first step, remove the load from the SSR so that the code works as normal, the SSR is switched on/off but no mains is switched.
If you still get resets, it is your code (or wiring error).
If there are no resets, it's mains interferance.

If the later, check your wiring. No mains leads running close to low voltage leads.
 

greencardigan

Senior Member
Still crashes

I tried disconnecting the load on the SSR but it still dies.

I have to run it for about 20 minutes from cold before I can get it to crash. Once it has crashed once, it crashes within a minute once the SSR and MOSFET are being switched on/off.

Sometimes it resets and returns to the beginning of the code. Othertimes it seems to freeze with the FET sometimes on and sometimes off.

Maybe I should just try a separate power supply for the motor and picaxe.
 

BeanieBots

Moderator
Well, that's good, you've eliminated mains interferrance.
Does it ever reset with the motor disconnected.

It's always a good idea to have seperate supplies for heavy loads but first identify what/which load causes the problem.
 

hippy

Ex-Staff (retired)
I would suggest adding additional SERTXD so you can trace where the code is and goes to and particularly indicate when the PICAXE is resetting or freezing. One handy trick for trapping an unexpected Reset after download is

Eeprom 0,(0)
Read 0, b0
If b0 <> 0 Then
SerTxd( "Reset!")
Do : Loop
End If
Write 0, 1

The code is likely just too complicated for anyone else to work through and especially as it crashes after some time. The best bet is in isolating where the crash actually occurs, then try and work back from there. If it's not a supply or reset issue my suspicion would be in some algorthm overflowing variables or trampling on others.

If you think the code is crashing in the part shown in post #31, add an "entered" before and an "exited" after the loop, perhaps print the values of 'z' and 'PID', If it enters and exits it's probably not crashing within the loop.
 

greencardigan

Senior Member
I have already tried using sertxd to track down where it crashes and this showed it was often crashing inside the loop I mentioned. However, the program is in that loop for most of the time so it could just be coincidence?

BB. I'll have to pull things apart to disconnect the motor load. I'll try this next time I have time.

In the meantime I might try running a simplified version of the code without any of the PID calcs. That should eliminate the possibility of variable overflow problems etc.

I just don't understand why it runs perfect for 20+ minutes if I haven't used it for some time. I don't see how this could be a coding problem.

I appreciate your help guys.
 

hippy

Ex-Staff (retired)
I just don't understand why it runs perfect for 20+ minutes if I haven't used it for some time. I don't see how this could be a coding problem.
It's often hard to see coding errors ( or more correctly mistakes in the algorithm ) and especially when it's an issue which only occurs after some time - though that could be a pointer to where the problem is.

What usually happens is you expect some variable to have a certain value, and most often it does, but then there's some case when it doesn't, a D'oh! moment in the making for when you find it and work out why.

Sometimes it's a case of going through every line of code and routine checking that it does what it is supposed to, checking how a potential error could occur, checking that a values in and out are correct. You may have to log masses of data while it's running then plough through that looking for something odd after it has crashed.

The larger the code the more complicated it is and there's a greater chance only the author understands what it's meant to be doing.

Two good code design approaches can help - modularisation and design for testability. Keep things as self-contained subroutines which perform a specific task so you can feed in values and get values out even when not connected to hardware and prove they work. Putting all input reads into a single subroutine rather than scattered throughout the code can help both for simulation and in running the system without real hardware attached. If you cannot run the code without the hardware attached it becomes very difficult to debug because you have no control over what's happening.
 

westaust55

Moderator
I think that if you want someone to go through your project in detail, you need to:

1. Provide a plain english description of what the code is intended to do

2. the range of values for any inputs (such as from READADC readadc10 manual_val, fanspeed )

3. provide a scheamtic diagram

From a very quick look at the code, there are many cases where the code can be simplified for readability and to save program space. For example:
Code:
	if counter2 = 0 then		'show which profile is selected
		high manual_led
		low ssr_led
	elseif counter2 = 1 then
		low manual_led
		high ssr_led
	else
		high manual_led
		high ssr_led
	endif
could be replaced with:


Code:
	if counter2 = 1 then 		'show which profile is selected
		low manual_led
	else
		high manual_led
	endif
	high ssr_led
I often spend a considerable amount of time with the code for my own projects to check intermediate maths in an endeavour to make sure math overflow and resultant errors will not occur. It does take time and MS Excel or another spreadsheet program can help there.
 
Last edited:

greencardigan

Senior Member
I dont really expect anyone to trawl through my code. I get a headache when I look at it myself. :(

I plan to run a simplified version of the code to try and eliminate the code as a cause of the crashes.

Essentially the code is a PID controller which switches a heater element (via SSR) using very slow PWM (1 Hz) to follow a set temperature profile (setpoint changes every 15 seconds). Temps are measured usking a K-Type thermocouple via a maxim chip and manual SPI code.

A fan is also controlled with 4 KHz PWM via a N channel mosfet. The PWM duty cycle is calculated based on the current PID temp setpoint.

All in the name of freshly roasted coffee beans. :D

A typical roast proceeds as follows:

1. Set toggle switch to auto mode (ie use PID algorithms)
2. Select which temp profile to follow using momentary switch
3. Select roast cutoff level using momentary switch
4. Start roast using momentary switch
5. Roast runs for approx 17 minutes following the set temp profile (increasing from 0 to approx 225 degrees celcius)
6. Once cutoff temp is reached, the heater stops and the fan remains on cooling the beans untill the temp reaches 40 deg.
7. Program ends.
 
Last edited:
Top