SetCounter issue with Quad Encoder

[chipfryer27]

Hi

I downloaded the Quad Encoder examples (which use 3D components) and when using the timer based example soon had it running in hardware.

All good so far, and I could reliably increase/decrease to limits.

I then modified the chart so that when the encoder was pressed it saved the current value to EEPROM (uC memory, not external) using WriteInt. When I reset, after initialising all that needed to be initialised, it retrieved and displayed the saved value. All good.

However I then used the WriteCounter command to set the value of the encoder to the previously saved value and things started to go a bit strange.

I had saved the value of decimal 24 to EEPROM and this was correctly retrieved. It was then used to set the value of the encoder. Without moving the encoder I expected to have 24 returned when read. Instead decimal 6 was returned.

Saving / retrieving and setting the following gave these results when read back by the encoder (note value correctly retrieved from EEPROM).

24 = 6
25= 6
26 = 6
27 = 6
28 = 7
29 = 7
30 = 7
31 = 7
32 = 8
33 = 8
34 = 8
35 = 8
etc

It is kind of as if the value is being shifted into the Encoder incorrectly. 24 = 0001 1000 but appearing as 0000 0110, being shifted two extra bits to the right. 27 = 0001 1011 = 0000 0110 (again showing as 6) with 28 = 0001 1100 = 0000 1110 = 7. This pattern repeats.

I didn't try in simulation, just hardware and I didn't try recreating the chart from scratch using 2D, however FC informed that the components were up to date.

Another more pressing matter arose so I didn't get a chance to try anything further.

Regards

[mnfisher]

Have you set the variable type for the encoder to 32 bit (in properties)?

If it's 16bit WriteCounter32 does nothing (which is a bit odd) - if 32 bit it sets the 'current' value. If it's 32bit WriteCounter gets #ifdef removed. Not sure why not have just one WriteCounter that works for either size data?

Martin

[chipfryer27]

Hi

Only changed pins and postscaler in properties, so Encoder is still set as 16-bit.

Guessing the reason they have both options is space. If you don't need 32-bit that extra two bytes may make a difference on a smaller PIC or the like?

When I next get a chance I'll try 32-bits and also creating from new using the 2D component, but that won't be for a few days.

Regards

[mnfisher]

It might save some memory - but both a 16 bit and a 32 bit counter are created (whichever size is defined) - the compiler 'might' optimise one out? Of course if the optimiser is good it would also optimise out the unused function (so the the pre-processor code is redundant?)

But - the bug hides elsewhere?

Martin

[mnfisher]

Looking at the code for the encoder - I'm not sure I follow how it works 100%.

I spot a few issues though:

for example Disable - the comment states that when disabled the encoder 'read' functions will return 0.

Code: Select all

/*=----------------------------------------------------------------------=*\
   Use :Disables the use of the quad encoder
       :Once this ist called, the read functions will return zeros until the next Enable() call
\*=----------------------------------------------------------------------=*/
void FCD_017b1_quadenc__Disable()
{
	// Encoder_Enabled = 0
	FCV_017b1_quadenc__ENCODER_ENABLED = 0;
}

However - the Read functions don't seem to follow this? (Tidied to remove pre-processor directives)

Code: Select all

MX_SINT32 FCD_017b1_quadenc__ReadCounter32()
{
	//Local variable definitions
	MX_SINT32 FCR_RETVAL;
	// .Return = Encoder_Count_Long
        FCR_RETVAL = FCV_017b1_quadenc__ENCODER_COUNT_LONG;
	return (FCR_RETVAL);
}

- CheckForChanges does return false (0) if disabled though...

I also can't help feeling an interrupt checking for pin changes is going to be good - rather than relying on the user calling CheckForChanges?

Martin

[chipfryer27]

Hi

In the component examples it gives a few options of using the encoder, one of which uses a Timer Interrupt that calls "check for changes". Works fine except to set the counter to a saved value (saving you from spinning the dial for ages ).

I doubt if I'll be doing much with it this week though.

Regards

[chipfryer27]

Hi

Just tried creating a quick test using the "new" 2D Quad Encoder components etc using v10.

Chart set a variable to decimal 24, then using WriteCounter set the value to 24. Using ReadCounter it then set a different variable to the value returned. Happy to report that this returned 24, so it seems the issue is with the "old" 3D component.

Regards

[chipfryer27]

Hi

Further to the above I thought I was going crazy.

In the above, which seemed to work, I was using a BL080 multiprogrammer. Yesterday I was using the older version and the problem returned. The EEPROM was correctly written/retrieved but the value displayed was "out" by a couple of binary positions

e.g.

Decimal 24 = 0001 1000
Returned 6 = 0000 0110

Decimal 28 = 0001 1100
Returned 7 = 0000 0111

This pattern repeats.

I tried every possible combination of writecounter / writecounter32 / read byte / int / float etc but problem remained.

This morning I returned to the BL080 and loaded the original test. This test initialises/enables all components, stores a value of "x" to the EEPROM, writes it to the WriteCounter then using the variable "Ret" reads the counter back and displays. All good no issue. Frustration returning, why does it work on BL080 and not on the other?

Safe to say we can discount any issue with the programmers, something is different somewhere. FC's are at same version and same database.

From the original test, I then constructed the intended program step by step. First I included the Timer Interrupt. All good, Next I included actually reading from the connected encoder and displaying the result in real time so to speak.

This should show the value of "Ret" retrieved from EEPROM and increment with each movement of the Encoder. In previous tests this showed the incorrect value as described above. This time it worked. Nothing wrong here....... Frustration level increasing......

However when I incremented the encoder, it was increasing by a factor of 4. Each turn would add/subtract 4 from the current value and is related to the PostScaler in the component properties. Default is 1:1 which records the number of transitions (typically four per "click"). I changed that to 1:4 which should then return the number of "clicks" and is what I usually use.

Now the problem returned. I'm not thaaat crazy after all...... If the postscaler is 1:4, although it then records each "click" rather than transitions correctly, it does not for some reason allow the writing/reading to/from counter to work correctly.

So whilst the issue remains, it is associated with the operation of the postscaler when set to 1:4, and seems to be performing >>2 (divide by four) on the value returned from ReadCounter.

I kind of see why this could happen if the component is counting transitions, and I can probably get around it by multiplying my value by four before Writing, but it seems a bit messy.

Regards

[Steve-Matrix]

Thanks for the info - this should be useful in helping fix the issue.

[chipfryer27]

Hi Steve

It would appear that the component counts the number of transitions and returns this, but when set to 1:4 it divides the return by four. I can see why it would do that. However when setting the counter to a predefined value (in my case 24) it doesn't know not to divide this initial setting. Now that I know what's going on I can simply multiply my value by four (<<2) before writing and this will resolve.

Regards