Exposed the focus motor position counter (relative) to lens_info.focus_pos (or, in Lua, lens.focus_pos). This counter has some nice properties: it appears to be the motor encoder output, as it doesn't lose track of its position, as long as the focus ring is moved by the internal motor.
TODO: combine motor position (high-res, relative, unknown origin, may lose position with MF) with focus distance reports (low-res, absolute, direction-dependent, probably with good repeatability) to get a precise estimation of the focus distance.
Also fixed a bug where the lens may get stuck at some endpoint, especially at low speed, even if you tell the lens to move away from that endpoint. This might also help with issue #2452 (not tested).
EOS M: refactored some code - are the focus ring triggers (for magic zoom and 5x/10x zoom) still working?
Note: on EOS M and 6D, the location of this counter is unknown, so I need some help with reverse engineering (just print the contents of PROP_LV_LENS and find out which offset contains the focus motor position). The current state would break the 6D and EOS M builds.
To answer my other question for EOS M, without finding focus_pos, just comment out that line.
is it as easy as printing PROP_LV_LENS?
I am using 6D's define for 70D and 100D but just to get the focal length right onto the display. thinking about it again some of my probs with fps override / dualiso etc might be related as I haveno clue what those value like off_0x08 etc mean::
I did have the lens on continuous autofocus, disabling it and re-running the test shows that the focus does not move.
Following your instruction for displaying PROP_LV_LENS this information printed on the screen:
3a9d 4000 3fc6 a000 3c9b a000 bb54 2000
I'm not sure if eight is enough, should I keep going?
Can you tell from those numbers which one is the focus motor position? Me neither ;)
That gave me an idea. I put the camera back into continuous autofocus and captured screenshots with the camera focused on two different distances. Does this help?
Doesn't look like, but that's the way to find it. Let's try some more numbers. To find out the array size, print len/2.
If this is a focus-by-wire lens, that counter would change when you turn the focus ring manually as well. It's similar to focus distance, but much more steps, and is proportional to how much you turn the focus ring (the focus distance is highly nonlinear). Also, it is 0 at power on.
So, it's not obvious from only 2 screenshots - you need to check the other hints as well.
I don't follow you on how to find the array size. Did some poking around and came up with this:
Note that manually focusing the lens will change the counter. I tried out some other lenses and it turns out that the first few digits never change but are different between the EF-M lenses that I have:
At least from my observations those are the digits that don't change and yes they are different on each lens.
In property handlers, you have a variable named len (you won't see it in the declaration, but if you look up the PROP_HANDLER macro, it's there). So, just print len.
Since each element in the array is a 16-bit number (two bytes), divide len by 2 to find out the array size.
The first 8 bytes are two float32 values. I'm not sure about their exact meaning, but it may be worth checking them as well.
print(len); doesn't work but this did:
This is what it printed: 3d 1e
Hope that's of some use.
Yes, that means the structure has 0x3D bytes, and if you interpret it as an array of uint16_t, you can use 0x1E items.
One of those should be the counter we are looking for.
I did this same test with the 700D and it reported:
I assume this camera has already been verified to work with the new code and only searching for the values for the 6D and EOSM. In any case I thought I'd report this result as a sort of sanity check that my tests are providing the right data. I did do another test that might prove interesting but is more complicated to explain so I am shooting a video to show exactly what is going on.
I didn't verify it, but I expect it to work. You could try running api_test.lua on it, if you didn't already.
I ran api_test.lua and reported my findings starting around the middle of this post:
Below is a link to a video showing what is getting displayed on the LCD. Note that in a prior test I noticed that moving the focus ring had no effect but when I made the video it did have an effect. This was probably because on my previous test the focus might have been at the close or far limit. It is difficult to tell with EF-M lenses where you're at.
I guess this hasn't really helped much but just to make sure, we're looking for the values for focus_pos on the 6D and EOSM, right?
A bit off topic but it seems that the EOSM controls the EF-M lenses differently than EF lenses via the adapter. In src/lens.h the prop_lv_lens structure has both a focus_dist and a focus_dist2. The focus_dist2 has some addresses but focus_dist does not. Could it be that focus_dist controls EF-M lenses and focus_dist2 controls EF lenses via the adapter? The reason I'm bringing this up is because running api_test.lua with an EF lens attached runs through the lens test rather quickly and it is obvious that the focus is moving while on EF-M lenses it takes a very long time to get through the lens test and there seems to be no activity with the lens focus. Shouldn't we also be looking for the addresses for focus_dist on the EOSM?
Interesting, so EF lenses are given focus commands just like before (some sort of compatibility mode) and EF-M lenses require a new set of commands?
Side note: that means, if you somehow manage to adapt an EF-M lens to an EF mount (even just by connecting the pins), it won't autofocus?
That appears to be true.
In theory. The EF-M has 9 contact pins while EF/EF-S has 8 contact pins (at least on the 700D body it does) so something must be different between the way the camera communicates with the lens.