MPI details

As many users asked for the details of MPI Interface, protocol and whether there is a way to make your own MPI adapter, here is a brief description of what I know:

Physical Layer

MPI uses RS485 serial communication with parity even and baud rates from 19.2 kBaud to 187.5 or to 12MBaud in newer systems.
Want to "sniff" MPI? Set your PLC's MPI speed to 19.2, because this is the only baudrate also supported by PC UARTs. Prepare a ribbon cable with one male and to female Sub-D connectors. Plug it into the PLCs MPI connector, an MPI adapter or CP5x1x into one female and an RS485/RS232 converter or PPI cable into the other one. Now your PC can listen!

Media Arbitration

MPI is basically a variety of Profibus, using the FDL profile.
Profibus is a token ring. One master at a time is in posession of the "token", which entitles it to send requests to other devices. It may hold the token for a limited time. Either when that time expires or when it has sent all its requests and has got the answers, it passes the token on to the next known master. From time to time, it asks for the presence of masters with numbers between its own number and the number of the next known master. Thus, new masters are "invited" to participate in the ring.
In case of MPI, the PLC in absence of a partner sends the token to itself:

Example

DC 02 02
After each token passing it sends a request to get the diagnostic state of device number x: 
10 x 02 49 bcc 16
This is repeated for all free device numbers. If you connect an MPI adapter it will do nothing, not even respond. After you set it up, e.g. with daveInitAdapter(), it has its MPI address, e.g. 0. Now it will respond as soon as the PLC requests diagnostic state from device 0. The PLC then passes the token to it: 
DC 00 02
Now the adapter, if it has a message to send, sends this message in a telegram of variable length to the CPU: 
68,11,11,68   //message, 17 bytes long 
	82,80,6D,00,14,	// request telegram to 2 from 0, SRD high DSAP=0,SSAP=0x14
	    E0,04,00,80,00,02,00,02,01,00,01,00,ED,16,	//the "payload" message 
	E5,		// short ackknowledge from CPU
DC,02,00,		//adapter passes token to CPU
10,05,02,49,50,16,	//CPU requests diagnostic state from device 5
DC,00,02,		//CPU passes token to adapter
DC,02,00,	//adapter passes token back to CPU
10,06,02,49,51,16,	//CPU requests diagnostic state from device 6
			//I'm not sure, but I guess CPU waits for some amount of time for a response.
			//This time should be part of Profibus specifications.
68,11,11,68,		//CPU sends message with length 17
	 80,82,6C,14,14,	// response telegram to 0 from 2, DSAP=14,SSAP=0x14
		D0,04,00,80,00,02,00,02,01,00,01,00,F0,16,//the "payload" message 
	    E5,		// short ackknowledge from adapter
DC,00,02,		//CPU passes token to adapter

Payload

The payload messages are something I want to call "S7 communication". They are common for all sorts of transport (MPI,PPI, ISO over TCP). Payload messages are sent to an MPI adapter either through 3964R (which is used by LIBNODAVE and all 3rd party software I know) or through another protocol used by Step7. The protocol used by Step7 has a more complicated checksum(CRC?). It also sends a kind of "keep alive message" when the connection is idle. This keep alive message changes after packets with payload, so the partner will know if a packet with payload got lost.
The S7 communication over MPI introduces additional ackknowledges for each "payload" message generated by PLC or PC and passed over Profibus FDL by the adapter. These are neither present in PPI nor ISO/TCP.

Homemade MPI Adapters

  • Find a uC with 2 UARTs of which one can handle 12MBaud.
  • Implement Profibus token passing.
  • Implement Profibus variable length messages.
  • Implement 3964R for PC side.
  • Implement the adapter init/disconnect commends.
  • Implement the "Step7 protocol" for PC side, if you want to use it with Step7.
  • Be aware that it is not tested for Profibus compliance. So you are at risk to stop dangerous machinery...