Programmatic focus control and absolute/relative focus position

Started by sl0w0rm, March 30, 2013, 07:35:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sl0w0rm

I'm trying to build remote follow focus and after some research I think that it is possible to build very accurate one. I know that there is Rack Focus option but it is very limited and not much accurate with my Canon 17-55 IS USM when focal is set to 55mm (when speed is set to 1 it has about 709 steps from shortest distance to infinity but 739 steps on the other way). Step size depends also on the selected focal so it's not much useful for me. I'm trying to build something that works like this:
1. you can use AF or manual focus to point to selected object
2. once focus is ok you can remember this position
3. you can select any remembered point and selecting one will always work and will be very accurate

It sounds to great to be possible but I discovered that there is some counter that shows relative position of the focus. When you change focus position using PROP_LV_LENS_DRIVE_REMOTE this counter is always accurate even when speed is set to 3. You can find it at 0x20-0x21 (Canon 60D) in structure given when handler for PROP_LV_LENS is executed. For my C17-55 it allows to distinct about 1500 positions, for C100mm it's about 3000!

Now it's time to describe the problem ;) Sometimes PROP_LV_LENS_DRIVE_REMOTE breaks some Canon code and some events are no longer sent (for example PROP_LV_LENS). To fix this you have to press shutter button or go to menu and go back to LiveView. I don't have any idea how to fix this from code so I thought that maybe I can find this counter in some other place. And after some memory scanning and disassembly of original firmware I can't find source of this value. I found some related values near 0x265FC and 0x549DC but there is only last step size (it's not correct when last step was shorter because of limit in focus range) and what's funny there is previous value of the counter I mentioned before (it's always one step behind). Even when PROP_LV_LENS is not sent and value of counter in structure related to this property is not updated the one step behind counter is always refreshed :)

So now I can ask my questions :) Does anyone know:
- how to fix LV notifications from code when PROP_LV_LENS_DRIVE_REMOTE breaks them?
- where can I find the origin of this counter, I tried to find this in disassembled code but it's not so easy for me (Java guy ;) ) because code related to this addresses has hundreds of subs and operates on SP with is hard to track for me (at least until someone will run original firmware in qemu ;) )

a1ex

Nice find. But... I'm afraid I'm not able to answer your questions.

If you dig back into ml-devel, you'll find out an alternate implementation of focus commands, by sztupy (look for the first 60D porting attempts). It uses very fine increments, but seems more likely to become stuck.

Do you have a way to reproduce the broken LV? I know it happens sometimes on 60D, but don't have a clear pattern for reproducing the error.

sl0w0rm

Thanks for quick reply. I checked sztupy's code and it's great, now I can move focus with any step size I want. This allows me to reduce number of requests so there is less chance that LV will break.

The simplest way to reproduce broken LV is sending PROP_LV_LENS_DRIVE_REMOTE too often (without wait flag it occurs after few seconds). The same issue occurs when you use standard PTP service for this (0x9155). Unfortunately it also occurs when step wait flag is on and in theory the previous request was completed. But I don't know why and when it occurs in that case.

sl0w0rm

I found that shit ;) Now I now I was reinventing the wheel a little bit but if anyone is interested:

1. More accurate step size that doesn't depend on selected focal.

You can find in sztupy's code two versions, one that use AfCtrl_SetLensParameterRemote which does work but to get expected step sized you have to guess correct value for off_0x1D8 which is related to off_0x1D4 (that depends on given lens). So this method is not much portable because you have to hard code some values. The second version (which is commented) invokes prop_request_change for property PROP_LV_FOCUS and have one drawback - it doesn't work :) at least on my 60D 1.1.1. But you can change it a little bit and it will work fine:

uint32_t prop_focus_code = 0x80050001;
struct prop_focus prop_focus_data;
prop_deliver(&prop_focus_code, &prop_focus_data, 5, 0);

For C17-55 step size (0x01-0x02) can be set from 1 to about 1500 (from nearest point to infinity)

2. Getting access to counter that keeps relative focus position

The simplest way to get this is to handle value change for property 0x80050000 and read it from given structure at 0x20-0x21. This value is always refreshed but refresh is not instant, it takes few milliseconds before it is refreshed. If for some reason LV breaks handler for this property will not be invoked.

The second way is to invoke prop_request_change(0x8005001B, 0, 0x38) and handle value change for 0x8005001B - it returns the same structure as 0x80050000 but stored in different place. Counter value will be always correct in this method. Setting 0 (null pointer) to second argument doesn't break anything (at least on my 60D ;) )

3. Fixing broken LV on 60D
Just invoke prop_request_change(0x80050000, 0, 0x38) and it will magically work again. It looks like handler for 0x80050000 do some work and at the end it invokes  prop_request_change for that property so there is infinite loop. Unfortunately on 60D this loop can be finite when this handler will crash :)

Hope this will help someone ;)

a1ex

Very nice, I'll take a look. Did you find an easy way to tell when the LV is broken? (without using timeouts)

a1ex

Low-level version of PROP_LV_FOCUS:

Quote from: a1ex on July 22, 2016, 10:43:28 PM
5D3: 0x08, 0x09, 0x01, num_steps_hi, num_steps_lo, 0x07, 0x00, 0x00: lens focus control in LiveView (also works in paused LiveView). Commands appear to be queued properly, but breaks focus distance reporting.

a1ex

Quote from: sl0w0rm on April 08, 2013, 01:17:51 AM
2. Getting access to counter that keeps relative focus position

The simplest way to get this is to handle value change for property 0x80050000 and read it from given structure at 0x20-0x21.

On focus-by-wire lenses, this counter is updated when you focus manually as well.

This counter can give a very precise estimation of the focus distance. Here's what this property reports for the 24mm/28 STM lens:


BBA

@A1ex @dmilligan

I am glad you posted this and restarted this topic !
I have been working on the same subject in Lua with lens.focus (open loop, relative focus positioning) and lens.focus_distance.
It would be very useful to be able to work in closed loop with absolute positioning as it would drastically simplify all what I have done so far !
I am very interested in trying to do it but I would need a guidance.

My aims are:
- to implement advanced stack focus after focusing on specific objects to be in sharp focus (or blurry) and after storing their absolute positions;
- to better stack focus in the near infinity range by working in the "nearly linear" image field;
- to position one's lens to hyperfocal distance or to position the lens on specific and previously set "infinity distances".
Those apps may need the use of companion file(s).
Many thanks in advance!

So far, if anybody is interested, I have tried (with incomplete results and success, given the very wide search field) to:
- scan different lenses with step sizes (in domains) 1, 2 and 3 (ex: EF 100mm f/2.8L MACRO IS USM : 4416 steps in domain 1, 396 steps in domain 2, the fp reporting didn't work in domain 3 but lens.focus moved the lens on 55, 56 times, EF 24mm f/1.4L II USM in domains 1, 2 and 3)
- to absolute position a lens in domain 1, after focusing it (automatically (AF) or manually (M)) on an object. The algorithm uses the properties of the step function by translating (projecting) the uncertainty zone to parts of the step function where there is more information in between (and while counting the steps done back and forth as the lens moves); at the beginning, the uncertainty range is the whole lens; with the "step" function, we can know on which "step" the fp lies; then, by using moves in domain 2, the uncertainty range can be divided by 2 at each "larger" step; after domain 2, projecting in domain 1 (still to be better studied), it is then possible to do the same with the finest steps until the uncertainty falls to a few fine steps (the number of moves in a domain is less than the log2 of the uncertainty range measured in steps). The problem is to optimize the algorithm to get the most precision as, in open loop, each move can add a one (or more) step(s) uncertainty.

It requires to store the step function in a file for the lens to be used.
Some primitive tasks :
1) Scan a lens with precision in domains 1 and 2 to get the step function and store the results in a reference file for that lens
2) find the absolute position of a lens using the reference file and store the position in another file for further use (with ancillary tasks : add, remove, clear all,...)
3) use later the positions stored in this last file to position the lens at will as accurately as possible
As said, the caveat is that the stepper motors can loose some steps erratically, so the more you move, the more there can be uncertainty on the positioning.

Research directions:
- Continue to check with different lenses as, until now, I have mostly used fine steps : how can domain 2 and 3 be projected in domain 1 ?
- Work in the « image domain » as the distance of the focal plane is nearly linear in function of the « stepper motor » step number; this can facilitate the use of the near infinity focal positions. Then, translate to « object domain » distance.
- Position uncertainty can be studied : electric power supply; low cost lens vs L lens (better mechanical qualities for moving parts ; perturbation torques; chocs) intervention à la main, frottements...
- measurements in reality : focus on target, measure absolute position, compute (interpolating with step function) a distance: compare computed with measured distance

a1ex

I've exposed the focus motor counter in Lua (focus branch) as lens.focus_pos.

The focus test from api_test.lua reports:

lens = table:
  name = "EF-S24mm f/2.8 STM"

Testing lens focus functionality...

Focus distance: 220
Focusing backward...
Focus distance: 655350
Focus motor position: 1209
Focusing forward with step size 3, wait=true...
..................
Focus distance: 160
Focus motor position: -597
Focusing backward with step size 3, wait=true...
..................
Focus distance: 655350
Focus motor position: 1209
Focus range: 18 steps forward, 18 steps backward.
Motor steps: 1806 forward, 1806 backward, 0 lost.
Focusing forward with step size 3, wait=false...
...................
Focus distance: 160
Focus motor position: -596
Focusing backward with step size 3, wait=false...
..................
Focus distance: 655350
Focus motor position: 1210
Focus range: 19 steps forward, 18 steps backward.
Motor steps: 1805 forward, 1806 backward, 1 lost.
Focusing forward with step size 2, wait=true...
...
Focus distance: 160
Focus motor position: -596
Focusing backward with step size 2, wait=true...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 120 steps forward, 119 steps backward.
Motor steps: 1806 forward, 1805 backward, 1 lost.
Focusing forward with step size 2, wait=false...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 2, wait=false...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 119 steps forward, 120 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.
Focusing forward with step size 1, wait=true...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 1, wait=true...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 453 steps forward, 453 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.
Focusing forward with step size 1, wait=false...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 1, wait=false...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 453 steps forward, 455 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.

Focus test completed.


So, the 24mm 2.8 STM has about 1808 steps, and it doesn't lose track of its position, even if I focus manually during the test. Nice :)

The small differences are probably given by the repeatability of the limit stops (the motor doesn't stop after a predefined number of steps, but when reaching some sort of switch, or when the lens appears stuck - including you stopping it forcefully).

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).

BBA

Very, very nice !
Can't believe it !
I can't wait to test it.
I have dowloaded the latest nightly (from today, the 24th).

magiclantern-Nightly.2016Aug24.5D3113.zip
Built on: 2016-08-24 01:11:02 +0200
Changeset: 96ca71e

If possible, where can I download your gem ?

(I have a 5Dmark3 so I won't be able to help you with reverse engineering on EOS M and 6D models)

a1ex

It's not yet in the nightly, and it may take a while, since the current state would break the 6D and EOS M builds. Meanwhile, you can compile the focus branch (and once you manage to do that, you can start playing with the low-level code 8) ).

garry23

As @BBA says, really exciting stuff.

For me the real value will come when I can make use of the developments in a Lua script.

I have learned to wait and watch ML developments, i.e. ML has helped me hone my patience  ;)

Cheers

Garry

Greg

55-250mm IS STM @ 55mm
lens = table:
  name = "EF-S55-250mm f/4-5.6 IS STM"

Testing lens focus functionality...

Focus distance: 38000
Focusing backward...
Focus distance: 655350
Focus motor position: 579
Focusing forward with step size 3, wait=true...
......
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 3, wait=true...
......
Focus distance: 655350
Focus motor position: 579
Focus range: 6 steps forward, 6 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 3, wait=false...
......
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 3, wait=false...
......
Focus distance: 655350
Focus motor position: 579
Focus range: 6 steps forward, 6 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 2, wait=true...
........................
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 2, wait=true...
......................
Focus distance: 655350
Focus motor position: 579
Focus range: 24 steps forward, 22 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 2, wait=false...
.......................
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 2, wait=false...
......................
Focus distance: 655350
Focus motor position: 579
Focus range: 23 steps forward, 22 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 1, wait=true...
...
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 1, wait=true...
...
Focus distance: 655350
Focus motor position: 579
Focus range: 281 steps forward, 270 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 1, wait=false...
...
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 1, wait=false...
...
Focus distance: 655350
Focus motor position: 579
Focus range: 281 steps forward, 273 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.

Focus test completed.

BBA

The very good news is that this new counter gives access to finer steps than what can be achieved with lens.focus and step sizes of 1 ( lens.focus(1,1) ).
This gives a common base of measure (let's say in sub-steps) for moves done with different step sizes (1,2 and 3).

For example, with the EF24mmf1.4LIIUSM, one step of size 1 gives 7 sub-steps (one step of size 2, 30 sub-steps, and 207/208 sub-steps for step size 3).
At each lens position measured in sub-steps, just add the measure in sub-steps of the move you want to do to know your new position in sub-steps (always some errors are possible, that don't matter when AF as there is a "consigne" (phase,contrast) that drives a closed loop).

There is an offset given by the initial position of the lens. So it is not absolute but relative to the initial lens position (hence the negative/positive numbers of sub-steps).

I don't know if turning the lens to one mechanical end (macro or infinity) will give a repeatable absolute scale from one experiment to the next.

Because of some errors, the total excursion of this lens (maybe is it faulty ?) can vary, particularly with step size 3. The sub-steps scale must then be "adjusted", if possible, to the ones of step-sizes 1 and 2.
I would like there were a mean to directly move the motor in sub-steps, like a lens.focus of "base" step size 0 !
It would then be easier to go to a given sub-step position.

Here are some graphs for this lens. The blue dots are for step-size 1 ( B column), red = step-size 2 ( E ), and yellow = 3 ( H ). The X axis is in sub-steps with offset = 0. The y axis represents the (object) focal point in mm. The step size 3 (yellow) curve was given a visual offset of -5 to better "adjust" it to the other dotted curves.
The near infinity (object) range is discarded.

https://www.dropbox.com/s/s60kaj63dpmptaw/EF24mmf14LIIUSM_1.jpg?dl=0


https://www.dropbox.com/s/iickvs2t6qjzch9/EF24mmf14LIIUSM_2.jpg?dl=0


https://www.dropbox.com/s/wmliyr46kevysz7/EF24mmf14LIIUSM_3.jpg?dl=0



 

BBA

I would like to share the graphical result of 88 lens.focus( num-steps, step-size) commands in the near infinity end.

The offset of the lens motor position is set to have 0 at infinity end. All the positions are negative numbers.
Axes:
X = number of the lens.focus command
Y = lens position in sub-steps
Labels = Y

Near infinity ( Y = 0 => X axis ), the sort of clipping is due to the fact that the lens position does not move anymore but commands are still sent until the lens.focus function returns the error message "false".
All the lens.focus commands are sent with wait argument = true.
The parameters of the lens.focus command are given near each command in the form : num-steps( step-size ) for instance : 2 steps of step-size = 3 is represented by 2(3).

You can see at the end of the curve the tricks used to move the lens motor of :
1 sub-step = 4(2) followed by 17(1)
4 sub-steps = 2(2)  "          "   8(1)

The move to infinity end are done one step at a time and delays in between which should not be that good for friction motors (one can hear each move distinctly as the friction surfaces are separated and comme back in contact).
For big jumps, I think it would be better to use big steps (step-size = 3) with ?maybe less precision? .
To be verified : use big num-steps of step-size = 1 or 2 (more precise?).


https://www.dropbox.com/s/h993qiouwhqvf60/Lenspath_2.jpg?dl=0


BBA

I have been using the lens.focus_pos counter for some time trough lua scripts with a compile of the focus branch (thanks @a1ex, @dmilligan, @dfort,...).

It is trial and error so nothing is definitely understood....
I will try to share more later as I can figure out some more correct hypotheses (The most annoying thing is the "random" or "not so random" variation of the step length during a scan from macro end to infinity end and as consequences, the repeatability and the final precision achieved).

There were a lot of surprises (at least for me).
To give one idea, I tested with the EF 17-40mm f/4 L: what is the length of one step (step-size=1) as given by lens.focus_pos (in sub-steps) :
- at a focal length of 40 mm, one step measures 4 sub-steps (it's pretty constant);
- at 17mm, one step measures 14 to 13 sub-steps.

Below, you can find the result of the scans from macro to infinity.
I tried to move the zoom barrel during the scan : the step lengths changed while zooming.
So, even if the total length of the lens in sub-steps is (nearly) constant, this length is achieved with steps of different length depending on the zoom factor.

https://www.dropbox.com/s/6cm5xqfe6j7zhay/EF17-40mmVarizoom.jpg?dl=0

I watched some videos of zoom disassembly on youtube : on some zoom lenses, there is a Gray encoder for the zoom barrel: IMHO, the lens can know an estimation of the zoom factor and therefore change the step length accordingly...

BBA

To try to sort things out, and try to find out what is a sub-step, I would like to test the sub-steps moves on a target with a 45° rule (the one that can be used to micro adjust lenses) and then send lens.focus commands and take pictures to see where the focus point (actually) moves away, and what value is returned by the lens.focus_pos.

The problem is that the "camera.shoot(64,false)" command refocuses each time before taking a picture (even with the "should AF" argument set to "false").
Even, I have tried to use stack focusing scripts that are working with the last unified branch. The same refocusing happens at each shoot.

Do you think something has been changed in the focus branch with camera.shoot ?
Maybe is my compile is faulty (last compiled on the 2016/10/10) ?
Any idea ?

a1ex

Interesting find - the step size probably depends on the reported focal length. Unfortunately, that only serves to increase the complexity for those lenses...

My theory is that step commands are not very exact, and the error may add up. So, I suggest closing the feedback loop like this:
- "home" the lens: at startup, move the focus ring all the way in some direction (or both) until reaching the limit
- use the focus_pos counter to know how many step commands to give (don't assume anything about their actual step size)

To check the repeatability, I suggest moving the lens to random positions, and then back to some fixed lens.focus_pos (the one with perfect focus on the ruler), take a (silent) picture, read the AFMA value from the ruler (may be hard to automate), and plot the results.

Tip: if you focus the camera on the target, then restart, lens.focus_pos will be 0 at that point (where focus should be perfect). So, just send focus commands at the lowest speed (or maybe at higher speeds first) until lens.focus_pos crosses through 0.

To diagnose camera.shoot(64,false), you need to find out whether the focus argument arrives as AF_DISABLE in lens_take_picture.

BBA

@A1ex
Thank you for your answer! I mostly agree with you.

Quote
To check the repeatability, I suggest moving the lens to random positions, and then back to some fixed lens.focus_pos (the one with perfect focus on the ruler), take a (silent) picture, read the AFMA value from the ruler (may be hard to automate), and plot the results.

The mean error should be half a step (of step-size 1), am I right ?

I can do some experiments with the 5Dm3 and the EF 24mmf/1.4 L USM. With that lens (it is not possible with all lenses) I can use domain 2 and 1 moves to get, at least that's what I hope, a better precision. (There is a tradeoff speed/precision)(one step is 7 sub-steps in length, half a step is 4 sub-steps in length). The difference in precision is not that big at low distances : that's why the ruler test should be interesting. I don't know if the difference will be of any use when focusing for astrophotography.

Quote
To diagnose camera.shoot(64,false), you need to find out whether the focus argument arrives as AF_DISABLE in lens_take_picture.

I am not that used with compiling.
I don't know if it is relevant :
I have seen a problem in my Lua scripts with the value of the KEY.SET constant. The value returned by keys:getkey() when pressing the SET key (5Dm3) is 10 but the value of KEY.SET is 9.
Could there be a difference with AF_DISABLE  constant too ?


dfort

Quote from: BBA on October 20, 2016, 04:35:59 PM
I am not that used with compiling.

How did you get the focus branch build? It is a development branch so it needs to be recompiled periodically as changes are committed.

You certainly have the technical ability to compile ML. I've written a few tutorials that make it relatively easy for both the Mac and Windows.

Quote from: a1ex on August 24, 2016, 02:56:27 PM
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).

I tried to help with the EOSM but didn't quite understand how to find which offset contains the focus motor position (focus_pos). I recently found out that there is a difference between the way EF and EF-M lenses are handled by the camera. Apparently the data in lens.h is for EF lenses mounted via an active adapter. We should probably go back and revisit lens_step, focus_dist and focus_dist2 for EF-M lenses.

Are there instructions somewhere that details how to print out the contents of PROP_LV_LENS? I mean something on the level of explaining it to your grandmother?

DeafEyeJedi

Re: EOSM -- I somewhat remember @a1ex asking me to do the same earlier this year and believe it has to do w "Don't click me" and I tried to understand the riddles but couldn't get around it. Perhaps I should dive in along w you @dfort?
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dfort

Quote from: DeafEyeJedi on October 21, 2016, 07:10:02 PM
Perhaps I should dive in along w you @dfort?

That would be great. If you can find those instructions please share. I was getting close a while back but didn't quite get there.

https://bitbucket.org/hudson/magic-lantern/pull-requests/748/focus-backend-updates-precise-focus/diff

BBA

@dfort
Quote
How did you get the focus branch build? It is a development branch so it needs to be recompiled periodically as changes are committed.

I compiled the branch.
On bitbucket.org, I found the focus branch. A1ex had written he had exposed the lens.focus_pos. I saw it as one of the last commits in the focus branch (on the 2016-08-24).

You made a very good job explaining how to set up a development setup on a macintosh ( for the unified ) and I want to thank you very much for that. I found it very helpful.

I found the hg commands to use to update the set of source files you have on your local computer and used those for the focus branch.

I must say I have been working with different systems/languages and, particularly, with HP-UX, but it was a long time ago and I have not used it enough : to be sure, I should dive into it again, and better know what I am doing...but I have preferred to get new skills in Lua  and try to solve problems when focusing in the near infinity range as Garry23 was writing his stack focusing script.

I think the compilation went not too bad : I had 2 errors with the documentation generation that (I think) could be ignored.
The lens.focus_pos went very well on the 5Dm3 and all the lenses I used (I still have to share about them).

I got problems when I tried to use the camera.shoot(64,false) command after moving the focus position: the camera refocused automatically at each shot.

A1ex told me to check if the false argument arrives as AF_DISABLE in the lens_take_picture routine.

@dfort @DeafEyeJedi

I would very much like to work with you to find out how to trace/check the different values we have to find.
(sorry for my english)


DeafEyeJedi

@dort & @BBA --

Here's what I was able to find dating back to March/April of this year (from the EOSM thread) and this is what he asked me to do...

QuoteDo you mind printing the value of get_current_dialog_handler() during movie playback? ML couldn't figure out that in the playback screen you actually have a video.
QuoteYou can't do it from Lua (or at least not yet), but you can put that in a printf or bmp_printf or NotifyBox somewhere (for example, in don't click me).

...and couldn't get my head around these two hints with my findings here. So not sure where exactly should we take a dive into first?
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

BBA

@dfort
I know I have gone too fast and I have taken some risks (Sorry for disturbing others because of that).
I should first use the sourcetree app to be sure the sources are sync'd.

@DeafEyeJedi & @dfort
(Please correct me if I am wrong or if I go too fast or too slow for you)

To summarize:
1) I have seen there are too many debugging messages coming all the time on the screen.

2) You probably know you can give instructions to the compiler to skip (or not) given code chunks or to replace some character strings (cf. the lines beginning with the # symbol).
This is particularly useful when debugging or when the code to compile has to be different from one camera to the other.
This feature will help you stop those many debugging messages from messing your own messages.

3) You also probably know where the source files are located on your computer and how to find given character strings in those files (search field in the finder or "grep" instruction with the OS X console).
This will help you locate where to switch off those debugging messages from being compiled the next time you compile.

4) After you get rid of those debugging messages, you can put your own debugging instructions and define some character string to switch them on or off.