Quadrature Enocder Simulation

Bob-

Thanks for the information about your project. Simplifying the test environment is good practice.

My grandfather was a tool and die maker in the overhead belt days, and my father owned a large machine shop so I am happy to be involved in metal working projects.

When I've finished the quadrature simulator code and want to share it with others, should I put it on Github or paste the code into a post?

Certainly you should post your completed code, or perhaps the serial monitor version, in this thread.

There is also a forum section called "Exhibition/Gallery" where completed projects are often posted.

Github is a good choice for hosting the code somewhere other than this website. It will be useful if you are directing people from metal working interest groups to your code and linear encoder projects.

Hi Cattledog,

I gave up the idea of having a PC based application to drive the QTG as it didn’t look like it was really worth the effort.

So here is the serial controlled final version.

I hope you get a chance to try it out.

I attached the file as it was above the 9000 character posting limit

Bob

Quadrature_test_generator.ino (16.5 KB)

Thanks for posting the completed code. You have put good effort into making the program more flexible, and I hope that you are finding it useful for your display development.

I have one observation on what you have done.

One of the the original ideas behind the code was to benchmark encoder reading algorithms or test programs reading encoders. The generator was running on different Arduino from the unit running the encoder reading software. Errors and speed were important.

What you have done is to place the distance targets and incrementing/decrementing them within the isr and they will always be accurately met. You really don’t test for missed counts if the encoder reading algorithm is slow or if interrupts are missed. This would be important if polling, rather than interrupt encoder reading algorithms were used, or if the quadrature interrupt isr were improperly lengthy and counts were missed while interrupts are disabled when the isr is executing.

I think you can make the distance targets independent of the quadrature reading isr by using an overflow interrupt on Timer1 so that each time it reaches ICR1 you record a count and use that count to verify the algorithm and show that no pulses are missed. You would have a count derived from the hardware timer, and a count derived from the isr or other reading routine. The two values should match if the reading algorithm is fast and accurate.

This use of the quadrature generator may be of no use to you as I doubt that the displays are interfering with the interrupt based counts and the algorithm used.

Cattledog,

Thank you for taking the time to comment.

I didn't properly think through your earlier (and this times) comments about using the overflow of the timer to record counts. I will look into adding it. What was the highest speed you got it to work?

Your comments about the speed and errors are noted. In an earlier version I did keep track of errors in the ISR but after some thought I replaced it with a error flag instead. The reasoning being that the amount of errors isn't very useful to me and also that the change made the ISR run faster. I can also compare the value on the DRO display to the QTG and they should match. That was the inspiration for the oscillate mode. So that I can leave the test looping overnight and the numbers should match when the loops end. Because the speeds of linear encoders are more manageable than rotary ones the QTG should be OK, but time will tell.

I think your idea of the encoder & decoder in the same micro is a stroke of genius. I would have never thought that up in a lifetime!

Now I need to start using the QTG...

Bob

PS Did you ever consider using an FPGA for this?

I sent my code to Visustin to get a flowchart made. (http://www.aivosto.com/visustin-service-free.html)

It looks really pretty and it unravels my spaghetti code nicely.

Attached is the pdf that they sent me.

Quadrature_test_generator V1.0 flowchart.pdf (28.4 KB)

Hello, friends! Somebody can tell how to adapt the code for encoder emulation for timer0. I need to emulate 2 encoders at the same time.

Thank you in advance...

how to adapt the code for encoder emulation for timer0. I need to emulate 2 encoders at the same time.

The quadrature emulation code in this thread is written for a 16 bit timer where the frequency can be set with ICRn.

For multiple instances, you will need to use an Arduino with multiple 16 bit timers like the MEGA. As far as I know, Timer0 is an 8 bit timer on both the Uno and the Mega and can not be used for the quadrature generator.

Hi Scorpkolev, If you want the simulator to have two channels then as Cattledog says you need another 16 bit timer. I needed 4 channels for the original project. It was easy to do by using extra arduino UNOs one for each channel all running the same code. This method has the added benefit that the channels are asynchronous to each other and so you can uncover more problems in your testing. When finished I just recycled the Arduinos for the next project.

I don't have a need to improve the simulator, but if I did, I would use the new Arduino Vidor, and use the FPGA part, as a multiple generator.

Hats off the Cattledog for helping me originally get this going...

Hi Scorpkolev

I've just seen the web page for the new arduino MKR Vidor 4000 that has an FPGA on it. There is a sketch to do 11 simultaneous quadrature encoder inputs at over a million pps.

I think if it was reprogrammed as a simulator, it would do any speed you are likely to encounter.

Bob

cattledog: The quadrature emulation code in this thread is written for a 16 bit timer where the frequency can be set with ICRn.

For multiple instances, you will need to use an Arduino with multiple 16 bit timers like the MEGA. As far as I know, Timer0 is an 8 bit timer on both the Uno and the Mega and can not be used for the quadrature generator.

Good afternoon! Thank you all for your advice. I made a mistake. But now I try to run a published code on the Arduino Mega and COM monitor stops responding when you run the command f. Can you tell me what the problem is?

Hi skorpkolev,

The code was made to run on a Uno. Why are you using a Mega?

To run it on a Mega, which has different hardware, you would have to make changes.

It would be best to test it on a Uno first, then migrate to the mega after it is working properly.

bob

bobdring: Hi skorpkolev,

The code was made to run on a Uno. Why are you using a Mega?

To run it on a Mega, which has different hardware, you would have to make changes.

It would be best to test it on a Uno first, then migrate to the mega after it is working properly.

bob

I ran on UNO. The code works correctly. I can transfer to MEGA if they tell me what the problem is. I do not understand. = (

Scorpkolev: I can transfer to MEGA if they tell me what the problem is. I do not understand. = (

What is the problem you encounter then?

As long as you're just working with Timer1 I don't expect any issues. Of course you have to make sure the output pins you declare in the code match your actual setup.

If you still have issues, start by reading the forum sticky and follow the instructions (so: post code, describe problem in detail, provide circuit diagrams, etc).

Hi Scorpkolev,

In a previous post you said..

Scorpkolev: Hello, friends! Somebody can tell how to adapt the code for encoder emulation for timer0. I need to emulate 2 encoders at the same time.

Thank you in advance...

You were told that this would require an extra 16 bit timer.

So you want to migrate to the Mega which has an extra timer

But the code I wrote doesn't work on the Mega.

So you will have to change it.

At the very least the statements effecting the pins (timer, digitals, interrupts etc) will need to be changed because the pins numbers are different on the Mega

Then the program commands need to be modified to allow you to choose which QE output. So that commands to each QE output can be different.

Even if you have the skills to do this modification you might then find that there isn't enough processing power in a Mega to service the interrupts for two simultaneous channels at reasonable speeds.

If the program hangs, then you might put in some printf's to tell you where it is in the code, and what it is doing.

As I said before I needed 4 QE channels and I used 4 Unos. and once testing was finished I reused them for other things

Good luck

Bob

This just helped me out sooo much. I really appreciate all the work you AND Cattledog have put into this. This was a FANTASTIC thread to read through, and was so incredibly helpful.

Thanks again.

bobdring: Hi Cattledog,

I gave up the idea of having a PC based application to drive the QTG as it didn't look like it was really worth the effort.

So here is the serial controlled final version.

I hope you get a chance to try it out.

I attached the file as it was above the 9000 character posting limit

Bob

This just helped me out sooo much. I really appreciate all the work you AND Cattledog have put into this. This was a FANTASTIC thread to read through, and was so incredibly helpful.

Thanks for the kind words @makeitdad. What application did you use this code for?

cattledog: Thanks for the kind words @makeitdad. What application did you use this code for?

Proof of concept for a project at work. I do contract mobile and industrial controls for a living, and a customer was concerned about the speed at which our hardware we spec'ed out for a project for them could take in digital inputs, as the application is relatively quick, and they are using a very high resolution quadruple output encoder (4 pulses all 90° out of phase, I had never seen one like it before). I was able to use this application to simulate two AB encoders, and run them into two sets of AB counter configured inputs, and then just run an algorithm to combine the signals to a single count. I was able to prove this out in a matter of hours instead of a matter of days (and the cost associated with the following) having to ship a bunch of encoders around, then build a whole stepper motor project to spin said encoders a known number of rotations/degrees at different frequencies, prove the stepper motor project/system was accurate, etc...

I loved being able to command it a certain number of counts, being able to oscillate it back and forth helped me catch a very minor bug (but a bug none-the-less) in how I handled a counter overflow.

Seriously though this project just worked, and I confirmed signal accuracy with my o-scope. This saved me DAYS of work. The only thing I had to do (and this is only because the inputs into the controller we are going to actually be using needs 9-32VDC inputs) was I had to build two high side switch circuits for the arduino outputs so they could switch a 24VDC into the controller instead of the 5VDC arduino outputs. Transistors for the win! I could only run up to a 12.5kHz output before my falling edge fell to slow. something something slew rates or something... I don't know I'm a mechanical engineer by education, I just vaguely know what I'm doing most of the time. Thank goodness for this forum and others like it! But 12.5kHz was fast enough to prove the project out.

If anyone is interested, I wrote a quadrature generator for the UNO . It uses only the timer hardware once started and can run up to 4Mhz without using any interrupts CPU cycles.

Here is the code…

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.