Welcome to the forum!
With some more info, we can help out more!
Different microcontrollers can have different ways to access the memory and will be different for each one. To be able to interpret the output of the encoder you will need some sort of interpreting device, this is where the microcontroller steps in.
With a project like this using a microcontroller that supports hardware interrupts will be key.
If the motor has some inertia to it and power is cut it might continue rotating making the value in the EEPROM incorrect.
You could add a calibration function using a hall effect sensor or reflectance sensor at a given reference point like in this split-flap display.
Not exactly true. The encoder should be coupled to the / a motor. If the motor runs on after switch off the encoder should report the TRUE position of the motor which is correct. It is no good reporting the position you think the motor should stop at if it didn’t do this. That is the whole purpose of the encoder, report the TRUE position of whatever it is connected to.
The video that Liam linked before shows a mechanical assembly of a design that you could use in your project.
Which parts in particular were you having trouble with? Breaking the project up into parts would be the best bet rather than doing it all at once. Once I’m back at my PC I can send through some more documentation.
Wouldn’t that be based on the type of encoder used?
The only experience I have with encoders was using an optical encoder, requires a calibration or initial condition to report the exact position. One that outputs sequential code could work in situ, from what I read the one in the pic above outputs pulses rather than a code.
I’ll see if I can track down an example and send it through, using one of them would make Sumayyah’s project way easier.
Liam was talking about any overrun of the motor reporting an inaccurate reading. In my book that is being accurate. Either the motor should not overrun or you may need to know by how much. Does not really matter what sort of reporting device is used. The main aim is to report what the device under surveillance is doing.
In all fairness to Core support staff and responders to this forum there is next to no helpful information forthcoming.It seems that Sumayyah is expecting some sort of clairvoyant to perform a miracle. I think he needs to provide a lot more information re what he is trying to do instead of everyone attempting to guess. There are too many variants.
What the encoder is outputting is one variant. Is it just a pulse train or grey code with 2 quadrature pulses.
OK I have managed to track down some encoder info from that photo.
LPD3806-360BM-G5-24C is the magic number
It is optical encoder although how it does its detection is immaterial, 360 pulses per revolution, A B quadrature output. Output is open collector (NPN I think) NOT switches, Max frequency 20k. Recommended max RPM 2000. Absolute max RPM 5000 (I think that is where Sumayyah’s figure of 5000 comes from).
The open collector output will require a pull up resistor in the interfacing circuit, value will depend on max collector current allowed, did not get that detail.
That little snippet of info may be a start if anyone can get any further.
I just want to store that values when the power is off and receive that previous values
I want to control an AC motor with this when the values of the sensor reached a particular position then stop the motor
I want a sample code of this concept
I am just a beginner
please help me with this project
OK. The main differences are 600 PPR and 5000 RPM. The rest is pretty much as above.
What is rotating the encoder? Is it coupled directly to the motor? How fast is it expected to rotate (RPM).
The first thing that’s to happen is decode the Gray (Grey??) Code which will return a number of pulses since power up. You then have to somehow get that number into your EEPROM. I have no idea how you do this.
My first concern would be the speed of these pulses assuming the motor would be running at a fair clip.
My next concern would be the possible large size of this number if the motor runs for any length of time.
You have not come forward with any of this information. Information seems to be like extracting teeth.
CoreElectronics Support team provide extensive support for inventory items and items they are associated with. Mostly for hobby or often advanced hobby use such as Arduino, Raspberry Pi or such products. Your problem may be beyond their scope, I don’t know but they probably will try. Now I don’t know exactly what sort of speed these products will handle when it comes to decoding your Gray Code to produce a number but there will be a limit. Also there will be a limit to the size of the number these products can handle. At 600 PPR it doesn’t take many revolutions to finish up with a very large number.
I guess what I am saying is don’t be too disappointed if Core or this Forum cannot help as the requirements may be beyond the capability of the products they deal with. I may be wrong here and maybe Core Support or some contributors can help but to get anywhere they have to know more. The parameters I mentioned above would be a start.
The encoder output will be 1 or 0 (high or low) on output A and 1 or 0 (high or low) on output B, 0 (low) active. 90º phase difference. A microcontroller or something then has to interpret this code and count the pulses up or down depending on phase. It is these numbers you want to store. The encoder does NOT count or output numbers. So far the only information you have provided is a photo of an encoder, even the first photo was wrong. You will not get any answers doing things like this.