Hello,
Maybe it's a good big project, but I am really interested in it.
This type of machines are used to check the gears quality. Instead of double flank machines they work in the real position the gear will worked.
They are very complex machines with brakes, 2 axis, motors... And of course encoders (English is not my language, so maybe I will make a lot of mistakes... Sorry because of this)
Instead of we usually use to think both gears (pinion and ring gear) when rolling the do not make a perfect rolling, they make small variations that makes a gear good or bad.
I have bought 2 incremental encoders with 600 ppr. And I will use a Mega to log the data. Already used encoder.h library with an example.
They works fine but I have used 230400 baud rate. The encoders are rolling at he same time and it seems not steps lost.
As said the gears do not roll equal. For example in a 1:1 relationship the encoder read will not be 1-1, 2-2....2400-2400.
It uses to be different reading for each encoder.
So, I have the encoders reads and a very helpful sketch that give me the pulses of each encoder at every change.
I need a little help to make some changes:
The encoder 1 should be read when the encoder 2 changes (I think I can do that)
The sketch I have prints in serial every encoder changes, but I want to log them and finally send them to a PC or maybe to a RPy.
It is known that the pairs of data will be 2400 (encoder accuracy)
And the pairs of data will be from 1 to 2400 one of them and from 1 to (not known, but positive and less than 24000)...
The main problem for me is to log that data in pairs supposed to be able to be sent to a computer...
Any idea?
I think you need to be a bit more specific with the issue you are having. Sending data to a PC is no problem at all, there are many ways. Each will have its advantages and disadvantages.
The simplest is to use serial. It is available on every Arduino board, you will need to create a little protocol and convert the numbers to strings e.g.
start character - number1 - delimiter - number2 - end character
$1000, 2000#
There are standards like NMEA 0183, that are used by GPS modules for instance to do this.
If you want to do this wireless you can use WiFi, Bluetooth and other RF modules. There are lots of protocols to send data.
If you need some more specific help, please read the "How to post ..". Its at the beginning of each subforum. Provide all the information people need to help you.
- exact hardware
- provide a example code for the issue (use code tags to post the code)
Your example
- datasheet links to all non-Arduino components, you want the experts to answer questions not search for datasheets you should have looked at already, even if you might not understand them
- schematic with affected hardware
Ask specific questions, "Any idea?" is not one. 
Hello again,
Thank you for your answer. I will try to be more specific.
As said I am using a MEGA to take the data from the encoders.
The both encoders are these they are very simple with 600 ppr with only 4 wires: Black for GND, Red for 5V and white and green for A and B signal.
As said I have used encoder.h library (Here the link if anyone likes it) and I have started with the example sketch.
/* Encoder Library - TwoKnobs Example
* http://www.pjrc.com/teensy/td_libs_Encoder.html
*
* This example code is in the public domain.
*/
#include <Encoder.h>
// Change these pin numbers to the pins connected to your encoder.
// Best Performance: both pins have interrupt capability
// Good Performance: only the first pin has interrupt capability
// Low Performance: neither pin has interrupt capability
Encoder knobLeft(18, 19);
Encoder knobRight(20, 21);
// avoid using pins with LEDs attached
void setup() {
Serial.begin(230400);
Serial.println("TwoKnobs Encoder Test:");
}
long positionLeft = -999;
long positionRight = -999;
void loop() {
long newLeft, newRight;
newLeft = knobLeft.read();
newRight = knobRight.read();
if (newLeft != positionLeft || newRight != positionRight) {
Serial.print("Left = ");
Serial.print(newLeft);
Serial.print(", Right = ");
Serial.print(newRight);
Serial.println();
positionLeft = newLeft;
positionRight = newRight;
}
// if a character is sent from the serial monitor,
// reset both back to zero.
if (Serial.available()) {
Serial.read();
Serial.println("Reset both knobs to zero");
knobLeft.write(0);
knobRight.write(0);
}
}
I have changed the bauds rate, because with the 9600 of the original sketch it was losing some pulses. It is easy to check because they are printed one by one. When I roll the encoder manually fast enough there were some lost.
With the 230400 rate it seems to be ok, at least manually trying to get 1 revolution per second (only manually, not sure) so 60 rpm. In my project i will work in range of 5rpm to 10 rpm so this will be better for lost pulses.
In the first post I was not very specific about my problems maybe because the language, sorry.
I do not like to log data, instead store it at the same time I am getting them.
Store them as pairs of long, I supposed:
1,1
2,4
...
2400,4800
When the 2400 pairs were got they should be sent to a computer. So my questions is how i should store them trying to avoid that the arduino were sending data at the same time it is getting them from the encoders. This is because i should try not to lose any pulse.
I hope this time the question is clear enough.
Regards,
How many pulses per second is your encoder producing?
...R
It will roll about 5 to 10 rpm. Let's say 10 rpm, the encoders are 600 ppr but with library I detect every change of pines so 600*4= 2400 ppr
24000 pulses per minute about 400 pulses per second... But we have two encoders so 800 pps
I hope they are not to many for the board...
800 pulses per second is one every 1250 microsecs which should not present a problem for an Arduino, except, of course, that the pulses from the two encoders probably won't be evenly spaced in time.
If your shafts always turn in the same direction then you are unlikely to need to detect more than the basic 600 pulses per rev which would greatly reduce the burden on the Arduino.
...R
Thank you Robin2.
The pulses will not be perfectly spaced, but they will be as well spaced as the motor will be able to work at same speed.
About the direction it supposed to make the same in the other direction.
About the pulses I need as many as possible in other to check the gears accuracy...
So do you think that the board would be able to read and write to Serial at same time, or it would be better to make both things separately?
harana:
The pulses will not be perfectly spaced, but they will be as well spaced as the motor will be able to work at same speed.
About the direction it supposed to make the same in the other direction.
About the pulses I need as many as possible in other to check the gears accuracy...
So do you think that the board would be able to read and write to Serial at same time, or it would be better to make both things separately?
This is a bit confusing.
I don't understand the first sentence
Does the second sentence mean that the shafts may turn in either direction and the Arduino needs to be able to detect the direction?
From what you have said there are only 600 pulses per revolution. The quadrature encoding is only for direction but it it adds a lot of work for the Arduino, hence my wondering if you need the direction information.
I don't know the answer to the 4th sentence. A lot depends on how much data needs to be received and sent, and how often. Would it be possible to collect data for a short period then pause the data collection to send the data to the PC?
...R
Sorry... I have problems to explain correctly.
The pulses will not be synchronized. A motor (maybe a Nema) will try to rotate at the exact speed but it will not be perfect. But the pulses are supposed to be similar spaced (not perfect I want to say).
It is going to turn in both directions but I do not need the quadrature to know that change. In fact I need read both encoders. Encoder 1 will lead the sketch; when it changes the position (one pulse more) we go to see where encoder 2 is. This give us 2 numbers from 1 to 2400 in encoder 1… and from 1 to (not known it depends of the gear relationship). But sure just 2400 pairs of numbers. Here they should be sent to PC.
The next step will be to change the motor direction (Arduino won't do that) and make again 2400 paid of numbers from 2400 to 1 of the encoder 1. And again send them to PC...
Not possible to stop data collection until the 2400 pairs will be collected.
Maybe it is impossible, or maybe it is only because I am not able to explain it correctly...
Sorry and thanks again.
It sounds plausible. You have a high enough baud rate. Does the PC really need all that data though? I assume you're trying to decide whether a gear is good or bad and I would think that you can tell that after encoder one has 2400 pulses by how many encoder two has.
Is there something you need from the intermediate counts too?
harana:
The pulses will not be synchronized. A motor (maybe a Nema) will try to rotate at the exact speed but it will not be perfect. But the pulses are supposed to be similar spaced (not perfect I want to say).
I'm afraid I can't make a mental image of what you are trying to create. I had the impression you have a machine with encoders and you want to detect the pulses from the encoders. But now, it seems to me, that you also plan to create the machine that does the rotation.
Maybe you can make a diagram that illustrates what you are trying to create and what you are trying to measure.
Maybe here a explanation better than mine. At least of what theorically the machines should do.
Link
Thanks for the link.
It seems that you want a motor to rotate one gear which then driver another gear and you want to record the pulses from encoders on the two shafts to see if the driven gear is moving smoothly or erratically relative to the powered gear. Is that correct?
I'm also guessing that, for a single test the direction of motion will be known and won't have to be determined by the Arduino from the encoder pulses. Is that correct?
Assuming that the Arduino can detect all the pulses (for simplicity let's assume 600 per revolution) it's not clear to me how you want to use that data. Do you need to capture the time (microsecs) at which each pulse occurs? Or do you just need to match the count from one encoder with the count from the other.
If you need to capture the time for each pulse (or the interval between pulses) and save the data for the duration of a single test then the number of data points you need to save may be an issue in the small memory of an Arduino.
And it's still not clear to me what role Serial has to play in all of this.
...R
I think the plan is to send the data over serial to a PC which will do the analysis to figure out whether the tested gear is good enough.
wildbill:
I think the plan is to send the data over serial to a PC which will do the analysis to figure out whether the tested gear is good enough.
That sounds reasonable - but we need the details - what data, and how much of it, and how often?
...R
Hello. Sorry for the delay. I was on travelling for weekend. You both have understand perfectly. Some answer to your questions.
Time is not important to compare.
Just save the 1st encoder position when 2nd one is going from pulse one to 2400.
This is because the 2nd one has to complete just one revolution (depending of their relationship) but the first encoder could do 1, 2, 3...
Imagine that the both gears has the same number of teeth. Ideally the encoders would show the same pulse each other. 1-1…2-2…2400-2400. The real situation is that it does not happen... 1-1…2-3…3-5…4-6…5-6
These values are important for me to make a graph (plot?) With the deviation from the theorical position to real one.
How many? as many the better: more real position for the gear set.
Imagine that the gear has (both) 40 teeth. With 2400 I will have 60 points for each tooth and hole. Gears are supposed to turn synchronized, but not, they make the thing you could see in the link.
About the turn direction. No needed, with other system y will put the gears to turn.
As I can imagine (thinking about it) the ideal sketch should do the next:
Start reading the second encoder. When changed, from 0 to 1… read the 1st encoder position. Make a pair with them and store them. If first changes nothing, when second changes again from 1 to 2 read again the actual position of the first one.
This while second encoder read is equal to 2400 (or maybe better smaller than 2401… cause the possibility the 2400 is missed).
It is the very big important target for me. A second part of the sketch would be just in the opposite, from 2400 to 0.
I hope this will help you both to understand. If you like I can say you some links with real machines (in any case looking for single flank tester in Google is enough...)
Tomorrow I will try to start customizing the sketch...
Regards, and thank you very much.
harana:
Just save the 1st encoder position when 2nd one is going from pulse one to 2400.
Sorry but I seem to be very dense today. Does that mean that every time one encoder moves through a full circle you want to record the encoder position that the other encoder has reached. In other words one reading for encoder2 for every revolution of encoder1
Imagine that the gear has (both) 40 teeth. With 2400 I will have 60 points for each tooth and hole
I believe you need to check that carefully. I think (based on what you said earlier) that there are only 600 individual encoder positions.
Start reading the second encoder. When changed, from 0 to 1… read the 1st encoder position. Make a pair with them and store them. If first changes nothing, when second changes again from 1 to 2 read again the actual position of the first one.
This while second encoder read is equal to 2400 (or maybe better smaller than 2401… cause the possibility the 2400 is missed).
That seems to me very different from the first part I quoted here. Now you seem to be saying that you want to record the position of encoder2 every time encoder1 increments.
And you have not told us what you want to do when you have collected the data.
If you are collecting the position of encoder2 every time that encoder1 increments then for 1 revolution you will have 600 (or maybe 2400) data points. Counting beyond 255 requires the value to be stored in an int so 2400 datapoints would require 4800 bytes of memory.
...R
In other words one reading for encoder2 for every revolution of encoder1
No. When en oder 2 changes (from 1 to 2, from 1013 to 1014, in one revolution 2400 changes) read where the encoder 1 is. And store these values.
I believe you need to check that carefully. I think (based on what you said earlier) that there are only 600 individual encoder positions.
The encoders has a quadrature signal, if you read every changes of each pin (first going up (1) second going up (2)… first going down (3)… second going down (4)) you have 600 pulses for 4 changes = 2400 changes per revolution.
That seems to me very different from the first part I quoted here. Now you seem to be saying that you want to record the position of encoder2 every time encoder1 increments
.
Yes, it is not important the number of encoder. The big gear must make one revolution so the encoder fixed to it must be the main encoder.
And you have not told us what you want to do when you have collected the data
Only compare the theorical position (where should be in an ideal gear) with the real position (where really it is).
About he memory not sure. I have to check it... Sleep time. Thank you very much. Tomorrow I will go on with it...
harana:
The encoders has a quadrature signal, if you read every changes of each pin (first going up (1) second going up (2)… first going down (3)… second going down (4)) you have 600 pulses for 4 changes = 2400 changes per revolution.
In the link you gave earlier it clearly says it is a 600p/r encoder. I suspect each of those positions generates more than 1 pulse - but that does not mean there are more positions. However you can write a short test program to verify the situation.
.
Now you seem to be saying that you want to record the position of encoder2 every time encoder1 increments
Yes, it is not important the number of encoder. The big gear must make one revolution so the encoder fixed to it must be the main encoder.
I'm trying to narrow down the options so I can envisage what a program needs to do. Will what I have suggested work? If not, then what do you need as an alternative.
Only compare the theorical position (where should be in an ideal gear) with the real position (where really it is).
Sorry for not being clear. When I asked what you want to do with the data I wanted to know if you want to send it to your PC or do calculations with it on the Arduino. I am trying to get to grips with something you have avoided answering a few times - what do you want to use Serial communication for?
...R
Hi again. About the data I prefer to make the calculations in other device, just in a PC or similar. For the Arduino board only take the data and send it through the Serial Port. This is why i need the serial port. There is another fast way to send it?