modbus tcp pour 100 esclaves

[loan dandem]

Bonjour à tous,

j'utilise un V700 pour lire et écrire des valeurs dans 2 capteurs pour le moment

j'ai réalisé le petit programme pour essayer la communication en Modbus tcp/ip et cela fonctionne correctement .

l'idée dans le futur est de réaliser la même chose pour 100 capteurs !!

Cela sera t-il possible ? qu'en sera t-il sur la vitesse d’exécution 

quelle sera la meilleure façon de faire le programme pour avoir des temps de réaction assez rapide?

je recherche donc des astuces de programmation pour réduire au maximum les temps de lecture et d’écriture de ce futur ensemble de 100 capteurs.

Dans l'attente de vos réponses

D'avance merci

Loan Dandem

[Flex727]

Add 12 more V700s and you can communicate with all of them simultaneously.

Seriously though, if your only choice is TCP protocol, then you will need to connect and disconnect each socket 12-13 times in order to communicate with all 100 sensors. The connect/disconnect process can take a few seconds, so you should be able to complete the communication with all 100 sensors in about a minute, assuming you have all the associated hardware (routers, etc) set up properly.

Another option might be to move to UniStream where you do not have an 8 socket limitation as you do with the V700.

[Fernando Castro]

Define how fast is fast.

 

And I was actually looking for the exact same solution. Best option so far is to use UDP, if your sensors allows it.

 

 

[loan dandem]

Merci "Flex et Fernando " pour vos retours et réponses

cela ne m'arrange pas bien sur ,je vais voir pour une autre méthode;

je ne connait pas UDP ! en quelques mots cela consiste en quoi ?

D'avance merci

LD

[Flex727]

5 hours ago, loan dandem said:

I don't know UDP! In a few words, what does this consist of?

UDP is a communication protocol somewhat similar to TCP, but unlike TCP, UDP is not connection-based. Since it doesn't require a connection, communication between multiple devices does not require separate sockets. The disadvantage is that not every message is guaranteed to be received. If your system allows the use of UDP and your communications can be tolerant of the occasional missed message, then UDP would work well for you.

[Joe Tauser]

To expand, I found this on techtarget.com - 

TCP vs. UDP

This process of error detection, in which TCP retransmits and reorders packets after they arrive, can introduce latency in a TCP stream. Highly time-sensitive applications, such as voice over IP (VoIP), streaming video and gaming, generally rely on a transport process such as User Datagram Protocol (UDP), because it reduces latency and jitter by not reordering packets or retransmitting missing data.

UDP is classified as a datagram protocol, or connectionless protocol, because it has no way of detecting whether both applications have finished their back-and-forth communication. Instead of correcting invalid data packets, as TCP does, UDP discards those packets and defers to the application layer for more detailed error detection.

The header of a UDP datagram contains far less information than a TCP segment header. The UDP header also goes through much less processing at the transport layer in the interest of reduced latency.

 

In summary, Transmission Control Protocol is a handshaking protocol, requiring the end device to respond to the initiating device, hence the need to "connect".  TCP is more of a guaranteed data transfer.

User Datagram Protocol is a broadcast only mechanism.  Since the initiating device isn't trying to verify the connection, it is way faster.  We had an application transferring 512 registers every second and UDP gave us the speed we needed.

If there's nothing on the network but the PLC and the slaves and it is a hard cabled network then UDP will probably work fine.  If you're going through cellular modems, Wi-fi, or any other packet-clogging devices then I'd go with TCP to get more reliability.

 

Joe T.