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

[Marsu42]

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]

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.

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.

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?

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

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.

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.

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]

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.

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]

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]

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

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]

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]

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.

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]

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.

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?

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]

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]

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?

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]

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.

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