Exemple : Net Base Services

Le projet contient deux CODESYS Control Win contrôleurs x64, chacun doté d'une application permettant de simuler une relation serveur-client. Configurez le nom du client partagé et l'adresse IP correspondante dans CLIENT_PRG programme pour le client ainsi que dans le SERVER_PRG programme pour le serveur. Si la communication TLS n'est pas requise, la variable myTLSContext peut être retiré (SERVER_PRG et CLIENT_PRG). L'application serveur (myServer) doit d'abord être activé.

Le projet est basé sur le TCP_Server_TCP_Client exemple. Dans le programme client CLIENT_PRG, une instance de ClientOptions bloc de fonction est déclaré. Ce bloc fonctionnel (dans le pool POU) contient trois options qui sont définies lorsque le socket est ouvert. Dans la partie relative à la déclaration de CLIENT_PRG, les options sont définies à l'aide du SetOptionProvider() méthode. Dans le programme serveur SERVER_PRG, aucune option pour TCP_Server est défini de telle sorte que la valeur par défaut soit utilisée. Si nécessaire, l'option peut être définie de la même manière que pour le client. Si la communication UDP est utilisée, les options peuvent être définies dans l'homologue UDP, ainsi qu'avec le même SetOptionProvider() méthode.

Le projet contient deux CODESYS Control Win contrôleurs x64, chacun doté d'une application permettant de simuler une relation serveur-client. Le serveur renvoie uniquement les valeurs envoyées par le client. CLIENT_PRG le programme montre un exemple de la façon dont la lecture, le traitement et l'écriture asynchrones sont effectués à l'aide du NBS.TCP_Reader, NBS.TCP_Processor, et NBS.TCP_Writer blocs fonctionnels. NBS.TCP_Processor le bloc de fonction est remplacé dans cet exemple afin d'implémenter le ProcessStream méthode. Cet exemple montre également la possibilité d'utiliser les méthodes clientes TCP directes Read() et Write() pour lire, manipuler et écrire de manière synchrone lorsque xAsync=FALSE.

Notez que cette relation serveur-client utilise un contexte TLS, de sorte qu'il est absolument nécessaire d'importer le certificat de serveur dans le client et vice-versa. Pour les communications non chiffrées, NBS.TLSContext le bloc fonctionnel peut être supprimé.

Le projet contient deux CODESYS Control Win contrôleurs x64, chacun doté d'une application permettant de simuler une relation UDP producteur-consommateur UDP synchrone. Le programme pour les producteurs PRODUCER_PRG renvoie uniquement les données qui ont déjà été reçues précédemment. Par conséquent, le Receive() et Send() méthodes d'interface du IPeer bloc fonctionnel est utilisé. Au début, le producteur crée une chaîne et l'envoie au consommateur. Le contrôleur des consommateurs contient également un homologue et c'est là que les données sont reçues via un appel de méthode direct depuis le pair Receive2(). Ceci est similaire à Receive(), mais il possède une sortie supplémentaire eTransmission afin de montrer si la trame est en monodiffusion, par exemple. Entre la réception et l'envoi, un ChangeStringValue La méthode est appelée afin de modifier la charge utile de la communication. Comme il s'agit d'UDP, il est recommandé d'activer d'abord le consommateur, puis le producteur

Le projet contient deux CODESYS Control Win appareils x64, chacun doté d'une application permettant de simuler une relation entre un producteur UDP et un consommateur UDP. Dans l'application destinée aux consommateurs, il existe un UDP_Processor qui étend la NBS.UDP_Processor afin que ce bloc de fonction implémente le ProcessPacket méthode d'interface. Certaines données sont traitées selon cette méthode (appelée par l'interface).