Nowadays, in spite of some advances, getting different types of system to talk to each other can be a real challenge.  Many manufacturers claim to include "standard", "universal" or "open" communication systems creating an expectation of some kind of plug-and-play utopia.  It's true that sometimes systems of differing manufacture can communicate with each other right out of the box - but in most instances they can't.  Take even a simple common standard such as an RS-232 serial connection, there still has to be agreement between devices on:

	Baud Rate:  4,800, 9,600, 19.2k, 38.4k. etc...
	Data Frame Format:  Number of Bits, Parity, Stop-Bits
	Physical/Electrical Connection:  2-Wire 3-Wire, n-Wire...
	Flow Control: Software Encoded  vs. Hardware (RTS/CTS)
	Frame type: Synchronous or non-Synchronous
	Language used:  Payload data; Format and Function

Even if both systems do fully conform to the same electrical specification, the most important and often the most elusive task, is to ensure that there is a common language used between systems or, in other words, that there is a common understanding for the underlying data. 

Some manufacturers aren't too helpful when it comes to publishing in-depth technical data because they are fully aware that this may discourage further selection from their own catalogue. At the same time, they shout loudly about how their equipment fully conforms to this or that communications standard. 

Assistance From Chelsfield Consultants

Whether it's trying to get two black boxes to talk to one another or integration of multiple, network-wide communication systems: the steps to follow are always the same. 1) ensure physical/electrical compatibility 2) ensure the communications specifications are met, and, 3) ensure there is a common language used. In many cases physical and/or electrical connections are catered for by using protocol converters that may be purchased off-the-shelf.

These may be effectively used to satisfy the criterion of 1 and 2 above.  Otherwise custom interface boxes can usually be designed and built.

The complexity of these can vary enormously; this usually depends on the degree to which any I/O adheres to any given standard.

We at Chelsfield can investigate and provide an in-depth analysis of the embedded conversation between two or more systems. If it then becomes possible to establish a satisfactory communications rules-set, then this will be defined (for the task) and documented. Language translation firmware can thereafter be written that stands between the two systems.

sales@Chelsfield Solutions