Accueil > Forum > contrôleurs SlimLine e Netsyst (LogicLab) > Modules d'extension de vitesse d'acquisition d'entrée numérique
- Ce sujet a 4 réponses, 3 participants et a été mis à jour pour la dernière fois 9 années, 3 mois da Sergio Bertana.
-
auteurPost
-
Août 8, 2012 à 8: pm 58 #35265Anonymeinactif
Consulter la fiche technique matérielle des modules slimline, vous voyez qu'il existe des entrées dites haute vitesse, quelle est la différence par rapport aux autres entrées disponibles?
Si vous souhaitez lire des impulsions de codeur avec une fréquence 200Hz maximum, vous pouvez également utiliser des entrées non haut débit?
Août 9, 2012 à 6: 40 am #37367Sergio BertanaAdministrateur du forumLes entrées haute vitesse sont réalisées avec des optocoupleurs très rapides et peuvent acquérir des signaux d'entrée avec une fréquence maximale de 50 kHz. Toutes les autres entrées ont des optocoupleurs lents et peuvent acquérir des signaux d'entrée avec une fréquence maximale de 10 kHz. Mais au-delà de la limite de vitesse électrique, il faut entrer dans la logique de fonctionnement du module d'acquisition pour comprendre ses possibilités et ses limites.
Un filtre numérique de 5 mS est disposé sur toutes les entrées (même rapides) ce qui limite la fréquence d'acquisition maximale à 200 Hz. Le filtre a été inséré pour couper les signaux de rebond (anti-rebond) des contacts électriques, un automate doit acquérir signaux provenant de transducteurs électromécaniques et doivent garantir leur acquisition correcte.
Sur les entrées rapides, il y a un circuit de comptage qui utilise le signal avant le filtre il permet de gérer un codeur en quadrature avec une fréquence maximale égale à celle typique de l'optocoupleur.
Août 9, 2012 à 6: 52 am #37368Sergio BertanaAdministrateur du forumMais pour répondre à votre question, je vous rappelle que le FB existe dans la bibliothèque de blocs fonction IOEncoder, codeur incrémental sur E / S (Voir extrait manuel). En connectant deux entrées numériques à ce bloc fonctionnel, il est possible d'acquérir un codeur incrémental sur celles-ci.
Bien sûr, la fréquence maximale que vous pouvez gérer dépend de la vitesse d'exécution du bloc fonction, en supposant d'utiliser les deux entrées du module CPU pour l'acquisition (elles n'ont pas de filtre) en créant un simple programme à relais comme celui du manuel, insérez le programme dans la tâche rapide et exécutez-le toutes les 1 mS, vous pouvez gérer des encodeurs avec une fréquence maximale de 200 Hz (Voir note d'application).
Vous pouvez également effectuer une acquisition d'entrée directe via le bloc fonction SysGetPhrDI, obtenez une entrée numérique périphérique, puis mappez les entrées à plusieurs instances du bloc fonction IOEncoder gestion de plusieurs encodeurs.
Janvier 11, 2015 à 9: 45 am #38634Maurizio ContiPartecipanteJ'acquiert une batterie DI avec SlimLine à partir du code suivant:
POUR i: = 0 À 21 DO
(* CAS I DE
0..5: DIN [i]: = SysCPUDI [i];
6..21: DIN [i]: = SysDI00 [i-6];
END_CASE; *)CAS I DE
0: DIN [0]: =% IX255.0;
1: DIN [1]: =% IX255.1;
...
21: DIN [21]: =% IX0.15;
END_CASE;
END_FOR;Pendant que le CAS non commenté fonctionne, lorsque j'essaie de compacter le code (code commenté), j'obtiens les erreurs suivantes: SysCPUDI => Les variables complexes ne peuvent pas avoir d'image de processus
SysDI00 => Les variables complexes ne peuvent pas avoir de mémoire imageToutefois, l'accès à l'élément de tableau SysDI00 dans la fenêtre de surveillance ne pose pas de problèmes. Qu'est-ce que je fais mal ?
Aussi, je vous demande, si vous souhaitez acquérir les DI via Modbus, est-il conseillé / préférable d'utiliser l'état de lecture d'entrée (FC = 02) ou de les placer sur une variable interne et de s'allumer avec la fonction de lecture des registres de maintien (FC = 03)?
Janvier 12, 2015 à 1: pm 54 #38635Sergio BertanaAdministrateur du forumLe problème est lié à la façon dont l'image de processus d'E / S est gérée, vous pouvez trouver plus d'informations dans ce sujet. En pratique, les entrées numériques sont acquises par le système d'exploitation dans la tâche Slow et sont transférées vers les variables UDINT SysCPUDI et SysDIxx, puis transférées vers la table de variables BOOL% IXxx.
Lorsqu'un programme se réfère à une variable% IXxx LogicLab vérifie quelle tâche le programme exécute et s'il s'agit de la tâche lente, il fait référence à la variable réelle, s'il s'agit de la tâche Back, il effectue une copie de la variable réelle dans une variable de support, créant une autre image de processus.
L'image de processus appelons-la une copie, elle est faite automatiquement uniquement sur les variables% IXxx, donc la solution à votre problème est d'exécuter le programme dans la tâche Slow.
En référence à l'acquisition de Modbus, la commande 16 # 02 Lire le statut de l'entrée que 16 # 03 Lire les registres d'exploitation, ils ont à peu près la même longueur en octets dans la trame de réponse, ils sont donc comparables au niveau de la trame. Alors bien sûr le premier vous renvoie un tableau de BOOL tandis que le second retourne un ou plusieurs mots qu'il vous faudra ensuite encore décompresser pour obtenir les valeurs en variables BOOL.
-
auteurPost
- Vous devez être connecté pour répondre à ce sujet.