The worst programmer ever to grace this forum - ME!

[Archangel]

Joe... re the counter/variable melarkey - remember, I'm very new to this. I've almost certainly done a tutorial somewhwere & simply applied what I learnt there to my program! (I haven't a lot of time to dedicate to being a<b> slick programmer</b>, so I just throw into the program the little bit that I know!). Could you be so kind as to outline the tighter code for that little increment you've honed in on as being a bit 'first lesson at PICBASIC evening class'!). BTW ...I use this magnet/switch 'count' to derive when to send a pulse to a stepper. This stepper I'm sending the pulse to, moves in synchronicity with the main motor, back & forward (the idea being to neatly feed coppoer wire on to the main turning motor). It's really cool on the odd (seemingly fluke) times I've had it working!

<b>HA HA HA, ME EITHER !</b> I wrote a Tachometer program, using count, look it over as an exemplar of using count. The code is in post #9. http://www.picbasic.co.uk/forum/showthread.php?t=9037

Now my head still spins at the thought of building in the debounce aspect, so
with these 'knowns' I have, which would be the best approach to ensure an accurate switch 'closing' count?


(BTW, I'm thinking now that maybe an optical pickup would be a much better solution, as this removes the debounce aspect & I can have more resolution -I will look into this, but for now I'd really like to get the cheap 'n dirty solution working!)

Optical can be cheap and reliable, magnetic is good too, thinking hall effect switch. Do you really need 36 degree resolution (10 magnets)? Using an interrupt might be your solution to all this. I do not think I would use a magneto mechanical (reed) switch as a pickup, but using a hall effect would free you of all that debounce nonsense. Sam used my code with 1 magnet for his Tach. and says it works well. As for optical, tear open an old mouse and you will find a PIC and 2 optical pickups using shutter wheels. People use printed encoders for tabletop robots all the time. A coil of wire, magnets, and a comparator input will work too, that is what works most auto ignitions, in fact I used an old car distributor while working out my tach. code. A 555 timer can be used as a wave shaper if you are not ready to try comparators yet.

[Bruce]

Joes' idea for the hall effect sensor would be the way to go. Then you could simplify the
whole thing with a timer configured to count external pulses. Preload the timer to over
flow after 500 ticks, and have an interrupt flip the port pin to kill the motor.

The timer counts in the background, so you can have all sorts of other things happening,
code wise in the meantime. And with zero code for counting pulses.

If you prefer to sit & spin in a loop until killing the motor, you could just monitor the timer
overflow bit, and not use any interrupts.

[HankMcSpank]

Alas, my existing switch setup is a simple reed switch (so I have to debounce).

I've done some googling today & think that optical is the way to go. I'll probably use this guys implementation - a CD with some black stripes drawn on it!

http://www.vk2zay.net/article/29

http://www.vk2zay.net/article/28

(but perhaps having it feed into a monostable to clean those pulses up a bit)

Firstly, it appeals to the cheapskate in me, but more importantly, I can get even finer resolution - surprisingly 36 degree resolution isn't really sufficient...I'd much rather have 10 degrees or less

Totally off topic, but here's the maths.

Let's I'm feeding 0.15mm wire onto the main motor (actually the main motor holds a steel rod in jaws, upon which the copper wire feeds onto forming a coil)

So, for every turn of the main motor, I need the stepper motor (feeding the wire onto it), to traverse by 0.15mm.

My stepper is a 7.5 deg motor (meaning it takes 48 pulses to get it to turn one full revolution). I've placed some M8 threaded rod over the stepper shaft (this has a pitch of 1.5mm)....it is via this thread that I wrap the copper wire around feeding onto the main motor, if you can't visualize this...have a look here for a similar setup about 23 seconds in...he's using *much* chunkier wire, mine is more akin to thick hair).

Therefore for every full turn of the stepper (48 pulses) the wire moves 1.5mm (this being the thread pitch). But I *need* it to move just 0.15mm for every turn of the main motor. So to get the stepper to move the wire just 0.15mm, I need to send 4.8 pulses to the stepper for every turn of the main motor - obviously, I can't send 0.8 of a pulse to the stepper! Therefore if I had more tach resolution, I'd avoid such 'rounding' errors (or as I'm doing now, having to add in extra pulses every so often to make up for the shortfall)

[Archangel]

Hi Hank,
48 steps per rev, wow most steppers are 200 steps per rev. Saw the video. 1 Q & D way to get resolution in accurate form, Order from your local speed shop a degree wheel for setting cam timing, has 360 degrees embossed on an 8 inch aluminum disc. you can drill holes at exact spacing or use it as a protractor to make other discs.

[HankMcSpank]

Hi Joe,

Thanks for the top tip re the disc (I'll ponder that one!)

Re my program....well I got it working last night, here's what I did...

(Note as you read below, you need to know the incoming magnetoic switch is connected to PORTB.7 & the default condition is High...when the switch is closed it goes low)

Main:
If portb.7 = 0 then 'if low, then a magnet's leading edge has just past the switch
mag_start = 1 ' therefore set a variable condition to reflect this
Pause 3 ' pause a little to ensure we don't check the switch while it's bouncing
goto next1 ' if we have the mag leading edge, go to the next bit
endif
goto main ' keep looping until we do get a leading edge

next1:
If portb.7 = 1 then ''if high, then a magnet's trailing edge has just past the switch
mag_end = 1 ' therefore set a variable condition to reflect this
endif
If mag_start = 1 and mag_end = 1 then ' if both conditions are met, then we've just had one magnet pass
Goto one_magnet_passed
endif

one_magnet_passed:
mag_start = 0 'reset this puppy, ready for next time
mag_end = 0 ' ditto
Num_Mags = Num_Mags + 1 ' count number of magnets that have passed
if Num_Mags > 9 then one_rev ' counted at least ten magnets so one revolution has occured, so go do 'stuff'

one_rev:
Num_Mags = 0
pulsout PortC.0, 10 ; pulse the stepper

blah, blah.

The benefit of doing it in the above manner (I'm sure there are better ways, but hey...it works for me!), is that it'll work at virtual 'stop' speed, right on up to about 400RPM.

I went all low tech & taped a lump to the edge of the motor, so I could feel/count revs with my finger as the lump passed. I also used debug to put the rev count onscreen to make sure it concurred with my manual count - it was bang on.


Many thanks for all your help!



PS Joe, yes, 7.5deg steppers are somewhat unusual, it was a 'form feed' motor taken out of an old dot matrix printer...it's actually ideal for this job...I doubt I'll ever need more than 48 steps resolution per RPM for the wire types I'm winding. It's also a very light motor, therefore draws little power & is virtually silent. If I get a moment I'll post up a youtube video of what my setup is (warning - it's very kludgy. & lo-tech & ugly...but it does the job!)

[HankMcSpank]

Hi - me again!

Ok, I think I mentioned that I was going to bin my 'magnets & reed switch'...in favour of an optical pickup (I needed more 'resolution' & less debouncing) - well, I have all the pieces in place now...so why am I back?

well, I need help wrt how I can be sure to ascertain that my circuit (& program) is actually picking up all the pulses fine. And with a motor turning at between 300 & 400RPM, and 48 stripes per revolution...I lose count when doing this manually!

Here's the circuit I've implemented.... http://hans-w.com/RPM.gif (I should point out that Im not using the same PIC - I'm using a 16F690 - nor his hex code...as I need to be able to customize the program)

Re the tach pickup itself - on the edge of my turning motor is a phototransistor aimed at a round disc with 48 lines on it (essentially a pie chart knocked up in Excel, printed onto a CD label & then onto an old CD!!) ...as each one of these lines passes the phototransistor, a pulse ultimately appears at a PIC input pin.

It seems to be working reasonably well *but* I have a sneaking suspiscion, that either the electronics is not setup right (there's a preset in that schematic that needs setting optimally - I have a scope, but at 48 pulses per rev running at 400RPM, the trace is too jittery to set the levels in this manner).

What I'd like to know, is the best way to establish that *all* 48 stripes are being 'seen' by the PIC and everyrevolution (not just for one revolution, but say over 400 revolutions).

I'm figuring it'll need some form of counter, with the methodology being something along these lines (this is a labourious method!)....

Start counter
Pulse 1 arrives - output this info to screen along with counter time (I'm using the Pickit2 Uart tool to debug)
Pulse 2 arrives - output this data to screen along with counter time.

I can then cut/paste the above into Excel, do a bit of simple maths (ie subtract each 'counter time' from the previous, which will yield the time taken beteween successive pulses) & ultimately put this into a bar chart. All being well my bar chart should have bars of equal height from left to right.

Since the above method seems a bit long winded, I'm sure there must me a slicker way in real time, for example...

Start counter
Pulse 1 arrives - note the time in variable1
pulse 2 arrives - note the time in variable2
Subtract variable 1 from variable 2 (to give the time between pulses) - place into variable 3

then continue in a similar vein?

The clever bit would be to have a calculation that goes along the lines of "If the time between successive pulses is greater than say 90%, then we must have missed a pulse - output this info to screen via the Pickit Uart tool.

Does this sound plausible?

Could anyone help me out with a little bit of code to get me started please?(I've never dealt with counters previously!)

[HankMcSpank]

Ok...first sign of madness is talking to yourself - I must be totally barking.

Tonight, I knocked up an encoder wheel & used DT's interupt utility to assist the PIC in cleanly counting the 96 black stripes ...using interupts vs polling is a great success (ie I reckon all the black lines are being counted now).

But I've a new problem!

Previously, I have been using the Microchip Uart tool to output the number of encoder revs counted by the PIC onto my PC screen (essentially I just output a dedicated variable that increments after every 96 black stripes have been counted).

Up until now, everything was fine - could see my info onscreen quite fine.

My problem now is that becuase the black stripe interupts are running every 2ms (this number being based on a speed of 300RPM - which equates to 5 revs per second... therefore 200ms divided by 96 'black stripes' = 2.08ms between interupts) ...my onscreen info has become truncated/garbled. If I slow the wheel speed right down to say about 30RPM...it's fine....I can read my revs on my PC screen again.

this suggests that the interupts are interfering with the serial comms/Debug/Uart signal flow. (this is a little puzzling as I had thought the whole point of interupts was to be non disruptive in the sense they tuck everything away before heading off to do the interupt routine, & then pick up where they left off by 'restoring things as they were' after the routine?)

Does anyone have a cunning plan to allow me to get my simple onscreen Debug info back - I only need to see one small bit of info...this being the total rev count in pseudo real time onscreen. (I'm happy to consider alternatives too?!)