Code quirk or bad wiring?

StephenMoore · 2012-07-14 12:16

This is one for the "stop bugging me file".

Without the waitcnt instruction the x-y table fails to make it to the limit switch. Any ideas... anyone?

PRI homeMotor(motorNum) | switchNum


  case motorNum
    0:
     switchNum := xHOM     
    1:
     switchNum := yHOM      
    
  reverseMotor(motorNum)
  onMotor(motorNum)




'  waitpeq(0, 1<< switchNum, 0)          ' I would like to use this intrsuction but it fails to reach the switch




       repeat while (ina[switchNum] == 1)


           waitcnt(clkfreq/100+cnt)




  offMotor(motorNum)
  
  case motorNum
   0:      
    long[@xworld] := long[@xoffset] := 0
   1:        
    long[@yworld] := long[@yoffset] := 0

msrobots · 2012-07-14 14:44

why 1<< switchNum ?

do you meant |<switchNum ?

what exactly IS switchnum ? Pinnumber or mask?

Enjoy!

Mike

Phil Pilgrim (PhiPi) · 2012-07-14 15:27

msrobots wrote:

why 1<< switchNum ? do you meant |<switchNum ?

They're equivalent. BTW, since his repeat while loop worked, I assume that switchNum is a pin number.

-Phil

Ariba · 2012-07-14 16:55

StephenMoore wrote: »

Without the waitcnt instruction the x-y table fails to make it to the limit switch. Any ideas... anyone?

I would say you have some short spikes on your switch input, which are detected by the watpeq but not by the repeat loop.
Waitpeq detects a change on the input down to 12.5ns, while your repeat loop only tests every 10ms. So there is a big chance that a short pulse is not stopping the motor.

Andy

prof_braino · 2012-07-14 17:38

So is this something for switch debouncing?

frank freedman · 2012-07-14 18:00

Phil Pilgrim (PhiPi) wrote: »

They're equivalent. BTW, since his repeat while loop worked, I assume that switchNum is a pin number.

-Phil

I have not had time to test this idea yet, but ........

I wonder if they are completely interchangeable. The |< bitwise decode is an assignment operator when used as shown (per the reputedly poor and much maligned ;<) prop manual) and the value is available to the waitpeq instruction, while I am not so sure that the 1<<variable statement is actually storing the result as in normal operation, the normal use of << does not cause any storage of the values unless it has the form <<= or newvar := oldvar << count

Ariba · 2012-07-14 18:24

prof_braino wrote: »

So is this something for switch debouncing?

Yes I think so. Only that its not bouncing of contacts but some spike inductions from the motors.

First I would try to route the switch cable differently, not next to the Motors or the motor cables.
Then perhaps lower the pullup resistor of the switch, and perhaps even add a capacitor.
If this not helps, make a debouncing in software like this:

repeat
      waitpeq(0, 1<<switchNum, 0)   'wait for pin low
      waitcnt(clkfreq/200+cnt)      'wait 5ms
   until ina[switchNum] == 0        'pin still low? otherwise repeat

This checks the state of the switch a second time after a short delay, to be sure the switch really is closed. You need to play a bit with the delay time.

Andy

StephenMoore · 2012-07-14 18:50

Sorry, xHOM, yHOM are mechanical contact limit switches with 10k ohm pull-up resistors on pins 22 and 21 respectively.

The onMotor and offMotor turn on pin outputs. As does reverseMotor. No funny business with other cogs accessing these pins either.

Using waitpeq the x-y table never even comes close to the limit switch (even with the bitwise decode |<). Works great with the waitcnt when the delay is no less than 1 msec..

When I get a chance I'll put the pin inputs on an o-scope but a volt meter shows a stable high until the switch is made.

Strange...

I appreciate your help very much.

frank freedman · 2012-07-14 19:32

Sorry, thought for some reason waitpeq may have prevented motor from being on long enough to move....

But, what happens under 1ms in the loop method? Also, what will it do if you put a couple ms delay ahead of the waitpeq instruction?

Really odd behavior, but the waitxxx gave me a few fits in my ADC timing objects for a parallel ADC capture system in pasm, not the simplest instruction in either language.

FF

Phil Pilgrim (PhiPi) · 2012-07-14 19:56

Put a short waitcnt after the waitpeq, and see what happens.

BTW, in cases like this, it's often helpful to post your entire program.

-Phil

StephenMoore · 2012-07-14 22:01

The whole program is rather large and, since I am not a powerhouse programmer, not always straight forward.

Of note though Phil, I have used some code you wrote a little while back for jitter free clocks (thank you again). This is the second use I've made of it. In this instance the counter modules are simply driving the stepper pulse pins.

Attached is the whole program.

What the application does (it is not quite finished) is map the shape of a magnetic field with multiple compass modules. It uses the x-y table to allow me to map a 6" x 5" region around a magnetic pole.

Thank you for your help,

sm

Mark_T · 2012-07-15 08:05

StephenMoore wrote: »

Sorry, xHOM, yHOM are mechanical contact limit switches with 10k ohm pull-up resistors on pins 22 and 21 respectively.

Change pull-ups to 1k and add 1nF ceramic caps between those pins and ground, you don't want to see crosstalk spikes on those signal lines. The wiring to the switches should be twisted pairs with the ground wire grounded only the Prop end - loses any ground loops and reduces pick-up.

cavelamb · 2012-07-15 14:23

prof_braino wrote: »

So is this something for switch debouncing?

Sounds like it.

Saw a bumper sticker last week...
"Every generation has to learn for itself that the stove is hot"

Mark_T · 2012-07-15 18:47

A switch can't bounce till its operated - this code starts the motor going and waits for the switch to make contact - at which point it halts. The contacts can bounce after that but they can't bounce until then - whereas a high impedance input wire is a prime candidate for picking up interference near motors and motor wiring.

Code quirk or bad wiring?

Comments