QEP position counter unlimited (no reset on index)

How will you be counting without reset.. will you not need a reference? also if it is not reset then at one point overflow will happen.... most likely I didn't get your question - please clarify.

Hi Arefeen

The motor drives a linear stage through a gear with 0 backlash. A single motor revolution moves the linear stage 10mm, so to move the full range of 500mm - 50 motor turns are required. With 1024 encoder lines I get 4096 encoder counts per motor revolution i.e. 50 x 4096 = 204800  encoder counts for the entire stage range.

I want to implement a position loop (on top of the speed loop) that brings the linear stage anywhere I choose. So the eQep should serve double purpose:

1) Generate the required angle information for commutation using the FOC algorithm

2) Give the precise stage position count at any given time to enable closing the position loop.

Hope this clarifies my question. I will appreciate any tips for easy ways to do this.

Regards,

Danny

In TI's example the position counter is reset each revolution and the important information of the location of the stage is lost.

Danny,

Yes, the HVPM_Sensored example uses QEPCTL.PCRM = 00. Thus, in QEP_MACRO, we can always get the raw angle using QPOSCNT and CalibratedAngle. CalibratedAngle will just make our angle respective to phase A instead of the index slot on the encoder. In this way the calculation is done based on the counter always getting reset when the index pulse hits.

One potential idea to use this same method and add the ability to keep counting encoder position is to update a software counter when the index occurs. QEP_MACRO already checks the QFLG.IEL bit to execute some code when the index has occurred. You could add a line of code here to keep a running count of index occurances. Then, in QEP_MACRO, you would have both the raw angle in each revolution as well as a running total of complete revolutions.

As an alternative, SPRUFK8 (Piccolo eQEP Reference Guide), section 4.2.1 describes the Index Event Latch mode of operation. If you are not concerned with mode compatibility to the example software, it sounds like this may be the mode you are describing in your original post, and it may work for you. This mode would certainly have implications to the RawTheta calculations in QEP_MACRO, and thus the example software.

-Ian

As Ian mentioned a software counter can potentially offer you the feature. You generate an interrupt on Index" to keep track of number of rotations and to calculate the linear distance. On a separate note this can be a good feature to add in any future revision of eQEP module.

Hi Ian

Thank you for the answer. I tried it. I used the latched direction bit to decide whether to increment or decrement the turns counter.

Unfortunately I do not like the results. In normal operation when the motor rotates in positive direction turns counter increments properly and decrements when turning in the negative direction. But when the motor jitters near the index pulse the counter misses rotations or increments when it should decrement.

Any other ideas?

Danny

Danny,

When 'jitter' occurs near the index pulse, you may just be getting back to back index pulses and, for example, "missing" the first index pulse while reading the second in the isr, which is in the direction of the jitter movement (in reverse).  Can you check for this condition in software?  For example, when you read that an index pulse has occured (QFLG.IEL set) you might be able to compare QPOSILAT with the value of QPOSCNT from the previous isr execution.  For a true index pulse occurance, QPOSILAT should be relatively close to the QPOSCNT values from the previous isr.  You would have to check to make sure this does not conflict with any true reversal of direction.

An alternative would be to look at Index Event Latch mode as described above (SPRUFK8-Piccolo eQEP Reference Guide, section 4.2.1).  This would require (at least) modifying QEP_MACRO to get the proper RawTheta calculations.  These calculations would no longer be from a "zero" index/phase-A reference but from the previously latched value.  You would also have to handle over/underflows properly.

-Ian

Well if the motor really jitters significatly , I am not sure the QEP module alone can address the issue. The QEP module reacts to signal edges and therefore whenever it sees an edge the counter will count one way or another depending on direction. One possible way is to use IO qualification so that the module doesn't react to noise but if it gets a valid edge I am not sure how one can avoid counting. By the way, I am curious how you determined that the counter counts in wrong direction?

The motor doesn't really jitter (in fact I am very happy with the initial performance I am getting). I induced the jitter on purpose with intention to validate the robustness of my modified qep macros derived from TI's code example according to Ian's suggestions.

To answer your question "how you determined that the counter counts in wrong direction?"

I didn't make myself clear, the hardware counter counts perfectly (also there is no noise problem). My full turns software counter is the one that gave me the trouble near index angle. Some of the index crossings were missed. I still do not know the reason I probably did something wrong but I stopped this investigation.

I tested it in the following way: I put zeros for both speed and Iq references and quickly moved the shaft (by hand) back and forth around the index pulse angle. I used the eQEP interrupts on index and used the latched direction bit to determine whether to increment or decrement the software full turns counter. 

TI has a very powerful and fancy QEP module. From my experience with incremental encoder the more you can do with hardware counting the better. I don't trust frequent software intervention.

Today I managed to do what I originally intended to do. The position is counted continuously without resetting on index pulses. The mechanical and electrical angles are derived from the position register by mathematical mod calculation. I think the method is slower but my F28335 doesn't care. I noticed the motor moves now even smoother then with the QEP_MACRO()code example and consumes less current. This led me to test again the original example.

I found out that in positive direction motion QepCountIndex is almost always 4095 (for my 1024 lines encoder). In very low speed it may get to 4096. But when moving in negative direction QepCountIndex is 4 most of the time but in slow speed or when jittering around the index pulse it can be 3, 2, 1, 0, 4095 or 4096.  

This is strange; I would expect to always find the same number latched in the index pulse.

In addition I tried Ian's suggestion with Index Event Latch mode and another method of calculating the angles. This worked fine and the results where the same as the original QEP_MACRO() example but not as good as the method I described before.

Regards,

Danny

Many thanks for detail information ... it looks you have addressed almost all your concerns ... nice work.

     I've the same problem in my motor driver(TMS28035). EQEP is in Reset on Index Event mode (QEPCTL[PCRM]=00), my eoncoder is 2500 lines. If I rotate it forward and backward around the index position, QPOSILAT will show 4 or 9995, not the correct vaule 0 or 9999, QEPSTS[PCEF] is set.

     However,  if I keep to rotate the encoder in the same diretion, the error QPOSILAT value will be updated by Index , 4 to 0, 9995 to 9999. It seems  that EQEP can be wrong under reverse conditions, similar to early LM3S(See  http://focus.ti.com/lit/er/spmz007f/spmz007f.pdf  ).