Crude positioning with encoder and AC motor

[dj_trippn]

Hi I have a project where I want to position a AC motor using a Omron encoder. Currently I have built the interface to the AC motor drive and can control speed and direction of the motor. What I am having trouble with and want advise is the encoder part.

I have read through all the posts regarding encoders and quadrature encoders. Do these super fast version of code allow you to do other tasks in the picaxe? I need to update an LCD display and control the motor speed and direction, while reading the encoder postion.

The encoder is a Omron 500 ppr encoder. But this is overkill and I probably only need about 50 ppr. Is it possible to use just one channel of the encoder and increment the count on every pulse either up if running the motor forward or down if running the motor backwards?

So basically my questions are:
Is it possible to use a 500 ppr encoder spinning at max 2 revs per second while also updating a LCD display and controlling motor speed and direction?
Is there a way to slow down the 500 ppr encoder to say 50 ppr using a standard IC?

Any advise and thoughts would be much appreciated.

Thanks,

Glenn

 

[BeanieBots]

Many questions and many options. Which way you go really depends on what you want to do. You haven't actually specified why you even need the encoder. Is it for speed control? Distance measurement?

The 'normal' function of an encoder is to provide speed/distance AND direction information by employing two 90deg phase difference pulses. If you do not require this functionality, then a whole host of options become available.

You could use just one of the signals at the expense of direction information.
Don't forget that just because you have reversed the drive, it will take time to stop and then reverse. Will the loss of this information be important?
If you do just use one phase, then you could pass that signal through a divider and count (or pulsin) those pulses.

Whether or not you can update an LCD display at the same time depends on which option you take. If you NEED the quadrature information, then no.
If you take the slowed down divided single phase option, then yes.
Again, there are several options here.

If you only want speed information, then take a sample (count or pulsin), then update the LCD then take another sample etc.

If you want distance information, then you need to react every time there is a pulse or you might miss one. This would require the use of interrupts. LCD functions (serial) take quite a long time to execute. The interrupt only interrupts at the end of each command. Hence, it would not be possible to do full quadrature encoding at the level of your encoder in the background but if you had a divider (no quadrature info) then it would be possible.

There are also multiple PICAXE options you could take.
Overclocking a 28X1 might be fast enough, I've not done the sums.

Really need you to come back with some more precise details of what you want to get from the encoder. Then somebody will be able to give a more precise answer.

 

[westaust55]

Hi Glen, and although at your post No 3, welcome to the PICAXE forum.

Please provide some additional information about the Omron encoder.

Is it an absolute or incremental encoder?

Is it a serial or parallel signal.

If parallel, is it straight binary, grey code or other? You may be able to skip some of the lower bits to effectively reduce the resolution.

Which PICAXE are you thinking about?

Some on this forum (cannot speak for all, without abuse ! ) are endeavouring to give some generic guidance to newcomers on how better present their technical questions in terms of information to provide to gain a solution as rapidly as possible. As such, you may like to have a read at post 4 of this thread for some ideas.
http://www.picaxeforum.co.uk/showthread.php?t=10982


Edit: BB slipped in ahead of me there

Edit2: Guessing further if you are trying to ascertain exact position, is it an asolute encoder with multiple parallel bits of data.
Have dealt with those in the past up to 32 bits in parallel with grey code format.
Hmmm, but then it would be a 512 pulse per rev encoder if smoe binary system and parallel data.

 

[hippy]

Two revolutions per second is 500ms per revolution, 500 pulses per revolution gives one pulse every 1ms. A PICAXE should be able to handle an encoder at those speeds and I would say definitely at 50 pulses per revolution.

As to how much else it can do is a matter of time between pulses and what you need to do. Serial transmission can be slow so LCD updates would have to be very carefully designed, such as only sending one or two bytes at a time between pulses.

Using multiple PICAXE's can spread the workload around and using the fastest PICAXE's and highest serial baud rates you can will help things.

 

[dj_trippn]

Hi everyone, thanks heaps for your fast response. Sorry I thought I had provided enough information, but I guess I didnt explain my problem clear enough.

BeanieBots:
The encoder is used for distance positioning. E.g Run the motor in one direction to a position setpoint, then run in the other direction to another position setpoint.

I do not need speed information just position (crude positioning) so the loss of information is not very important. How do I implement a divider?

WestAust55:
I am using an incremental rotary encoder, with parallel A and B channel signals, here is a link to the datasheet http://www.ia.omron.com/product/family/488/index_fea.html
I will use any picaxe that will do the job, I have a range in my collection to test with, I was thinking of overclocking a 28X1

Hippy:
If I was to have a dedicated picaxe for doing the encoder counting, I still need to get that data to another picaxe to update the LCD, which would involve a serial out command. Unless I could use say 8 digital I/O and send the position via digital signals. How would be the best way to do this?

Just to clarify abit, my question was can I get full quadrature encoding , while also updating the LCD display (answer: no). If not is there a better method e.g splitting jobs onto multiple picaxes? Or as I don't need the encoding to be 500ppr can I somehow reduce the resolution?

Thanks,

Glenn

 

[BeanieBots]

All you need for a divider is a single (divider) chip. eg 4040 or 4060.
(binary counter).
Clock it with the encoder pulses and then have the PICAXE read a suitable Q output. (/2, /4, /8 or whatever suites)
If you can actually tollerate missing a few pulses, then you could simply take the risk of letting a serout a bit "too long" and use an interrupt method. Might even be OK as pointed by hippy.

 

[westaust55]

Crude positioning with incremental encoder

Okay clear now.

As BB says, use a 4040 binary divider chip. Put Phase Z from the Omron encoder into the 4040.

Divide by say 4 using the Q output at pin 7. Note the output will go high after 4 increments then stay high for 4 further increments – hence divide by 4 not 8 which will give 62.5 pulses per rev.

With the 4040 output as an interrupt on a rising signal into the PICAXE, then that equates to 8 increments. If the PICAXE is quick enough, then next just look at the state of Phase B. If Phase B is high you are turning CCW but if Phase B is low you are turning CW.

 

[dj_trippn]

I will try using the 4040 as a divider tonight when I get home and see how that goes. I will let you know how I get on. I will use the interrupt on the output from the counter and check the status of phase B.

THanks for you help.

 

[leftyretro]

"Run the motor in one direction to a position setpoint, then run in the other direction to another position setpoint."

Sounds like you wish to build, and have discribed above, is a servo system using an encoder for the feedback signal. That parts is fine but how are you going to electrically drive a AC motor such that you can have it turn fractionally and in either direction.

I've worked on various servo systems from small R/C servos to ones as big as a car and I've never seen one that uses an AC motor. DC motors, stepper motors, linear DC actuators, hydraulic actuators, yes, but not an AC motor. Can you provide a reference to what you are trying to accomplish?

An AC motor is kind of an on and off affair, with no easy ability to control it's RPM or direction.

 

[dj_trippn]

I have a 1.5kW Omron Inverter drive to drive the motor, that I am interfacing with. Its not a servo system but similar. The AC motor is geared down with a pulley on the end. Around this pulley is a rope with its ends tied together and an idler pulley about 30 meters away.There is an object attached to the rope which moves from one side to the other back and forth when the motor is driven.

The point of the encoder is because the position it goes to before heading back in the other direction changes. So it moves back and forth to different positions.

 

[westaust55]

"Run the motor in one direction to a position setpoint, then run in the other direction to another position setpoint."

Sounds like you wish to build, and have discribed above, is a servo system using an encoder for the feedback signal. That parts is fine but how are you going to electrically drive a AC motor such that you can have it turn fractionally and in either direction.

I've worked on various servo systems from small R/C servos to ones as big as a car and I've never seen one that uses an AC motor. DC motors, stepper motors, linear DC actuators, hydraulic actuators, yes, but not an AC motor. Can you provide a reference to what you are trying to accomplish?

An AC motor is kind of an on and off affair, with no easy ability to control it's RPM or direction.

The concepts are not greatly different to many raw material stackers and reclaimers which I have dealings with. Some of these might have travel of the order of 1 kilometre and may weigh from 500 to 1200 tonnes.
These machines might use around to 8 or 10 drive motors each rated say 20kW per side controlled by one variable speed drive (VSD aka VFD) per side for skew control. The VSD”s control speed and direction.
With one encoder on a long travel wheel (preferably a non-drive wheel to avoid error through any wheel slip under power/braking) we feed the distance and direction into the machine PLC. These machines can with the VSD hold at zero speed against the feeding conveyor or travel at any speed up to max design speed along a stockpile.

 

[leftyretro]

The concepts are not greatly different to many raw material stackers and reclaimers which I have dealings with. Some of these might have travel of the order of 1 kilometre and may weigh from 500 to 1200 tonnes.
These machines might use around to 8 or 10 drive motors each rated say 20kW per side controlled by one variable speed drive (VSD aka VFD) per side for skew control. The VSD”s control speed and direction.
With one encoder on a long travel wheel (preferably a non-drive wheel to avoid error through any wheel slip under power/braking) we feed the distance and direction into the machine PLC. These machines can with the VSD hold at zero speed against the feeding conveyor or travel at any speed up to max design speed along a stockpile.

Well that certainly explains a lot, thanks. I worked on several large (15,000HP) VSD controllers so I have some experience in that area. However the control interface was pretty simple, ramp up to speed (avoiding lingering at a couple of the compressor critical RPM points), speed control using PID commands from a process controller and of course a zillion alarms and trip protection schemes. Water cooled and the water system was a bitch to maintain with DI filter bottle replacement, heat exchanger motors and on and on. Glad to be retired from that now ;-)

 

[hippy]

All you need for a divider is a single (divider) chip. eg 4040 or 4060.
(binary counter).

Will this or any simple counter work ? Not saying it won't, I haven't tested it, but was wondering what would happen if there were three steps forward, two steps back, then off it goes forward again; will it lose synchronisation ?

An alternative, assuming a PICAXE can handle the 500 PPR at 8MHz, may be to use an 08M as a smart divider which can accurately track the incoming two-phase quadrature clock and generate the same but at a lower PPR. A 28X1 can run at 16MHz/20MHz if an 08M doesn't have the performance needed.

 

[BeanieBots]

Will this or any simple counter work ? Not saying it won't, I haven't tested it, but was wondering what would happen if there were three steps forward, two steps back, then off it goes forward again; will it lose synchronisation ?

An alternative, assuming a PICAXE can handle the 500 PPR at 8MHz, may be to use an 08M as a smart divider which can accurately track the incoming two-phase quadrature clock and generate the same but at a lower PPR. A 28X1 can run at 16MHz/20MHz if an 08M doesn't have the performance needed.

The use of a divider will lose the quadrature information. I did actually state that but maybe the consequences were not made obvious. In the scenario described, it would NOT give accurate information. Worst case would be sitting on the edge of a 'transistion' with some vibration.

Love your idea of dedicated 08M 'true quadrature' divider. Does assume it can cope at 500 PPR. It could have two outputs (pulse & direction) to drive another PICAXE via interrupts.

 

[dj_trippn]

I have got the encoder working using the binary counter as a divider.

I might experiment with using a dedicated axe as a divider so as to not lose any information. I know I said it doesnt matter if I loose data but I might as well do it, if it is possible. What is the fastest code around to track quadrature encoder position? I can use this as a start for creating a divider.

Another option I might take as mentioned earlier, If I use a dedicated Axe to track the quadrature data from the encoder then spit the position straight out to an 8-bit output port. Then the other Axe can read the encoder position from these 8 digital lines whenever it wants.

Is this feasable? Does setting 8 outputs to the corresponding high / low take much processor time? Can you use a command such as pins = w6?

Thanks for your help guys

 

[BeanieBots]

Once you have some quadrature code that puts a position value into a word var, then getting to the outputs is quite easy and won't take long compared to the quadrature part. There is no "pins = w6" option. Only a single byte can be sent to pins. However, I'm sure there is a poke value that can be used to send the other byte to one of the other ports.
Seems a dreadful waste of I/O pins though. Nothing two pins and an interrupt couldn't do. That would leave you with an extra 14 I/O lines for other uses or use two much smaller (cheaper) PICAXEs.

EDIT: Just re-read and you only want 8-bit. The use of "w6" made me think you wanted 16 bit.
Yes, pins=b0. (still a waste of I/O IMHO).

 

[dj_trippn]

Yes it does seems a huge waste of IO. I suggested it because I thought it might be the only way. How would I use 2 IO plus an interupt as u suggested?

 

[BeanieBots]

If you were to use say an 08M to 'divide' the quadrature, instead of counting inside the 08M for position, convert to 'clock pulse' and 'direction'.
These two signals would then connect to a second PICAXE.
The second PICAXE would be set for interrupts and convert the two signals into position. As this is now the 'divided' signal, the rate will be much lower and so the second PICAXE can wait until it has finished slow tasks such as serout before it needs to service the interrupt routine without the risk of missing a pulse.

The caveat with this of course is if an 08M is quick enough for the encoder.

 

[dj_trippn]

I understand the theory of using a the axe to create a clock pulse and direction bit. But if I used the finite state machine code to read the pulses how would I output this as a slower clock pulse? Where in the code would I put my clock pulse?

I am currently using the code found here http://homepage.ntlworld.com/the.happy.hippy/picaxe/encoder.txt. Is this the most updated version of this Hippy?

Thanks

 

[Gunnar]

Any more progress so far?

I`m in a similar situation. I want to make a controller for a masking system for a projector screen. I`m a MCU-newbie, and it`s a steep learning curve...

I have also considered using the "Finite state machine" code. Yesterday I found http://www.allaboutcircuits.com/vol_4/chpt_11/3.html
If you look at the circuit at the bottom, you`ll see that a D-flip flop can be used to determine up/down count. This way clock and direction of count can be sent to the picaxe on two pins, and the code can then be simplified alot(?)

 

[Tom2000]

Glenn,

For your app, is an encoder an absolute "must"? It seems that a couple of limit switches might do the job for you, and eliminate any concerns introduced by mechanical slop in your system.

If you really need an encoder, and that Omron provides too much resolution for you, you can build your own custom encoder. I've written a little freeware program that lets you design and print your own custom codewheels, so you might be able to tailor an encoder to your app.

You can find the program, and a primer on encoding, here.

Good luck!

Tom

 

[dj_trippn]

Thanks for your post Tom,

an encoder is not a must, but positioning of some sort is a must, there limit switches will not do. The accuracy does not need to be hugely accurate though, within 15cm would be ok, but if I can get it more accurate easily then I would like too.

I got a good system working by using a 18X running at 8MHz using Hippy Finite State Machine code. Then I simply added a bit of code to give direction on output pin 0. His code wrote the current count value to the output port, therefore you could use any of the 7 outputs (not output 0 which is direction) to give a pulse. You could change the output to give you more or less pulses per revolution. I then used this pulse plus the direction into another picaxe which had my main program running. This worked mint until I realised I need to spin the encoder shaft faster than I thought, which means the 18X is not getting every pulse and therefore corrupts the data.

Is it possible to run this any faster?

I have had a break on this project, but have just got back into it. I am now using 2 magnets on the fan on the motor and have a reed switch as an input into the picaxe. This is working ok, but I dont have as much accuracy as I would like. Also I am increasing or decreasing the counter depending on which output I have on (forward or reverse), so this will incur some error if I am moving forward and then suddenly change to reverse and the motor takes a certain amount of time to stop then move the other direction.

Any other ideas for a type of encoder? How reliable are the codewheel encoders you make?

Also what is the max speed you can run a picaxe, 16MHz?

Thanks heaps guys

 

[demonicpicaxeguy]

if it's any inspiration :

the crude encoder wheel shown here is cutout of sheet aluminium ,so far works perfectly with a simple ir led and photo diode, at up to 500rpm, mostly because thats the fastest it'll spin, for those who are wondering it's my diy "mother of all cnc servo motors"
it consists of a cordless drill motor and gearbox, and i use a pic18f4550 to controll it via usb courtesy of a simple mosfet and a relay

max picaxe speed: if it's got an external crystal/resonator 16mhz, however 20mhz is doable but the hitch is that editor doesn't support it