Tilt switch test rig

Rampz

Well-known member
Hello All

Building a test rig for testing tilt switches, my best attempt at code below, having a few issues, atleast it mostly works firstly

1) I wanted to show in the terminal each time the tilt switch is operated on and off, but since i'm in a loop it shows multiple times, the switch controlling the motor and the led to display status of the tilt switch works nicely

2) Seems to be some issue where the test doesn't go for the required amount of microswitch activations that indicates reolutions of the test rig, as an example its set currently to 100 and test concludes around mid 50's, switch actions doesn't seem to be displaying number of tilt switch activations, something wrong

3) when test complete, eg number of revolutions done, i want to compare tilt switch activations against revolutions, i want to allow maybe addition 1 for error, if number are the same + 1 then go to PASS, if not go to FAIL



Code:
' Test rig to test TILT switches, motor speed ccontrol to left of rig to set motor speed, will in time be replaced with PWM speed control. Button and associated led for setting up tilt switch under test position, button turns on motor and led operates as tilt switch operates. I did want to show on terminal when tilt swith operates but terminal shows that every loop not just when operated?

'Middle top button stops above loop and gets ready for start of test, resets counters, second press starts test which should be for a quantity of revolutions detected by the microswitch, reads correctly but duration of test is not in this case 100 microswitch operations.

'after test i need to compare revolutions against tilt switch activations allowing for an error of 1 or 2 and then go to either Pass or Fail, not working correctly

#picaxe 14m2
#no_data
#terminal 4800

'Constants
symbol INCH = PinC.2    'rotate motor to setup tilt switch
Symbol TESTswitch = PinB.3    'Switch on test
Symbol REVOswitch = PinC.4    'motor revolutions
Symbol START = PinB.5     'Start button
Symbol AXE134pin = C.1  'connected to screen input
symbol MotorRelay = B.1 'switch motor on and off
Symbol Mspeed = B.2     'motor speed output to mosfet
symbol led = B.4        'led to show tilt switch position for setup
Symbol Pressed = 1
symbol Released = 0
symbol REVOLUTIONS = 100

'Variables
symbol REVcount = W0    'count revolutions from microswitch of motor
symbol SWITCHcount = W1 'count activations of test switch
symbol TESTtime = W2   'quantity of motor revolutions needed to complete test
symbol COUNTdiff = b6   'difference between count allowed
symbol TOTALCount = W4  'total revolution count to test for fail

init:
pause 2000
SerTxd("Coding by Rampz", CR, LF )
SerTxd("Tilt Switch Test Rig", CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 128 ) 'set at first line
SEROUT AXE134pin , N2400_4 , ( "Code by Rampz")
low led

SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "              " ) 'clear fourth line

  REVcount = 0 'reset counter to 0
  SEROUT AXE134pin , N2400_4 , ( 254 , 192 ) 'set at second line
  SEROUT AXE134pin , N2400_4 , ( "Revolutions    ", #REVcount, " ") 'display reset
  SWITCHcount = 0 'reset counter to 0
  SEROUT AXE134pin , N2400_4 , ( 254 , 148 ) 'set at third line
  SEROUT AXE134pin , N2400_4 , ( "Switch Actions ", #SWITCHcount, "   ") 'display reset

Setup: 'used to set switch under test in correct position

do

  if TESTswitch = pressed then 'if switch on then turn led on
  pause 100
  SerTxd("Test switch on", CR, LF) 'trying to display when switch activated, not correct
  high led
  endif
  if TESTswitch = released then 'if switched off then led off
  pause 100
  SerTxd("Test switch off", CR, LF) 'trying to display when switch off, not correct
  low led
  endif

  if INCH = pressed then 'if switch is on turn on motor to aligh switch under test
  pause 100
  high MotorRelay
  endif
  if INCH = released then 'if switch off stop motor
  pause 100
  low MotorRelay
  endif
loop until START = pressed 'if start button pressed exit loop an continue
    pause 100
    gosub BEGIN
 
BEGIN: 'reset counters and get ready to start the test

low MotorRelay
SerTxd("Motor Off", CR, LF)
Do : Loop Until START = Pressed ; Wait for push to turn motor on
  Pause 200 'debounce
  SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
  SEROUT AXE134pin , N2400_4 , ( "              " )
  high MotorRelay
  REVcount = 0 'reset counter to 0
  SWITCHcount = 0 'reset counter to 0
  COUNTdiff = 1 'difference allowed between REVcount and SWITCHcount
  SerTxd("Motor On", CR, LF)


For TESTtime = 1 to REVOLUTIONS 'should count revolutions, i think its counting loops?
 
  IF REVOswitch = Pressed then 'microswitch detecting revolutions
      pause 100 'debounce
      REVcount = REVcount + 1 'incrementing counter for each revoltion
      TESTtime = TESTtime + 1 'incrementing counter for each revolution, so test concludes after quantity of revolutions
Endif
  
  SerTxd("Revolutions", #REVcount,CR, LF )
  SEROUT AXE134pin , N2400_4 , ( 254 , 192 ) 'set at second line
  SEROUT AXE134pin , N2400_4 , ( "Revolutions    ", #REVcount, " ")

  IF TESTswitch = pressed then 'if button 1 pressed
      pause 50 'debounce
      SWITCHcount = SWITCHcount + 1
Endif
  SerTxd("Switch Actions", #SWITCHcount,CR, LF )
  SEROUT AXE134pin , N2400_4 , ( 254 , 148 ) 'set at third line
  SEROUT AXE134pin , N2400_4 , ( "Switch Actions ", #SWITCHcount, "   ")


  TOTALcount = COUNTdiff + REVcount 'allowing an error of 1
  IF TOTALcount > SWITCHcount then 'something wrong here too
      Gosub Failed
  endif
NEXT

Gosub Passed

Failed: 'should be at this point if the revolutions doesn't match test switch activations

SerTxd("Test switch FAILED",CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "SWITCH FAILED" )
Gosub setup

Passed: 'should be at this point if the revolutions does match test switch activations
SerTxd("Test switch PASSED",CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "SWITCH PASSED" )
Gosub setup
 

Attachments

Last edited:

Rampz

Well-known member
The main problem i have disregarding pass and fail at the end and the terminal showing correctly is counting of Switch Actions, Revolutions seem to count correctly, but switch actions seem to count continuously when the tilt switch operates, it seems when the tilt switch is operated for that period its counting loops, really strange, the second part of this is the program stops before revolutions = number required (symbol REVOLUTIONS), i wanted the test to run for say 100 revolutions which would be counted from the red microswitch, so i inc 2 different counters, Revolutions thats displayed on the screen seems good but the counter that is looking for 100 revolutions has mind of its own, can't see where i'm going wrong.
I get the feeling that my loop is running too slowly and i am missing microswitch operations, i did increase clock speed and adjust timings etc, didn't help much

Edit

I just tried running the motor very slowly and when the microswitch is activated the number of revolutions runs away too, so the fact that it seems to work is a fluke.

I'm thinking its the way i am checking my 2 inputs and "inc" the counters thats the problem, i want each counter to "inc" once per activation, since i'm in a loop to check the inputs quickly its causing issues with the counters seems they run away when either input is activated and then counts loops, really lost help please

Another thought

Am i better running parallel tasks, with one input and one counter per task, in each loop "gosub" to a position to count the activation and wait for switch release before returning to loop, i assume each task could output to different lines on the screen as i have now, a third task run the motor for a set time and compare results at the end from other tasks? Thoughts please, struggling
 
Last edited:

David_Reynolds

Well-known member
Hello, Rampz.
I am a complete newcomer to programming, so please forgive me if I am wrong, but I do not see any interrupts set in your listing. I think that if your program is running, the time to scan through those lines may be "missing" some the operations of your switch.
If this is so then I assume an interrupt could service your up or down count and then jump back to where it was at he time. I would think that interrupts for all the "occasional" signals might well be needed.

Dave.
 

PhilHornby

Senior Member
I started to have a tidy-up of the code. I noted it was de-bouncing the switches in the "OFF" position (something I've never found necessary) and using unnecessarily long waits for the "ON"s. (Just executing sertxd("Test switch on",cr,lf) takes 33mS @ 4800baud).
It also wasn't waiting for the switch to release - which didn't seem right in this application.

Irrelevant code corrections removed

then I realised that there is more amiss...

I don't think your understanding of the concept of a 'subroutine' is correct... (without wishing to be rude :) )

When you gosub 'someroutine', the interpreter saves the current location and jumps to the label in question. When the code following that label eventually issues a return statement, the interpreter uses the location stored earlier and executes the next statement that follows it.

Your code contains lots of gosubs, but no returns o_O

The Picaxe Editor isn't robust enough to spot these errors and the Picaxe firmware doesn't have a lot of options in the way it deals with them.

I suspect the Picaxe is just running wild with the code as it stands :(
 
Last edited:

papaof2

Senior Member
Dave's suggestions of using interrupts might be the way to go. Long ago, I used interrupts on an 08M to measure waterflow by counting the pulses (815 pulses/gallon) from a magnetic switch flow sensor (from a Whirlpool clothes washer). This was using gravity flow from a rainwater collection tank so the flow rate wasn't high.
 

PhilHornby

Senior Member
I think that if your program is running, the time to scan through those lines may be "missing" some the operations of your switch.
I think that is entirely possible. It would be interesting to do some rough calculations, to determine the maximum frequency (and duration) of the signals involved.
 

David_Reynolds

Well-known member
Hi, Phil,and Papa.
Good points, I also would add that in the routines for capturing the switch operation, that they should only increment once the switch condition has ended, and the cycle is finished, that way it cannot keep counting / looping until it next reactivates.
I am at present working on a program that requires a trigger button press, , the routine it then calls when finished, waits on the clearance of the button before resuming. It means that no matter how quickly I press the trigger or how long I hold it on, the operation will not move on and the counter will not add until I let go.
 
Last edited:

Rampz

Well-known member
I don't think your understanding of the concept of a 'subroutine' is correct... (without wishing to be rude :) )
Hello PhilHornby
I am very new to BASIC and picaxe or anything like this, I'm learning as I go, I will add "return" I didn't understand them as you say, I felt I had to say where to go rather than just return, am I heading in the right direction with what I'm trying to do?

I have removed "gosub" since i wasn't really going to a sub it was a miss use of the term and i have changed to "Goto" , should i detect on and then off of the switch before moving on? i need to be careful not to miss new activations but at same time stop the setup counting "loops" which i feel its doing between switch on and switch off.

I have removed the debounce of switch off, i was applying it regardless, inexperience again, any help with code would be great PhilHornby

I started to have a tidy-up of the code.
i am not very good at laying the code out at the moment, i am trying and i am trying to add info so everyone knows what i am trying to do too
 
Last edited:

Rampz

Well-known member
I also would add that in the routines for capturing the switch operation, that they should only increment once the switch condition has ended, and the cycle is finished, that way it cannot keep counting / looping until it next reactivates.
Hello David_Reynolds
Yep I was thinking the same but couldn't work out how to do that, it was just running away counting loops when first activated

but I do not see any interrupts set in your listing
I don't understand how to use "Interrupts" i have had help from members recently in projects that detect switch activations similary to what i am doing here and they didn't use interrupts so i went along previous lines with this code
 
Last edited:

Rampz

Well-known member
My code as it stands now, removed "gosub" because i think i was using them incorrectly when i just want to carry on through the code, removed the pass fail calculations at the end because they weren't working too, need to get main body of code working first
Tried to tidy code layout up too
Still not working correctly, still seeming to run away when switch is operated

Code:
' Test rig to test TILT switches, motor speed ccontrol to left of rig to set motor speed, will in time be replaced with PWM speed control. Button and
' associated led for setting up tilt switch under test position, button turns on motor and led operates as tilt switch operates. I did want to show on 'terminal when tilt swith operates but terminal shows that every loop not just when operated?

'Middle top button stops above loop and gets ready for start of test, resets counters, second press starts test which should be for a quantity of 'revolutions detected by the microswitch, reads correctly but duration of test is not in this case 100 microswitch operations.

'after test i need to compare revolutions against tilt switch activations allowing for an error of 1 or 2 and then go to either Pass or Fail, not working 'correctly

#picaxe 14m2
#no_data
#terminal 19200
SetFreq M16

'Constants
symbol INCH = PinC.2             'rotate motor to setup tilt switch
Symbol TESTswitch = PinB.3    'Switch on test
Symbol REVOswitch = PinC.4   'motor revolutions
Symbol START = PinB.5            'Start button
Symbol AXE134pin = C.1         'connected to screen input
symbol MotorRelay = B.1         'switch motor on and off
Symbol Mspeed = B.2              'motor speed output to mosfet
symbol led = B.4                      'led to show tilt switch position for setup
Symbol Pressed = 1
symbol Released = 0
symbol REVOLUTIONS = 200  'number of revoltions till test finished
symbol Baud = N2400_16

'Variables
symbol REVcount = W0        'count revolutions from microswitch of motor
symbol SWITCHcount = W1 'count activations of test switch
symbol TESTtime = W2        'quantity of motor revolutions needed to complete test
symbol COUNTdiff = b6       'difference between count allowed
symbol TOTALCount = W4   'total revolution count to test for fail

init:
    pause 2000
    SerTxd("Coding by Rampz", CR, LF )
    SerTxd("Tilt Switch Test Rig", CR, LF )
    SEROUT AXE134pin , Baud , ( 254 , 128 ) 'set at first line
    SEROUT AXE134pin , Baud , ( "Code by Rampz")
    low led

    SEROUT AXE134pin , Baud , ( 254 , 215 ) 'set at fourth line
    SEROUT AXE134pin , Baud , ( "              " ) 'clear fourth line

    REVcount = 0 'reset counter to 0
    SEROUT AXE134pin , baud , ( 254 , 192 ) 'set at second line
    SEROUT AXE134pin , baud , ( "Revolutions    ", #REVcount, " ") 'display reset
    SWITCHcount = 0 'reset counter to 0
    SEROUT AXE134pin , baud , ( 254 , 148 ) 'set at third line
    SEROUT AXE134pin , baud , ( "Switch Actions ", #SWITCHcount, "   ") 'display reset

Setup: 'used to set switch under test in correct position

do
 
if TESTswitch = pressed then 'if switch on then turn led on
      pause 400
      'SerTxd("Test switch on", CR, LF) 'trying to display when switch activated, not correct
      high led
endif
if TESTswitch = released then 'if switched off then led off
 
      'SerTxd("Test switch off", CR, LF) 'trying to display when switch off, not correct
      low led
endif
 
if INCH = pressed then 'if switch is on turn on motor to aligh switch under test

      pause 100
      high MotorRelay
endif
if INCH = released then 'if switch off stop motor

      low MotorRelay
endif
    loop until START = pressed 'if start button pressed exit loop an continue
    pause 100
   
   
BEGIN: 'reset counters and get ready to start the test

      low Led
      low MotorRelay
      SerTxd("Motor Off", CR, LF)
Do : Loop Until START = Pressed ; Wait for push to turn motor on
      Pause 100 'debounce
      SEROUT AXE134pin , Baud , ( 254 , 215 ) 'set at fourth line
      SEROUT AXE134pin , Baud , ( "              " )
      high MotorRelay
      REVcount = 1 'reset counter to 1 because likely in first revoltion
      SWITCHcount = 0 'reset counter to 0
      COUNTdiff = 1 'difference allowed between REVcount and SWITCHcount
      SerTxd("Motor On", CR, LF)
 

For TESTtime = 0 to REVOLUTIONS 'should count revolutions, i think its counting loops?
   
IF REVOswitch = Pressed then 'microswitch detecting revolutions
      pause 400 'debounce
      inc REVcount  'incrementing counter for each revoltion
      inc TESTtime  'incrementing counter for each revolution, so test concludes after quantity of revolutions
endif
    
      SerTxd("Revolutions", #REVcount,CR, LF )
      SEROUT AXE134pin , Baud , ( 254 , 192 ) 'set at second line
      SEROUT AXE134pin , Baud , ( "Revolutions    ", #REVcount, " ")
 
IF TESTswitch = pressed then 'if tilt switch operated
     pause 400 'debounce
endif
    inc SWITCHcount

      SerTxd("Switch Actions", #SWITCHcount,CR, LF )
      SEROUT AXE134pin , Baud , ( 254 , 148 ) 'set at third line
      SEROUT AXE134pin , Baud , ( "Switch Actions ", #SWITCHcount, "   ")
next
goto setup 
 



Failed: 'should be at this point if the revolutions doesn't match test switch activations

     SerTxd("Test switch FAILED",CR, LF )
     SEROUT AXE134pin , N2400_8 , ( 254 , 215 ) 'set at fourth line
     SEROUT AXE134pin , N2400_8 , ( "SWITCH FAILED" )
     SerTxd("Motor Off", CR, LF)
     Goto setup

Passed: 'should be at this point if the revolutions does match test switch activations
     SerTxd("Test switch PASSED",CR, LF )
     SEROUT AXE134pin , N2400_8 , ( 254 , 215 ) 'set at fourth line
     SEROUT AXE134pin , N2400_8 , ( "SWITCH PASSED" )
     SerTxd("Motor Off", CR, LF)
     Goto setup
 

David_Reynolds

Well-known member
Hello All

Building a test rig for testing tilt switches, my best attempt at code below, having a few issues, atleast it mostly works firstly

1) I wanted to show in the terminal each time the tilt switch is operated on and off, but since i'm in a loop it shows multiple times, the switch controlling the motor and the led to display status of the tilt switch works nicely

2) Seems to be some issue where the test doesn't go for the required amount of microswitch activations that indicates reolutions of the test rig, as an example its set currently to 100 and test concludes around mid 50's, switch actions doesn't seem to be displaying number of tilt switch activations, something wrong

3) when test complete, eg number of revolutions done, i want to compare tilt switch activations against revolutions, i want to allow maybe addition 1 for error, if number are the same + 1 then go to PASS, if not go to FAIL



Code:
' Test rig to test TILT switches, motor speed ccontrol to left of rig to set motor speed, will in time be replaced with PWM speed control. Button and associated led for setting up tilt switch under test position, button turns on motor and led operates as tilt switch operates. I did want to show on terminal when tilt swith operates but terminal shows that every loop not just when operated?

'Middle top button stops above loop and gets ready for start of test, resets counters, second press starts test which should be for a quantity of revolutions detected by the microswitch, reads correctly but duration of test is not in this case 100 microswitch operations.

'after test i need to compare revolutions against tilt switch activations allowing for an error of 1 or 2 and then go to either Pass or Fail, not working correctly

#picaxe 14m2
#no_data
#terminal 4800

'Constants
symbol INCH = PinC.2    'rotate motor to setup tilt switch
Symbol TESTswitch = PinB.3    'Switch on test
Symbol REVOswitch = PinC.4    'motor revolutions
Symbol START = PinB.5     'Start button
Symbol AXE134pin = C.1  'connected to screen input
symbol MotorRelay = B.1 'switch motor on and off
Symbol Mspeed = B.2     'motor speed output to mosfet
symbol led = B.4        'led to show tilt switch position for setup
Symbol Pressed = 1
symbol Released = 0
symbol REVOLUTIONS = 100

'Variables
symbol REVcount = W0    'count revolutions from microswitch of motor
symbol SWITCHcount = W1 'count activations of test switch
symbol TESTtime = W2   'quantity of motor revolutions needed to complete test
symbol COUNTdiff = b6   'difference between count allowed
symbol TOTALCount = W4  'total revolution count to test for fail

init:
pause 2000
SerTxd("Coding by Rampz", CR, LF )
SerTxd("Tilt Switch Test Rig", CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 128 ) 'set at first line
SEROUT AXE134pin , N2400_4 , ( "Code by Rampz")
low led

SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "              " ) 'clear fourth line

  REVcount = 0 'reset counter to 0
  SEROUT AXE134pin , N2400_4 , ( 254 , 192 ) 'set at second line
  SEROUT AXE134pin , N2400_4 , ( "Revolutions    ", #REVcount, " ") 'display reset
  SWITCHcount = 0 'reset counter to 0
  SEROUT AXE134pin , N2400_4 , ( 254 , 148 ) 'set at third line
  SEROUT AXE134pin , N2400_4 , ( "Switch Actions ", #SWITCHcount, "   ") 'display reset

Setup: 'used to set switch under test in correct position

do

  if TESTswitch = pressed then 'if switch on then turn led on
  pause 100
  SerTxd("Test switch on", CR, LF) 'trying to display when switch activated, not correct
  high led
  endif
  if TESTswitch = released then 'if switched off then led off
  pause 100
  SerTxd("Test switch off", CR, LF) 'trying to display when switch off, not correct
  low led
  endif

  if INCH = pressed then 'if switch is on turn on motor to aligh switch under test
  pause 100
  high MotorRelay
  endif
  if INCH = released then 'if switch off stop motor
  pause 100
  low MotorRelay
  endif
loop until START = pressed 'if start button pressed exit loop an continue
    pause 100
    gosub BEGIN

BEGIN: 'reset counters and get ready to start the test

low MotorRelay
SerTxd("Motor Off", CR, LF)
Do : Loop Until START = Pressed ; Wait for push to turn motor on
  Pause 200 'debounce
  SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
  SEROUT AXE134pin , N2400_4 , ( "              " )
  high MotorRelay
  REVcount = 0 'reset counter to 0
  SWITCHcount = 0 'reset counter to 0
  COUNTdiff = 1 'difference allowed between REVcount and SWITCHcount
  SerTxd("Motor On", CR, LF)


For TESTtime = 1 to REVOLUTIONS 'should count revolutions, i think its counting loops?

  IF REVOswitch = Pressed then 'microswitch detecting revolutions
      pause 100 'debounce
      REVcount = REVcount + 1 'incrementing counter for each revoltion
      TESTtime = TESTtime + 1 'incrementing counter for each revolution, so test concludes after quantity of revolutions
Endif
 
  SerTxd("Revolutions", #REVcount,CR, LF )
  SEROUT AXE134pin , N2400_4 , ( 254 , 192 ) 'set at second line
  SEROUT AXE134pin , N2400_4 , ( "Revolutions    ", #REVcount, " ")

      If TESTswitch = pressed Then Goto DebounceSW1
' Daves  interferance begins 
DebounceSW1:  
       Pause 20  'debounce
      If TESTswitch = pressed  Then DebounceSW1   'loopback until switch opens
      If TESTswitch = released Then
    switchcount = switchcount + 1
 
 Daves ends 

Endif
  SerTxd("Switch Actions", #SWITCHcount,CR, LF )
  SEROUT AXE134pin , N2400_4 , ( 254 , 148 ) 'set at third line
  SEROUT AXE134pin , N2400_4 , ( "Switch Actions ", #SWITCHcount, "   ")


  TOTALcount = COUNTdiff + REVcount 'allowing an error of 1
  IF TOTALcount > SWITCHcount then 'something wrong here too
      Gosub Failed
  endif
NEXT

Gosub Passed

Failed: 'should be at this point if the revolutions doesn't match test switch activations

SerTxd("Test switch FAILED",CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "SWITCH FAILED" )
Gosub setup

Passed: 'should be at this point if the revolutions does match test switch activations
SerTxd("Test switch PASSED",CR, LF )
SEROUT AXE134pin , N2400_4 , ( 254 , 215 ) 'set at fourth line
SEROUT AXE134pin , N2400_4 , ( "SWITCH PASSED" )
Gosub setup
 

David_Reynolds

Well-known member
Hello David_Reynolds
Yep I was thinking the same but couldn't work out how to do that, it was just running away counting loops when first activated


I don't understand how to use "Interrupts" i have had help from members recently in projects that detect switch activations similary to what i am doing here and they didn't use interrupts so i went along previous lines with this code
I dont even know how this site works yet but I have interfered with your listing, oops. I thought it would remain separate, but anyway you can probably catch those switches with just a simple feedback loop just has I placed in it.

If testswitch = pressed Then Goto DebounceSW1

DebounceSW1:
Pause 20 'debounce
If testswitch = pressed Then DebounceSW1 ; loop back until switch opens
If testswitch = released Then
switchcount = switchcount + 1

"Return"

It will hold the count until the switch goes open again, since looking at your hardware I do not think it will move that fast that you would need interupts. They are also confined to certain pins from the info that I have seen.
This capture loop can be used for any switches that you need a specific count on.
Obviously they would be " DebounceSW2 Etc."
I tried to simulate it and it works OK the "return" as far as I can see is not required since it just carries on with the next line, I am sure that PhilHornby would disagree though ! As I am completely new to this programming hobby, I would take on board all he has to say about it.
 
Last edited:

Rampz

Well-known member
I dont even know how this site works yet but I have interfered with your listing
You can go to edit of the above comment and go and delete it if you want, but don't worry, i will try your code alteration later when i get home, so it looks like you are leaving the loop and going to "debounceSW1" during its activation then returning after, like you say both switches aren't activating very quickly, it is possible to move the microswitch position so its activations are well away from the switch under test activation periods so all activations get pickup up, i assume while i am in a "debounceSW1" position the loop is stopped and we aren't checking the other switch etc?

The other issue is that i want the test to continue for a count of Revolutions so i guess i need to get the revolutions switch to advance the count on 2x counters
 

hippy

Technical Support
Staff member
I am very new to BASIC and picaxe or anything like this, I'm learning as I go
The best advice I have, which applies to those just starting as well as the experienced, is to always start small. Create the core part of the program, ensure it does what it is meant to do, fix it if it doesn't, and only then add more to it. Build it up incrementally.

It's the old - How do you eat an elephant? One small piece at a time.

In this case the core objective is to count revolutions ( which I've called 'turns' ) and to count tilt switch activations. So I would start with code which simply does that, counts them and reports changes to the Terminal when they occur. Power the motors up manually and see if it keeps count, one tilt per turn. You might need to adjust TURN_PIN and TILT_PIN if I have got the wrong pins -
Code:
#Picaxe 14M2
#No_Data
#Terminal 19200

Symbol TURN_PIN = pinC.4
Symbol TILT_PIN = pinB.3

Symbol reserveW0 = w0 ; b1:b0
Symbol turnCount = w1 ; b3:b2
Symbol tiltCount = w2 ; b5:b4

Symbol turnWas   = b6
Symbol tiltWas   = b7
Symbol changed   = b8

Initialise:
  SetFreq M16
  turnCount = 0
  tiltCount = 0
  turnWas   = TURN_PIN
  tiltWas   = TILT_PIN
  changed   = 1

MainLoop:
  Do
    ; Count revolutions
    If TURN_PIN <> turnWas Then
      turnWas = turnWas ^ 1
      If turnWas <> 0 Then
        turnCount = turnCount + 1
        changed   = 1
      End If
    End If
    ; Count tilts
    If TILT_PIN <> tiltWas Then
      tiltWas = tiltWas ^ 1
      If tiltWas <> 0 Then
        tiltCount = tiltCount + 1
        changed   = 1
      End If
    End If
    ; Report status
    If changed <> 0 Then
      SerTxd( "Turns = ", #turnCount, ", Tilts = ", #tiltCount, CR, LF )
      changed = 0
    End If
    Pause 20
  Loop
One thing to note is the consistent naming of things which relate to a particular aspect; "TURN_PIN", "turnCount" and "turnWas" for revolutions, "TILT_PIN", "tiltCount" and "tiltWas" for the tilt switch. That makes it easier for others to see what is being done. I chose "turn" because it's the same four letter length as "tilt" but it could be "rev" if you refer that.

Before running on the 14M2 you can run it through PE6 Simulation, click the pins for the revolution / turn microswitch input, the tilt switch input, to see that it is counting and doing what it should.
 

Rampz

Well-known member
One thing to note is the consistent naming of things which relate to a particular aspect; "TURN_PIN", "turnCount" and "turnWas" for revolutions, "TILT_PIN", "tiltCount" and "tiltWas" for the tilt switch. That makes it easier for others to see what is being done. I chose "turn" because it's the same four letter length as "tilt" but it could be "rev" if you refer that.

Before running on the 14M2 you can run it through PE6 Simulation, click the pins for the revolution / turn microswitch input, the tilt switch input, to see that it is counting and doing what it should.
Thank You hippy
I will alter my code later, after finding not much was working correctly, i came to the conclusion that it should be a stage at a time, being an electrician i am ok at the electronics part but fall over on code, its easy to copy and paste from previous projects, i find the PE6 Simulation difficult too, i have tried to use it but feel i get better feedback with seeing the errors in real life.

I did try and make the names in "symbols" mean what i wanted but didn't get them clear enough, i wanted people to be able to understand what i was doing or trying to do, needed some new eyes to clear it up, i tried laying the code out nicely and correctly to help, huge learning curve, thank you for providing code its the only way i learn, i see often people give ideas without code and while its great to get everybodies input, i'm trying, a month ago i could only get a few lines worked out on a new project, much to learn
 

David_Reynolds

Well-known member
Hippy! You some kind of computer program or a machine ?

I think I will go away and try to make my very fragmented and elongated program a little more like machine code
one of which is taking up way to much room 2000 out of 2048. Bye Rampz.
 

Rampz

Well-known member
Before running on the 14M2 you can run it through PE6 Simulation, click the pins for the revolution / turn microswitch input, the tilt switch input, to see that it is counting and doing what it should.
Hippy

I tried the code and ran in PE6 Simulation and it worked just fine, so i added the ability to setup the tilt switch and a manual way to start and stop the motor so i could try the code on the test rig and uploaded.

It counts TURN just fine, but since the tilt switch gets moved back and forth almost horizontally i seem to be getting several activations, regards the test of tilt switches the way i use them, i find every now and again they stop responding, so as long as between each increment of the TURN i get to see a TILT then i would consider it to be ok.

So either i need to increment the TILT counter just once even if a get a set of pulses or as above look for a minimum of one TILT for every TURN if that makes sense, i assume its not a good idea to put a huge debounce time in or i might miss TURN activations?

Code as it stands so you can see if i am doing something else crazy

Code:
#Picaxe 14M2
#No_Data
#Terminal 19200

Symbol TURN_PIN = pinC.4
Symbol TILT_PIN = pinB.3
Symbol START_TEST = PinB.5 ;added as test start button    
symbol INCH = PinC.2 ;added as a push button to manually rotate motor
symbol led = B.4 ;added to show what tilt switch is doing during setup
symbol MotorRelay = B.1 ;added motor relay so can test code on rig
Symbol Pressed = 1 ;added and used during setup
symbol Released = 0 ;added and used during setup

Symbol reserveW0 = w0 ; b1:b0
Symbol turnCount = w1 ; b3:b2
Symbol tiltCount = w2 ; b5:b4

Symbol turnWas   = b6
Symbol tiltWas   = b7
Symbol changed   = b8

Initialise:
  SetFreq M16
  turnCount = 0
  tiltCount = 0
  turnWas   = TURN_PIN
  tiltWas   = TILT_PIN
  changed   = 1

Setup: ;added to allow positioning of tilt switch on test rig

do
low MotorRelay
if TILT_PIN = pressed then 'if switch on then turn led on
    pause 400
      high led
endif
if TILT_PIN = released then 'if switched off then led off
      low led
endif
if INCH = pressed then 'if switch is on turn on motor to aligh switch under test
    pause 100
      high MotorRelay
endif
if INCH = released then 'if switch off stop motor
      low MotorRelay
endif
    loop until START_TEST = pressed 'if start button pressed exit loop an continue
      Pause 100 'debounce
high MotorRelay

MainLoop:
  Do
    ; Count revolutions
    If TURN_PIN <> turnWas Then
      turnWas = turnWas ^ 1
      If turnWas <> 0 Then
        turnCount = turnCount + 1
        changed   = 1
      End If
    End If
    ; Count tilts
    If TILT_PIN <> tiltWas Then
        pause 200 ;added because i think we were counting contact bounces
      tiltWas = tiltWas ^ 1
      If tiltWas <> 0 Then
        tiltCount = tiltCount + 1
        changed   = 1
      End If
    End If
    ; Report status
    If changed <> 0 Then
      SerTxd( "Turns = ", #turnCount, ", Tilts = ", #tiltCount, CR, LF )
      changed = 0
    End If
    Pause 20
    IF START_TEST = Pressed then ; Added to turn motor off
        pause 100 goto Initialise ;added as debounce for START_TEST push button
  endif
  Loop
As a thought it might be worth making the code stop the motor just after a TURN is detected so we always know where the motor is, meaning when ever the motor stops it stops in the same place, i have just tried that manually and then when i start the counting the TILT activation happens before the TURN, so i could start the TURN at 1 and if we can only count multiple TILTs between TURNs as 1 then could work well, what you think?

Ok i have just run the motor manually very slowly to see just the order of activations, if the motor can be stopped just after a TURN then following that, there is a TILT operation moving one way and then back again, while the TURN is detected the tilt switch (TILT) is stationary, so matybe check know the position of the motor at the start and then look for any amount of TILT activations and count it as one, then wait for a TURN and so on?
 
Last edited:

Rampz

Well-known member
Altered code further so that the setup: starts with the INCH switch to allow the setup of the tilt switch at the start - runs till the START_TEST button is pressed, the motor runs till TURN is actvated and stops breifly motor restarts and starts test, counting both TURN and TILT activations, when START_TEST is pressed a second time motor runs till TURN position is found and stops.

Maybe there is an easier way to do what i have added, just can't get rid of the additional TILTs its counting, just want 1 per TURN counting, for me the tiltswitch will have failed if between any 2 TURNs i don't get ant TILTs


Code:
#Picaxe 14M2
#No_Data
#Terminal 19200

Symbol TURN_PIN = pinC.4
Symbol TILT_PIN = pinB.3
Symbol START_TEST = PinB.5 ;added as test start button       
symbol INCH = PinC.2 ;added as a push button to manually rotate motor
symbol led = B.4 ;added to show what tilt switch is doing during setup
symbol MotorRelay = B.1 ;added motor relay so can test code on rig
Symbol Pressed = 1 ;added and used during setup
symbol Released = 0 ;added and used during setup

Symbol reserveW0 = w0 ; b1:b0
Symbol turnCount = w1 ; b3:b2
Symbol tiltCount = w2 ; b5:b4

Symbol turnWas   = b6
Symbol tiltWas   = b7
Symbol changed   = b8

Initialise:
  SetFreq M16
  turnCount = 0
  tiltCount = 0
  turnWas   = TURN_PIN
  tiltWas   = TILT_PIN
  changed   = 1

Setup: ;added to allow positioning of tilt switch on test rig
low MotorRelay
do
if TILT_PIN = pressed then 'if switch on then turn led on
    pause 400
      high led
endif
if TILT_PIN = released then 'if switched off then led off
      low led
endif
if INCH = pressed then 'if switch is on turn on motor to aligh switch under test
    pause 100
      high MotorRelay
endif
loop until START_TEST = pressed gosub motorstop1 'added to stop setup and start test
    pause 200
      high MotorRelay

MainLoop:
  Do
    ; Count revolutions
    If TURN_PIN <> turnWas Then
      turnWas = turnWas ^ 1
      If turnWas <> 0 Then
        turnCount = turnCount + 1
        changed   = 1
      End If
    End If
    ; Count tilts
    If TILT_PIN <> tiltWas Then
        pause 400 ;added because i think we were counting contact bounces
      tiltWas = tiltWas ^ 1
      If tiltWas <> 0 Then
        tiltCount = tiltCount + 1
        changed   = 1
      End If
    End If
    ; Report status
    If changed <> 0 Then
      SerTxd( "Turns = ", #turnCount, ", Tilts = ", #tiltCount, CR, LF )
      changed = 0
    End If
    Pause 20
    IF START_TEST = Pressed then gosub MOTORSTOP 'maybe GOSUB wasn't corectly used here
    'pause 100
  Loop

MOTORSTOP:
    pause 400; Added to turn motor off after testing
    do: loop until TURN_PIN = pressed
    pause 500
    low MotorRelay
    goto Initialise ;added to go back to start after test
  
MOTORSTOP1:
    pause 400; Added to turn motor off at start point and start test
    do: loop until TURN_PIN = pressed
    pause 500
    low MotorRelay
    pause 500
    return
 
Last edited:

hippy

Technical Support
Staff member
With the tilt switch mercury, or whatever it is these days, sloshing about in the switch, that does complicate things.

It does seem some kind of additional debouncing or lock-out would be needed. I'll have to think about that.
 

Rampz

Well-known member
It does seem some kind of additional debouncing or lock-out would be needed
Thanks Hippy

Just a thought to try and help, how about, since you are looking for the release of the switch in both cases and the motor now stops either on or just past the TURN switch.

Then firstly look for a count from the TILT pin and count +1 then go and wait for a TURN pin and count +1 then go wait for a TILT pin or a TURN pin and so on, the reason i say a TILT or a TURN is because at slow speeds as the tilt switches are used sometimes they don't activate when they should and i wanted to test for the switch's that aren't reliable, too many activations between TURNs isn't an issue, lack of any is the problem i need to know about

OR

I surpose in your current code from the TILT switch it can sub count as many as it gets and only +1 to the count at the point it gets a TURN pin ?

Thinking further maybe after the initial TILT = 0 is received the loop should sub loop waiting for the TURN and add 1 to each count then go back to waiting for either again, so it would still +1 for each TURN regardless of TILTs?
 
Last edited:

geezer88

Senior Member
I am late to the party, so this comment may be too late. But it may give you a head start on another project some day.

One of the useful features of the picaxe is the ability to control an RC servo.

It would be very quick and easy to mount the servo on your board, and make a simple fixture to hold the switch under test on the output shaft of the servo.

The program would be quite simple: instruct the servo to move, wait a little, check switch status, then move back, recheck switch, log and display status, repeat for desired number of cycles.

I don't know the details of your switch, but the servo can move in quite small increments. There are quite a variety of them, with ball bearing shafts, and a variety of power levels and speeds.

Best luck with your project!

tom
 

hippy

Technical Support
Staff member
at slow speeds as the tilt switches are used sometimes they don't activate when they should and i wanted to test for the switch's that aren't reliable, too many activations between TURNs isn't an issue, lack of any is the problem i need to know about
What is important, when it comes to programming, is to know what one is trying to achieve before deciding how best to implement it. If it is just a 'never activates, the liquid has turned to gunk' situation it might be possible to determine that without the complexities there appears to be.

I was assuming that it would be a rather simple test; when this way the contacts must be closed, when that way they must be open. That's not easy because there is no clear this way or that way, and there's a whole lot of in-between, and a lot more sloshing about than I had anticipated.. Thus there will be false positive and false negatives and we need to filter those out. But that's not easy to do because it's not simple to tell what is false and what isn't. Every algorithm I can think of seems to be prone to failure, quite difficult to implement, or impacted by some unknown or other.

I think we need to take a step back and define what a faulty switch is, what it's not doing which it should be doing, and from that we can consider how best to test for that.

And it may be easier to alter the test jig than try and solve things algorithmically. If two microswitches could be used; one positioned where the tilt switch must be closed, one where the switch must be open it could be comparatively easier to do.
 

Rampz

Well-known member
What is important, when it comes to programming, is to know what one is trying to achieve before deciding how best to implement it. If it is just a 'never activates, the liquid has turned to gunk' situation it might be possible to determine that without the complexities there appears to be.
Hippy yes i agree, when i started the project i understood from previous work with the tilt switches that they turn on and off and there maybe some contact bounce.

2 types of switches have been tried first type being mecury in a glass tube and the second type being a small ball in a steel tube.

I have learn't so far that the activation isn't very clean i am getting between 1 and 4 activations per cycle with the test rig

The mechanisim that the tilt switch is used on is an auto winding motor for a turret clock as used in churches, as the drum of the clock unwinds through time it triggers a tilt switch that drives a motor to provide tension against a spring, so spring becomes tentioned and the clock carries on telling the time, this repeats depending on the clock every 5-15mins, so the tilt switch gets tilted very very slowly

In normal operation the tilt switch will be off, will then slowly move till becoming on and then the motor will move the tilit back to the off position

On the current test rig the motor won't go slow enough to match the speed that a clock would be going at, but the test rig does operate the tilt switch in the same manner as the clock would in the backwards and forwards movement

The issue i have had previously was the tilt switch would function correctly for a week or so, then for some reason it just stops, when going the the drive a flicking the tilt switch it would correct itself just as if it hadn't activated the tilt switch correctly

So i wanted to try and test tilt switches before use, i can see if we can redesign the test rig to give a turn indicator before and after the expected tilt movement and make the movement a lot slower, because although the tilt switch gets triggered very very slowly, once the motor is triggered for about half a second it moves back again at some speed and stop and very very slowly tilt again

For such a simple concept of a switch opening and closing and counting that it's quite involved, i have to test the switch just as they are being used, this style has been used for several years on turret clocks and has always been a problem in various ways, i am trying to sort the mess out and get to the bottom of the problems in my spare time, the one shot timer that the tilt switch is connected to normally is 555 based, my first ever project on the forum was to replace that time with a picaxe 08m2

At the moment with the test rig project where it is and how it is, what i am wanting from it is a count of the times that there isn't a TILT signal between any 2 TURN signals rather than anything else based on what i now know of how the tilt switch operates, so count TURNs as it does and look for missed TILTs and count the misses? Does that help Hippy?

Rampz
 
Last edited:

Buzby

Senior Member
You say the tilt-switch switches a motor to rewind the clock, and ther tilt-switch fails after a few weeks.

I would suspect something is happening to the tilt-switch, not the tilt-switch going erratic for no reason.

What is the voltage and current for the motor ?

Is there arcing in the tilt-switch, thus damaging the internal contacts ?.

Is there a snubbing capacitor across the tilt-switch ?
 

Rampz

Well-known member
You say the tilt-switch switches a motor to rewind the clock, and ther tilt-switch fails after a few weeks.

I would suspect something is happening to the tilt-switch, not the tilt-switch going erratic for no reason.

What is the voltage and current for the motor ?

Is there arcing in the tilt-switch, thus damaging the internal contacts ?.

Is there a snubbing capacitor across the tilt-switch ?
Hello Buzby

The tilt switch activates currently a NE555 timer setup as one shot, this in turn triggers a N-channel mosfet rated at 60A, the motor has a diode across it for back emf, the motor is 12v DC fed from a contiuosly charged charged 12v 10Ah lead acid battery, the charger is a commercial version suitable for the battery being used, generally the system works fine across many clocks over the last 15 years, but there are issues as i said above.

I can't see there will be any arcing from tilt switch with it wired as the trigger to a 555 timer, voltage will be within limits.

The The one shot timer setup allows for contact bounce upto 400ms

I'm into electronics much more than my ability to code anything, the original design a couple of years ago used a hall effect switch and a magnetic ball but they used to stick also, so the design was changed to tilt switches and a snubber network that tended to weld the ball we think, this then connected to a n-channel mosfet, when i became involved in the project i removed the snubber network and replaced with a NE555 timer and that made everything run better, but stiil getting the issues the test rig was supposed to help find.

Thanks for your input, any other ideas?
 

Buzby

Senior Member
OK, that looks like it is not an arcing problem, so what else can it be :unsure: ?

I've seen mercury tilt-switches used in machines that have run for years, with millions of switch operations no problem.

I don't know so much about the 'ball-in-tube' type, but assume they are hermetically sealed, so should be just as reliable electrically.

However, 'ball-in-tube' types I have played with did need to move through a bigger angle to 'make' reliable contact.

Looking at a datasheet ( e.g. https://docs.rs-online.com/2893/0900766b80027e13.pdf ) shows that the switch must exceed +15' and -15' from horizontal, i.e. 15' both up and down, to ensure operation.

Does your switch in the clock move at least this much, or whatever spec your switch has ?.

My gut feeling is that testing the switches 'out of environment' is not going to help much in solving your problem

Cheers,

Buzby
 

Rampz

Well-known member
I don't know so much about the 'ball-in-tube' type, but assume they are hermetically sealed, so should be just as reliable electrically.
Hello Buzby

The switch mentioned at this point was a part machined by the builder of the drive unit, a tube effect with a ball that moved and a hall effect sensor all in a hard plastic material, they weren't too successful i understand and after some years moved to modern type tilt switches, the ones used are 7.5 degrees versions i think bought from RS Components so should be of decent quality, i have raised my concern with the builder that the tilt switch might not be used as it was designed, i would expect a tilting over a fixed axis not a sloshing effect with tilt built-in so 3D movement

Attached is a pic of the drive units in question you will see a small circular disc about 20mm thick with a wire coming out of it this is the tilt switch location and a second pic showing multiple unit on a larger turret clock, so you can get an idea how they move
 

Attachments

Buzby

Senior Member
Hmm ?.

A steel ball and a Hall effect device sounds bullet proof electronically, but if the tube is not hermetically sealed it could fill with all kinds of crap.

I'm not sure what you mean by "a sloshing effect with tilt built-in so 3D movement", but it doesn't sound good !.

It is essential that the tilt switch moves in the plane as described in the datasheet.

( Some mercury tilt-switches used a tube with a bend. The middle of the tube was higher than the ends, so as the tube tilted the mercury 'snapped' over the hump, giving a clean make/break. These only worked properly if the tilt was around one specific axis only. )

Do you have the RS part number, or the device part number, for the tilt-switches you are using ?

Cheers,

Buzby
 

Rampz

Well-known member
I'm not sure what you mean by "a sloshing effect with tilt built-in so 3D movement", but it doesn't sound good !.
From the picture you may gather that the tilt switch moves through an arc rather than falling over on a fixed axis, so it moves through the arc very very slowly as the winding drum unwinds and the clock works, at some point the motor is activated by the tilt switch and the motor drives more rapidly against the springs seen in the pics for 500ms max and allows the clock to carry on telling them time, this setup replaces a huge weight that is weekly wound up by a human, like i said i raised my concerns that the tilt switch isn't being used as i would expect for a tilt switch if you know what i mean, alternatively i need to find an alternative way to trigger the motor when the unit has moved an amount of degrees and it needs to be really reliable.

I will get hold of the RS number later
 

hippy

Technical Support
Staff member
Does that help Hippy?
Certainly does, and the rest. Thanks.

I am also mystified as to what the failure mode would be.

I don't know enough about tilt switch mechanics to have any idea how they would operate at very slow speeds. It sounds like a viscosity problem or surface tension or just friction holding things back, the flick which frees things up breaking whatever bond is holding it back.

The two failure modes I can think of are, as above, not making the connection, or making the connection but that not being noticed by the electronics, the flick breaking then re-making the connections, the re-making it kicking it back to life.

I'm thinking 'bath of water' where the bath isn't being tilted enough to clear one end, always leaving a connection between the ends. For mercury that probably starts out as ball but if left to sit perhaps becomes a pool.

Next time one fails it would be worth checking if it has failed open or closed.

Perhaps a small solenoid which can give the switch a regular tap could be a solution ?

I think the proper solution is to solve the core problem, am also not convinced that testing would ensure no failures when installed. Developing an accurate test could be a lot of effort which ultimately achieves nothing. I am also wondering if the test you have should be reversed, based on detecting tilts and how many turns there have been for those. It would be easier to debounce tilt activations while still counting turns.

It could be you are on a hiding to nowhere with tilt switches and may be better off with some other 'end of travel detection'. End-stop microswitches and a flexible stick which pushes against those might be possible. Similar using reed relays, hall switches, optical break sensors, or even a coupled rotary pot.
 

Rampz

Well-known member
I don't know enough about tilt switch mechanics to have any idea how they would operate at very slow speeds. It sounds like a viscosity problem or surface tension or just friction holding things back, the flick which frees things up breaking whatever bond is holding it back.
Hippy we are both thinking along the same lines regards either the problem or the solution.

I need the solution to work for about a week should the mains fail and its on battery, so the move to a 08m2 will help with the running electronics since 3x 555 timers were drawing 34ma and that should drop to maybe 3ma max with PICaxe, so need to be careful adding additional say solenoid or similar.

Checking if open or short when it fails is quite hard since the slightest tap and its working again.

I am aware that even with testing, failures can still happen, the builder was clutching at straws with the test rig and through building it we can see that the problem is more complicated than first thought, your code did work much better than mine, i did include a small debounce time for the TURN, i have said to the builder that it may be better to make a test rig that worked along the actual clock style as being a more reliable way to test but like you say maybe still pointless in the long run.

Maybe something along the lines of a rotary encoder to measure degrees of turn against a ground fixed reference, so maybe pulses would be counted from a reliable source, i need to look into them and see what could be used, anything you have come across? I can't fix anything to the clock mech due to historic reasons, the church don't allow anything like this

Or maybe something optical along the lines of a slotted optocoupler and a disc with holes in held from the ground detecting the movement of the motor unit as the clock unwinds
 
Last edited:

PhilHornby

Senior Member
Could you just use a simple timer to determine when the clock needs rewinding? ... perhaps with some stall detection on the motor, so it's always wound to its maximum?
 

Rampz

Well-known member
Could you just use a simple timer to determine when the clock needs rewinding? ... perhaps with some stall detection on the motor, so it's always wound to its maximum?
Interesting idea, but since the clocks are left unattended for many months, need to be really careful that no damage can occur from over winding or a motor unit crashing into part of the clock mech, its felt its better to provide a short drive pulse of the motor every time the winding drum rotates a set angle, along with every clock being different from many different clock builders over a few hundred years, i need a reliable way to detect the need and action it, the drive units aren't my design i am just using my spare time to try and make them more reliable.

RS part number 235-7623 for the tilt switch used
 
Last edited:

rq3

Senior Member
Interesting idea, but since the clocks are left unattended for many months, need to be really careful that no damage can occur from over winding or a motor unit crashing into part of the clock mech, its felt its better to provide a short drive pulse of the motor every time the winding drum rotates a set angle, along with every clock being different from many different clock builders over a few hundred years, i need a reliable way to detect the need and action it, the drive units aren't my design i am just using my spare time to try and make them more reliable.
Usually the first dictum when dealing with antique mechanisms is "first, do no harm"; i.e., make no modifications that cannot be completely and invisibly undone.

In the case of a large weight driven clock, I would use two optical triggers. One to detect when the weight has descended far enough to require rewinding. The second to detect when the weight has been re-wound (raised) enough. Neither of these would require any physical contact with the clock. You could set the spacing between the optical triggers for anything between a full re-wind (say every week), to fractions of an inch, to rewind every few minutes or so.

I would re-wind with a stepper motor or other device that can be harmlessly stalled indefinitely, on the off chance that the re-wind motor didn't get the "stop re-winding" signal.

The only down-side to this setup is if the controller/motor power supply went dead, in which case the clock would run until it couldn't, and you'd have to re-wind it by hand. But no harm done.
 

Rampz

Well-known member
Usually the first dictum when dealing with antique mechanisms is "first, do no harm"; i.e., make no modifications that cannot be completely and invisibly undone.
Exactly the issue I'm working with, the church allow the weights to be removed and the auto winding setup as shown in the pics replaces that, all connnections to the winding point on the clock are by steel set screws with special brass tips to not mark the shafts nothing else in any position can be connected to the clock or its winding drums.
The motors used currently are window wiper motors from manufacturer in Spain, very high torque low speed, I have a picaxe set up ready for this that was developed with much help from forum members by which if the motor doesn't turn off after a few seconds the motor times out, the clock mech isn't required to be fully wound up and consistent tention on the drum against a spring for stored energy is enough
 

Rampz

Well-known member
I have just found GMR angle sensors they are integrated circuits used in automotive applications run on 3.3-5v and seem to be programmable and could possibly be used with a picaxe, anyone come cross them? The data sheet I found was 40+ pages
 

hippy

Technical Support
Staff member
Not heard of GMR but the one I looked at seemed suitable for use with a PICAXE. I would be more concerned as to whether or not they are suitable for this application. They seem to be angular compasses rather than tilt, pitch or yaw, sensors.

Some sort of gyro or accelerometer chip could do the job, and you probably don't have to worry about converting whatever the data is to human understandable angles, can likely get away with whether a raw value is on the right side of this way and that way.

Thanks for the RS reference for the sensor. Looking at the photos it seems to me the tilt switch is perhaps sitting almost horizontal at one extreme. The data sheet indicates +/-10 degree for guaranteed on-off operation, so it could be it is simply not getting that, is ending up in an indeterminate position. That could explain the problems.
 

rq3

Senior Member
I have just found GMR angle sensors they are integrated circuits used in automotive applications run on 3.3-5v and seem to be programmable and could possibly be used with a picaxe, anyone come cross them? The data sheet I found was 40+ pages
I have been using these for a decade in a commercial product with a Picaxe 20M2.

The analog output feeds an AD input on the picaxe, and they both run from the same 5 volt supply. This makes the result ratiometric, with a resolution of about 0.3 degrees even if the supply voltage drifts with age, temperature, and load.
 
Top