Chuck, While packaging automation is a big market for this type of capability, integration of robotic arms into machines is a phenomena that reaches into all types of applications. Especially with the development of technology to create "programmable safety zones", it's now possible for robotics to become more tightly integrated with the machine process. That reduces floor space requirements and enables automation engineers to design around robotic arms to eliminate some custom design. Now with the ability to program the line controls for the machine, plus robotic motions, using the same programming environment on a single machine controller, it's creating more incentive to move machine designs in this direction.
TJ, The most common and popular software approach for these type of systems is based on the IEC61131-3 programming languages, with solutions provided by a wide range of automation vendors. These automation software packages are already wide in used for general machine control, so robotic kinematics is another group of software objects/libraries that can be integrated into the package.
naperlou, for vision I'd agree with you. I've not seen a PAC that tightly integrated vision the way motion has been.
Eventually, it will be; I can see the benefits of merging the two for even better robotics. I haven't seen any of the big automation companies offer a camera yet.
Centralized control does make sense (assuming redundancy is covered properly) when there are numerous devices with similar control requirements. Central control means a single point to adjust programming, and a central point from which supervisory and HMI systems can collect data.
Distributed controls means touching each and every machine to roll out a change (connect, download, verify, disconnect, again and again). It also means a much more complex task for collecting data. In some cases, the number of connections becomes a limiting factor.
ttemple, we use a lot of Rockwell Automation hardware and software (Logix5000).
I've also used AML from Pacific Scientific (a long time ago). Both are an integrated programming environment, and I find I like that, a LOT.
Having to have different suites of software for different parts of a large system can get cumbersome, FAST, especially when the software does not play nice with other packages (Rockwell and Siemens are notorious for this).
Running different suites in their own Virtual Machines is how we handle that problem, but again, it's much nicer to have a single programming environment.
Frankly, I agree with TJ. This becomes a single point of failure. I also am more inclined, in design projects I am involved in, to push the intellgence out to where it is used. There are lots of processors that have specilaized instructions that will handle the computational load at a much lower power level. Vision systems, for example, are tending toward smart cameras. This allows most, of not all, of the processing to be done at the camera, thereby reducing the traffic on the communications link.
The main issue that seems to be addressed here is the comminications latency. There are standard busses that handle this with predictability and high speed.
Determining the quantities and location of sensors in an Internet of Things application requires a thorough problem statement and a clear vision of success, an expert will tell engineers at the upcoming Design & Manufacturing Show in Minneapolis.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies.
You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived.
So if you can't attend live, attend at your convenience.