Rotary encoder usage

[alistairsam]

will it be any faster if I use external discrete counters to store 8 or 16 bit values and then the picaxe just reads those bits?
I could interface this detector to a discrete counter and that way the picaxe would only need to read the bits and display.
but the read and display refresh would be at the rate at which pulses arrive.

 

[Jeremy Leach]

Well I think you're making great progress in thinking it all through. There's a lot to consider.

I can't guess on the execution speed I'm afraid and of course it depends upon the clock speed of the PICAXE. However it's not too hard to measure:

All you need to do is to make the code output a signal on one of it's output pins, that is synchonised to the code loop you are trying to measure. So that's why I said to get my code to output 255 and 0. If you start inserting other lines of code to get this output then you're clouding the issue and won't get an accurate time.

Once you've forced the code to generate an output waveform you then either measure the width of the pulses or count them over a longish period of time. If you happen to have an oscilloscope then you can immediately measure the pulse width which is handy. If you don't then another PICAXE can come to the rescue: You can either use the Pulsin command to read the incoming pulse width, or you can use the Count command to count the pulses. I'd go for the count command because it would give more accurate results.

You could use SerTxd in my code. I was trying to think of the fastest way of outputting the count value and although it's a bit messy, I think my parallel idea might be a lot quicker than SerTxd. Reading the parallel valuefrom another 'Master' PICAXE is a bit of a challenge, but I 'think' it could be done fairly easily.

I personally think you need a separate Master PICAXE to handle your display to LED. This could be in a loop: Read counter value from Slave, Update 7-seg LED displays.

Keep up the good work

 

[Jeremy Leach]

The discrete counter idea is good - although it depends on what chips are out there.

In theory, you could have the chip that outputs tacho and direction feeding directly into an up/down counter IC. Sometimes these counters have an internal register where you can latch the current counter value then read the value out serially. I hunted for one to do all this (ie combining both into one) a while ago and didn't come up with anything.

Whichever way you do it the theory is the same: Have a separate 'black box' that reads the values and updates a counter value. Then a master can interrogate this 'slave' and get the counter value when it needs it.

 

[alistairsam]

Hi
I know and have used the CD4060 counters which have 8 bits as binary output and 1 clock input. they can be cascaded to go as many bits as we want, so thats fairly easy.
issue is that I don't think these counters decrement. they only have a reset. so that idea may not work.

when you say the master queries the slave when needed, it will be basically whenever there is a pulse or a state change, so they have to be sync'd.

I think there are LCD modules that accept BCD, so if I could update say 4 pins in binary, that would display the decimal value on the LCD, just guessing.

no issues with using more than one picaxe or discretes, so will keep my options open.

I'm getting the detectors tomorrow hopefully so I can test that as well
will post first results tonight

I do have an digital oscilloscope, not the professional ones, but the LCD one. that can measure frequency quite accurately.

what would you suggest to do a timing test, just toggle pins high and low, or use pulsout or any other command?
I could then measure the maximum frequency and get an idea of how many times it goes through the loop per second.

 

[Jeremy Leach]

the master queries the slave when needed, it will be basically whenever there is a pulse or a state change, so they have to be sync'd.

This is the bit I don't understand with your design: Why would the Master need to know the counter value all the time? If you are just displaying the value then this isn't true - you just need an update at whatever refresh rate you use for your display.

For instance, you might decide to update your display twice a second. So every 500ms the Master would get the counter value, then refresh the display.

In the code I gave, it outputs the CounterMSB and CounterLSB values separately each time round the loop. So if you force these values to be 0 and 255 rspectively, then you'll get a square wave output. This would be ideal for measuring.

[FONT=Courier New]     <-Loop Period ->[/FONT]
[FONT=Courier New]     .-------.       .-------.[/FONT]
[FONT=Courier New]     |       |       |       |[/FONT]
[FONT=Courier New]     |       |       |       |[/FONT]
[FONT=Courier New]-----'       '-------'       '------[/FONT]

The way I've got my code, each loop actually reads two values, so the time it takes to read one value will be half the Loop period.

 

[alistairsam]

found some posts where they've done some timing tests with an 08M.
~250us per component or ~512us per command line is what they've arrived at.
page 99 of manual 1 mentions

post #6 in this thread http://www.picaxeforum.co.uk/showthread.php?t=13001&highlight=execution+time&page=2

just noticed that only the 28X2 3V model supports an external 16MHz resonator. have to think that through as most of the logic signals are 5V. have never worked with TTL levels.
else will have to use a 20X2 with the internal resonator at 64MHz or the 28X2 with an external 10MHz(40MHzinternal)

Page 99 of manual 1 states "the microcontroller processes 1 million assembler commands a second, which equates to roughly about 1000 BASIC commands per second." this is at 4MHz.

 

[alistairsam]

This is the bit I don't understand with your design: Why would the Master need to know the counter value all the time? If you are just displaying the value then this isn't true - you just need an update at whatever refresh rate you use for your display.

first of all, I don't know much about displays, so did'nt know that it has a seperate refresh rate.
But I'm not sure If I can use a constant refresh rate. that might not display changes in arcseconds as the pulses could come in faster than the refresh rate.
Thats why I thought it'd be better to output the counter value in every loop of the code, that way the refresh would be however fast the picaxe can output data serially.
I don't know how fast displays refresh, but unless they're comparable to the picaxe execution times or even faster, I might have to adopt updating display in the loop

 

[Jeremy Leach]

I know, but these are only VERY rough guides. It's not difficult to do this timing.

Symbol EncoderValue  = b0 
Symbol Direction   = b1
Symbol Counter   = w1
Symbol CounterLSB  = b2
Symbol CounterMSB  = b3
Do
 'Calculate new Count value and transmit CounterLSB to Master
 EncoderValue = pins
 Read EncoderValue,Direction
 Counter = Counter + Direction - 1
 pins = 0 '******<<<TEST VALUE FOR TIMING
 
 'Calculate new Count value and transmit CounterMSB to Master
 EncoderValue = pins
 Read EncoderValue,Direction
 Counter = Counter + Direction - 1
 pins = 255 '******<<<TEST VALUE FOR TIMING
Loop

 

[alistairsam]

will measure the frequency of your last code with my scope and post results.
I have a 14M and a 28X2 with an external 8MHz resonator, will try both to compare.

 

[Jeremy Leach]

Ah, well regarding displays, it all depends what you go for. You mentioned LED because of the light levels and I understand that.

I was thinking along the lines of a set of 7-segment LEDs. There's a lot of info in the manuals about how to use these and they are very good. Although they are admittedly more difficult to use than the ready-made serial LCD displays.

If you use 7-seg LED displays then you will need a subroutine of code (perhaps quite a lot of code) to get values to display to degrees/minutes/seconds. YOU determine whatever refresh rate you need, because you make your code run this 'RefreshDisplay' subroutine at whatever rate you think is suitable.

An update of twice a second might be reasonable, or could go a bit quicker perhaps. However there's no point in going much quicker because you won't visually be able to register the differences in the values.

Does this help at all?

 

[hippy]

Following on for Jeremy's 'discrete counter' idea; that's the way you will probably have to go anyway, whether using logic counters or a PICAXE. While the PICAXE may be able to keep up with a certain rate of change of the encoder within its basic loop, as soon as you need to output data there's a chance that it will miss changes while engaged in outputting.

If you use SEROUT at 4800 baud to display the determined count you'll likely have a 15ms period or so while readable data is being output with all encoder changes being ignored during that time.

The counting PICAXE needs to have a fast way of outputting the count which something else can interpret and display while it get backs to counting. The fastest is just to put the count on the output pins. You will effectively be using a PICAXE as a logic counter, except it won't be capable of responding as fast.

Think of it like counting people entering an event. The person on the gate who is counting will shout to someone else how many so far when asked then keep counting. That someone else will update a chalkboard showing how many have gone in even while counting keeps happening and changing. If the person counting has to go and write on the chalkboard they will miss people going in.

Basically you need to split counting and display. You display snapshots of the count and update that at a rate different (slower) to the rate of counting. When the rate of people arriving slows the display count will more likely match between counter and display. When arrivals stop the display will match the count.

You can only accurately count and display when the count changes slower than the display update. When the change is faster than the display update you need a split system.

 

[alistairsam]

I know, but these are only VERY rough guides. It's not difficult to do this timing.

Symbol EncoderValue  = b0 
Symbol Direction   = b1
Symbol Counter   = w1
Symbol CounterLSB  = b2
Symbol CounterMSB  = b3
Do
 'Calculate new Count value and transmit CounterLSB to Master
 EncoderValue = pins
 Read EncoderValue,Direction
 Counter = Counter + Direction - 1
 pins = 0 '******<<<TEST VALUE FOR TIMING
 
 'Calculate new Count value and transmit CounterMSB to Master
 EncoderValue = pins
 Read EncoderValue,Direction
 Counter = Counter + Direction - 1
 pins = 255 '******<<<TEST VALUE FOR TIMING
Loop

Hi, did a test with this code and a 14M.
at th default clock, I got a frequency of 211Hz, and with 8MHz clock, I got 421 Hz.
rough guess, 4.7ms per code loop at 4MHz clock and 2.3ms with 8MHz clock.

just guessing, if it can do 421 code loops per second, that would be 421 * 60 = 25260 code loops in 60 seconds which is how long it would take to rotate 360 deg.

so if we seperate the display picaxe, the counting picaxe would have an accuracy of
1296000/25260 = 51 arc secs.
this is with a 14M at 8MHz. i think the resolution would be adequate with a 20X2 at 64MHz or a 28X2 at 40MHz. will test that as well.

understood your point about the display, did'nt think of the eye's limiting factor in discerning changing displays.

 

[alistairsam]

The fastest is just to put the count on the output pins. You will effectively be using a PICAXE as a logic counter, except it won't be capable of responding as fast.

no issues with using two picaxes. I guess i'll need the fastest picaxe at the highest clock as the counting picaxe, and a nominal one for the display.
two questions arise, choice of picaxes for each, and how to transfer counter value to the display picaxe.
when you say put the count on the output pins, I'm guessing you meant using the pins to represent 8 or 16 bit binary value, and then the display picaxe reads the pin status at refresh intervals and displays it. unless i've got it wrong.

the display will have to convert binary to decimal and then decimal to degree min secs and then display.

alternately, if there was a discrete counter chip that can increment or decrement, that would simplify things for the display chip as it would only need to read instantaneous counter values at its refresh interval and display.

will do a bit more reading and researching.

 

[Jeremy Leach]

Ok, so at 8MHz clock that's 421 times round the loop every second, or 842 samples (changes in the counter value) every second.

So there you have it. If you want, say, 20,000 counts per revolution, then the absolute fastest you will be able to do a revolution without missing counts, at 8MHz clock, is 20,000/842 = 23 seconds.

This is for a steady motor speed too. If the motor speed spiked at all then you'd lose counts.


I feel you should think about the mechanical side of things too. Be realistic about the achievable resolution, allowing for backlash in gearing etc. Maybe you could make it just get the 'rough' positioning of the telescope right? Say, 3600 counts per revolution?

 

[alistairsam]

was just editing my post with similar results.
I'm also looking at up/down counters. there're quite a few cmos chips that are up/down counters.
so if the tacho and direction pulses can be interfaced with the discrete counter, and I can get a BCD value to the picaxe, it would be even more accurate and I might get away with just one picaxe and a discrete.
still researching for discretes.

 

[alistairsam]

was just editing my post with similar results.
I'm also looking at up/down counters. there're quite a few cmos chips that are up/down counters.
so if the tacho and direction pulses can be interfaced with the discrete counter, and I can get a BCD value to the picaxe, it would be even more accurate and I might get away with just one picaxe and a discrete.
still researching for discretes.

I think I'll have to do away with discretes as the counter.
reason is that I will need to load a preset value to the counter while doing star alignment.
basically the fixed point star has co-ordinates in deg, min sec that does not change. so once I point the scope to the star, raise a pin high, I'll need to update the counter with that preset value from eeprom. once that is done, then moving left or right will increment or decrement from that value.
for the southern star, its 36 deg 50m 59sec.
this approach will help in more than one way as I can then have a database of objects in an external eeprom, and check its relation to the current position. but thats once I get this counter and display working.

 

[Jeremy Leach]

even more accurate

Just remember the mechanical side. The electronics are only one part that make up the 'accuracy' of your system - no point in making the electronics super accurate if the mechanical side won't be. My gut feeling is that I'd be very surprised if you could make the mechanical side more accurate than 0.1 degrees.

 

[alistairsam]

I feel you should think about the mechanical side of things too. Be realistic about the achievable resolution, allowing for backlash in gearing etc. Maybe you could make it just get the 'rough' positioning of the telescope right? Say, 3600 counts per revolution?

very true. as I mentioned, 10000 cpr encoders work well, but for reasonable accuracy, the starting point would be 4500 counts per revolution.
the max I've read of people using is 20000 cpr. but i'm happy with something between that as my mount is home made, but have designed it with timing belts for minimal backlash.

backlash in gearing would be minimal as the encoder is not part of the motor gear train. its separate. just a simple timing pulley to the telescope shaft, so minimal backlash and no slippage as there is hardly any load on the encoder wheel.

 

[Jeremy Leach]

I don't think you need to give up on the discrete idea - it's the best way to go 'if' you can find something. You don't need to load the counter value of the discreet at all, just know it's value when you've locked onto your reference star, then everything is relative to that.

I'm not trying to discourage you about the accuracy. It's a lovely project and a great idea to have an EEPROM table of stars etc. In fact I've wondered about something similar. But it's best to be realistic about the accuracy side upfront, and design your system accordingly. It will save a lot of pain too in the long run because you can work with smaller values etc.

 

[MartinM57]

two questions arise, choice of picaxes for each, and how to transfer counter value to the display picaxe.

if you had two X2 parts you could look at "hi2csetup - slave mode (X2 parts only)" in Manual 2...quote

When in slave mode all i2c functions of the slave PICAXE chip are completely
automatic. An i2c master can read or write to the slave PICAXE chip as if it was a
128 (X1, 20X2) or 256 (X2) byte 24LCxx series EEPROM, with the scratchpad
area acting as the memory transfer area. The master can read the slave PICAXE
chip at any time. This does not have any noticable affect on the slave PICAXE
program, however....

Might be suitable, the "does not have any noticable affect on the slave PICAXE" looks good (you'd make the decoder PICAXE the slave and the display PICAXE the master - un-intuitively ) - never used it myself though...

 

[alistairsam]

I don't think you need to give up on the discrete idea - it's the best way to go 'if' you can find something. You don't need to load the counter value of the discreet at all, just know it's value when you've locked onto your reference star, then everything is relative to that.

How do you mean you don't need to load the value of the discrete?
my idea was that when the star is locked, by entering a preset value into the counter, the display would change to show the stars actual value and then movement would be relative to that.

are'nt we getting the angular value from the discrete counter by converting actual discrete value?
eg, if resolution is 10000cpr, the values of the discrete counter would range from 1 to 10000. if the star is at say 4700, that would be converted to angular coordinates and displayed, and by loading a preset value, we're just shifting the zero point of the encoder wheel so that the discrete value is now say 6500 to match the star coordinates.

understood your point about accuracy. I don't expect high accuracy mechanically, but once I get the electronics "capable" of reasonably high accuracy, I don't need to revisit it at all. just improve the mechanics.

 

[Jeremy Leach]

Well, if you find a discrete encoder module to do the counting, then you will have:

1. A Counter value held internally in the discrete module that can be interrogated by the PICAXE (let's call it EncoderCounterValue)
2. A Counter variable held in the PICAXE (let's call it PICAXECounterValue)

Let's say you point to your reference star, and the PICAXE reads the module and gets the value 3254 back. Well, it knows that this 'means' a count of 0. So you just store this as an 'Offset' value in the PICAXE. So:

PICAXECounterValue = EncoderCounterValue - 3254

So then you know that whatever counter values come in from the module in future, you just need to do this calculation.

This way, it doesn't matter what the EncoderCounter value is to start with.

 

[alistairsam]

Ok, so at 8MHz clock that's 421 times round the loop every second, or 842 samples (changes in the counter value) every second.

So there you have it. If you want, say, 20,000 counts per revolution, then the absolute fastest you will be able to do a revolution without missing counts, at 8MHz clock, is 20,000/842 = 23 seconds.

Hi, just tested your timing code with a 28X2 at 8MHz clock and external 8MHz (32MHz)

at 8MHz internal, it was 231 Hz at the output and at 32MHz, it was 1131Hz.
so as per your calc above,
thats 1131 times around the loop every second or 2262 samples per second.

or 1131 * 60 = 67860 pulses in 60 seconds for one revolution,
for 20000cpr, thats 20000/2262 = 8.2 secs as fastest.

what do you think?

 

[Jeremy Leach]

That's right. So as this is theoretical max, then in reality you should expect less - perhaps 10k counts in 8 seconds - to be sure the PICAXE wouldn't drop counts.

What sort of motor are you using? Will it keep constant speed?

 

[alistairsam]

Hi,
i reality, it would be 10k counts in around 60 to 90 seconds at most and not quicker.
so should be safe to go up a bit. will test this of course as nothing compares to actual tests. also depends on what I can come up with in terms of printing the code wheel and gearing the encoder. so in all, it won't be very high.
that given, I think its worth trying the counter and display code in one picaxe along with a toggle at the start and end of the loop and time it to see what it can actually do with sertxd. this will be with a 28X2 and external resonator.
will then try the master slave method as Martin mentioned.

I'm using a stepper motor with timing belts and pulleys and one planetary gearbox. I'm using a 28X2 to step the stepper using an a4983 stepper driver from allegro.

I'll post some videos of the whole drive shortly so you'd get an idea of the speed.
this is a video of just the motor and the picaxe http://www.youtube.com/watch?v=oO68oe5R-Ws

 

[Jeremy Leach]

Ok, another consideration is the translation between the Count value and the D/M/S value.

360*60*60 = 1296000 as you've said.

= 16000 * 81

So if you had 16000 counts per revolution then each count would represent 81 seconds of arc. This is just an example, but gives a nice value.

On the conversion side of things, this is my suggestion ...

I'd have 3 variables:
Seconds (Byte value 0 to 59)
Minutes (Byte value 0 to 59)
Degrees (Word value 0 to 359)

Then for each new Count value you receive, you work out the difference between this count and the last count:
DeltaCount = NewCounterValue - OldCounterValue

Then you work this out in seconds:
DeltaSeconds = DeltaCount * 81

Then you add this value to the Seconds, Minutes and Degrees variables. The way you do this is key, but it's not too hard.

EDIT: As you can see, if each count is 81 seconds then there's no point in having a seconds display at all !

 

[alistairsam]

thanks. will write it up and post.
I'll have to think about the resolution and decide whats practical

 

[Jeremy Leach]

Best of luck. It's a nice project.

 

[Jeremy Leach]

You might want to consider an IC like this : http://www.farnell.com/datasheets/20478.pdf
It handles 2-axis and does the whole lot for you (got internal counters and could interface to PICAXE).

It might be spoiling the fun of trying to do it yourself though.

I also think that if anyone has any PIC assembler skills then it might well be fairly simple to design an 8 pin, dual channel, interface IC.
Pins:
Power
GND
Input A1 Encoder inputs
Input B1 "
Input A2 "
Input B2 "
Input - for requesting Count
Output - sending out the counter data

There could be quite a few ideas for how to get the counter data from the device.

 

[alistairsam]

You might want to consider an IC like this : http://www.farnell.com/datasheets/20478.pdf
It handles 2-axis and does the whole lot for you (got internal counters and could interface to PICAXE).

It might be spoiling the fun of trying to do it yourself though.

wow, just when I was going to solder all my components !

that is a very good find Jeremy, thanks.
its true, might take the fun out of the whole thing.
what I might do is build both, one with just the picaxe, and one with this chip and compare.
if the picaxe only solution works comparably, then its worth considering. will also keep costs down and keep the circuit board simple.

I blew an LED from a mouse last night , followed instructions from a website to apply 5v without a resistor.
anyways, I got the IR detector/decoder as posted earlier, so testing it tonight with some code.
will post results. will also order this chip once I understand the bus interface and memory addressing.
have to get a display as well. but thanks to yours and others contributions, I'm fairly confident it'll work.

apparently, there is a mathematical method of converting relative angles from the encoder to celestial angles. you point to a star, measure the relative value, point to another, measure again, and with the formula, it does a triangulation for a third star and then computes the offset for celestial co-ordinates.
i'm far away from that, but might get that done eventually.

 

[Jeremy Leach]

Well I'll leave that maths one to you You've got enough to be getting on with I think !!

 

[alistairsam]

hi
is it possible to have an initial section in the picaxe program code where the program pauses for a pin to be toggled and then goes to the next routine?

idea is that an offset has to be calculated based on when the desired position on the encoder is reached, this will be done twice, and those values loaded into variables and then the code continues with the read and display routines.

whether I use the agilent chip as in your last post to convey the encoder position value, or I use the picaxe to count and store position value based on pulses from the tacho, I need to calibrate the position variable once I've aligned to the first star.
So, if the routine pauses at start, I pull a pin high, it then updates the counter value with that of the star, or determines the offset value as you suggested, it will then be "calibrated", and then on, all positions will be relative to that.
I'm not yet trying to do the math that I mentioned earlier, just the one star alignment bit.

 

[Jeremy Leach]

You can have as much initialisation as you like . Perhaps you need to play with PICAXEs a bit more before embarking on this? You've got to understand the blocks before you start putting them together.

Another thought - perhaps a backlit, serial, LCD display would be better. More versatile, less code, could display messages like "Initialising".

Sounds to me like you need buttons to manually maneuver the motors to the reference star at startup (or when you choose), then a button to reset the counters.

 

[alistairsam]

yep, more play required. doing precisely that.

I do have buttons for my motors. thats on a seperate picaxe.
this one will be independent, and the display I was thinking of was
"point to star x and press return"
and it displays the counter values as it slews.
"point to star x and press return"
and displays values again.
should get it working in a few days hopefully. just waiting for the IR LED that I ordered.
what would be good will be manual input, so if I have a keypad to enter a two digit number, that would choose star positions from eeprom either external or internal.
lots more can be done, but I'll get the basics working first.

this is a commercially available version of what I'm trying to do with the picaxe, costs $400 plus. http://www.skyeng.com/

 

[alistairsam]

Hi,
is it possible to simulate hardware interrupts in the programming editor. tried searching in this forum but did'nt find anything indicating the contrary.
when i try to simulate choosing a 20x2 or 28x2, the hint pins B.0 or B.1 dont cause an interrupt, but for some reason, C.1 does raise an interrupt.

i've started on the code, idea is to use two 20X2's (because I can raise the clock to 64MHz at 5V), one as the counter that just increments or decrements a linear decimal counter and stores the value in scratchpad, and the second picaxe gets that value periodically, converts it to deg min sec and displays it. I'll be using the IR sensor with the quadrature logic HLC2705.

there will also be a numeric keypad connected to the second 20x2 to select 1 of 3 or 4 routines that can define or fix variables or modes.

for example, its not really possible to get the precise number of pulses in a geared encoder setup for 360 degrees without counting. this is needed to calculate relationship between relative postion and angular position, so thought of using a simple optical or electrical switch on the fork of the scope to act as the index, and use a routine on the picaxe that resets the position variable on initial rotation, and once the fork has rotated through 360 deg, the index switch will trigger the picaxe to load that instantaneous value of counted pulses to the position variable and store it in an external eeprom

the second menu would be the star alignment. I chose a single star alignment to make things simpler.

I'll have to use the second picaxe to perform the mathematical conversion of decimal to d/m/s. still working on that, keypad, display and mode routines, trying to get around the decimal issue for dms conversion.

initial code below
commented what I've thought of for the display

'startup display would be as below (20x4 backlit LCD)
'----------------------
'|RA  000d 00m 00s    |
'|DEC 000d 00m 00s    |
'|* to setup Enc      |
'|# to Star Align     |  
'----------------------

'Alignment display1
'----------------------
'|RA  000d 00m 00s    |
'|DEC 000d 00m 00s    |
'|Star Align ->       |
'|Point to Sigma, Pr# |  
'----------------------


'Feature to count number of pulses and store as enccount variable
'on entering encoder setup mode

'Encoder Calibration display1
'----------------------
'|RA  000d 00m 00s    |
'|DEC 000d 00m 00s    |
'|Encoder Calibrate ->|
'|Rotate RA by 360d   |  
'----------------------

'Encoder Calibration display2
'----------------------
'|RA  000d 00m 00s    |
'|DEC 000d 00m 00s    |   
'|                    |
'|RAEncoder Calibrated|
'----------------------

'Pins
'B.1 = Tacho pulse
'B.0 = Dir pulse

#picaxe 20X2

Symbol position = w0
Symbol flg = b8
Symbol enccount = w1

setint %00000010,%00000010 'interrupt on pinB.1 high only

enccount = 10000 'enter max encoder pulses
position = 0

Main1:
Do
put 1,word w0 
Loop

Incr:
if position = enccount then let position = 0
Endif
Inc position
setint %00000010,%00000010
return

Decr:
if position = 0 then let position = enccount
Endif
Dec position
setint %00000010,%00000010
return

Interrupt:
b7 = 1
if pinsB = %00000010 then goto decr
if pinsB = %00000011 then goto incr
if pinsB = 0 then setint %00000010,%00000010
Endif
return

 

[Jeremy Leach]

I haven't personally got the time to get into too much detail here, but a few quick things:

I don't know about the interrupts in the SIM. As long as you design the interrupt conditions correctly then it shouldn't really need simulating and you can just force the test code to assume a particular condition.

I thought you were going to initialise the counters to a fixed star, rather than initialise based on a switch ? The star approach makes more sense to me, because surely you need some initial alignment between the 'real' external world and your system's 'internal' coordinate system (the encoders on each axis).

Trying to translate between Counter values and D/M/S values might prove to be very difficult if you're going to try to have a generic Translation routine. Because you'd need to translate from Counter value to seconds, then do the divisions. But the seconds values will be enormous and too big for the PICAXE to handle using normal integer maths. So my previous suggestion was to instead increment a locally held D/M/S variable as the counter value changes.

What I mean is this: In my previous example 1 count = 81 seconds. It's fairly straightforward to make an 'add' routine that adds 81 seconds onto an existing D/M/S variable (well 3 variables, one for each part). Or even a subtraction routine. What is VERY difficult is a division routine. So your best bet is to add or subtract chunks of counts to an existing D/M/S variable.

 

[hippy]

is it possible to simulate hardware interrupts in the programming editor ... when i try to simulate choosing a 20x2 or 28x2, the hint pins B.0 or B.1 dont cause an interrupt, but for some reason, C.1 does raise an interrupt.

Works okay for me when I simulate a 20X2 and 28X2; make sure you have the latest 3.5.1 Programming Editor plus the correct PICAXE selected or use the #PICAXE directive, check PICAXE Manual 1 ( page 10 ) for pinouts and HINTx pin allocation.

For 20X2 ...

HINT0 is not available on the 20X2
HINT1 is pin B.0
HINT2 is pin B.1
Other pins have no effect

For 28X2 ...

HINT0 is pin B.0
HINT1 is pin B.1
HINT2 is pin B.2
Other pins have no effect

#Picaxe 20X2

HIntSetup %01100110

Gosub Interrupt_Enable

Do : Loop

Interrupt:
  If hInt1Flag = 1 Then
    SerTxd( "Interrupt 1", CR, LF )
    hInt1Flag = 0
  End If
  If hInt2Flag = 1 Then
    SerTxd( "Interrupt 2", CR, LF )
    hInt2Flag = 0
  End If

Interrupt_Enable:
  SetIntFlags OR %00000110, %00000110
  Return

#Picaxe 28X2

HIntSetup %01110111

Gosub Interrupt_Enable

Do : Loop

Interrupt:
  If hInt0Flag = 1 Then
    SerTxd( "Interrupt 0", CR, LF )
    hInt0Flag = 0
  End If
  If hInt1Flag = 1 Then
    SerTxd( "Interrupt 1", CR, LF )
    hInt1Flag = 0
  End If
  If hInt2Flag = 1 Then
    SerTxd( "Interrupt 2", CR, LF )
    hInt2Flag = 0
  End If

Interrupt_Enable:
  SetIntFlags OR %00000111, %00000111
  Return

 

[alistairsam]

Thanks Jeremy, will try that.
I am using the star alignment, the index switch was just to count the number of pulses after gearing the encoder. both will be seperate routines.
the encoder pulse routine need done only once and will be stored in external eeprom. the star alignment routine will be done at every viewing session.

if I was using a standard encoder that has over 5000 plus pulses on one rotation of the encoder shaft, then I could use its index track to count pulses over 360 deg. but with geared encoder, I have to place the index track externally, in this case, on something coupled to the scope shaft.

Hippy, I went over the setint command again and noticed the restriction on 20X2 that only Port C can be used. But the pinout shows hint 1 and hint2 as B.1 and B.2. does this mean that C.1 to C.5 can be used as input pins that raise interrupts with the setint command?
I went through both commands, but did'nt understand the difference between setint and hintsetup

will try your code as well.

 

[hippy]

Yes SETINT only works on C.x pins on 20X2, HINTSETUP uses different pins, and behavior depends on commands used.

SETINT - Enable polling the pins between commands and if there's 'a match' with the SETINT configuration enter the interrupt routine.

HINTSETUP - Configure the HINTx pins. When a pin matches that configuration set HINTxFLAG. This works no matter what the PICAXE may be doing.

SETINTFLAGS - Enable polling the flags between commands and if there's 'a match' with the SETINTFLAGS configuration enter the interrupt routine.

It's possible to use HINTSETUP without using SETINTFLAGS if you want to detect pin changes at any time but not have an interrupt.

 

[alistairsam]

if you had two X2 parts you could look at "hi2csetup - slave mode (X2 parts only)" in Manual 2...quoteMight be suitable, the "does not have any noticable affect on the slave PICAXE" looks good (you'd make the decoder PICAXE the slave and the display PICAXE the master - un-intuitively ) - never used it myself though...

Hi,
if I used a master slave picaxe as above, the display picaxe would need to read the values off the dms variables periodically to refresh the display.
but as the slave handles counting based on interrups from the tacho pulses, can the master read the values off the slave's memory only after the slave has finished its loop or its interrupts are reset?
can three picaxes be connected together as well? reason is I'd need two counter picaxes, one for each axis, and one for the display.

I don't think I can use the HCTL-2032 chip as it outputs counts over 32 bits, and I'll have to convert it from integer to dms. instead I'll work on incrementing counters in dms format to start with over 3 variables.

got the IR LED's today. will be testing the quadrature detector with a picaxe today.