14M program seems to stop overnight

A

airton65

Member
Hi,
I have a problem which has beaten me, Yesterday I rebuilt the circuit with a brand new 14M and still I have THE problem.
The attached program works fine when I am around during the day, no problems, however when I get up in the morning i don't get any response when I go to start the generator. I then turn the power to the autostart off and back on and it runs properly again.
Any suggestions would be welcome
Thanks
Tony
 

Attachments

M

MPep

Senior Member
Hi Tony,

Maybe it senses night-time, and wants to sleep! :D

I suspect your problem is having GOSUBs but not always returning from them.
Try re-writing your code using GOTO only. Should be able to be done. Your problems will disappear.

MPep.
 
M

MPep

Senior Member
Try this, or something like it
Code: 
#picaxe 14M    
    
symbol Startsw = pin2        ;Start switch
symbol Sense = pin0        ;Senses 12V output from generator
symbol OilPress = pin3        ;oil pressure sensor, low when off and high when running
symbol FuelLevel = pin4        ;low fuel sensor, low when empty

symbol InLed = 1            ;output indicator led 
symbol Volts = 2            ;output switches contactor
symbol Fuel = 4            ;output turns on fuel soleniod
symbol Starter = 5        ;output turns on Starter

symbol Counter = b1        ;Loop Counter register



Main:    
    if Startsw = 0 and OilPress = 0 and Sense = 0 then goto Start
    if sense = 1 then goto RunCheck
goto Main
        
Start:
    for Counter = 0 to 30
        high InLed
        pause 50
        low InLed
        pause 50
    next Counter
    
    low Volts,Fuel,Starter

    for Counter = 0 to 2
        if Sense = 1 then Main
        if Startsw = 1 then Main
        high fuel
        pause 1000
        high Starter
        pause 1000
        low Starter
        pause 5000
        high Volts
        if Sense = 1 then Main
        low Volts, fuel,Starter
        pause 5000
        if Sense = 1 then Main
    next Counter
    low Volts,Fuel,Starter
goto Alarm

RunCheck:
    if FuelLevel = 0 then goto Diesel
    if OilPress = 0 then goto Alarm
    if Startsw = 1 then goto Shutdown
goto Main

Shutdown:
      low Volts,Fuel,Starter
    for Counter = 0 to 9
        high InLed
        pause 500
        low InLed
        pause 500
    next Counter
goto main
    
Alarm:
    low Volts,Fuel,Starter
    for Counter = 0 to 30
        high InLed
        pause 200
        low InLed
        pause 200
    next Counter
goto Alarm
        
Diesel:
    high InLed
    pause 500
    low InLed
goto Main
 
M

MartinM57

Moderator
Definitely at least one possible path that will cause a problem if the input variables have certain values...

main -> gosub runcheck -> goto shutdown -> goto main -> ...and go round this loop for ever until the gosubs overflow

I would NOT try to rewrite it with only GOTOs - I would try to rewrite it with GOSUBs only, which is a much better practice. GOTOs only results in spaghetti-code - code that goes everywhere and is eventually impossible to follow
 
A

airton65

Member
Thanks for that MPep,
I have programed that in and will see if the genset is sleepy tomorrow, It's been below zero in the mornings here so I know how the genset feels. I added a couple of lines to pulse a led on output 0 every time it goes through the "main" loop.
 
D

Dippy

Moderator
Good advice.

I know it's old-fashioned and slightly quaint, but a large sheet of paper, a pencil (+eraser) and a ruler is useful.
It's much easier to see decision routes graphically with boxes and true/false/yes/no arrows and lines. Try it.
 
A

airton65

Member
Thanks for the replies Dippy and MartinM57,

I just wrote this out and then it disappeared when I attempted a spell check.

I thought that in my original program I had only included the GOTO's where I had to but now I understand what's going on. I will try a rewrite but I want the Alarm routine to just loop until someone physically goes over the gen set to see what is wrong and manually reset the autostart.
I can see my problem with the overflow though.

I actually did draw this out first and I thought it was pretty good but there you go.

Thanks for all the replies
Tony
 
M

MartinM57

Moderator
Of course it might not be a software problem at all - generators, electrical noise, poor circuit design, less than ideal construction etc, with one or more of them causing the software to go AWOL. Any chance of that Tony?

As I said there are possible paths that blow the GOSUB stack, but I didn't look closely at the data values to see if the real world values of the variables could make the software go down that path...
 
premelec

premelec

Senior Member
Night dependent?

I wonder if your fault is occuring after a specific time or at time of day - if TOD likely some sort of temperature dependent item or something that happens at a TOD like unit turns on at 10 PM etc... - if after a certain length of operation time then liikely GOSUB etc dependent... Good luck with it!
 
A

airton65

Member
Hi all,

Premelec I don't think it was a time of day or heat related issue as all it took was a reset to fix the problem....
Like I said yesterday I programed with MPeps code and it was still running this morning so I am sure it was the subroutine overflow problem like everybody said. I have now rewritten the code using only go subs and it running nicely. If it stops again I will repost the program,

Thanks
Tony
 
M

MPep

Senior Member
Hi Tony,

Am pleased that you now have it working. Good idea of the LED blinking away to let you know if the system is still operational.
GOSUBs and GOTOs can be used successfully together. I most certainly have.

The main thing to remember is that if you use a GOSUB, then you MUST use a RETURN. Don't use a GOTO inside a sub-routine, well ... not unless you are absolutely sure that you somehow come back to 'clear' the GOSUB with a RETURN.

Please do post your revised code, after testing that it indeed works as expected. This is how new-comers learn, by re-reading existing problems, and the subsequent 'fix'.

@Dippy,

Old fashioned and quaint your idea of drawing out the requirement may be, but if it works, why not use it!;)

@Martin57,

Either way, use all GOTOs or GOSUBs. Slightly less to go wrong using GOTOs only, IMHO, which is why I suggested it. I appreciate the avoidance of 'spaghetti' code creation!

Regards,
MPep.
 
techElder

techElder

Well-known member
Well, GOTOs are useful in subroutines as long as their references are WHOLLY CONTAINED within the subroutine. (Between the LABLE and the RETURN.)
 
I

InvaderZim

Senior Member
There are a lot of ways to skin a cat, but most of my programs have all the subroutines with names like "subCountTheThings" and such. That keeps me focused on what parts of code need to "return" and which ones don't. So I would never write "gosub CountTheThings" or "goto subCountTheThings" because that's obviously asking for trouble.
 
A

airton65

Member
Hi all

I didn't realize you could write a command 'say' subDiesel, it would make it easier to follow,,The new code with only subroutines has been running all day and is still going well. I have attached the program to see what you guys think.

Thanks
Tony
 

Attachments

M

MartinM57

Moderator
Hi Tony

A few suggestions for the code:
- no comments - it compiles, it runs for a day, but I still can't really work out what it does - will you, when you come back to it an a year or so?
- use indentation for the statements within the loop - makes it much easier to read
- you don't need the lines "let bx = 0" immediately before "for bx = someval to ..." (x = 1 or 2 in your code)
- "inled" really confuses me! I guess it mean "in(dicator) LED" not "in(put) LED"?
- pin 0 is presumably a status LED - worth using a symbol for that as well to help the reader

The main question is...does it actually work? Ok so it's been running all day (presumably the status LED has been flashing all day), but have you tested it with all the possible input combinations (initially I would do it on the simulator, but I would also do it on the real gen set) - or are you just hoping?

It's surprising how many different combinations exist for your 4 inputs (well, there's 16 actually). Have you drawn up a table of all 16 combinations and considered a) whether each can actually exist b) what the code should do if they occur c) what the code does do if they occur and (maybe a tricky one) d) what happens if one state transitions to another while your in one of your delaying loops while inLED flashes - would it be important to detect that transition straight away?

I don't understand gen sets particularly and despite no GOTOs (hurrah!), I still can't really follow the code with a picture in my mind of how of the IF... statements relate to the real world of controlling the contactor, the fuel switch and the starter motor

In fact, back to basics, it's not clear what the program is trying to do at the highest level - just co-ordinate the starting activities from a single switch/restart it automatically if it stops/something else?

(I've read the above and it seems a bit negative - it's not meant to be. Congrats on getting this far :))
 
D

Dippy

Moderator
Yes, well done for improving things. I hope it works out.

Program(me) writing can be quite a 'personal' thing but I generally agree with Martin from a reader's pov.
Indenting and standardising makes it easier for others to read.
Comment every line (ish) - you WILL forget what's going on in a few days/weeks :)
And, when you want others to analyse your code then it really really helps.

I prefer IF / ENDIFs on separate lines as that is the standard way and sometimes you have been a little non-ideal.
Eg:-
if sense = 1 then return endif
if startsw = 1 then return endif
... that could be neatified.

And, as mentioned, we are assuming a) your wiring is good and b) that your sensors are 100% and c) the PSU is nice. Only you know that as you will have tested it fully ;)
 
A

airton65

Member
The ????? thing stopped again last night

Hi,

Thanks MartinM57 and Dippy for the comments, I will take them on board and do a rewrite and post it to see what you think. I did try to go through all the possibilities in the simulator before I programmed. This generator lives on a small bush block we have up in the mountains and at this time of year it gets pretty cold. Also the diesel generator is a bit noisy so I built a concrete enclosure about 30M away from our hut. My plan is to be able to hop up in the morning and be able to start the generator without freezing to death.

The idea is for the auto start to stay in the MAIN loop until the start switch is grounded (pin 2), If the start switch is grounded then the program is supposed to check for no oil pressure (pin 3), and no voltage from the generator (pin 0). If all these requirements are met then we can presume that the generator is really shutdown, and the program moves into the start routine, I flash a led (and will sound a buzzer) to alert for a start and then tries for start after once more confirming that the generator is really shutdown. Firstly I turn on the fuel solenoid (fuel), then I turn on the starter for 1 second (starter), then I pause for 5 seconds for it to cough and splutter and settle down, Next I turn on the contactor, after which I check for voltage from the generator through the sense (pin 0), if the program decides that there is no voltage from the generator it turns off the contactor the fuel, and just to be safe, the starter. It then pauses for another 5 seconds for the generator to stop in case it was running, checks for voltage once again and if there is no voltage tries for a start two more times..... If it fails to start on the third occasion it goes into the alarm routine until I go over and see why not and reset the program. Presuming a start the program then moves between the "MAIN" procedure and the "RUNCHECK" If the "fuellevel" pin goes to ground the idea is that the INLED flashes inside the hut so I know to put some fuel in the generator, If the "oilpress" pin goes to ground then I want an alarm shutdown and the INLED flashes at a different frequency inside the hut. If the "startsw" goes high I want a shutdown and for the program to back to the MAIN loop

However the program stopped last night after running all day yesterday and last night till I checked it at about 4.00am, so now I am back to thinking it's a heat related issue which is where I started with this problem a week ago, At 4.00 am I reset the circuit and it's still going.
I just went outside now and tested the battery ant it's at 12.9V then I disconnected the oil pressure switch and it went into shutdown mode as it does when I do a simulation.

Now when I think about it when I had MPep's program running I had the circuit sitting on the office bench beside me in the warm house not outside below freezing.

The frustrating thing is that I originally presumed I had a dry joint so I checked my soldering, then I presumed I had a heat sensitive component, so I replaced what I could, then I thought maybe a faulty picaxe, so I ordered a couple more and rebuilt the circuit completely on a fresh Kiwi Patch Board.

Tonight I might just program in a simple flashing led routine and see what happens,

Lucky I like a challenge
Regards and thanks
Tony
 
I

InvaderZim

Senior Member
Also, I didn't catch what your hardware looks like, but beware of glitchy inputs. I note that a tiny glitch on the start line will trigger a motor start. This may not seem likely, but if glitches are happening often, or if you take out all the "blink a light" code, then it becomes quite likely that a bit of noise will start your motor when you don't expect it to. Look up "switch debouncing" which can be done in hardware and software for great results.
 
A

airton65

Member
Hi InvaderZim,

Yes I probably better put a debounce on the inputs, at the moment I have an opto-isolator on the sense input, but I am still thinking it must be a temp problem because once again it has been cycling through the MAIN routine since 4.00AM without a hitch.

Thanks
Tony
 
M

MartinM57

Moderator
So what value temperatures are you talking about? - you give no clue

Unless you're talking extremes (<-10C or >50C - and even they're not that extreme) I would doubt temperature is a problem.

When you say it "stops working" what do you mean?

I'm starting to think it's maybe not a software issue..if you're happy with the functionality and the logic and it "stops working" then I'm thinking hardware design (of which we know almost nothing) or construction (of which we know absolutely nothing)
 
M

MartinM57

Moderator
...and is anything special happening to the gen set when it "stops working" or is it, as far as you know, just running normally and there are no changes to the inputs to the software? (in which case debouncing shouldn't be the problem that causes it to stop working)
 
A

airton65

Member
Hi MartinM57,

This morning I got my axe092 starter kit and put it in the freezer with a simple flashing led routine and I just took it out and it is still working.
The temputure over here in the mornings is probably 1C or 2C below going on the fact there is a bit of frost around, so I don't think it is a issue for the picaxe, however the circuit is suprising simple. The imputs are tied high by a 10K resistor except for the sense pin which is held low by a 10K resistor. I have a opto coupler on the sense pin to avoid direct connection to the generator charge supply. The other input are pulled to ground by the associted switches (oil, Fuel and Start switches).... The output I just feed into a relay bank I buy off Electronics-Salon on ebay... If you haven't seen these, they are well built modules and cheaper than buying the relays alone. the relay that controls the contactor I have a RC network on.

The autostart now does exactly what it is supposed to do, eg shutdown if I short the oil sender wire to ground, flash the inled if I short the fuel level sender to ground, stop if I unground the start switch.

The thing that is making me think it is heat related is that the program (as far as I know) should be just cycling around the Main loop..I am not interfering with it at all and if I replicate a faulty sender the program doesn't stop but goes to the appriate sub routine

I've been playing around with electronics, purely as a hobyist, for over 20 years and I not saying I've got much upstairs, but I'm pretty sure my soldering is OK and that the electronic design isn't the issue here. I could draw it up in VSM and upload it if you like. I posted a picture to show how simple it is , I haven't tidied it up yet because I want to soak test it ha ha, I'll soak it allright.

So now I am back to wondering could the 14M be stopping in the cold, or could I have a dodgy switch or regulator even though they have both been renewed, not the switch. I will test them tomorrow morning, I might get a can of freeze spray from the plumbing supplies.

My wife suggests that I lay some railway tracks down to the generator enclosure and put the generator on a little carrige with a rope attached and in the morning pull the generator up to the hut, start it and lower it back... Might just have to do that yet.

Thanks everone for your time on this

Tony
 

Attachments

D

Dippy

Moderator
I reckon it's about time you simplified all this and started with easy tests and build up.

You say that you tried the axe092 starter kit in the freezer and it was OK.
Why don't you try a similar simple test with your 14M?

Have you tested the behaviour of the other components in the cold?
You questioned the switch and regulators - that's easy to test. Just give them a thermal thrashing.

Are your ebay relays OK in the cold?
Is there a cold AND condensation problem?
It would probably be a good idea to break all this down and see what is happening.

Can you include some lines into your code to indicate which routine it's in , maybe some LEDs or a serial connection a to a PC to keep an eye on what it's up to?
 
S

Svejk

Senior Member
I've rewriten your code as below, still I'm not sure it does what it should. Please check the comments.

A through check of hardware [it is mouted on a steel plate?, condensation could be a problem] would be good.


Code: 
#picaxe 14M

symbol startsw = pin2		[COLOR="DarkGreen"];Start switch[/COLOR]
symbol sense = pin0		[COLOR="DarkGreen"];Senses 12V output from generator[/COLOR]
symbol oilpress = pin3		[COLOR="darkgreen"];oil pressure sensor, low when off and high when running[/COLOR]
symbol fuellevel = pin4		[COLOR="darkgreen"];low fuel sensor, low when empty[/COLOR]
symbol inled = 1			[COLOR="darkgreen"];output indicator led [/COLOR]
symbol volts = 2			[COLOR="darkgreen"];output switches contactor[/COLOR]
symbol fuel = 4			[COLOR="darkgreen"];output turns on fuel soleniod[/COLOR]
symbol starter = 5			[COLOR="darkgreen"];output turns on starter[/COLOR]

symbol StopedFlag = bit0		[COLOR="darkgreen"]'boolean flag: true if stop; false if runing[/COLOR]
symbol AlarmFlag  = bit1		[COLOR="darkgreen"]'boolean flag: true if any alarm condition is true[/COLOR]

symbol True  = 1
symbol False = 0


OnPowerUp:
	pause 1000
	AlarmFlag = False		[COLOR="darkgreen"]'optimistic approach: asumes nothing wrong[/COLOR]
	gosub fCheckIfRuning	[COLOR="darkgreen"]'test if generator is runing, returns StopedFlag[/COLOR]
	

Main:	
	if startsw = 0 then 			[COLOR="darkgreen"]'start switch pressed[/COLOR]
		gosub fCheckIfRuning		[COLOR="darkgreen"]'returns StopedFlag[/COLOR]
		if StopedFlag = True then 		[COLOR="darkgreen"]'if generator not runing attempts to start it[/COLOR]
			gosub Star  [COLOR="darkgreen"]'unsuccesfull start returns true AlarmFlag[/COLOR]
		endif
	endif
					[COLOR="darkgreen"]'if generator is runing then check oil presure and fuel[/COLOR]
	if StopedFlag = false then gosub fCheckAlarmConditions

	if AlarmFlag = True then Alarm		[COLOR="darkgreen"]'Check alarm conditions[/COLOR]
	
	[COLOR="darkgreen"]'?[/COLOR]
	high 0
	pause 500
	low 0
	pause 500
goto Main
	
	
[COLOR="darkgreen"]'returns StopedFlag: true if stoped. false if runing[/COLOR]
fCheckIfRuning:
	if oilpress = 0 and sense = 0 then 	[COLOR="darkgreen"]'no oil pressure and no voltage generated[/COLOR]
		StopedFlag = True
	else								[COLOR="darkgreen"]'otherwise return false[/COLOR]
		StopedFlag = False
	endif
return
	
[COLOR="darkgreen"]'returns AlarmFlag: true if any alarm conditions are true[/COLOR]
fCheckAlarmConditions:
	if oilpress = 0 then 
		AlarmFlag = True
	endif
	if fuellevel = 0 then 
		AlarmFlag = True
	endif
return
		
		
start:
	let b1 = 0
	for b1 = 0 to 30
	high inled
	pause 50
	low inled
	pause 50
	next b1
	low volts, fuel,starter
	let b2 = 0
	for b2 = 0 to 2
	if sense = 1 then return endif		[COLOR="darkgreen"]'retuns if voltage is generated[/COLOR]
	if startsw = 1 then return endif		[COLOR="darkgreen"]'returns if startsw is still operated[/COLOR]

	high fuel							[COLOR="darkgreen"]'try again[/COLOR]	pause 1000
	high starter
	pause 1000
	low starter
	pause 5000
	high volts

	if sense = 1 then return endif		[COLOR="darkgreen"]'retuns if voltage is generated[/COLOR]
	low volts, fuel,starter
	pause 5000
	
	if sense = 1 then return endif		[COLOR="darkgreen"]'retuns if voltage is generated[/COLOR]
	next b2
	low volts, fuel,starter
	
	AlarmFlag = True					[COLOR="darkgreen"]'start failed, set alarm[/COLOR]return
		
Shutdown:						
     low volts, fuel,starter
return	
	
	
[COLOR="darkgreen"]'blinks Alarm LED, shutdown, endless loop: requires manual reset.[/COLOR]
Alarm:
	gosub Shutdown
	high inled
	pause 200
	low inled
	pause 200
goto Alarm
 
Last edited:
M

MartinM57

Moderator
Sorry Tony I'm still not up to speed with this.

So...
- at 0400 you get up and go down to the hut
- and the program has "stopped working"
-...which means what...precisely?

Is the generator still running (should it be running?)?
Is the generator stopped (should it be stopped?)?
Your trying to start it and it won't start?
..or something else.

It's just a bit difficult to understand generators when you've lived in houses with permanent mains electric all your life...

Another vote for some serious debugging to find out what's going on - best bet would be SERTXD's all over the place to show you where it is in the code (you might want to put a PAUSE or two around the place to stop huge amounts of output e.g. PAUSE 100(milliseconds) in the main loop) - but that might mean conencting the bush block to the hut with a serial connection - 30m is probably just about OK if you have a cable (or else it's a laptop in the bush block, but that might not be practical)
 
hippy

hippy

Ex-Staff (retired)
As InvaderZim notes, "beware of glitchy inputs". As it currently stands you don't know why the generator has stopped only that it has. It would be sensible to not keep looping but hold the program with some indication as to why that stop has occurred. You will then know what led to the program causing the generator to stop when you get up in the morning.

Your algorithm also doesn't seem to be failsafe as intended. Assume the generator is started everything is okay, the 'main' loop will repeat, calling 'RunCheck' to check everything is okay ...

If 'RunCheck' deems everything is okay, is just about to return when oil pressure drops, once you are back in 'main' it will never call 'RunCheck' again to kill the generator. Likewise a failure to output voltage will never stop the generator and will also prevent a subsequent oil pressure drop being detected.

Re-coding as a 'finite state machine' rather than as a repeating loop will improve that situation, should reduce code size, and should help in determining what has happened when things go wrong.
 
A

airton65

Member
Hi All,

Firstly sorry if I have mislead any of you. The autostart and generator work well, no real problems, I realize that my programing is very amateurish but it runs OK all day. I am keen to program it with Svejk's slick code though. At night the generator is off and the program is supposed to just loop around the "Main" routine and as it does so it lights the "inled" in half second or so intervals. It does this fine all day long and until I go to bed but in the morning there is no "inled" flashing and I can't start the generator by grounding the start switch. I then turn the power off and back on and it is right again until next morning.

Dippy
The circuit is in a steel box sitting on concrete and when you guys mentioned condensation it made alarms bells go off. When I went into the shed to start work today I had to wipe down a couple of machines because of all the condensation on them. I was planning on sticking the whole assemble in the freezer to see what happens but I will have to do a fair amount of reorganizing before that is possible. I added the flashing "inled" to the main routine to keep an eye that it was in fact doing what it is supposed to, which it does for the most part ie, except in the morning.

Svejk

Thanks for the code, and the condensation clue. I will try your code tomorrow but I want to see what happens tonight when I leave it untouched.

MartinM57
At the moment the autostart and generator are sitting just outside the window here at home connected to the computer for program changes.
I can see the autostart from here and the "inled" is flashing away as it should. I have the start switch wires coming in here and if I short them out the generator will start. The generator doesn't run at night. Now when I come out in the morning the "inled" has stopped flashing and I get no response if I short out the start wires. I then go outside, turn the unit off and on, and all is well for the rest of the day. If I don't have any luck in the morning ie testing the switch and a few voltages here and there plus the condensation issue, I will look into the sertxd's. I haven't play around with these before.

Hippy
Once again sorry, it's not the generator that stopped running just the program.
If the program is about to return from the runcheck routine and oil pressure drops then I would have thought that because I have the "or sense = 1" statement, that it would move back to the runcheck routine.
(if sense = 1 or oilpress = 1 then gosub Runcheck )
If this is incorrect then I have a problem. Also I need to check the "sense" input in the runcheck routine, I missed that.

I'm don't really understand how to re-code for a finite state machine, This code was about my limit.

Thanks everyone for your time
I hope your not charging consultancy fees
Tony
 
D

Dippy

Moderator
"Guarantee"?
Sorry, I use Ebay so I don't know what that word means.

Airton, code it up as an Infinite Improbability Drive - as that sounds even more impressive :)

If it still plays up then you must break it down into smaller chunks. wrestling with a big lump is much more difficult.
 
hippy

hippy

Ex-Staff (retired)
airton65 said:
At night the generator is off and the program is supposed to just loop around the "Main" routine and as it does so it lights the "inled" in half second or so intervals. It does this fine all day long and until I go to bed but in the morning there is no "inled" flashing and I can't start the generator by grounding the start switch.
Click to expand...
Possibly a more complicated scenario to resolve. The question is, "Why would the program stop executing that loop, go <somewhere>, then never come back into the loop", or, "why would the program go into some sort of loop which doesn't flash the LED".

It's either leaving that main loop because it assesses the conditions to leave are met, it's resetting continuously, or it's plain-simply crashed and burned somehow, affected by some external event or interference.

I reckon it's time to put some debugging code in as previously suggested so you can see where it is going, try to determine what it is doing.
 
I

inglewoodpete

Senior Member
I've just read this thread. Hopefully everthing but I'm sure to have missed something.:rolleyes:

Things that have stopped my programs (note that I avoid GoTos like the plague):
1. Variable overflow.
2. Failing to initialise a variable
3. Reusing a variable without saving/restoring or discarding/initialising the value.
4. Electrical interference. Never rule this one out!
5. Bad complier version: Check that you're using the latest.

To expand on (4) Electrical interference.
This can happen with bad wiring practice and bad shielding. In one case, I had a PICAXE running in my car. It ran perfectly day after day but when I drove under 330kV power lines several times in 1 day, it went haywire (not reset) every time. Mind you, the power lines were so noisy, even the FM radio had noise problems.

So is there any switching going on with the generator or its loads? (There probably won't be any 330kV lines nearby if you're using a genset!)
 
A

airton65

Member
It's still running this morning

Hi All

Well I was happy to see that the program was still running this morning. I'm about to go out take a few voltage measurement.
I will do as you guys suggest and put some debugging code in now.. I will have a look at the Sertxd command, all the subroutines have a flashing led of different frequency except for "Diesel and Main" which have the same frequency so I will change one of these. I will have to add a flashing led routine to "Runcheck" though..

Inglewoodpete,
Re the electrical interference, There is really no interference to speak of until the gen set starts up. When it's running there are no problems with the autostart (If you see what I mean).

Anyway I'm glad that you guys take checks,,,,,whew I thought you might have wanted money.

Regards
Tony
 
A

airton65

Member
Just a quick update

Hi All

just a quick update, Before work this morning I got the circuit into the freezer and it is still running, now I can't stop the damn thing..I am leaning towards the condensation idea at the moment but I will have a bit of a study of the sertxd command tonight.

BeanieBots, my cheques are as valuable as my checks so you can take your pick whichever.

I included a photo to show the conditions I am working under down here. If Forest wasn't such a gentleman I'd eat him. He clears his nostrils every third breath and his back end is just as lively, his old and lame and good for nothing, but the friendliest and politest horse I've ever come across.

Regards
Tony
 

Attachments

A

airton65

Member
I've discovered the problem

Hi,

I have been working on this problem till I go to bed each night and the last thing I do is turn the computer off and stumble off to bed. Well tonight I was playing around with the sertxd command and finding nothing amiss. So I thought I'd do some reading and turned the computer off. The program stopped, I tried it again, same thing. I got the original circuit and programed it with the same program. It ran whilst the computer shutdown BUT it stopped on boot up. I tried all this several times. I then plugged in my axe092 kit (08M) with a simple flashing led routine on outpin 1, It runs during shutdown and boot up. I put the same flashing led routine into each of 14M, and the same one stopped during shutdown and the same one stopped during boot up. Yesterday I unplugged the download lead from the autostart to move it and that is why it ran last night.

I'm not sure if this is common knowledge but I can't recall reading about unplugging the download lead in fact I'm sure I left a 18X plugged in for days when I was playing around with a project that used an LCD display, and I'm sure I would have noticed that stopping.

Anyway I really appreciate all the time and effort everybody has devoted to this problem and now I'm going to try and get my head around Svejk's programming method

Thanks again
Tony
 
You must log in or register to reply here.
Top