microface, I agree that integrators and their expertise have been left out of this discussion so far. "Customers" referred to the end user of the machine vision system. But those customers can vary widely in knowledge and experience. Some are small operations with no institutional knowledge or previous experience of vision, and others may be huge companies with in-house developers and manufacturing engineers experienced in this area. Not all of them use integrators, so much of the discussion has been aimed at those who don't.
Trying to equate the small number of interfaces available on the PC to the number of interfaces on camera systems is in my opinion an apple and oranges comparison. PC's are in my opinion commodity products which need to be simplified to the extent that 99% of people can use them, thus USB 1.1, 2.0 and 3.0, and Ethernet. Firewire grew out of the need for a synchronous mode that was not offered by either Ethernet or USB at the time it ws developed and standardized.
Camera interfaces are for the imaging community, and it is our jo as VAR/professionals to keep track, and/or make sense of these interfaces as they evolve with the various platforms, (Windows, Linux, Mac). I do not expect even a knowledgeable IT person to be able to setup, and or make good choices for some of the more complex imaging jobs that I hav encountered. There are some jobs i have worked that any person who had any knowledge could have finished by just reading the various trade journals or white papers that throw so much PR hype around the industry.
As someone who has watched video/imaging/streaming grow up from PAL/NTSC into the HD "standards" of today i can tell anyone who is willingto listen that unless I sit down with a client, and visit their facility, and truly understand their situation the client will inevitablly have a system that either underperforms, or is powered beyond the needs of the client. i have had to go in and "fix" several installations, where my opinions were not heeded, or I did not come in as the lowest bid.
In my opinion more choices does complicate the situation for those who do not keep up, but my personal opinion is that as the number of camera interfaces expands to include all manner of imaging hardware this situation will equilibraate to 3 dominant interfaces. Thus the tradespace for various features will be governed or limited, or held hostage to these constraints.
This is all my opinion, course i have been working in this arena for 20+ years, so take my opinion, or leave it as you wish. i can always "fix" what yuo have put together anyway.
I think the issue of choice needs to be considered from different perspectives. From the camera maker's perspective, it's mostly a good thing, as long as the vendor can support multiple product lines. And the choice of which one to support is more or less a choice for a camera maker. From the frame grabber maker's perspective, supporting multiple interface standards is a bit more problematic, since it's less of a choice for them. From the user's perspective, the whole thing can be confusing. Remember how USB was supposed to simplify interfaces on the PCs we use? And it did, except, well, we also have FireWire and Ethernet and a few others.
It's certainly possible, and not uncommon, to mix and match interfaces in a single vision network. But it does take time and know-how.
A Camera interface that works well for a low resolution image such as 640 x 480 is impossibly slow for a system which uses 720p, and even that system is slow speed when you need to have the resolution of 1080p. As the resolution of the cameras increases the need for speed increases.
Now to address the differences in the various Camera Link, GigE, USB interfaces. Each as their strengths and weak points.
GigE can be pased through a slip ring and is routable, so it does not need to be attached DIRECTLY to a computer box
Camera Link and USB 3 need to be attached DIRECTLY to some kind of computer box. I know and have tested that Camera Link will not pass through a normal slip ring, and needs an optical slip ring and so must use a SERDES system.
USB 3 I have not tested with various slip rings, so I can not address that issue.
Each of the signalling protocols has some strengths, and weaknesses.
If you do not know them all, then you are in danger of solving every problem with a hammer, when a screw would be a better solution.
Now to address lockin. Yes there is a certain amount of lockin with CameraLink, and USB 3, but with some internet searching you can find equivalent cameras with all 3 interfaces. GigE has no lockin that I am aware of since you can use any software you choose to present the image to whatever saving, archiving or analysis code you want. I personally use C/C++ with Imaging SDK's, other prefer to use LAbView or SCiLab, still others use the various other frameworks that are advertised. All these software frameworks, or creation tools will use ANY of these interfaces. I have successully mixed and matched GigE, FrameCapture with MAtrox Cards, and CameraLink in a system that of neccessity used 3 small computers for local control.
I for one EMBRACE and CHERISH CHOICE, so I can solve my customers problem with the appropriate choices. ONE CHOICE DOES NOT FIT ALL.
Ladies, please stop being so nice---you are journalists and you should call it like it is. The standards are incompatible because they lock in and give proprietary advantage to vendors. How else would a vendor get away with making new version that is incompatible with the old version, like in CamLink HS vs camLink
None of these standards are interoperable, Beth, so you nailed that problem. I think this is going to cause a lot of confusion among engineers, and it's also tough on the smaller vendors who don't have big development budgets for multiple product lines.
While the idea of choice is certainly a good thing, this half dozen and growing array of standards would only serve to muddy the market, I would think, creating incompatibilities and lots of leg work for engineers putting together these systems. Unless, of course, there is some sort of backward compatibility or base standard that they all can share and then build on from there.
A new service lets engineers and orthopedic surgeons design and 3D print highly accurate, patient-specific, orthopedic medical implants made of metal -- without owning a 3D printer. Using free, downloadable software, users can import ASCII and binary .STL files, design the implant, and send an encrypted design file to a third-party manufacturer.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.