# 6d/100L macro/Kenko 2X TC lockup



## langdonb (Dec 25, 2013)

Just tried my Kenko 2x Pro300 with 100mmL lens on a 6d and it locks up the camera...can't shoot in any mode, auto or manual focus, etc. and when I shut off the camera, LCD continues to display. Remove Kenko, remove battery, restart and camera/lens works fine. 

When used on a 70-300 L lens, the Kenko camera works normally. Any ideas on what is going on would be greatly appreciated!

Just tried it on a 60D body, the 100L works fine. Seems to be a 6D body issue??


----------



## Marsu42 (Dec 25, 2013)

langdonb said:


> Just tried my Kenko 2x Pro300 with 100mmL lens on a 6d and it locks up the camera...can't shoot in any mode, auto or manual focus, etc. and when I shut off the camera, LCD continues to display. Remove Kenko, remove battery, restart and camera/lens works fine.



It's a known problem, Kenko even deprecates using the current extenders on 5d3/6d (I'm still hoping for a working update) ... disable autofocus micro adjustment and try again.


----------



## Lichtgestalt (Dec 25, 2013)

my 1.4 kenko (blue dot) works fine with the 6D and 100mm L.


----------



## ftico (Dec 26, 2013)

It is a known issue, try disabling AF microadjustments...

See e.g. http://www.canonrumors.com/forum/index.php?topic=17450.msg330286#msg330286

Hope this helps, happy holidays!


----------



## langdonb (Dec 26, 2013)

Thanks for your replies. Shutting off AFMA solved the problem, but as my 100L needed a +9 AFMA, not sure the overall solution will be satisfactory...


----------



## dgatwood (Dec 26, 2013)

langdonb said:


> Thanks for your replies. Shutting off AFMA solved the problem, but as my 100L needed a +9 AFMA, not sure the overall solution will be satisfactory...



Complain to Canon. A camera body locking up (freezing) is an unacceptable firmware bug, regardless of whether it occurs with Canon's lenses or someone else's. It's a bug, and Canon needs to fix it.


----------



## Random Orbits (Dec 26, 2013)

dgatwood said:


> langdonb said:
> 
> 
> > Thanks for your replies. Shutting off AFMA solved the problem, but as my 100L needed a +9 AFMA, not sure the overall solution will be satisfactory...
> ...



Nope, it's a bug with Kenko. Complain to Kenko. Clearly did not reverse-engineer Canon's software properly.


----------



## Marsu42 (Dec 26, 2013)

Random Orbits said:


> Nope, it's a bug with Kenko. Complain to Kenko. properly.



Complaints have been made, and they already deprecate the tc with 5d3/6d because of this bug... no way to "fix" it than to replace the whole thing since 3rd party manufacturers (Sigma, Yongnuo) only recently got smart enough to put usb interfaces into their products.



Random Orbits said:


> Clearly did not reverse-engineer Canon's software properly.



I doubt that, they re'ed what was the lens-body protocol at the time - but Canon changed or extended it, at least to enable dual afma for zooms. No one knows the change necessarily meant breaking the competition's products, but personally I don't think Canon minds a lot as they sell their own tcs.


----------



## Random Orbits (Dec 26, 2013)

Marsu42 said:


> Random Orbits said:
> 
> 
> > Nope, it's a bug with Kenko. Complain to Kenko. properly.
> ...



I don't think so. The version II TCs were out before the 6D/5DIII and did not need to be revised when the 6D/5DIII came out. Canon extended the protocol, but what was existing worked as before. That Kenko did not get reverse-engineer the software correctly is not Canon's fault. That is the risk of buying third party parts. My original post is that it is not Canon's fault that Kenko does not work with new cameras. Kenko could have updated the software/firmware for a nominal fee, but chose not to. Not Canon's fault. Dgatwood's point is that it's Canon's responsibility to have their equipment work with third party parts. I'm saying it's the other way. What Sigma is doing is a step in the correct direction.


----------



## dgatwood (Dec 26, 2013)

Random Orbits said:


> dgatwood said:
> 
> 
> > langdonb said:
> ...



No, it isn't. If is fails for a Kenko device, then it can fail with the lens directly if the response gets garbled because of a bad connection. More to the point, it is a fundamental tenet of computer security that if your software crashes because of bad input, it is always the fault of the software, not the data.

If the camera refused to recognize the lens, we could blame either Kenko or Canon, but because it crashes the whole camera, Canon is entirely at fault.


----------



## dgatwood (Dec 26, 2013)

Marsu42 said:


> Random Orbits said:
> 
> 
> > Nope, it's a bug with Kenko. Complain to Kenko. properly.
> ...



Show me a Canon 3x extender that works with the 70-300L, and I'll buy one.


----------



## Marsu42 (Dec 26, 2013)

Random Orbits said:


> I don't think so. The version II TCs were out before the 6D/5DIII and did not need to be revised when the 6D/5DIII came out.



... most likely Canon had scheduled the protocol extension before the v2 tcs, but they didn't implement them - just like they will have the specs for the 5d4 & 1dx2 in the drawer already to avoid compatibility problems once they are released.



Random Orbits said:


> Kenko could have updated the software/firmware for a nominal fee, but chose not to.



How do you know they have already have fix at all (they didn't release a new version, and didn't do a silent update yet afaik)? And if they have, maybe it's plain impossible to update the old tcs just by fw.



Random Orbits said:


> Not Canon's fault. Dgatwood's point is that it's Canon's responsibility to have their equipment work with third party parts. I'm saying it's the other way.



Not to be mistaken: I agree that Kenko is the company to act, the not very widely known warning isn't really convincing, they seem to choose the "don't ask, don't tell" approach until when they've got an updated version ready ... and if.



Random Orbits said:


> What Sigma is doing is a step in the correct direction.



Yes, we can certainly agree on that  ... Yongnuo did the same with their new flash controller and there's already the first fw update out for 6d & 5d3.


----------



## Marsu42 (Dec 26, 2013)

dgatwood said:


> If the camera refused to recognize the lens, we could blame either Kenko or Canon, but because it crashes the whole camera, Canon is entirely at fault.



Nope, Canon does not say Kenko tcs work with their cameras, why should they be responsible if they don't? If you try to superglue a Nikon lens on your ef mount and it doesn't work, would you complain to Canon?

The one thing Canon could help with is to introduce a fair licensing scheme for their protocols to enable 3rd party manufacturers to release more compatible products, enhancing the whole Canon "system". Obviously, Canon decided against this, and they are free to do so, so there you are: http://media.onecall.com/Image_Products/Canon/3rdPartyLenses.pdf


----------



## Mt Spokane Photography (Dec 26, 2013)

dgatwood said:


> Complain to Canon. A camera body locking up (freezing) is an unacceptable firmware bug, regardless of whether it occurs with Canon's lenses or someone else's. It's a bug, and Canon needs to fix it.


A third party makes a item that doesn't work with Canon, and you expect Canon to fix it??


----------



## GmwDarkroom (Dec 26, 2013)

langdonb said:


> Thanks for your replies. Shutting off AFMA solved the problem, but as my 100L needed a +9 AFMA, not sure the overall solution will be satisfactory...


Back to the original question:

If you're going to be doing macro that close, I'd suggest going to Live View so that the mirror is up when you take the photo. That kind of vibration can affect the results at that close of a focus distance. If you use Live View, then the AFMA isn't necessary for accurate focus.


----------



## dgatwood (Dec 27, 2013)

Marsu42 said:


> dgatwood said:
> 
> 
> > If the camera refused to recognize the lens, we could blame either Kenko or Canon, but because it crashes the whole camera, Canon is entirely at fault.
> ...



I would expect it to not work, but if it caused the camera to lock up, yes, I would complain.




Mt Spokane Photography said:


> A third party makes a item that doesn't work with Canon, and you expect Canon to fix it??



Yes. This is what we computer programmers refer to as "code smell". In my nearly three decades of computer programming experience, I've found two rules to be almost invariably true:

[list type=decimal]
[*]A bug like this is typically caused by a division by zero error, failure to do proper bounds checking, or other *extremely* sloppy programming—the sort of mistake that should almost never occur in shipping code and, once discovered, should *never* make it into a second revision of that production code.
[*]If there's sloppily written code in one part of a piece of software, there's usually sloppily written code throughout the software in question. After all, if the QA department didn't catch such an easily reproduced bug, they probably didn't catch lots of even more serious bugs.
[/list]

Quality products simply *do not crash reproducibly, period*. In most software engineering organizations, a crasher-level bug that is easily reproduced would be considered a block-ship-level bug, whether the company guarantees compatibility with that other product or not. And proper engineering organizations—even the ones that don't guarantee compatibility with other companies products—do typically *test* a heck of a lot of them, and also usually let third-party vendors test their gear with their code long before it ships, so that if they break something, they can fix it *before customers notice*. That's just common sense based on software engineering best practices. Any company that doesn't do those things is grossly inept, to be absolutely blunt.

Why do almost all respectable software engineering organizations do these things when they don't have to, you might ask? Because above all other things, in the users' minds, attention to detail matters. Users don't care whether it's the manufacturer's fault or the peripheral's fault. They just expect their $1,600 camera to work without crashing, without breaking compatibility with other hardware in a firmware update, etc. When that extremely basic expectation isn't met, it's the fault of *everyone the customer can point his or her finger at*, including the camera maker. And when that camera maker tries to deflect blame, it just makes them look like they don't care about their customers at all, and makes those customers choose other companies' products the next time.


----------



## Don Haines (Dec 27, 2013)

Mt Spokane Photography said:


> dgatwood said:
> 
> 
> > Complain to Canon. A camera body locking up (freezing) is an unacceptable firmware bug, regardless of whether it occurs with Canon's lenses or someone else's. It's a bug, and Canon needs to fix it.
> ...


A bug in the Kenko should not lock up the camera.... It should report an error, but it should not lock up.


----------



## Mt Spokane Photography (Dec 27, 2013)

dgatwood said:


> If the camera refused to recognize the lens, we could blame either Kenko or Canon, but because it crashes the whole camera, Canon is entirely at fault.


 
Wow, that's a strange notion, make Canon responsible for third party firmware that is poorly designed? You probably expect them to anticipate all the infinite number of possible third party designs and be proof against them.


----------



## barracuda (Dec 27, 2013)

dgatwood said:


> Marsu42 said:
> 
> 
> > dgatwood said:
> ...



Nope. I'm in software engineering as well. You're not giving enough weight to the fact that Canon is a closed system - they don't license their software to third-party vendors, nor do they provide developer SDKs. That's why what Kenko does is called reverse-engineering. Canon is under no obligation to make their cameras compatible with unlicensed third party equipment. How the failure manifests itself, from reporting error messages to a complete lock-up, is completely irrelevant.

Sigma, on the other hand, does recognize that Canon is not obligated to make their products compatible with their's. That's why they created their USB dock. If Canon releases a camera body that affects the operation of their lenses, Sigma recognizes that it is up to them to make the fix to their firmware, not Canon.


----------



## Don Haines (Dec 27, 2013)

barracuda said:


> dgatwood said:
> 
> 
> > Marsu42 said:
> ...


As a programmer, I would have included a fail safe timer in the camera OS.... So many seconds have gone by without a refresh, force a reset.....

Canon is not responsible for Kenko's problems, but their camera should not lock up under an error condition, it should at least display an error code.....


----------



## Marsu42 (Dec 27, 2013)

Don Haines said:


> Canon is not responsible for Kenko's problems, but their camera should not lock up under an error condition, it should at least display an error code.....



Quite the contrary: As a programer in a profit-oriented enterprise you want the competitions' products to fail as catastropically as possible so that users realize the value of the original brand.

That's why Microsoft built its own DR-DOS error handling into an older Windows version which generated out a mean looking error messeage if the competitor's product was used. Microsoft was sued for this and lost, but only after successfully driving the original competitor to bancrupcy.


----------



## dgatwood (Dec 27, 2013)

Marsu42 said:


> Don Haines said:
> 
> 
> > Canon is not responsible for Kenko's problems, but their camera should not lock up under an error condition, it should at least display an error code.....
> ...



But it was part of a history of anticompetitive actions that caused them to be severely sanctioned by the courts just a few years later, and nearly got their company broken up. Were it not for those sanctions, there would likely not be Office for Mac (and Apple would have gone bankrupt, too). Now, the company they were forced to prop up is eating them alive. That just isn't a viable business practice.

Besides, Canon does not compete with Kenko. Kenko builds hardware that expands the market for Canon's core products, and Canon makes no products that directly compete with Kenko's TCs—Canon makes no 3x TCs at all, and never has, and even in ranges where Canon does build TCs, they don't build any that are compatible with their most popular zoom lenses. In short, Canon and Kenko's offerings are almost entirely complementary, not competitive, and treating them as a competitor is basically shooting their own foot.



barracuda said:


> dgatwood said:
> 
> 
> > Marsu42 said:
> ...



Bad code is bad code. If your code doesn't do proper error handling, your code is s**t, period. It doesn't matter what triggered that code to crash. It's still a security hole waiting to happen. And as I said, bad code in one part almost invariably means that you have bad code throughout. These sorts of problems lead me to the inevitable conclusion that their entire firmware is probably held together by shoestrings and bailing wire. That's not very reassuring, speaking as someone with $15k invested in Canon gear.

The part that's more infuriating is realizing that a one-line bug fix would probably make these things work, if we could just get the bug report past the CSRs to the engineering team.


----------



## Don Haines (Dec 27, 2013)

Marsu42 said:


> Don Haines said:
> 
> 
> > Canon is not responsible for Kenko's problems, but their camera should not lock up under an error condition, it should at least display an error code.....
> ...



I argue stenuously against this.

Canon wants an error code to show up on the screen that indicates that the problem is Kenko's fault. That shows "the evils of buying outside the family" and moves the blame away from Canon. The camera turning into a brick is a huge finger pointing at Canon saying "shame shame shame" and reflects badly on them.


----------



## Marsu42 (Dec 27, 2013)

Don Haines said:


> Canon wants an error code to show up on the screen that indicates that the problem is Kenko's fault.



But in this case, people would ask themselves: If they are able to print a nice error code, surely this just a cheap marketing ploy and Canon could have easily worked around the problem in the fw or at least with a fw update? Better let it fail silently, a crashed camera is much more likely to remembered :->


----------



## barracuda (Dec 27, 2013)

Don Haines said:


> As a programmer, I would have included a fail safe timer in the camera OS.... So many seconds have gone by without a refresh, force a reset.....
> 
> Canon is not responsible for Kenko's problems, but their camera should not lock up under an error condition, it should at least display an error code.....






dgatwood said:


> Bad code is bad code. If your code doesn't do proper error handling, your code is s**t, period. It doesn't matter what triggered that code to crash. It's still a security hole waiting to happen. And as I said, bad code in one part almost invariably means that you have bad code throughout. These sorts of problems lead me to the inevitable conclusion that their entire firmware is probably held together by shoestrings and bailing wire. That's not very reassuring, speaking as someone with $15k invested in Canon gear.
> 
> The part that's more infuriating is realizing that a one-line bug fix would probably make these things work, if we could just get the bug report past the CSRs to the engineering team.



Perhaps. Improper error handling should not happen in a perfect world. However, I hope you will concede that Canon can only test and recreate error conditions it has control over. That's the case for any software development process. We have no idea what Kenko is doing in their reverse engineering efforts that causes a camera to lock up, and that's really my point - neither does Canon. 

I am not going to question my $35k+ (and counting)  in invested Canon gear when an unlicensed, third-party, reverse-engineered teleconverter locks up my camera. I'll just take out the battery, reinsert it, and then think twice about buying non-Canon gear in the future.


----------



## dgatwood (Dec 28, 2013)

barracuda said:


> Perhaps. Improper error handling should not happen in a perfect world. However, I hope you will concede that Canon can only test and recreate error conditions it has control over. That's the case for any software development process. We have no idea what Kenko is doing in their reverse engineering efforts that causes a camera to lock up, and that's really my point - neither does Canon.



I'm sure Canon has protocol analyzers, and it's a fairly simple protocol, as I understand it. I doubt Kenko is doing much more than passing the data unmolested to the lenses and returning the responses, multiplying the focal length on the way back through. They don't even modify the lens ID information, I don't think.

My bet is that the Kenko extenders don't support some added command that the body is sending, but because the camera doesn't know it is there, the camera expects to be talking to a lens that does support that command, and fails on some assert when the "lens" says "I don't know how to do that". If that's the case, then the camera just needs to fall back to doing what it would do for an older lens that doesn't support that command rather than failing when the TC fails to pass the unknown command on to the lens.

That said, I'm half tempted to borrow an SPI to USB adapter and see exactly what's going on. Or maybe even buy one for $30:

http://www.adafruit.com/products/237?gclid=CKbvudmo07sCFeJF7AodLQYAuw

That, a sacrificial full-electrics extension tube, and about fifteen minutes will tell you everything you need to know about what's happening. Well, that, and a Canon TC to compare the results.


----------



## barracuda (Dec 30, 2013)

dgatwood said:


> barracuda said:
> 
> 
> > Perhaps. Improper error handling should not happen in a perfect world. However, I hope you will concede that Canon can only test and recreate error conditions it has control over. That's the case for any software development process. We have no idea what Kenko is doing in their reverse engineering efforts that causes a camera to lock up, and that's really my point - neither does Canon.
> ...



I'm sure Canon is fully capable of debugging and fixing this issue if they wanted to. But that goes back to the point that Canon is under no obligation to make their cameras compatible with unlicensed third-party products.

There are tens or possibly hundreds of third-party lenses, adapters, flash units, etc. that Canon would have to procure and test for each new camera release and/or firmware update if they were inclined to do so. I would prefer Canon leave it up to the third-party vendors to resolve their own problems so that we can all get new Canon products and firmware updates in a timely manner. Wouldn't you?


----------



## dgatwood (Dec 31, 2013)

barracuda said:


> dgatwood said:
> 
> 
> > barracuda said:
> ...



Given that the way the third-party vendors "resolve" these problems involves having to pony up hundreds of dollars for new glass, no, I really wouldn't. I'd *much* rather see Canon assume that things work until people scream, but take the time to fix crasher-level bugs when we report them....


----------



## Marsu42 (Dec 31, 2013)

dgatwood said:


> I'd *much* rather see Canon assume that things work until people scream, but take the time to fix crasher-level bugs when we report them..



You did report this to Canon? What did they say then?


----------



## dgatwood (Dec 31, 2013)

Marsu42 said:


> dgatwood said:
> 
> 
> > I'd *much* rather see Canon assume that things work until people scream, but take the time to fix crasher-level bugs when we report them..
> ...



Not a very useful response. They pretty much said that it's Kenko's problem. I then lit into them and insisted that they pass it on to their engineering team and let them make that decision. I haven't gotten a second response other than a customer service survey. You can probably already guess how I'm going to fill that out.


----------



## joshmurrah (Jan 7, 2014)

GmwDarkroom said:


> langdonb said:
> 
> 
> > Thanks for your replies. Shutting off AFMA solved the problem, but as my 100L needed a +9 AFMA, not sure the overall solution will be satisfactory...
> ...



THIS... let's get back to the question at hand. Live view is going to be your standard tool at that magnification anyway.


----------

