PhilHornby
Senior Member
As per Post #124 - I think you've just re-invented 20mA Current Loop
Possibly, though it might be better described as getting bogged-down in minutiae, premature optimisation, fretting over things which aren't worth worrying about at this stage of the project, trying to address problems you may not have.but am i over complicating the issue
Thank you Hippy, i was trying to follow the idea with this to define what was the minimum needed right at the start, work out the best picaxe etc rather than keep re-engineering, but you're right get something working and go from there.Possibly, though it might be better described as getting bogged-down in minutiae, premature optimisation, fretting over things which aren't worth worrying about at this stage of the project, trying to address problems you may not have.
When a project has too much to it, it can stall under its own weight, becomes too diverse or complicated to be handled. What one wants to do gets held back back by 'how one will do it' sub-projects, which may turn out to have been unnecessary.
The traditional development approach is to prototype in a perfect environment to get what's wanted done and proven to work, and then commission that and resolve any issues which may exist in the deployed environment.
One would normally also simplify the prototype, get that working, then expand it. For a display which reports data from two devices, those devices don't need to be the real devices, can be substituted by something which sends fixed or simplified data. We don't care what that data is as we are merely trying to get the protocol working, getting data displayed. Get that working then figuring out how real devices would implement what's needed is an incremental step on top of that.
Of course there are projects where everything needs to defined before anything can be implemented. But those are often the expensive ones which over run their budgets and timescales and quite often don't deliver anything at all.
Phil, i don't know anything about 20ma current loop, but will look it up, like Hippy says i am looking for solution for problems i haven't encountered yet, i'm trying to cover all aspects, i guess its finding the easiest way to communicate, this being an area i have no great understanding yetAs per Post #124 - I think you've just re-invented 20mA Current Loop
Exactly which OLED? There are many examples on the forum. 8-bit will update faster than 4-bit, but it's a rare case where that speed would make a difference to a human viewer. 8-bit has less software complexity, but if you're copying existing code (as I have done in all cases with displays on picaxes), it doesn't much matter--hippy and others have led the way.28X2 directly driving an 4 line OLED screen showing the time and see how it goes
Ibenson the OLED is the one that comes as part number AXE134Y from the picaxe store, 8-bit sounds fine anything to keep the code more simple etc, as long as can still use the other pins like i will need for the clock module, hserin and hserout etcExactly which OLED? There are many examples on the forum. 8-bit will update faster than 4-bit, but it's a rare case where that speed would make a difference to a human viewer. 8-bit has less software complexity, but if you're copying existing code (as I have done in all cases with displays on picaxes), it doesn't much matter--hippy and others have led the way.
Alan, i wasn't planning to use the backpack, unless the feeling is that its the best way to go??? I was looking to use the X2 picaxe only so i have the ability of Hserin and Hserout and scratchpad, if in the end i don't need these i can drop to the M2 range, i need to get started somewhere and give myself the best chance of successBut the AXE134Y module has its own 18M2 processor to receive serial data, so where do the 8-bits come in? Are you planning to rewrite the 18M2 program code, or to buy separate (raw) OLED (or LCD) modules?
i had a call from clock bloke to say when he got to his unit this morning a picaxe controlled autodrive had stopped working
I assume the clock is stopping due to the autowind spring tension being lost, rather than stopping because the clock needs cleaning and lubricating?On this drive last week i was asked to reduce the pulse time after the last activation from 501 = approx 400ms to 250 = approx 200ms then the system failed, but not straight away, still took a few hundred activations, i need to get to the bottom of what the tilt switch does wrong from time to time, maybe 1 in 100 activations, atleast we are using a picaxe now and can alter code to help if needed.
Yes Jack that was they way it stopped this time, i have a reset button to reset the stall condition i ask the bloke if he tried pressing that when he came to it, he said he tried that and it didn't do anything, the motor and gearboxes used are 12v car wiper motors and the are sourced directly from the manufacturer in Italy, this is a brand new unit, the issue only showed when i was asked to reduce reduce the delay on time, its possible it would have failed anyway at this time.I assume the clock is stopping due to the autowind spring tension being lost
Hi all, I just dived in here again , can I add my two penneth to this. From what I know about the tilt switch methodology I would like to ask if the switch is handable, since the best way to set it is in N/C is satisfied and therefore when it tilts and breaks contact, the drive operates and momentarily pulls the contacts away from the ball / glob, the drive moves until the ball catches up with it, ( that is going to be the absolute minimum requirement).Getting back to the main thread, this being the code for the autodrive controller, i had a call from clock bloke to say when he got to his unit this morning a picaxe controlled autodrive had stopped working, i had made a small change to the code only so that he can have a plug in oled display to see its status, he can see the voltage, the fault registers and a string of numbers which are the main settings being used, so he can always see what code is in a drive, also i can reprogram the picaxe through this interface.
On this drive last week i was asked to reduce the pulse time after the last activation from 501 = approx 400ms to 250 = approx 200ms then the system failed, but not straight away, still took a few hundred activations, i need to get to the bottom of what the tilt switch does wrong from time to time, maybe 1 in 100 activations, atleast we are using a picaxe now and can alter code to help if needed.
I have been asked if i can make the tilt switch code work for a tilt switch that is "on" normally and have it look for an "off" ie the opposite to how it works now, i know hippy gave a solution for use on the tilt switch test rig which showed that the tilt switches seem to work better working backwards.
Today i have bought a turret clock so i can have a live test bed, just need to go collect it this week
Thanks DavidThis could be covered by ignoring the reset position and just doing a timed response to the first hit BUT making sure that it achieves a full clearance and reset of the switch.
Can you link to the exact code you have running as I've lost track of what that is, and you say you recently changed the code, reduced the delay on time.makes me wonder if there is something slightly a miss in the code, a chance to get out of sync or something ... Or can anyone see in the code a possibility for falling out of the loop, its unlikley it actually had 253 stalls?
Hello Hippy its in PDF format in post #170 above, i will see if i can add it in pe6 editor version too, sorted.Can you link to the exact code you have running as I've lost track of what that is, and you say you recently changed the code, reduced the delay on time.
Is there any possibility that the Picaxe is (occasionally) resetting, when power is applied to the motor?Or can anyone see in the code a possibility for falling out of the loop, its unlikely it actually had 253 stalls?
Good idea Phil, didn't think of that, i do have the capacitor 100nf directly across picaxe supply pins, as in on reverse of pcb and also have a 22uf next to the regulator on the control board.Is there any possibility that the Picaxe is (occasionally) resetting, when power is applied to the motor?
If you are able, I would obviously recommend getting to the bottom of the hardware issue, (if that's what it is)....could be along those lines though, how did you sort it in software?
Phil i get one of these if i plug the screen into the pcb with power on, doing it on the development board i added a 1K resistor between C0 and the screen, it worked on development board but doesn't seem to on actual pcb. I did originally intened that the drives would be unplugged to add the screen then re-powered to read system details etc, but finding i could do it live on the development board i put all the info i wanted to display to be sent every second while a voltage measurement is being done.'spurious resets'
'spurious resets'
Is the picaxe crashing/locking up, or is it just the display that’s not working when you connect it with the power on?Phil i get one of these if i plug the screen into the pcb with power on, doing it on the development board i added a 1K resistor between C0 and the screen, it worked on development board but doesn't seem to on actual pcb.
Jack this is something that happens a side from the stall issue above.Is the picaxe crashing/locking up, or is it just the display that’s not working when you connect it with the power on?
That change might be more significant than it looks.I had a call from clock bloke to say when he got to his unit this morning a picaxe controlled autodrive had stopped working, I had made a small change to the code only so that he can have a plug in oled display to see its status,
IF TILT = Activated then
SEROUT AXE134pin , N2400_16 , ( 254 , 212 ); Position the cursor at start of 4th line
SEROUT AXE134pin , N2400_16 , ( "TILT SWITCH OPERATED" ) ; Send to AXE134
IF BTN = Pressed then
sertxd("Tilt switch operated",13,10)
High MOTOR
statement.But you have:I have a reset button to reset the stall condition I ask the bloke if he tried pressing that when he came to it, he said he tried that and it didn't do anything
for c5counter = 1 to 120
pause 1000
next c5counter
disconnect
disconnect
).I reckon the tilt switch needs debouncing (again) after the motor starts. Perhaps also add some debugging around that point, to determine if the Picaxe is resetting. (Set a flag using the 'hippy' technique I linked to above, and check for its presence at boot time. Remember to clear the flag when the motor is switched OFF).N/O is not good since the moment the circuit contacts, the drive moves, and follows the ball causing multiple hits, and a random reset point according to the bounces.
Phil i did notice it was taking longer to send data than it did on the PE6 Editor, i guess from what your saying the timing difference is due to the differeances in baud rate?That change might be more significant than it looks.
Its the opposite, for 30 seconds i can do a download after which that input becomes the reset button from a stall condition , and it works just fine, i would have preffered not to have done it like that, but i was asked to provide the means to reset from a stall condition and i had already used all my pinsSo the reset button is only active for the first 30 seconds after boot - then it's disabled (by thedisconnect
).
Yep it isn't too hard to flip the tilt switch around and position it to work in reverse, when i get my test rig built up i will try that, i want to be able to test it live on a clock.I think the problem is more likely to be in this area though...
I reckon the tilt switch needs debouncing (again) after the motor starts. Perhaps also add some debugging around that point, to determine if the Picaxe is resetting. (Set a flag using the 'hippy' technique I linked to above, and check for its presence at boot time. Remember to clear the flag when the motor is switched OFF).
I need to be careful, if its a autodrive on the clock mech then it would be fine, if its on the chimes side then there will be a string of several tilt switch activations as multiple drives of the motor is required because it can be striking upto 12 times for the hour etcI reckon the tilt switch needs debouncing (again) after the motor starts
Ah - I hadn't spotted the ...It's the opposite, for 30 seconds I can do a download after which that input becomes the reset button from a stall condition and it works just fine
do : loop while TILT = Activated and StallReset = released '// Wait for switch to be released, btn2 = released resets motorstalled condition
disconnect
low MOTOR
statement that precedes it (i.e. the clock unwinds itself again and moves the Tilt switch).A very simple version, which just detects the condition, would be:Adding flags etc I'm not sure how to do that, it has been spoken about before in other things
#Picaxe 08M2
;
; Put the Symbol, with the existing ones.
;
Symbol BORCON = $56 ;$116
;
; Existing code
;
INIT: ' initialisation code
PAUSE 500
SEROUT AXE134pin , N2400_16 , ( 254 , 1 )
;+
; NEW CODE: Check for unexpected RESET
;
PeekSfr BORCON, b0 ;get the BORCON register contents
If bit6 = 0 Then
SerTxd( "NORMAL Power-On", CR, LF )
else
SerTxd( "UNEXPECTED RESET", CR, LF ) ;BORFS=1
;
; Might want to do something else here.
;
End If
;
; Set flag to allow for RESET detection
;
PokeSfr BORCON, %11000001 ;set BORFS bit in BORCON register
;
; END OF NEW CODE.
;-
We're back to the suitability of that tilt switch, for this application...I need to be careful, if it's an autodrive on the clock mech then it would be fine, if it's on the chimes side then there will be a string of several tilt switch activations as multiple drives of the motor is required because it can be striking up to 12 times for the hour etc
Pulsout
)Phil its not intending to be used directly after a boot, maybe gets ready for a download that's not coming, i haven't tried it.What does it do, if you press it immediately after boot, before thedisconnect
If the tilt switch is still closed and the motor hasn't moved for some reason it will stay in the stalled condition either till the tilt switch goes open which is unlikely to happen if the motor isn't moving, so something was needed to do the same as the tilt switch going open, and when the motor is sat in the stall condition, pressing the button gives it upto 6 seconds more power to drive, it works well.Since it doesn't appear to do anything when pressed 'after a stall', can we assume that the condition resets itself,
Got to be a bit careful that pulses of the tilt switch aren't missed 250ms might be long enough to miss something, thats why everything is in a fast loop to make sure the tilt switch is monitored as often as possible, just a shame the tilt switch is a bit unreliable from a repeatability point of view, the clock bloke isn't current interested in changing to a different meens of detection.Perhaps the logic should be:
- On detecting TILT, send a 400mS pulse to the motor (using simple
Pulsout
)- Wait say 250mS.
- If TILT is still activated, goto 1
When you originally started this thread, you experienced problems with button pushes being missed due to rapid presses (button represented the tilt switch).Got to be a bit careful that pulses of the tilt switch aren't missed 250ms might be long enough to miss something, thats why everything is in a fast loop to make sure the tilt switch is monitored as often as possible
However we now know a lot more about your project and it is our understanding that if the autodrive motor needs to be operated then the tilt switch will be permanently on, so it shouldn’t matter if the tilt switch was monitored less frequently as it would still be detected. Obviously you don’t want excessively long delays as you want to keep the spring tension reasonably constant.if the button is pressed many times quickly then there are presses where the LED is off for a split second
Jack yep I guess so, the original need came from how the 555 was being used, kind of missing pulse detector, that was the setup for the drive on the Chimes mech whereas the clock mech was using a 555 in monostable mode, it was found that the Chimes one was suitable for both drives.However we now know a lot more about your project and it is our understanding that if the autodrive motor needs to be operated then the tilt switch will be permanently on, so it shouldn’t matter if the tilt switch was monitored less frequently as it would still be detected. Obviously you don’t want excessively long delays as you want to keep the spring tension reasonably constant.
Intended or not , if you press it, the Picaxe resets about 2 seconds after releasing it. (I tested it).Phil it's not intending to be used directly after a boot, maybe gets ready for a download that's not coming, I haven't tried it.
Have you encountered a 'stall' in the wild, that required the Reset button pressingIf the tilt switch is still closed and the motor hasn't moved for some reason it will stay in the stalled condition either till the tilt switch goes open which is unlikely to happen if the motor isn't moving, so something was needed to do the same as the tilt switch going open, and when the motor is sat in the stall condition, pressing the button gives it upto 6 seconds more power to drive, it works well.
I can see that you want to respond to the first sign of a 'Tilt'. When the proposed pulsout completes, you know exactly where the winding mechanism ought to be.Got to be a bit careful that pulses of the tilt switch aren't missed 250ms might be long enough to miss something
Thanks Phil, in the autodrive that push button is accessed with a paper clip through a hole in the motor control box, I guess the reset is not from code but rather from pulling that pin highIntended or not , if you press it, the Picaxe resets about 2 seconds after releasing it. (I tested it).
Yep I wanted to catch the first sign of the tilt switch being operated, they want to keep the angle that is required quite small and we know the switch doesn't close very cleanly there can be several bounces, 7 bounces is the most I found on the test rig, but I wasn't happy about the test method I was usingI can see that you want to respond to the first sign of a 'Tilt'. When the proposed pulsout completes, you know exactly where the winding mechanism ought to be.
I don't think it can of had that many stalls considering but something caused the counter to increment and for the motor to be sat in the unwound position where the tilt switch would have been fully closed, I wasn't there to witness how he found the clock. The picture of the screen he sent to me when he plugged it in to try and see the problem.(You previously said you had a Stall count of 253 and the Reset button had no effect. Surely it can't have 253 genuine detects of Tilt after 6 seconds, none of which resulted in the program locking-up in the 'Stall Reset loop')
Phil really interesting idea, things i need to consider just how to calibrate it, the autodrive would need to be self installed on the clock correctly before a calibration routine can begin, what feedback can be given to the user that its progressing correctly, ideally it would all want to be self contained.I'm envisaging something along the lines of: Pulsing the motor, a set number of times, for a pre-set period, for each initial Tilt detection - based on pre-set parameters. So for example, at 11am, it knows that 6 'cranks' are required ... and at 1pm, only one; that sort of thing. Same sort of idea for the ¼,½ & ¾ hours. The length of the Pulse, time between Pulses and number of Pulses can be different in each case; there are not that many of them to store.
The existing code increments the Stall count only once after 6 seconds, however if the Tilt switch is permanently on and the Reset button has been pushed, then the Stall count will increment again. This can be repeated during a stall but does need the reset button to be pressed each time. So lots of Reset button pushes required to get to 253.Surely it can't have 253 genuine detects of Tilt after 6 seconds
Um - that's a possibility. I've suffered something similar - the cause being the start up of Central Heating pump (hardly a massive electrical load - but nonetheless...). Again, I addressed that problem in software - I just made it require a slightly longer pressMake me wonder if electrical noise is getting to the Serial In pin (used for Reset button) and flagging a stall reset without the button being pushed.
Having slept on it, maybe it's not as complicated as it sounds...things I need to consider just how to calibrate it, the autodrive would need to be self installed on the clock correctly before a calibration routine can begin, what feedback can be given to the user that its progressing correctly, ideally it would all want to be self contained.
... snip ...
The clock module would need to auto change over to Daylight Saving Time,
Jack seems likely the only way it could have got in to such a mess, the screen wasn't attached when it went stupid, so the length of track connected to the picaxe pin would have been very short, maybe 30-40mm, any ideas on possible damping this pin?Make me wonder if electrical noise is getting to the Serial In pin (used for Reset button) and flagging a stall reset without the button being pushed.
Yep i did start thinking along those lines, it would be good for the control unit to be able to display somehow where it thinks it is in the cycle, it could then be incremented to the right place after a form of calibration and if the time gets changed for DST then it can be incremented to the right place after altering the church clock.I didn't think it actually needs a DS3231 in order to know the time - it would just need synchronising with real-time once. After all, 2pm always follows 1pm, half-past always follows quarter-past etc - it would just need to know where it was in the 'sequence'.
These things are self install i'm going to factor in stupidity etcMaybe the calibration wouldn't be as bad as it sounds either. It's something you can investigate when you get your own clock.
Yes quite possible, currently my test clock only has a clock drive because the clock bloke wants me to work on the grab mech at the momentPerhaps you'll find, that the values are multiples of one another. (For example, when you know what is needed to rewind after striking 1pm, perhaps the values required for winding after all later strikes will all be predictable, i.e. in some fixed ratio or pattern)
Did you really mean 100pF as Rev-Ed recommend 100nF as close to the picaxe as possible?After the regulator it has a 22uf capacitor within 10mm, and there is a 100pf capacitor connected directly to the supply pins of the picaxe, the capacitor is on the reverse of the pcb.
"A bypass capacitor is recommended across the LP2950/LP2951 input to ground if more than 4 inches of wire connects the input to either a battery or power supply filter capacitor."
init: ' initialisation code
pause 500
SEROUT AXE134pin , N2400_16 , ( 254 , 1 )
I'm not sure if this is exactly what you had in mind, but I thought that if the button had to be held down for a set period of time, then it would be very unlikely to get an accidental reset from interference.Also maybe some debounce on the stall-reset switch to rule out interference?
' *** Original line rem'd out ***
'do : loop while TILT = Activated and StallReset = released '// Wait for TILT switch to be released OR StallReset to be pushed
' *** New code to replace original line ***
'// Wait for TILT switch to be released OR StallReset pushed for 2 secs
Time = 0
do
if StallReset <> Pressed then
Time = 0
end if
loop while TILT = Activated and Time < 2
Jack yes sorry its 100nf my mistake.Did you really mean 100pF as Rev-Ed recommend 100nF as close to the picaxe as possible?
No i don't have one at this point i will look into what it recommendsThe LP2950CZ datasheet also recommends a capacitor on its input - do you have one fitted?
Yep good point, the main reason for that being there was after a download when there is loads of weird stuff showing on the screen from the download it clears the screen at this point the screen has been powered for some time, but i can increase itThe pause 500 in your initialisation is actually pausing for 125ms as your running your code at 16MHz. I suggest increasing this to "pause 4000" which will give you 1000ms at 16MHz. I find my 16x2 OLD need this long to reliably initialise.
I don't have a start up message, after a screen clear it gets the voltage details, and fault registersAre you using the standard firmware on the OLED backpack, or do you have a customised startup message? as it's possible that any new message written by the autowind unit could be mis-interpreted if the OLED wasn't starting with a clear screen?
On the drives the recall button is covered its not intended to be used by the userFor the time being, I would be inclined to disable the RECALL button (or modify the memoryrecall subroutine) to avoid the possibility of getting the code stuck in a potentially long fault recall sequence.
I assume by that you mean because the recall button had been pressed and the heartbeat was actually the memory being recalled?I notice you can get the code into a state where you think it's working but it's actually doing something else,
I think that's worth looking at using regardless JackThe following code requires the StallReset button to held down for 2 seconds continuously for the reset to take place. The actual delay is not really that important as the autodrive has already stalled, however it can be easily changed if you want a different delay.