Profibus Network Performance Estimation

[dustinbrubacher]

I am investigating a profibus solution (in replace of devicenet) in a material handling facility.

The PLC details are:
-Controllogix L63 processor
-Prosoft MVI56-PDPMV1 profibus module
-Advantys STB IO (STB NDP 1010 or 2212)
-likely one 6 input card and one 6 output card per node for control stations (not defined yet)
-either Altivar 31 VFD (io hardwired) or Altivar 312 VFD with profibus adapter
-I am planning on running the network at 1.5Mbps with max 200m networks.

The profibus network will likely be 50% VFDs and 50% IO (i am assuming VFDs are Altivar 312 over profibus).

How can i estimate the network performance of this network? I can vary the number of nodes one a network to get a deterministic network scan time of about 20ms.

Typically, when comparing devicenet to profibus, which is better suited for a network like this?

Does profibus have the ability to only send data on a change of state like devicenet does?

any other info you can provide that would be useful would also be appreciated.

Thanks,

 

[Peter Nachtwey]

So how many bits are you sending and receiving in total?
At 1.5 Mbs you can transfer 1500 bits per milllisecond and effectively about half that. Multiply by 20 milliseconds and you get 15 kbits. That is a lot

Why not use 12 Mbs? It must be the distance involved.
The limiting factor may be the Control Logix back plane.
I have seen systems that are much bigger with faster update times even when using 1.5 Mbs but the card was in a PC.

DeviceNet is slow compared to Profibus. 500 Kbs vs 12 Mbs doesn't give devicenet much of a fighting chance . Also Devicenet packets are very small and half of the packet data is overhead.

 

[dustinbrubacher]

Unfortunately, as you may have noticed i dont have much experience with profibus so im going to ask some fairly basic questions.

How do you calculate the number of bytes that will be transmitted from a slave to a master for a given io rack?
For example, lets say i have a STB io rack (basically distributed io) on profibus with three 4 point input cards and three 4 point output cards.
-how many bytes are sent back and forth each scan?
-how much overhead is involved as a percentage?

I dont know if the contrologix backplane will have a large affect on the overall performance. I have used prosoft MVI56 serial and ethernet cards before and they havent increased cysle time that much, however, i have never used this exact card before so i will take your precaution into consideration.

As for Devicenet, one attractive feature is the change-of-state functionality to send data on each individual IO card separately which reduces the amount of data being transmitted. Do you know if this functionality is incorporated into profibus? I have not been able to find it anywhere so i assume it doesnt exist.

A couple questions when comparing devicenet with profibus,
how do the devicenet packets compare to profibus packets?
If devicenet is smaller and incorporating in the change-of-state functionality does that make it almost comparable to profibus at 1.5mbps? We have a lot of experience with devicenet so if the performance if comparable we would save money on development costs but i think i can see an advantage from profibus that i would like to explore.

Some posts that i have seen use simatic step 7 to estimate the network performance. If you have experience and know this, is it possible to estimate the network performance with this and correlate it to the controllogix processor independent of the processor type?

Thanks so much for the help.

 

[TyconAutomation]

Cycle Time Estimation

Hi,

Profibus cycle time can be estimated using the following approximation.
TMC» (380 + 300*S + 11*D)*Tbit + 75ms

where:
–S = the number of slaves
–D = total number of bytes of I/O data (input & output bytes).
–Tbit = 1/Baud rate (for eg at 1.5Mbit/sec its 1 divided by 1.5= 0.667)

I hope this helps.

Thanks

Scott
Tycon Automation Ltd
www.tyconautomation.co.uk

 

[TyconAutomation]

Hi again.

Profibus would be our preference, everyday of the week due to the extended diagnostic information available from slaves. For example on the remote IO application you mention then certain remote IO stations would have diagnostics to inform you of sensor wire breaks etc which can be very useful if coded correctly and used informatively to engineering staff.

The amount of IO each scan? Would that be PLC scan or Profibus cycle?
The Profibus master card in the CLX will look after the Profibus and polling of its slaves and the data is refreshed from the buffer memory into controller TAGS of the PLC, the two "scans" are in fact independent.

The amount of data available from each slave is dependent on the modules selected. Depending on what is written into the firmware of the slave and the associated GSD file depends on how many bytes are configurable for a certain module or in case of remote IO a certain input or output card. The whole profibus model is based on a modular functionality which makes it such a powerful and flexible protocol.


As far as I am aware the amount of data transferable on Profibus is a fixed cyclic type, you can with DPV1 write bespoke message functions to access information but this is usually carried out for additional information rather than the critical process data.

The best form of independent assessment of the profibus system would be in the form of a bus analyser. That gives a non vendor specific unbias view of the Profibus network.

Hope this helps.

Cheers

Scott

 

[dustinbrubacher]

Thanks everyone for the help, they have really helped.

I found some estimations online and also simulated my network through simatic step 7 and came out with 15.1ms cycle time. However, i estimated this with asiemens cpu with onboard profibus.

For TyconAutomation, your estimation calculation looks similiar to thers that i have found except the "+ 75ms" part. Doesnt 75ms seem pretty high? I would have said maybe 7.5ms. Was this a typo?

Again, thanks for the help.

 

[JesperMP]

I have never seen or heard anything about a +75 ms. Maybe is meant +75 microseconds (µs). TTR of 75 ms or worse could mean no go for a lot of applications.

At 1.5Mbps, and in mono-master operation, I get mostly less than 10 ms. It also depends on the selected bus-profile. For mono-master networks I use always "DP" busprofile.

 

[dustinbrubacher]

I could even see 7.5ms as a fudge factor. If so, then it would be fairly consistent with some other estimations that i have seen/done for the network. For me, +75ms is definately a deal breaker, i need deterministic scan time of max 20ms.

Also, I am proposing Profibus DP at 1.5Mbps.

When i simulatd the network in Step 7, i got a Ttr typical of 15.1ms and a Ttr of 30.1ms. What do these values mean, the help in step 7 is writting in semi broken english so i dont trust it all that much. It actually says that Ttr is only specified for "informational purposes".

Can anyone give me a practical description of what Ttr and Ttr typical are (im doing only very little acyclical messaging)?
Im looking for examples like: "Given a healthy network, the network scan time will be Ttr typical. If a node is disconnected the network scan time will jump to Ttr."

Any help would be appreciated.

Thanks for the help everyone.

 

[JesperMP]

TTR is the guaranteed time. It is the time you will need to use for considering if it is "good enough". (sort of how much traffic a road can carry in case there must be an evacuation).

TTRtyp is a guesstimate of which time that will be achieved during normal operation. It is interesting to know, but of little use if you ask me. (sort of how much traffic there will be on the road during a normal day). edit 3: It says in the online help that it is TTRtyp that is provided for information only.

edit 1: You can get less than 7.5 ms TTR if the bus speed is 1.5M and there are just one master and a couple of slaves. I dont see where the 7.5 ms should come from and I havent seen it before.

edit 2: What busprofile do you use ?

 

[TyconAutomation]

Hi all,

Jesper was right it should have been micro seconds! Apologies for the confusion with the typo!! It is as far as I am aware a constant "fudge factor" for the calculation.

Cheers

Scott

Tycon Automation Ltd