Bonjour à tous,
Je fais appel à vous car je rencontre un défaut étrange sur un ATV320 équipé d’un VW3A3616 (carte Modbus TCP - Ethernet/IP).
Côté API, j’utilise un M221 avec l’entrée ETH1 configurée en tant que :
API :
Tâche maître en scrutation normale libre (env. 1ms)
Port ETH1 :
Mode Client - Scrutateur d’E/S Modbus TCP
Type : ATV320_ETH_DIRECT
(Com) Time out = 1000ms
(Canaux) Cycle = 50ms
Les registres ETA, RFRD, ETI, DP0 en lecture et CMD et LFRD en écriture au format Cia402 sont mis à jour à chaque cycle automate modulo le cycle des trames à 5x10ms (écrit/lu en dur via les %QWN / %IWN sans les READ/WRITE_VAR qui ne servent à rien en Ioscanner de ce que j'ai compris).
Coté Var, j’utilise un ATV320 et une carte VW3A3616 :
CHCF – Configuration des canaux : Mode canal combiné
FR1 – Fréquence de consigne : fréquence de référence via module de comm
CD1 - Commande : module de comm extérieur
IPM – Adresse IP maître : adresse IP API
IOSA – Comm Ioscanner : Marche
ETHM – Protocole Ethernet : Modbus TCP
TOUT – Time Out : 10s
Mon problème étant le suivant :
Le time out de comm (TOUT) du var réglé à 10s est trop lent (coupure du mouvement après une déconnexion du réseau > 10s).
Nous souhaiterions abaisser cette valeur à 2s.
Cependant, en dessous de 10s, le variateur se met systématiquement défaut « CnF » (communication network fault).
D'après la doc c'est soit les time out mal configurés (mais ce sont les valeurs par défaut sauf trames à 50ms), soit une surcharge, soit défaut hardware (on a changé la carte et même souci).
Par conséquent j'ai remis en cause l'écriture des variables de com %QWN et %IWN et j’ai testé le code en utilisant des blocs MotionControl (MC_POWER/STOP/JOG/etc) plutôt que d’écrire en dur les registres CMD/LFRD. Ça avait le merite de ne pas surcharger la com si ça vient là... Mais le bloc MC_POWER me remonte un défaut n° 1 : IOSCANNER (sans plus de précision …) lors de l'exécution du bloc (tous les blocs remontent ce défaut. Je précise que le statut de la comm côté API via le mot système est opérationnel, pas de défaut détecté côté API. C est le var qui se "bloque" tout seul.
Je précise qu’une fois TOUT = 10s, le défaut ne se déclenche plus et la machine fonctionne parfaitement.
Fait intéressant, impossible de supprimer le défaut CnF sans redémarrer le var. La commande reset en dur et via le bloc MC_RESET ne fonctionne pas pour ce défaut ...
Est-ce que quelqu’un a rencontré ce souci ou a un modèle M221/ATV320 en modbus tcp ioscanner ?
Franchement c'est si simple sur les tutoriel que je comprends pas ce qui peut bien bloquer ...
Merci,
ATV320/M221 : Défaut CnF - Modbus TCP
Re: ATV320/M221 : Défaut CnF - Modbus TCP
Re, j'ai trouvé cela venait du reset de la comm via le bit système.. Pas d'envoi de commande (même un reset defaut var) pendant la réinitialisation (logique). Problème réglé en 2s.