Partagez des capteurs ou des appareils de contrôle de terminal pour former des instances de contrôle en boucle

21.1 Présentation

Les travaux antérieurs de ServerSuperIO ont progressivement jeté les bases de la formation du contrôle en boucle ou du contrôle en cascade, comme le développement et l'application de connecteurs de service et de connecteurs de pilotes de périphériques. En bref, des commandes sont émises sous diverses formes pour contrôler des appareils (pilotes) ou des capteurs. Le cloud contrôle les capteurs sur des sites ou des points de surveillance, l'application ou d'autres terminaux contrôlent les capteurs et contrôlent un autre capteur en fonction des données collectées par le capteur. .

Ce qui suit décrit comment le cloud, l'application ou d'autres terminaux contrôlent les capteurs (les capteurs de contrôle des capteurs sont similaires, veuillez consulter : 12. Développement d'interfaces de service et interaction bidirectionnelle avec le cloud). Selon le protocole de communication, la solution structurée ne nécessite pas trop de code pour compléter les fonctions correspondantes. L'effet est le suivant :

21.2 Schéma structurel

Le terminal de contrôle initie une commande de contrôle et utilise le ServerSuperIO interface de service pour développer un simple Le service proxy interagit avec le pilote de périphérique via l'interface du connecteur de service IServiceConnector. Après avoir reçu la commande de contrôle, le pilote de périphérique l'envoie au périphérique ou au capteur, attend le message de confirmation renvoyé par le contrôle, puis le renvoie au terminal de contrôle.

21.3 Protocole de communication

Certaines personnes se demandent pourquoi ne pas utiliser le protocole MQTT. Comment peut-il être compatible avec les protocoles de différents appareils et capteurs ? Compte tenu de la situation actuelle en Chine, il est évident qu'il est impossible d'atteindre le niveau de normes unifiées. En cas de mauvaises conditions économiques, il est impossible pour les entreprises d'investir dans le remplacement du matériel d'origine. Il n'est pas non plus conforme au principe de conception de ServerSuperIO, qui consiste à atteindre l'indépendance du protocole, et tout protocole standard ou non standard peut être intégré. Si vous souhaitez traverser une rivière, vous devez réparer le pont, installer le téléphérique et aménager le bateau... C'est à vous de décider comment traverser la rivière.

Quelqu'un a demandé à quels protocoles ServerSuperIO est intégré ? La réponse a été donnée ci-dessus, et ce que je veux dire, c'est qu'aucun cadre ne peut résoudre tous les problèmes. En pensant du point de vue opposé, si un protocole est ajouté comme configuration, quelle valeur l'entreprise souhaite-t-elle accorder à l'échange peer-to-peer, de sorte que le pilote du protocole soit laissé à chacun d'écrire par lui-même.

Le protocole que nous avons démontré est le suivant :

21.4 Fin de contrôle

La fin de contrôle comprend de nombreux types : le cloud envoie des commandes de contrôle au niveau inférieur, une application ou un logiciel PC se connecte au service pour envoyer des commandes de contrôle, etc. Envoyez les commandes de contrôle comme indiqué ci-dessous :

21.5 Service proxy (interface de service SSIO)

Le service proxy est implémenté via l'interface IService de ServerSuperIO et est utilisé dans classes héritées Le mode singleton du framework ServerSuperIO développe lui-même le service proxy. Le code est le suivant :

public override void StartService()
        {
            string devId = "ControlDeviceService";
            Driver dev = new Driver();
            dev.ReceiveRequestInfos += Dev_ReceiveRequestInfos;
            dev.DeviceParameter.DeviceName = "控制设备驱动器";
            dev.DeviceParameter.DeviceAddr = 0;
            dev.DeviceParameter.DeviceID = devId;
            dev.DeviceParameter.DeviceCode = "";
            dev.DeviceDynamic.DeviceID = devId;
            dev.DeviceParameter.NET.RemoteIP = "127.0.0.1";
            dev.DeviceParameter.NET.RemotePort = 9600;
            dev.DeviceParameter.NET.ControllerGroup = "LocalGroup";
            dev.CommunicateType = CommunicateType.NET;
            dev.Initialize(devId);

            IServer server = new ServerManager().CreateServer(new ServerConfig()
            {
                ServerName = "控制设备服务",
                ListenPort=6670,
                ComReadTimeout = 1000,
                ComWriteTimeout = 1000,
                NetReceiveTimeout = 1000,
                NetSendTimeout = 1000,
                ControlMode = ControlMode.Singleton,
                SocketMode = SocketMode.Tcp,
                StartReceiveDataFliter = false,
                ClearSocketSession = false,
                StartCheckPackageLength = false,
                CheckSameSocketSession = false,
            });

            server.AddDeviceCompleted += server_AddDeviceCompleted;
            server.DeleteDeviceCompleted += server_DeleteDeviceCompleted;
            server.SocketConnected += server_SocketConnected;
            server.SocketClosed += server_SocketClosed;
            server.Start();

            server.AddDevice(dev);
        }

.

L'événement dev.ReceiveRequestInfos est une interface d'événement dont le pilote de contrôle hérite de l'extension de classe du pilote RunDevice dans le framework ServerSuperIO. Le mode singleton ServerSuperIO reçoit des informations de données s'il répond aux normes du protocole, les informations de données seront renvoyées. l'interface Communicate du pilote. L'événement ReceiverRequestInfos Les informations sur les données sont transmises à la fonction Dev_ReceiveRequestInfos du service proxy qui s'abonne à l'événement. Le code est le suivant :

La fonction Dev_ReceiveRequestInfos du service proxy transmet les informations au pilote de périphérique correspondant en fonction du DeviceCode (addr) via l'interface du connecteur de service IServiceConnector. . Le code est le suivant :

Le service proxy reçoit les informations de résultat renvoyées par le pilote de périphérique via les interfaces de fonction ServiceConnectorCallback et ServiceConnectorCallbackError si une exception se produit au milieu. , le ServiceConnectorCallbackError sera appelé. Si c'est normal, la fonction ServiceConnectorCallback sera appelée. L'interface de fonction ServiceConnectorCallback envoie le résultat à l'extrémité de contrôle en fonction de la relation correspondante entre la commande enregistrée et le canal IO. Le code ServiceConnectorCallback est tel qu'indiqué ci-dessous :

Il y a une chose à noter ici, c'est-à-dire que le pilote de périphérique ne renvoie pas les informations de confirmation de la commande de contrôle dans le délai spécifié. temps, c'est-à-dire que le capteur ne renvoie pas les informations correspondantes. Dans ce cas, un service de détection de synchronisation doit être ajouté. S'il n'y a aucune information de retour après l'expiration du délai, un message correspondant sera envoyé à l'extrémité de contrôle. Le code est le suivant :

21.6 Pilote de périphérique

Ce pilote de périphérique correspond au capteur et interagit les uns avec les autres dans les données. L'interface RunServiceConnector du pilote de périphérique est chargée de recevoir les informations de commande transmises par la fonction Dev_ReceiveRequestInfos (OnServiceConnector) du service proxy. Le code est le suivant :

Il y a deux explications : 1. Après avoir reçu les données de commande, vous pouvez immédiatement envoyer les informations de données via la fonction OnSendData et utiliser le Réglez IP pour trouver le canal IO correspondant, adapté au mode de contrôle automatique. 2. Après avoir reçu les données de la commande, placez-les dans le cache du protocole this.Protocol.SendCache et attendez que la commande soit émise. Elle convient aux modes d'interrogation et simultanés.

Pour le paramètre isAsyn de l'objet de résultat renvoyé ServiceConnectorCallbackResult, s'il est vrai, cela signifie que les informations de résultat sont renvoyées via le rappel AsyncServiceConnectorCallback, ce qui signifie que vous devez attendre que le capteur renvoie les informations de confirmation, et le pilote de périphérique le reçoit avant de le renvoyer au service d'agent ; si elle est fausse, la description sera immédiatement renvoyée au service proxy, adapté pour transmettre des informations sur les données, que l'interaction avec le capteur soit réussie ou non.

Vous pouvez enregistrer temporairement le paramètre de rappel dans cette fonction, attendre que le capteur renvoie des informations de confirmation, puis déclencher un rappel asynchrone vers le service proxy dans la fonction Communiquer. Le code est le suivant :

21.7 Instructions de démonstration

Ouvrez deux programmes TestDevice, un comme capteur d'appareil et un comme fin de contrôle DeviceCode. être correspondant ; TestDeviceDriver Il s'agit d'un pilote de périphérique chargé dans l'instance de service. J'utilise le mode de contrôle automatique et le projet TestSelfMain est un service proxy chargé dans TestSelfMain. Pour plus de détails, veuillez vous référer au code du projet : .

Remarque : à l'avenir, notre plateforme Big Data pourra également émettre des commandes de contrôle sur le site via ce mode.

---

1. [Série] "Conception et mise en œuvre du cadre de communication C# (port série et réseau)"

2. C# Cross Introduction au framework de communication IoT de la plateforme ServerSuperIO (SSIO)

2 La solution globale pour créer un système utilisant SuperIO (SIO) et le framework IoT multiplateforme open source ServerSuperIO (SSIO)

3.C# Industrial Things Voie technique pour les solutions de mise en réseau et de systèmes intégrés (source de données, collecte de données, téléchargement et réception de données, ActiveMQ, Mongodb, WebApi, application mobile)

Adresse open source de ServerSuperIO :

Internet des objets et technologie d'intégration (.NET) Groupe QQ : 54256083

Adresse de téléchargement :

---

1.C# Introduction au framework de communication IoT multiplateforme ServerSuperIO (SSIO)

"Serial | IoT Framework ServerSuperIO Tutorial" 1.4 mécanismes de mode de communication.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" 2. Description des paramètres de configuration de l'instance de service

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 3. Introduction au pilote de périphérique

" Serial|Internet of Things Framework ServerSuperIO Tutorial"-4. Par exemple, développez un ensemble de pilotes de périphériques prenant en charge à la fois le port série et la communication réseau.

"Série | Internet of Things Framework ServerSuperIO Tutorial" - 5. Développement et précautions du mode de communication d'interrogation.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 6. Développement et précautions du mode de communication simultané

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 7. Développement d'un mode de communication auto-contrôlé et précautions

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 8. Développement du mode de communication Singleton et précautions

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 9. Filtre de protocole à résoudre un problème Paquets multiples, paquets persistants, données redondantes

"Sérialisation | Internet of Things Framework ServerSuperIO Tutorial" - 10. Deux façons de transmettre en continu des flux de données volumineux (tels que des fichiers)

"Sérialisation | Internet of Things Framework ServerSuperIO Tutorial" - 11. Implémenter l'interaction entre les appareils (pilote) et les appareils (pilote) et le contrôle en cascade.

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 12. Développement d'interfaces de service et interaction bidirectionnelle avec le cloud

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 13. Développement d'une interface d'affichage de vue personnalisée pour répondre à différents besoins d'affichage

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 14. Introduction aux outils de configuration et au montage des pilotes de périphérique, des pilotes d'affichage et des instances de service

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 15. Utilisation de l'interface de persistance des données

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 16. Étapes d'utilisation du serveur OPC

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 17. Prise en charge réelle -base de données temporelle, enregistrez les données des points de mesure avec une concurrence élevée

"Serial | Internet of Things Framework ServerSuperIO Tutorial" - 18. Intégrez le client OPC et les étapes d'utilisation

"Serial | Internet of Things Framework ServerSuperIO Tutorial" -19 Le pilote de périphérique et le client OPC prennent en charge la persistance de MySQL, Oracle, SQLite, sqlserver

"Tutoriel Internet of Things Framework ServerSuperIO"-20. Les contrôleurs de communication réseau sont regroupés pour améliorer les capacités d'équilibrage de charge interactif. Sortie de la version v3.6.6

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!