CAMX is an XML based communication standard published by IPC in the late 1990’s​. Over the years it has been adopted and used by equipment suppliers, electronic contract manufacturers as well as software providers within the SMT industry. In essence, CAMX was developed by IPC in response to the use of SECS/GEM – our industry needed a protocol better suited to electronics assembly using newer technologies.

As with any standard, CAMX has some obvious strengths and weaknesses. From my perspective, the pros to using CAMX center around its flexibility and ease of use. CAMX allows extensions to be added to standard messages, and because of the human readable structure this is quite simple to do. Within CAMX, technological progress isn’t hindered or slowed down because it allows the addition of message extensions. Because it’s easy to understand, CAMX makes troubleshooting simple and straightforward.

On the flip side CAMX has some drawbacks. Due to its asynchronous nature, it isn’t well suited to provide commands (an interlock) directly to a machine. Additionally, CAMX requires the implementation of a message broker without a standard based communication system.

With all the buzz surrounding CFX, it’s as though this standard is the hot new student in class! Released by IPC in 2018, this communication standard is PCBA-centric and based on JSON message format utilizing the AMQP protocol. Contrary to popular belief, CFX simply defines the protocol and message content, it does not augment data beyond what is currently available from the machines.

As with any new initiative, CFX is still working out all the kinks. Based on JSON, it’s a much lighter weight and compact message format compared to XML, so CFX doesn’t eat up too much space. It integrates both synchronous and asynchronous communication – commands are asynchronous and events the latter. Compared to CAMX, the AMQP standardized message broker middleware is simpler to use. Additionally, the MQTT message broker option is also supported within CFX.

Unfortunately, CFX isn’t entirely flexible as it doesn’t allow for message extensions. Every time a new vendor wants to apply a new piece of data to the protocol, this vendor has to go to the CFX committee and submit a proposed change for the next revision of CFX without any guarantees it will be adopted. Many vendors are forced to work around the CFX standard. Because we cannot stop natural progress, many innovative vendors and end-users have proposed their own message definitions outside of the standard. Since not all process data attributes are completely covered by every machine type within SMT manufacturing, other protocols, mainly proprietary ones are used in order to access all of the available machine data. Still in its infancy, CFX still has some maturing to do – most notably for a thorough MES integration.

CFX is an emerging standard, and while it receives a lot of press, there are still very few real-life manufacturing implementations. Widespread future adoption is still uncertain.

While SECS/GEM was originally developed for semiconductor equipment over 30 years ago, this protocol has been adopted by some within SMT manufacturing. As a mature and well-used equipment protocol, SECS/GEM can work quite well for gathering machine data.

Sometimes the tried and true solutions are the best. SECS/GEM is a lightweight communication protocol that is incredibly flexible and easy to use. Equipment manufacturers, suppliers, contract manufacturers, and software providers within the semiconductor all use this standard. In PCB assembly, SECS/GEM adoption and usage is marginal at best and has declined even further in the past few years.

But nothing is perfect and one of the main drawbacks of SECS/GEM is the requirement to purchase a transport library from an approved third-party source. Additionally, the message structure isn’t human readable, so it isn’t easy to understand nor troubleshoot. Using SECS/GEM, a machine can only connect to one host – without a broker concept, sharing machine events to multiple places simultaneously isn’t possible.

As you can see, all communication protocols have their pros and cons. As with any development, these initiatives take time to mature and naturally evolve over time. The SECS/GEM standard for the semiconductor industry is an excellent example of a proven and well-used communication protocol that has evolved and adapted over the last 30 years while remaining its relevancy. History always has a story to tell, and past experience has shown that it’s not always beneficial to scrap what’s available and start anew. The electronics industry is a small portion of a much broader ecosystem with IIoT and other emerging technological advancements (AI, Deep Learning). These new technologies will soon gain prevalence in our industry, and we will have to adopt and integrate their specific standards and protocols.

Put simply, multiple standards will continue to exist in our industry, and new ones will continue to come into our industry. As these protocols continue to change and evolve, it will be incredibly challenging for both equipment and software suppliers to keep up with these ever-changing requirements. Considering internal resources, it can cost a tremendous amount of time and money to support and maintain all the different standards… And not just the ones mentioned in this article. There are countless proprietary protocols, too.

Remaining flexible and agile is key – it’s never been enough to rely on one single standard. This isn’t likely to change anytime in the future. For customers and suppliers alike, the best strategy is to ensure your toolbox is well equipped to handle various types of integration scenarios. If you need help with connectivity, Cogiscan is a neutral connectivity expert to help you better integrate with all types of communication protocols in a wide variety of manufacturing ecosystems.