S7 300 MPI Protocol Library

[NoviceS]

Hi
I tried the MPI Protocol Library downloaded from http://decibel.ni.com/content/docs/DOC-1330

I am connecting to an s7 313-2DP siemens plc. I am trying to read around 72 bytes of data. With 8 bytes in 1 segment so on to 9 segments. I am also writing so data. In all I have 6 reads and 2 writes in a sub vi. This sub vi is called 9 times in a for next loop.
Starting from segment 1 to segment 9 takes around 8 seconds. So if I start at segment 1 and finish read. Then move to segment 2 and there is fresh data at segment 1. Then to read this new data it takes around 8 seconds.
I tested the MPI library as a stand alone with the MPI test 2 vi. I added some time features. I find that it takes .4 secs for 3 elements in the cluster, .82 secs for 6 elements.

Now my question is : How to reduce the time and enable faster processing. There is a 10 ms. delay in the state machine (probably turn around time). Can this be reduced ?

Does this libraray take so much time or is MPI itself a slow protocol?
Suresh

[jpaul]

Suresh,

After looking at the VIs associated with the MPI Protocol Library it appears that the delay is software created. The question than as you asked is related to whether or not it is the software itself or if it is needed by the protocol. Again an observation that I noticed in the VI throughout that there are delays intentionally introduced which lends itself to the fact that either the code is being conversative in order to ensure data is received by client or it is needed my the protocol. This can be tested by decrementing these delay about 100mS at a time and see if it affects the PLC communication.

Cheers,

Jonah

Applications Engineer

National Instruments

[NoviceS]

Hi Jonah

Thanks for the quick response. I could find only one delay of 10 mS in one place in the library.That is in the mpi_state_machine vi in a false case structure. Can you pls tell me where else these delays or are referring to the timeouts

Thanks again
Suresh

[jpaul]

Suresh,

I apologize, in refer to my comments before, I was referencing the Simple MPI Logging VI. I took a look at the mpi_state_machine and the Test VI that you referred to in your first post and found that in this case the software has been designed with limitations that look like they conform to hardware. For instance the serial baud rate values allowed are only 18k & 36k, putting a communication bottleneck at this point. Again I believe that based on these observations there was most likely a deliberate architectural decision to slow down the software due to the MPI protocol. Sorry for the original confusion on my end.

Cheers,

Jonah
Applications Engineer
National Instruments

[NoviceS]

Jonah
Thanks for the response and no apology needed. Yes I could perceive the design itself imposing a restriction though I was not able to place my finger on the precise location. Except for the 10mS delay in the state machine. As for the MPI Test 2 Vi the delay will be in multiples. For example given a simple data read will take 100 mS then the MPI Test2 takes no of elements in the cluster x 100 mS.

But block read where one can specify the length of the no. of bytes to read at a stretch takes the same time of reading 1 byte. Therefore I presume that that a fixed time is consumed by the protocol itself. But this is just sounding off, since I cannot be sure. No MPI specification is available with me. Just one question: You mentioned the Simple MPI Logging vi. Which vi is that in the MPI library

Thanks again.

[NoviceS]

Given this scenario, I wonder if this library can be modified to communicate over USB. There are mpi adapters USB version, which are faster. I am at loss as to where to start the process of changing this to USB

[rolfk]

---

@NoviceS wrote:
Jonah
Thanks for the response and no apology needed. Yes I could perceive the design itself imposing a restriction though I was not able to place my finger on the precise location. Except for the 10mS delay in the state machine. As for the MPI Test 2 Vi the delay will be in multiples. For example given a simple data read will take 100 mS then the MPI Test2 takes no of elements in the cluster x 100 mS.

But block read where one can specify the length of the no. of bytes to read at a stretch takes the same time of reading 1 byte. Therefore I presume that that a fixed time is consumed by the protocol itself. But this is just sounding off, since I cannot be sure. No MPI specification is available with me. Just one question: You mentioned the Simple MPI Logging vi. Which vi is that in the MPI library

Thanks again.

---

Some time ago I implemented the AS511 protocol for the programming port of the Siemens S5 PLCs and its speed is definitly limited by the protocol itself with several handshaking back and forth messages for each data exchange. The result was that a single transaction cost around 25 ms just for the protocol handshaking and then (with a maximum baudrate of 9600 for that port ) around 1ms for every byte of information transmitted. So writing one 16 bit register took around 30 ms while writing 50 16 bit registers in one go took about 125 ms.

With transfer pooling and such in the higher level of my Scada application (I wrote a VI based DSC server for that) that took care to gather various bytes from the memory image to transmit/update together in one go I could actually get the system to perform a sustained operation of around 200 tags per seconds reading and about 20 tags per second writing with about half of the tags being bit tags and the rest 16bit analog values and timers.

But the part that was gathering the necessary memory bytes to transfer and put them into one single communication transaction was probably the worst piece of software I have ever written in terms of complexity and debuggability because I was doing all kinds of complicated data structures to avoid LabVIEW having to copy data all over the place too.

So while you can use the programmer port of PLCs for data transfer it is definitly not designed to do so since the protocol used is somewhat complex and cares more about robust communication than about speed.

Rolf Kalbermatter

[rolfk]

---

@NoviceS wrote:
Given this scenario, I wonder if this library can be modified to communicate over USB. There are mpi adapters USB version, which are faster. I am at loss as to where to start the process of changing this to USB

---

I would expect those USP-MPI adapters to really just be virtual COM ports. But who knows. The MPI side of things seems to be some sort of RS-485 communication bus.

Rolf Kalbermatter

[NoviceS]

Hi Jonah
Thanks ! And yes, it is very true, MPI is slow. I should have been more careful when selecting a protocol. I think profibus would have been a better option.
And MPI USB seems to be very fast supporting upto 187 kbps. but again we need to modify this library which atleast for me will be an herculean task. As Rolf said, the Siemens MPI adapter does not create a virtual com as is done by other ports.

Thanks again
Suresh