Issue with PICAXE and Instrumental Amplifier AD623

Andrei IRL

Senior Member
Hi everyone.

I am building a strain-gauge and the controller using PICAXE 14M2 and AD623 Instrumental Amplifier.

Everything is working as expected except for one small issue.

Every now and again PICAXE would get a random reading lower then expected without any changes to the strain gauge.

I have the System running off Bench power supply but have also tried using battery pack which resulted in the same issue.

I have tried to filter any odd readings buy running an extra routine in the program "fire check", which placed a delay of 25ms (50ms at 8Mhz) and re-checking the inut signal once more.

Only then if the signal is still less then threshold would the code move on.

However this random triggering is still happening despite trying to rule it out buy using code.

I have attached Schematic diagram as well as Screenshot of the Terminal.

Screenshot shows the moment false triggering happened when ADC reading went to 386 or so. Threashold for the trigger was set to around 500.

Reading with no load on the loadcell is around 560 the rest of the time.

So i am trying to figure out whats causing this random ADC readings and how to go about fixing it.

What i have noticed is this random triggering might happen when i turn my table light on or off at times, but id have to try for a good few minutes to make this happen.

Not sure if this would happened when ran on battery power only.

I have tried different straingauges (loadcell) wit same result.

I have an oscilloscope but its about 60 years old analog one and i have tried reading some signals using it but could detect any noise anywhere on the circuit.

Thanks very much in advance for any input on this.

Terminal Picture.JPG
 

Andrei IRL

Senior Member
Schematics are attached below.

Also see the CODE.
Code:
#picaxe 14m2
setfreq m8 ` Running at 8Mhz, all pause values are x2 times
symbol greenled=B.1 	`GREEN LED
symbol redled=B.2		'RED LED
symbol RELAY1=B.3
symbol RELAY2=B.4			'Assuming when sensor is PULLed READADC is increasing
symbol push_but=pin2
symbol pull_but=pin3
symbol kill = b27			'Assuming when senor is PUSHed READADC is decreasing
symbol pull_sens=w0							'w0-b0/b1 - pull_sens
symbol push_sens=w1							'w1-b2/b3 - push_sens
symbol sens_zero=w7							'w7-b14/b15
symbol delta=w8
symbol adc=w3
symbol counter=b26
read 0,kill
readadc10 C.4,sens_zero
if pull_but=1 then pull
if push_but=1 then push_1

read 1,word pull_sens
read 4,word push_sens
read 6, word delta

	pull_sens=pull_sens+sens_zero
	push_sens=sens_zero-push_sens
	if push_sens > sens_zero then let push_sens=0
endif

main:		high greenled
		low redled
		readadc10 C.4,adc						'w4-b8/b9 - strain gauge running
		if adc>pull_sens  then firecheck
		if adc<push_sens then firecheck
		if pull_but=1 and push_but=1 then BothPushed
  		if pull_but=1 then Plusone
  		if push_but=1 then Minusone
  	
goto main

push_1: 	pause 100
		low greenled
		high redled
		pause 100
		high greenled
		low redled
		if push_but=1 then push_1				'Learning Sensitivity for PUSH
		pause 100
		if push_but=1 then push_1
 
	push_sens=$FFFF
do
	toggle greenled
	toggle redled
	readadc10 C.4,adc					'w3-b6/b7	
 		if adc<push_sens then
   			let push_sens = adc
	end if
	pause 100
	
loop while push_but=0 and pull_but=0

	push_sens=sens_zero-push_sens
	delta=push_sens/10
	write 6, word delta
	push_sens=push_sens+delta
	write 4,word push_sens
	pull_sens=40000
	write 1,word pull_sens
	push_sens=sens_zero-push_sens
	
goto main

pull: 	pause 100
		low greenled
		high redled
		pause 100
		high greenled
		low redled
		if pull_but=1 then pull							'Learning Sensitivity for PUSH
		pause 100
		if pull_but=1 then pull
						'Learning Sensitivity for PUSH
	pull_sens=0
do 
	toggle greenled
	toggle redled
	readadc10 4,adc					'w3-b6/b7	
 		if adc>pull_sens then
   			let pull_sens = adc
	end if
	pause 100
	
loop while pull_but=0 and push_but=0

	pull_sens=pull_sens-sens_zero
	delta=pull_sens/10
	write 6, word delta
	pull_sens=pull_sens+delta
	write 1,word pull_sens
	push_sens=sens_zero
	write 4,word push_sens
	
	pull_sens=pull_sens+sens_zero
	push_sens=sens_zero-push_sens	
	if push_sens >= sens_zero then let push_sens=0
	
endif
	
goto main


firecheck:
		pause 20
		if adc>pull_sens  then fire
		if adc<push_sens then fire
		
goto main

fire: 
		high relay1
		high relay2
		high redled
		low greenled
		pause kill
		low relay1
		low redled
		pause 40
		low relay2
		
			let pull_sens=pull_sens-25
			let push_sens=push_sens+25

waitqs: 	readadc10 4,adc
		if adc>pull_sens then waitqs
		if adc<push_sens then waitqs
			let pull_sens=pull_sens+25
			let push_sens=push_sens-25


pause 400
goto main

bothpushed:	kill = 130	`kill time 65ms
		write 0,kill 
		low greenled
		For b25=0 to 4							'b6 - led counter
		high greenled
		pause 600 	` pause 300ms
		low greenled
		pause 600	`pause 300ms
	next b25

goto main

plusone:if kill>200 then main		`MAX 100ms
		kill = kill + 2  		`+1ms
		write 0,kill
		low greenled
		pause 1000			`pause 500ms
		high greenled
		
goto main

minusone:if kill<80 then main		`MIN 40ms
		kill = kill - 2		`-1ms
		write 0,kill
		low greenled
		pause 1000 			`pause 500ms
		high greenled
		
goto main

Schematics.JPG
 

hippy

Technical Support
Staff member
The first thing to do would be to determine if the ADC is glitching by itself -

Code:
#Picaxe 14M2
#Terminal 9600
SetFreq M8

Symbol val    = w0
Symbol minVal = w1
Symbol maxVal = w2

ReadAdc10 C.4, val
minVal = val
maxVal = val
SerTxd( #minVal, TAB, #maxVal, CR, LF )

Do
  ReadAdc10 C.4, val
  Select Case val
    Case < minVal
      minVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
    Case > maxVal
      maxVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
  End Select
Loop
Leave that running for a while and if there is no major glitching then try turning your lamp and other things on and off to see if that causes them.

I believe instrumentation amplifiers are quite sensitive so it could be glitching because of induced EMI or RF, a fridge or other item switching on or off, some other spike on the mains.
 

Andrei IRL

Senior Member
The first thing to do would be to determine if the ADC is glitching by itself -

Code:
#Picaxe 14M2
#Terminal 9600
SetFreq M8

Symbol val    = w0
Symbol minVal = w1
Symbol maxVal = w2

ReadAdc10 C.4, val
minVal = val
maxVal = val
SerTxd( #minVal, TAB, #maxVal, CR, LF )

Do
  ReadAdc10 C.4, val
  Select Case val
    Case < minVal
      minVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
    Case > maxVal
      maxVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
  End Select
Loop
Leave that running for a while and if there is no major glitching then try turning your lamp and other things on and off to see if that causes them.

I believe instrumentation amplifiers are quite sensitive so it could be glitching because of induced EMI or RF, a fridge or other item switching on or off, some other spike on the mains.
Thanks very much for that.

I will try that this evening.

The main problem is, i want to use this system on a motorcycle and motorcycles have a very noisy electrical environment.

I haven't tested it on a bike yet so the above statement is only a guess.

Thanks again.

I'll report with the findings
 

hippy

Technical Support
Staff member
As a safety critical system, it's not just an issue of making what you have work, it's a matter of making it immune from errors. Both during calibration and in use.

As it is safety critical I will dispense with the usual niceties. Your code simply isn't up to scratch for a safety critical system.
 

Andrei IRL

Senior Member
As a safety critical system, it's not just an issue of making what you have work, it's a matter of making it immune from errors. Both during calibration and in use.

As it is safety critical I will dispense with the usual niceties. Your code simply isn't up to scratch for a safety critical system.
Thanks very much for the feed back hippy.

Could you please point me in the right direction in order to improve the code?
 

PhilHornby

Senior Member
Some thoughts...

The PIC16(L)F1825/9 datasheet, says "The maximum recommended impedance for analog sources is 10 k&#8486;". The AD623 datasheet says "The AD623 is designed to drive loads of 10 k&#937; or greater". So they're only just within each other's specs.

The AD623 datasheet has quite a lot of info. on the physical layout to be used, to guard against RF interference. It talks for instance, about PCBs using ground-planes both sides. Analog Devices have a range of evaluation boards (presumably built to their design rules). Maybe you could try one of those and see if you still get the problems?

Finally, you might be able to work around the issue, by taking more samples - which may involve increasing the clock speed of the 14M2. However, this in-turn could lead to problems with the Picaxe - the PIC datasheet cautions against using certain ADC Clock Periods vs certain Device Operating Frequencies. Since the Picaxe firmware is in control of the ADC, not you - experimentation may be required. (I know, for example, that attempts to read the Supply Voltage @ 32MHz gives the wrong answer).
 
Last edited:

hippy

Technical Support
Staff member
For safety critical system one needs to be able to prove it doesn't fail.

The code needs to be understandable and easy to follow with its intent and actions clear. It needs to be structured in such a way that each individual part can be determined to do what it's meant to do, and when those parts are put together that it does what it is meant to achieve.

That means block structured commands, modularisation, things moved to subroutines even if they don't need to be in subroutines, no GOTO commands, better descriptions of routines and variables and making it clear what the intent is.

Anyone looking at teh code should be able to see what each part does and understand it, and then go deeper to see how it does it, for example -

Code:
PowerOn:
  If calibrating Then
    Gosub Calibrate
  Else
    Gosub ReadExistingCalibration
  End If
MainLoop:
  Do
    Gosub DeterminePedalPosition
    Select Case pedalPosition
       Case PEDAL_UP   : Gosub GoUpAGear
       Case PEDAL_DOWN : Gosub GoDownAGear
    End Select
  Loop
That I'm guessing is your intent, and all that remains is to create the code which fulfils the additional parts. Put those in subroutines not inline in the existing code.

For reading and writing EPROM for example; you should have a 'ReadSettings:' and a 'WriteSettings:' or similarly named routines which do just that and are called to achieve those actions. It's then easier to prove they do match and do work as intended.

It's hard to describe because it's like asking how an artist paints a great picture, how a songwriter crafts a great song. A lot comes from experience.

Above all it needs to match with a formal written specification as to what the system is intended to do and a functional specification of how it achieves that.
 

Andrei IRL

Senior Member
The PIC16(L)F1825/9 datasheet, says "The maximum recommended impedance for analog sources is 10 k&#8486;". The AD623 datasheet says "The AD623 is designed to drive loads of 10 k&#937; or greater". So they're only just within each other's specs.

The AD623 datasheet has quite a lot of info. on the physical layout to be used, to guard against RF interference. It talks for instance, about PCBs using ground-planes both sides. Analog Devices have a range of evaluation boards (presumably built to their design rules). Maybe you could try one of those and see if you still get the problems?

Finally, you might be able to work around the issue, by taking more samples - which may involve increasing the clock speed of the 14M2. However, this in-turn could lead to problems with the Picaxe - the PIC datasheet cautions against using certain ADC Clock Periods vs certain Device Operating Frequencies. Since the Picaxe firmware is in control of the ADC, not you - experimentation may be required. (I know, for example, that attempts to read the Supply Voltage @ 32MHz give the wrong answer).
Thanks very much.

I will go over the IC datasheet again and see if i have missed anything.
 

Andrei IRL

Senior Member
For safety critical system one needs to be able to prove it doesn't fail.

The code needs to be understandable and easy to follow with its intent and actions clear. It needs to be structured in such a way that each individual part can be determined to do what it's meant to do, and when those parts are put together that it does what it is meant to achieve.

That means block structured commands, modularisation, things moved to subroutines even if they don't need to be in subroutines, no GOTO commands, better descriptions of routines and variables and making it clear what the intent is.

Anyone looking at teh code should be able to see what each part does and understand it, and then go deeper to see how it does it, for example -

Code:
PowerOn:
  If calibrating Then
    Gosub Calibrate
  Else
    Gosub ReadExistingCalibration
  End If
MainLoop:
  Do
    Gosub DeterminePedalPosition
    Select Case pedalPosition
       Case PEDAL_UP   : Gosub GoUpAGear
       Case PEDAL_DOWN : Gosub GoDownAGear
    End Select
  Loop
That I'm guessing is your intent, and all that remains is to create the code which fulfils the additional parts. Put those in subroutines not inline in the existing code.

For reading and writing EPROM for example; you should have a 'ReadSettings:' and a 'WriteSettings:' or similarly named routines which do just that and are called to achieve those actions. It's then easier to prove they do match and do work as intended.

It's hard to describe because it's like asking how an artist paints a great picture, how a songwriter crafts a great song. A lot comes from experience.

Above all it needs to match with a formal written specification as to what the system is intended to do and a functional specification of how it achieves that.
Thanks again hippy.

I will try edit the code to the format you have provided.

It does make great sense.

Thanks very much.
 

hippy

Technical Support
Staff member
The formal name is "top down approach", build the outer stuff and then fill in the stuff below. The opposite is "bottom up" where you write all the stuff you'll need and then fit it all together later. In practice it usually ends up a bit of each; it's the middle where the majority of the complexity is.

The trick is to compartmentalise so you have simple top, middle and bottom stuff. There may be a lot of stuff but it allows individual bits to be understood if not the whole. And hopefully allows everyone to analyse what they can understand even if they don't understand the rest.

One can focus on one thing, not worry how it's used, how it's implemented below, just that in itself it is sound. Do that for all bits and it should all be sound.

What might at first sight seem a waste in having "Gosub TurnMotorOn" with a TurnMotorOn routine which simply sets a pin high isn't so much a waste as it may seem. It allows the TurnMotorOn routine to be confirmed as "fact", is using the right pin, is set to the right polarity, and it also means anything turning the motor on with that GOSUB will be doing what was intended. It's also self documenting; everyone will have a good understanding of what TurnMotorOn does without having to go look for it.

It also means that you can change that easily. If it turns out you actually have to control the motor differently - disable the motor, wait a while, set it high, re-enable it - you only need to tweak that one routine. Anything which calls it remains the same, should work as well as it ever did.

In your particular case, calibrating the pedal and then determining if pushed up or down are the key things. If they can be made separate parts to what uses them it will be much easier to fine tune them as separate lumps. It also allows people to analyse and test those as standalone lumps without having any of the other hardware which may be required to make the whole work.

This also applies to another post which is active where a PICAXE appears to be resetting when it shouldn't. Having things modular allows the part which is causing a problem to be identified, then the rest can be stripped away so just the problem remains. That makes it easier to analyse and also to fix. In a 1,000 line program which doesn't work it's "who knows", in a three line piece of code there's a lot less which could be wrong if it's not working.
 

Andrei IRL

Senior Member
The formal name is "top down approach", build the outer stuff and then fill in the stuff below. The opposite is "bottom up" where you write all the stuff you'll need and then fit it all together later. In practice it usually ends up a bit of each; it's the middle where the majority of the complexity is.

The trick is to compartmentalise so you have simple top, middle and bottom stuff. There may be a lot of stuff but it allows individual bits to be understood if not the whole. And hopefully allows everyone to analyse what they can understand even if they don't understand the rest.

One can focus on one thing, not worry how it's used, how it's implemented below, just that in itself it is sound. Do that for all bits and it should all be sound.

What might at first sight seem a waste in having "Gosub TurnMotorOn" with a TurnMotorOn routine which simply sets a pin high isn't so much a waste as it may seem. It allows the TurnMotorOn routine to be confirmed as "fact", is using the right pin, is set to the right polarity, and it also means anything turning the motor on with that GOSUB will be doing what was intended. It's also self documenting; everyone will have a good understanding of what TurnMotorOn does without having to go look for it.

It also means that you can change that easily. If it turns out you actually have to control the motor differently - disable the motor, wait a while, set it high, re-enable it - you only need to tweak that one routine. Anything which calls it remains the same, should work as well as it ever did.

In your particular case, calibrating the pedal and then determining if pushed up or down are the key things. If they can be made separate parts to what uses them it will be much easier to fine tune them as separate lumps. It also allows people to analyse and test those as standalone lumps without having any of the other hardware which may be required to make the whole work.

This also applies to another post which is active where a PICAXE appears to be resetting when it shouldn't. Having things modular allows the part which is causing a problem to be identified, then the rest can be stripped away so just the problem remains. That makes it easier to analyse and also to fix. In a 1,000 line program which doesn't work it's "who knows", in a three line piece of code there's a lot less which could be wrong if it's not working.
Thanks very much once more hippy.

I will work on the code and Will try to get it to a better code writing standard.

I really appreciate the time you spent shearing your advice.
 

Pongo

Senior Member
If the schematic is complete I would say the power supply filtering (2x 100 nF?) is inadequate for an automotive application, or any that involves switching relay coils.
 

Andrei IRL

Senior Member
I have used the code below (thanks hippy) to test the system.

Code:
'this code will display MAX and MIN values recieved by PICAXE on PIN4 using READADC command.

#Picaxe 14M2
#Terminal 9600
SetFreq M8

Symbol val    = w0
Symbol minVal = w1
Symbol maxVal = w2

ReadAdc10 C.4, val
minVal = val
maxVal = val
SerTxd( #minVal, TAB, #maxVal, CR, LF )

Do
  ReadAdc10 C.4, val
  Select Case val
    Case < minVal
      minVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
    Case > maxVal
      maxVal = val
      SerTxd( #minVal, TAB, #maxVal, CR, LF )
  End Select
Loop
Variance of ADC some times when something electrical in the house turned ON or OFF, like a light.

Termianl Picture2.JPG

I have tried powering the circuit using battery and same oddly low readings came up when light switch inside the room is toggled numerous times.

At this stage, USB is the only thing physically linking the circuit to house electrical circuit.

I have 0.1uF ceramic cap across the power at the AD623 chip but not the 10uF as per Manual.

I am using LM7812 together with LM7805 (100ma version) to power PICAXE and AD623.

I have one 10uF and 22uF electrolytic caps across the Input and output of LM7805.

Looks like noise is still coming through somehow.

Any idea what else i could test to find out the culprit?

Thanks Very much.

Andrei.
 

hippy

Technical Support
Staff member
I know virtually nothing about instrumentation amps but from the datasheet I looked at a 250R resistor sets a gain of 400, which means 2.5mV of noise would give a 1V output change.

The noise could be coming in through the inputs, the REF, even the power supply or 0V.

What exactly is your strain gauge circuit, and how is it wired ? I can't figure out the circuit from the stuff at the top left.
 

Andrei IRL

Senior Member
I know virtually nothing about instrumentation amps but from the datasheet I looked at a 250R resistor sets a gain of 400, which means 2.5mV of noise would give a 1V output change.

The noise could be coming in through the inputs, the REF, even the power supply or 0V.

What exactly is your strain gauge circuit, and how is it wired ? If it's just across the two inputs then isn't that simply floating ?
Im using half weatstone bridge configuring.
Two 350 ohm 0.1% resistors and two strain gauges.
Only one strain gauge is sensing the force, the other is for temperature compensation.

I'm not sure if that answers your question.
 

premelec

Senior Member
Strain gauge probably a resistor bridge with additional TempCo compensation... however in general OP might do well to build shield box with input/output filter caps - this can often be realised with printed circuit board pieces soldered together. In automotive applications it's been noted that spikes in voltage lines of 3 to 5 times the 12 volt battery may occur and so regulators should be able to handle that [and there are regulators spec'd for this type use]. You may also have a common mode voltage spec to pay attention to with the INAmp.
 

Andrei IRL

Senior Member
Strain gauge probably a resistor bridge with additional TempCo compensation... however in general OP might do well to build shield box with input/output filter caps - this can often be realised with printed circuit board pieces soldered together. In automotive applications it's been noted that spikes in voltage lines of 3 to 5 times the 12 volt battery may occur and so regulators should be able to handle that [and there are regulators spec'd for this type use]. You may also have a common mode voltage spec to pay attention to with the INAmp.
Thanks for your reply.

Have you any experience in automotive linear voltage regulators?

I will do some research on them.
 

premelec

Senior Member
What voltage do you have on the strain bridge - and what voltage on the INAmp? Are they the same source?

I haven't had direct experience with the Auto rated regulators - just read manufacturers announcements and such...
 
Last edited:

Andrei IRL

Senior Member
What voltage do you have on the strain bridge - and what voltage on the INAmp? Are they the same source?

I haven't had direct experience with the Auto rated regulators - just read manufacturers announcements and such...
Im using 5v on the InAmp and using same source to power the straingauge bridge.
 

premelec

Senior Member
Should be OK - I looked some for VRs specific to automotive environment and didn't find much though Infineon had this chart but all the outputs seem to be 3v. https://www.infineon.com/cms/en/product/power/linear-voltage-regulator/ main auto market seems to be toward high power... I guess any regulator that can take up to 60v spikes should work. Or put a hefty suppression on the input of ordinary regulator. Temperature span and short protection should be considered.
 

Andrei IRL

Senior Member
Should be OK - I looked some for VRs specific to automotive environment and didn't find much though Infineon had this chart but all the outputs seem to be 3v. https://www.infineon.com/cms/en/product/power/linear-voltage-regulator/ main auto market seems to be toward high power... I guess any regulator that can take up to 60v spikes should work. Or put a hefty suppression on the input of ordinary regulator. Temperature span and short protection should be considered.
Had a long reply typed up and then Chrome crashed, boom...

Any way, i have ordered a couple of linear voltage regulators that are specificaly designed for automotive applications.

One is Infineon TLE42744G V50, LDO Regulator, 400mA, 5 V
and the other one is very-low-dropout L4931 from ST.

Also i thought it might be a good idea to use 18V Zener before the regulation just as a precaution.
 

AllyCat

Senior Member
Hi,

Had a long reply typed up and then Chrome crashed, boom...
One of the good features of the PICaxe forum software is that it has an "Auto Backup" feature and you can (sometimes) recover your work by clicking "Restore Auto Saved Contents" at the foot of the reply window (may need to use the "Go Advanced" Tab.). However, it does appear to be rather browser-dependent: recently it "disappeared" when I changed browsers, but it seems to be working fine for me at the moment.

Cheers, Alan.
 

Andrei IRL

Senior Member
Hi,



One of the good features of the PICaxe forum software is that it has an "Auto Backup" feature and you can (sometimes) recover your work by clicking "Restore Auto Saved Contents" at the foot of the reply window (may need to use the "Go Advanced" Tab.). However, it does appear to be rather browser-dependent: recently it "disappeared" when I changed browsers, but it seems to be working fine for me at the moment.

Cheers, Alan.
Great to know, thanks very much for that Alan.
 

BESQUEUT

Senior Member
That means block structured commands, modularisation, things moved to subroutines even if they don't need to be in subroutines, no GOTO commands, better descriptions of routines and variables and making it clear what the intent is.
The program should not be stalled in a subroutine. The main loop should run as fast as possible.
So PAUSE should be avoided ... (even more if long, and even more if in a loop...)

For example, to flash a LED every 500 ms, the main loop must "know" how many loop to achieve 500ms, (say 77 loop)
Each 77 loops, the main loop can toggle the LED.
But during that time, it can do many others things...
The main loop also need a flag to know if it has to flash the LED, or to switch it OFF.
 
Last edited:

PhilHornby

Senior Member
Personally, I'd take a leaf out of the Automotive Industry's book... (You refuse point blank to let anyone look at your source code and lie through your teeth, about how it works (...VW!)

Being serious: they seem to double-up on important things, like throttle-pedal position sensors - and immediately go into limp mode if there are discrepancies between them.
 
Last edited:

hippy

Technical Support
Staff member
Being serious: they seem to double-up on important things, like throttle-pedal position sensors - and immediately go into limp mode if there are discrepancies between them.
Fail safe, error detection and handling are important issues and that often requires a technique called "defensive programming". For example you don't let a 'time' variable run and act when it reaches 10 with "IF time = 10 THEN", you code it in some way that something sensible is done if 'time' has somehow gone beyond 10 at that point.

In most code "IF time >= 10 THEN" will be good enough but in safety critical systems one will need to think harder about the consequences of such an unexpected situation.

Maybe two buttons cannot be pushed together; but what happens if they are ? Safety critical is more about what happens when things aren't right rather than when they are. It requires a different mindset to usual.
 

BESQUEUT

Senior Member
Fail safe, error detection and handling are important issues and that often requires a technique called "defensive programming". For example you don't let a 'time' variable run and act when it reaches 10 with "IF time = 10 THEN", you code it in some way that something sensible is done if 'time' has somehow gone beyond 10 at that point.

In most code "IF time >= 10 THEN" will be good enough but in safety critical systems one will need to think harder about the consequences of such an unexpected situation.

Maybe two buttons cannot be pushed together; but what happens if they are ? Safety critical is more about what happens when things aren't right rather than when they are. It requires a different mindset to usual.
Ariane5 accident report
In the failure scenario, the primary technical causes are the Operand Error when converting the horizontal bias variable BH, and the lack of protection of this conversion which caused the SRI computer to stop.

b0=255
inc b0
==> b0=0
====> little error : only 2 500 000 000 francs...
 

premelec

Senior Member
Then there are simple errors like I made not long ago - plugged mini USB male into regular size female USB and it shorted out the computer [was one of each size on the ends of a lead and I was in a hurry]. So many ways to ways to fail... ;-0
 
Top