Schéma de câblage des terminaux INTOOLS : solution efficace

Ce post est une série ; une fois le travail terminé et publié, il pourra être partagé avec tout le monde

SPI, c’est vraiment top. Passage avec EXCEL. . .

Pour en parler brièvement, l’idée est bonne, mais elle présente souvent des problèmes de fiabilité. Lorsque je l’ai fait à l’époque, j’avais également pensé à remplir Orical par écriture externe, mais j’ai découvert que c’était trop risqué et qu’il y avait de fortes chances de rencontrer des problèmes. Comme il s’agit d’une opération manuelle et non contrôlable, les données que vous importez peuvent ne pas respecter les règles de la base de données : espaces ajoutés avant ou après les données, ainsi que toutes sortes d’opérations inhabituelles sont possibles. Étant donné que les données sont importées (généralement à l’aide d’EXCEL), on ne peut pas garantir leur normalisation, ce qui peut facilement endommager la base de données. De plus, une fois ce problème survenu, il est difficile de le détecter ; vous ne remarquerez que des erreurs lors de l’utilisation de la fonction de connexion SPI, sans pouvoir identifier précisément l’erreur. Par conséquent, pour des logiciels aussi spécialisés et fermés, il n’est pas recommandé d’utiliser directement une méthode d’écriture externe. Vous pouvez utiliser les données présentes dans sa propre base de données, mais il n’est pas conseillé d’y écrire des données soi-même.

Bonjour, merci pour votre message. À l’heure actuelle, après des tests, l’écriture dans la base de données via SQL ne pose aucun problème. L’essentiel réside dans l’analyse de la structure de la base de données INTOOLS, afin de clarifier les liens entre les différents paramètres ainsi que les interactions entre les données.

Le développement peut être divisé en 5 étapes : 1. Analyser la structure de la base de données et sélectionner les tables nécessaires. 2. Analyser les tables de la base de données sélectionnées, définir les différentes informations des paramètres, établir le format des paramètres pour les instructions SQL, ainsi que les différentes informations de mise en appel des tables de la base de données. 3. Élaborer des règles pour l’attribution des numéros de position, des câbles et du contrôle centralisé, en tenant compte des normes du secteur. 4. Intégrer les règles établies dans le programme, et générer en masse des instructions SQL directement utilisables dans la base de données, conformément au format des instructions SQL défini lors de la deuxième phase.

Il convient d’abord d’expliquer la méthode traditionnelle de dessin CAD. Cette méthode est facile à maîtriser, mais elle nécessite de créer manuellement le cadre et d’entrer diverses informations, ce qui la rend peu efficace. Cependant, dans les grands projets, avec des numéros de référence allant parfois à plusieurs milliers, cela nécessite souvent beaucoup d’heures de travail et ne permet pas de répondre aux besoins de production.

La première étape consiste à analyser la structure de la base de données. Après avoir fréquemment utilisé INTOOLS, on devient plus familier avec sa structure ; aucune explication supplémentaire n’est nécessaire à ce sujet. De plus, des questions de confidentialité sont également en jeu, nous espérons que vous comprenez. Dans la deuxième phase, une fois la structure de la base de données INTOOLS définie, il est nécessaire de mettre en place un format pour chaque instruction individuelle : par exemple, pour enregistrer un câble, une boîte de connexion, une borne, etc., des instructions spécifiques sont requises. Une fois ces instructions élaborées à cette étape, la quatrième phase les traitera en lot.

La troisième phase consiste principalement à établir, en se basant sur les normes du secteur, divers règlements adaptés à ce domaine, y compris des règles concernant les câbles, les boîtiers de connexion, le poste de contrôle central, etc. La quatrième phase est le processus d’intégration des deuxième et troisième phases, au cours duquel les procédures appropriées sont élaborées selon les besoins.

Les conditions d’entrée du logiciel nécessitent au total cinq informations : numéro de position, type IO, boîte de connexion de départ, boîte de connexion intermédiaire et poste de contrôle central. Une fois ces informations saisies, il est possible d’obtenir via le logiciel des instructions SQL directement exécutables

L’image en pièce jointe contient des instructions SQL générées en masse, au format EXCEL. Pour les utiliser, il suffit de copier et coller les SQL dans le client puis de les exécuter. L’exécution des instructions SQL pour un projet de 3000 entrées prend environ 5 minutes. Le temps réel de génération des instructions SQL par le logiciel est d’environ 30 secondes.

D’après votre description, il s’agit probablement d’une erreur de type de données lors de l’écriture ; les valeurs correspondantes devraient être liées entre elles. Par exemple, pour le stockage du type IO dans la base de données, il suffit d’appeler les données de la table IO_TYPE ; dans la table component, il suffit de saisir l’ID correspondant. Cependant, si vous saisissez directement le type IO dans la base de données, celle-ci affichera une erreur. Chaque module d’INTOOLS est identique, et son appel est très complexe.

Une fois l’écriture terminée, vous pouvez vous connecter à INTOOLS pour consulter ce qui a été écrit ; en cas de problème, vous pouvez effectuer des ajustements manuels. Après l’écriture du module de connexion, le câble est également écrit, et il est possible de récupérer la liste des câbles directement depuis INTOOLS.

Eh bien… vous ne comprenez peut-être pas ce que je veux dire. Je ne sais pas si ce que vous écrivez est destiné à votre usage personnel ou à l’usage de toute l’équipe. Si vous créez un logiciel que tout le monde doit utiliser, alors vous comprendrez ce que je veux dire une fois qu’il sera mis en service. Les utilisateurs n’ont absolument aucune idée de comment fonctionne votre programme ; ils savent simplement que s’ils saisissent des données, vous pourrez les transférer dans INTOOLS. La correction de ces données ne fait pas du tout partie de leurs préoccupations. Par exemple, si une colonne dans la base de données est de type numérique, mais que l’utilisateur y saisisse du texte, cela provoquera une erreur lors du transfert dans la base de données. C’est quelque chose de facile à détecter. Beaucoup de gens utilisent la fonction copier-coller dans Excel, et il est même possible qu’ils collent divers caractères invisibles. Par exemple, on dirait qu’il n’y a rien, mais en réalité il y a un espace après les données ; on voit bien l’espace, mais en fait c’est un symbole caché dont on ignore la nature. De tels problèmes sont monnaie courante et apparaissent sans cesse. Ce n’est pas que la fonctionnalité ne puisse pas être mise en œuvre, mais c’est tout simplement trop difficile à utiliser pour les utilisateurs, ce qui entraîne une instabilité des données du projet. C’est ce que je veux dire.

Je comprends alors : le niveau varie au sein du département, ce problème existe bel et bien. Mais mon logiciel n’a besoin que d’informations simples ; lors de son utilisation, il suffit de recopier-coller les données sources et de ne conserver que les données. Il n’y a qu’un élément clé, le reste, avec des espaces ou autre, n’est pas affecté

J’admire vraiment ce type de développement secondaire dans les logiciels, car il permet d’améliorer considérablement l’efficacité au travail.

Dans le processus de conception réel, il est préférable que les ingénieurs responsables aient des compétences de base en rédaction de commandes SQL, ainsi qu’une certaine connaissance de la structure de la base de données.