AXE201 voltage bleed

Olly928

New Member
Hi all,

while playing around with my AXE201 module I noticed that if I gave voltage to an input pin, i would then get voltage present at other input pins.

My test circuit is pretty simple, a variable power supply set at 4.5v connected to pin 13 of the module which is input A.0 on the 28X2 chip, with the ground of the power supply connected to the 0V 27 pin of the module.

now if I measure between ground and the other input pins I pick up voltage across many of them, ranging from 1.5v to 3.5V+, I even get 4.5V at the on-board 5V regulated supply, pin 25.

I cant find a circuit diagram of the module itself.

Is this normal?

Is there a way to prevent this?


Cheers in advance

Olly
 

Technoman

Senior Member
Hi Olly,

Can you give more informations on what you intend to do?

As you don't say if pin 28 is connected, I think your measurement depend of the internal circuit of the 28X2 chip. The input is probably protected with diodes, the cathode of one of them connected to Vcc. The supply voltage is then coming from the connected input.
 

hippy

Technical Support
Staff member
Is this normal?
If you don't have a supply voltage connected to VIN ( leg 28) or to +5V ( leg 26 ) then the behaviour you see is likely to be expected.

This is generally called phantom powering where parts of the circuit may power-up as voltage to the input pins passes through the clamping diodes to what is the internal power rail. It is the input pin voltage less the diode drop which appears as an output on the +5V leg.

This might amuse you; the PICAXE-04M ...

http://www.picaxeforum.co.uk/showthread.php?18429-Extreme-Hacksaw-quot-PICAXE-04M-quot


Is there a way to prevent this?
Connect VIN or +5V :)
 

Olly928

New Member
If you don't have a supply voltage connected to VIN ( leg 28) or to +5V ( leg 26 ) then the behaviour you see is likely to be expected.

Connect VIN or +5V :)
Yeah this solved it, :)


Hi Olly,

Can you give more information on what you intend to do?
My complete circuit counts pulses, if the pulses are more than a certain amount in a given time - 0.3s - the system then counts real time while monitoring the pulses. If the pulses drop below a certain amount the system stops counting. There is also an analogue input that should be above a certain level if the pulses are more than the specified amount, so if this is above a certain voltage the system will also count real time. Periodically the system checks the supply voltage if it falls below a threshold level it writes the real time count to the eprom.

There is also a digital input and a serial output, that can be connected to a handheld display and rotary switch, the rotary switch controls the digital input voltage level, to change the screen function between, viewing the current real time count amount, viewing the code version number and counter number and then a test mode which displays the count in real time.

The main problem I'm trying to investigate is that on some occasions the counter seems to miss huge chunks of run time, but others its near enough spot on. and I currently cant find a connection or a reason why the time is missing.

I just noticed this first thing while investigating.
 

AllyCat

Senior Member
Hi,

The main problem I'm trying to investigate is that on some occasions the counter seems to miss huge chunks of run time, but others its near enough spot on. and I currently cant find a connection or a reason why the time is missing.
Some PICaxe commands can take a significant time to execute (such as SEROUT and DEBUG) and some are "Blocking" (e.g. COUNT), i.e. nothing else can happen until the command has completed. So any "counting" part of a program may indeed "miss" input signals if the PICaxe is doing "something else" at the time.

If you post your code we might be able to see what is causing the problem.

Cheers, Alan.
 

Olly928

New Member
Hi,



Some PICaxe commands can take a significant time to execute (such as SEROUT and DEBUG) and some are "Blocking" (e.g. COUNT), i.e. nothing else can happen until the command has completed. So any "counting" part of a program may indeed "miss" input signals if the PICaxe is doing "something else" at the time.

If you post your code we might be able to see what is causing the problem.

Cheers, Alan.
Yeah I understand that the serout and count commands will hold the program until this command is complete and the program accounts for that. hopefully the code sheds some light on what I mean.

It works in simulation on the picaxe editor and so far I've been unable to replicate the problem on a bench test with the actual picaxe. however when put into the actual application, on some occasions time is missing.


Code:
'  Hours Counter Main Code
' Version 1.09
' Before Loading Ensure Engine Number and Clock Number are Correct In Cell_7_9
'

{ ;Symbols
symbol varA = b0 ' cam count
symbol OilP = b1 ' Oil Pressure
symbol RPM = w1 ' RPM Count
symbol varB = b2 ' RPM count
symbol varC = b3 ' RPM count
symbol Secs = b4 ' Secs
symbol Mins = b5 ' Mins
symbol Hrs = b6 ' Hrs
symbol VIn = b7 ' Voltage Level
symbol DIn = b8 ' Digital In Value
symbol varD = b9 ' display Oil P
symbol varE = b10 ' display Oil P
symbol varF = b11 ' display Oil P
symbol varG = b12 ' display RPM
symbol varH = b13 ' display RPM
symbol varI = b14 ' display RPM
symbol varJ = b15 ' display RPM
symbol varK = b16 ' display RPM
symbol varL = b17 ' display Secs
symbol varM = b18 ' display Secs
symbol varN = b19 ' display Secs
symbol varO = b20 ' display Mins
symbol varP = b21 ' display Mins
symbol varQ = b22 ' display Mins
symbol varR = b23 ' display Hrs
symbol varS = b24 ' display Hrs
symbol varT = b25 ' display Hrs
symbol Msecs = b26 ' Msecs
symbol OilPBar = w14 ' Oil Pressure Bar Calc
symbol OilPBar1 = b28 ' Oil Pressure Bar Calc
symbol OilPBar2 = b29 ' Oil Pressure Bar Calc
symbol VarU = b30 ' display Oil P
symbol VarV = b31 ' display Oil p
symbol SecsC = b32 ' Secs Check
symbol MinsC = b33 ' Mins Check
symbol HrsC = b34 ' Hrs Check
symbol varTEMPWORD1 = w25 ' cam count
symbol varTEMPBYTE1 = b50 ' cam count
symbol varTEMPBYTE2 = b51 ' cam count
symbol varTEMPWORD2 = w26
symbol varTEMPBYTE3 = b52
symbol varTEMPBYTE4 = b53
symbol varTEMPWORD3 = w27
symbol varTEMPBYTE5 = b54
symbol varTEMPBYTE6 = b55
}


main:


	let dirsA = 16
	let dirsB = 255
	let dirsC = 0
	
wait 1

Cell_7_2:
Readadc A.2, VIn ' check voltage
	If VIn > 120 then
		goto Cell_7_3
	Else
		goto Cell_7_2
	Endif

Cell_7_3:
READ 0, Secs
READ 8, Mins
READ 16, Hrs ' read from memory


Cell_7_4:
Readadc C.6, DIn ' Digital In
	If DIn < 60 then
		goto Cell_7_5 ' counts
	Else
		If DIn >= 60 And DIn < 80 then
			pause 1000
			goto Cell_7_7 ' Digital In Position 1
		Else	
			If DIn >= 80 And DIn < 155 then
				pause 1000
				goto Cell_7_8 ' Digital In Position 2 
			Else
				If DIn >= 155 And DIn < 200 then
					pause 1000
					goto Cell_7_9 ' Digital In Position 3
				Else
					If DIn >= 200 And DIn <= 255 then
						pause 1000
						goto Cell_7_10 ' Digital In Position 4
					Else
					Endif
				Endif
			Endif
		Endif
	Endif

Cell_7_5:
Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
		goto Cell_7_6	
	Endif	

Cell_7_6: ' counts
count C.0, 600 , varTEMPWORD1 ' cam count
	let varA = varTEMPWORD1 max 255
	let RPM = varA * 10 * 2 * 60 / 3 ' RPM calc
Readadc A.0, OilP ' Oil Pressure
Readadc C.6, DIn ' Digital In
	If Din >= 60 then
		goto Cell_7_4
	Else
	Endif
Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	
 ' count conditions
If RPM >= 2000 OR OilP > 70 then
	let Msecs = Msecs + 1
		If Msecs = 2 then
			let Msecs = 0
			Secs = Secs + 1
				If Secs = 60 then
					let Secs = 0
					Mins = Mins + 1
						If Mins = 60 then
							let Mins = 0
							Hrs = Hrs + 1
							Else 
						Endif
					Else
				Endif
			Else
		Endif	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
      Else
	Endif
	pauseus 5000     ' 5000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 5000     ' 10000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 5000     ' 15000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 3630    ' 18630
	
	Else
	READ 0, SecsC
	READ 8, MinsC
	READ 16, HrsC ' read from memory to check
	If SecsC = Secs then
		If MinsC = Mins then
			If HrsC = Hrs then
				goto Cell_7_6
				Else goto Cell_7_11
			End IF
			Else goto Cell_7_11
		End IF
		Else goto Cell_7_11
	End IF
	goto Cell_7_5
EndIf	
goto Cell_7_5
	
Cell_7_7: ' Digital In Postion 1
do {
	Readadc C.6, DIn ' Digital In
	wait 1
loop while DIn >= 60 And DIn < 80
pause 30
goto Cell_7_4

Cell_7_8: ' Digital In Position 2
serout A.4, N2400, (254, 1)
serout A.4, N2400, (254, 128, "       Counter       ") 
serout A.4, N2400, (254, 192, "         EHC         ")
pause 2000
serout A.4, N2400, (254, 192, "    Hrs:Mins:Secs   ")
do {
	bintoascii Secs, VarL, varM, varN 
	bintoascii Mins, varO, varP, varQ 
	bintoascii Hrs, varR, varS, varT
	serout A.4, N2400, (254, 148, "      ", varR, varS, varT, ":",varP, varQ, ":",varM, varN,"      ")
	Readadc C.6, DIn ' Digital In
loop while DIn >= 80 And DIn < 155
serout A.4, N2400, (254,1)
pause 30 
goto Cell_7_4

Cell_7_9: ' Digital In Position 3
serout A.4, N2400, (254, 1)
serout A.4, N2400, (254, 128, "       Counter       ") 
serout A.4, N2400, (254, 192, "  EHC Serial Check   ")
pause 2000
serout A.4, N2400, (254, 192, " EHC Serial Numbers  ") 
serout A.4, N2400, (254, 148, "                     ")
serout A.4, N2400, (254, 212, "   EHC-031 V1.09     ")
do {
	Readadc C.6, DIn ' Digital In
loop while DIn >= 155 And DIn < 200
serout A.4, N2400, (254,1)
pause 30 
goto Cell_7_4 

Cell_7_10: ' Digital In Position 4
serout A.4, N2400, (254, 1)
serout A.4, N2400, (254, 128, "       Counter       ") 
serout A.4, N2400, (254, 192, "    EHC Test Mode    ")
pause 2000
	serout A.4, N2400, (254, 1)
	serout A.4, N2400, (254, 128, "   Hrs:Mins:Secs    ") 
	serout A.4, N2400, (254, 148, "    RPM   Oil P     ")
	bintoascii Secs, varL, varM, varN 
	bintoascii Mins, varO, varP, varQ 
	bintoascii Hrs, varR, varS, varT 
	bintoascii RPM, varG, varH, varI, varJ, varK
	bintoascii OilPBar, varD, varE, varF, b30, b31
	serout A.4, N2400, (254, 192, "    ", varR, varS, varT, ": ", varP, varQ, " :", varM, varN,"       ") 
	serout A.4, N2400, (254, 212, "   ", varG, varH, varI, varJ, varK, "  ", varF, ".", b30, b31, "   ")
do {
Cell_7_10_1:
Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
		goto Cell_7_10_2	
	Endif	
Cell_7_10_2: ' counts
count C.0, 400 , varTEMPWORD1 ' cam count
	let varA = varTEMPWORD1 max 255
	let RPM = varA * 5 * 2 * 60 ' RPM calc
Readadc A.0, OilP ' Oil Pressure
	
 ' count conditions
If RPM >= 1800 OR OilP > 70 then
	let Msecs = Msecs + 1
		If Msecs = 2 then
			let Msecs = 0
			Secs = Secs + 1
				If Secs = 60 then
					let Secs = 0
					Mins = Mins + 1
						If Mins = 60 then
							let Mins = 0
							Hrs = Hrs + 1
							Else 
						Endif
					Else
				Endif
			Else
		Endif	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 2978
	
	Else
	goto Cell_7_10_3
EndIf	
goto Cell_7_10_3

Cell_7_10_3:
	let W14 = OilP * 545 - 28259 / 100 ' Oil P calc
	bintoascii Secs, varL, varM, varN 
	bintoascii Mins, varO, varP, varQ 
	bintoascii Hrs, varR, varS, varT 
	bintoascii RPM, varG, varH, varI, varJ, varK
	bintoascii OilPBar, varD, varE, varF, b30, b31
	serout A.4, N2400, (254, 192, "    ", varR, varS, varT, ": ", varP, varQ, " :", varM, varN,"       ") 
	serout A.4, N2400, (254, 212, "   ", varG, varH, varI, varJ, varK, "  ", varF, ".", b30, b31, "   ")
	Readadc C.6, DIn ' Digital In
loop while DIn >= 200 And DIn <= 255
serout A.4, N2400, (254,1)
pause 30 
goto Cell_7_11

Cell_7_11: ' write to memory
WRITE 0, Secs
WRITE 8, Mins
WRITE 16, Hrs
goto Cell_7_2


#no_data	'reduce download time
 

hippy

Technical Support
Staff member
hopefully the code sheds some light on what I mean.
Code generated from a flowchart can be a little difficult to figure out and follow so it may be worth posting your flowchart .PLF file.

It is is not exactly clear what data is being lost or under what circumstances. If it is data which should have been written to EEPROM on low voltage it could be that the voltage has gone too low before it can be successfully written, or the code is held up in some other loop where it is not checking for that low voltage.

I haven't studied the code in detail but it looks to me that your code is repeatedly writing to EEPROM. If that is so it is possible that EEPROM can become worn out. The flowchart would make it clearer exactly what the program flow is.
 

hippy

Technical Support
Staff member
hopefully the code sheds some light on what I mean.
Code generated from a flowchart can be a little difficult to figure out and follow so it may be worth posting your flowchart .PLF file.

It is is not exactly clear what data is being lost or under what circumstances. If it is data which should have been written to EEPROM on low voltage it could be that the voltage has gone too low before it can be successfully written, or the code is held up in some other loop where it is not checking for that low voltage.

I haven't studied the code in detail but it looks to me that your code is repeatedly writing to EEPROM. If that is so it is possible that EEPROM can become worn out. The flowchart would make it clearer exactly what the program flow is.
 

Olly928

New Member
Code generated from a flowchart can be a little difficult to figure out and follow so it may be worth posting your flowchart .PLF file.

It is is not exactly clear what data is being lost or under what circumstances. If it is data which should have been written to EEPROM on low voltage it could be that the voltage has gone too low before it can be successfully written, or the code is held up in some other loop where it is not checking for that low voltage.

I haven't studied the code in detail but it looks to me that your code is repeatedly writing to EEPROM. If that is so it is possible that EEPROM can become worn out. The flowchart would make it clearer exactly what the program flow is.
It's not generated from a flow chart, the original might have been opened in a flow chart but it was soon just switched to basic, and the only thing that remains is the cell naming convention which I just kept as it was there.

The data that is being lost is the Time in Hrs Mins and Secs that the engine has been running for, so an engine might have a total run time of 1hr:29mins:30s but the clock shows 20mins:40s the run time would have been made up of say 3 specific engine runs. but on the other hand there are some that come back that are showing a time that is within the desired tolerance to actual run time. There is/should be no difference in the way the engine is run and only the time should vary.

there is a large capacitor to help increase the time from power loss to the picaxe becoming unresponsive, and also the voltage check appears frequently to help this situation. The eprom should only be written to in the case of a power loss, o

I should also add that the highlighted bit in this section of code is new to help deal with this problem.

Code:
Cell_7_6: ' counts
count C.0, 600 , varTEMPWORD1 ' cam count
	let varA = varTEMPWORD1 max 255
	let RPM = varA * 10 * 2 * 60 / 3 ' RPM calc
Readadc A.0, OilP ' Oil Pressure
Readadc C.6, DIn ' Digital In
	If Din >= 60 then
		goto Cell_7_4
	Else
	Endif
Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	
 ' count conditions
If RPM >= 2000 OR OilP > 70 then
	let Msecs = Msecs + 1
		If Msecs = 2 then
			let Msecs = 0
			Secs = Secs + 1
				If Secs = 60 then
					let Secs = 0
					Mins = Mins + 1
						If Mins = 60 then
							let Mins = 0
							Hrs = Hrs + 1
							Else 
						Endif
					Else
				Endif
			Else
		Endif	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
      Else
	Endif
	pauseus 5000     ' 5000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 5000     ' 10000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 5000     ' 15000
	
	Readadc A.2, VIn ' check voltage
	If VIn < 120 then
		goto Cell_7_11
	Else
	Endif
	pauseus 3630    ' 18630
	
	Else
	[B][I]READ 0, SecsC
	READ 8, MinsC
	READ 16, HrsC ' read from memory to check
	If SecsC = Secs then
		If MinsC = Mins then
			If HrsC = Hrs then
				goto Cell_7_6
				Else goto Cell_7_11
			End IF
			Else goto Cell_7_11
		End IF
		Else goto Cell_7_11
	End IF[/I][/B]
	goto Cell_7_5
EndIf	
goto Cell_7_5
The EEPROM should only be written to in the case of a power loss, or now with this added bit of code if the engine stops but there is still power to the system and the EEPROM saved time and current time are different, it then saves. This is to make sure that it is not saving to the EEPROM on every cycle, but that it records any change in engine run time.
 

hippy

Technical Support
Staff member
It might help to rewrite and restructure the code so it is clearer how its flow is, or reduce it to the bare minimum which illustrates the problem.

Otherwise it is rather hard to figure out what may be going wrong or why.

If the run time is shown correctly before the unit is switched off, but isn't when it is turned back on, you might be able to figure out why that is by which program paths it would have been gone through when that happens.
 

Olly928

New Member
It might help to rewrite and restructure the code so it is clearer how its flow is, or reduce it to the bare minimum which illustrates the problem.

Otherwise it is rather hard to figure out what may be going wrong or why.

If the run time is shown correctly before the unit is switched off, but isn't when it is turned back on, you might be able to figure out why that is by which program paths it would have been gone through when that happens.

When you say rewrite or restructure the code to make the flow clearer, I don't understand what you mean? the code flows down from top to bottom doesn't it? unless its told to redirect by a section of code of course.
Also I'm not sure in which bit of the code the problem is in hence why I put it all there.

I am looking into whether the run time is correct before the unit is switched off, it should go through a program path that saves the data but i will have to dig further.
 

hippy

Technical Support
Staff member
When you say rewrite or restructure the code to make the flow clearer, I don't understand what you mean? the code flows down from top to bottom doesn't it? unless its told to redirect by a section of code of course..
It perhaps is mostly in code like the following where it can become most difficult ...

Code:
If condition Then
  Goto Cell_X_Y_Z
Else
  Goto Cell_A_B_C
End If
Any 'Sphagetti code', where flow jumps from one place to another, is difficult to get to grips with. It is not so much that it's wrong, it's just that can be much harder for others to comprehend.

Things may be easy for you to follow having written the code, knowing what it's meant to be doing at each point, what "Cell_X_Y_Z" and what "Cell_A_B_C" do, but it gets rather confusing quite quickly when not familiar with the code, trying to reverse engineer the full program's intent.

It is quite difficult to explain, but the examples below illustrates the problem. How long does it take to figure out what this code does ... ?

Code:
Cell_3_1_1:
  b0 = 0

Cell_3_1_2:
  b0 = b0 + 1

Cell_3_1_3:
  If b0 <= 9 Then
    Goto Cell_3_2_1
  Else
    Goto Cell_3_1_1
  End If

Cell_3_2_1:
  SerTxd( #b0 )
  Goto Cell_3_1_2
No matter how long it actually takes, it is almost certain that it would have been understood more quickly if written in a different way, with fewer GOTO statements.
 

Olly928

New Member
It perhaps is mostly in code like the following where it can become most difficult ...

No matter how long it actually takes, it is almost certain that it would have been understood more quickly if written in a different way, with fewer GOTO statements.
Ah okay I understand what you mean now.

However I am unsure how I would go about changing this and removing the goto's....

sorry I feel like I'm being really dismissive and blunt, but I don't have a massive amount of code experience and everything I learnt, I learnt building this, so any pointers or suggestions would be greatly appreciated.
 

AllyCat

Senior Member
Hi,

Some of those labels (such as "Cell_3_1_3:") seem to be included only to show "where the code came from", so they can be simply deleted. But before you delete (any row) it can be worth first "commenting out" the line with a ; or a ' character at the beginning of the row. Then do a syntax check with the Program Editor and if there are no errors reported then the commented lines can be deleted (or cut out).

Where a label is necessary, then change it to something "meaningful", for example "print_b0:" instead of "Cell_3_2_1:" in hippy's example above. Sometimes a GOTO can be changed to a GOSUB (but you do need to appreciate the difference), which may keep the "GOTO Haters" happy. :)

Generally, try to put simple and/or obvious instructions "in-line" (i.e. in the main part of the program) and "hide" the messy bits inside a subroutine (later in the program listing), again with a meaningful name. I'm not a believer in removing every GOTO, but do try to see if rearranging the program (using cut-and-paste) can reduce their number. Note that there are several different structures for the IF .. THEN .. ELSE commands (which can be quite confusing for a beginner) but an ELSE or an ENDIF can often help to remove a GOTO <label> .

Cheers, Alan.
 

hippy

Technical Support
Staff member
sorry I feel like I'm being really dismissive and blunt, but I don't have a massive amount of code experience and everything I learnt, I learnt building this, so any pointers or suggestions would be greatly appreciated.
Really don't worry about it. Writing good looking code which is easier to understand is something one has to grow into doing. It might be reassuring to know everyone here has gone through that, or is going through it. It's not something which can be taught as such but there are a few good rules to adopt -

Modularisation - Try to divide up code so it's more self contained where it is rather than being a monolithic chunk. Get used to using GOSUB to put code into subroutines which can be called by other parts of the code.

Naming - Use meaningful but not overly long names for variables and subroutines.

Abstraction - Try and hide complexity. In the example below the mode selections are named and the low voltage condition is added as an additional mode to the switch mode selected. The (slightly) complicated handling of that is in the 'ReadModeSwitch', but the rest of the program can then just use the 'mode' variable, no need to worry how things have to be to be in the mode it is.

I would suggest putting what you have to one side, use that to build upon, a bit like an essay rewrite having attended your first 'how to write good' class :)

I would start with something like the template below. You should be able to modify that to add in what you have already developed so nothing will have gone to waste.

Don't worry if it all looks a bit daunting at first. If you do have any questions then please do ask.

Code:
#Picaxe 28X2

; *************
; * Variables *
; *************

Symbol temp = b0

Symbol mode = b1

Symbol secs = b2
Symbol mins = b3
Symbol hour = b4

; *******************
; * Operating modes *
; *******************

Symbol MODE_LOW_VOLTAGE = 0
Symbol MODE_MONITOR     = 1
Symbol MODE_THIS        = 2
Symbol MODE_THAT        = 3
Symbol MODE_THE_OTHER   = 4

; *********************
; * Main Program loop *
; *********************

MainLoop:
  Do
    Gosub ReadModeSwitch
    Select Case mode
      Case MODE_LOW_VOLTAGE : Gosub LowVoltage
      Case MODE_MONITOR     : Gosub Monitor
      Case MODE_THIS        : Gosub This
      Case MODE_THAT        : Gosub That
      Case MODE_THE_OTHER   : Gosub TheOther
    End Select
  Loop

; ********************************************
; * Low voltage - Wait until not low voltage *
; ********************************************

LowVoltage:
  Do
    Gosub ReadModeSwitch
  Loop While mode = MODE_LOW_VOLTAGE
  Return

; **************************
; * Engine monitoring mode *
; **************************

Monitor:
  Gosub ReadTimeFromMemory
  Do
    ; More code here
    Gosub ReadModeSwitch
  Loop While mode = MODE_MONITOR
  Gosub WriteTimeToMemory
  Return

; *************
; * This Mode *
; *************

This:
  Do
    ; More code here
    Gosub ReadModeSwitch
  Loop While mode = MODE_THIS
  Return

; *************
; * That Mode *
; *************

That:
  Do
    ; More code here
    Gosub ReadModeSwitch
  Loop While mode = MODE_THAT
  Return

; ******************
; * The Other Mode *
; ******************

TheOther:
  Do
    ; More code here
    Gosub ReadModeSwitch
  Loop While mode = MODE_THE_OTHER
  Return

; ***************************************************
; * Read voltage and mode switch and determine mode *
; ***************************************************

ReadModeSwitch:
  ReadAdc A.2, temp   ; Read supply voltage
  If temp < 120 Then
    mode = MODE_LOW_VOLTAGE
  Else
    ReadAdc C.6, temp ; Read switch position
    Select Case temp
      Case <  60 : mode = MODE_MONITOR   ;   0 to. 59
      Case <  80 : mode = MODE_THIS      ;  60 to  79
      Case < 155 : mode = MODE_THAT      ;  80 to 155
      Else       : mode = MODE_THE_OTHER ; 155 to 255
    End Select
  End If
  Return

; ***********************
; * Handle Time storage *
; ***********************

ReadTimeFromMemory:
  Read 0, secs
  Read 1, mins
  Read 2, hour
  Return

WriteTimeToMemory:
  Read 0, temp : If temp <> secs Then : Write 0, secs : End If
  Read 1, temp : If temp <> mins Then : Write 1, mins : End If
  Read 2, temp : If temp <> hour Then : Write 2, hour : End If
  Return

; ******************
; * End of Program *
; ******************
I am expecting you should be able to wedge your existing engine monitoring code into the DO-LOOP of the 'Monitor' routine, and that will either cause the problem you were having to simply go away, or will allow people to better analyse what the issue might be.

Probably a good place to start in deciding what the names of the modes are, replacing my 'this', 'that' and 'the other' with what your bit of kit actually does, "Live RPM Monitoring" or whatever.
 
Top