- Ce sujet a 19 réponses, 1 participant et a été mis à jour pour la dernière fois 4 années, 2 mois da
.
-
Post
-
J'ai reçu des demandes de clients qui souhaitent utiliser nos produits SlimLine e Netsyst pour créer un DataLogger. En pratique, il est nécessaire d'acquérir des valeurs analogiques et numériques ou de lire les données des instruments via Modbus et de les enregistrer à intervalles réguliers dans un fichier csv sur le système local.
Pour cette exigence facilement réalisable en utilisant le FB StringToLogFile_v1 (Sujet), J'ai ajouté la possibilité de transférer le fichier journal du disque local du système vers un serveur distant dans le cloud via le protocole FTP en utilisant le FB ClientFTP (Sujet).
Le problème à surmonter dans cette application est la sauvegarde des enregistrements du journal pendant que l'opération de transfert du fichier local vers le serveur FTP est en cours. Ce problème est facilement surmonté avec le FB fifofile, ce qui permet de stocker les données dans un fichier puis de les extraire lorsque cela est possible (Sujet). Comme vous pouvez le voir, le programme exemple historise les données dans le FIFO toutes les minutes et en même temps, si le fichier journal local est libre, il lit à partir du FIFO et enregistre dans le fichier csv.
La connexion au serveur distant se fait toutes les heures (dans l'exemple il se trouve sur le site AlterVista) et le fichier local est transféré vers le serveur distant. Le nom du fichier sur le serveur distant est créé en composant la valeur Date / Heure à laquelle le journal fait référence (Nous aurons des fichiers de type 20160404-23.csv, 20160405-00.csv, etc ...).
Le programme source est fourni pour que chacun puisse le modifier en fonction de ses besoins (Imprimer le programme, Télécharger le programme).
J'utilise le programme Ptp139a000 depuis quelques mois après l'avoir modifié pour les besoins de mon client dans la partie génération de chaînes, mais la logique d'état est restée celle d'origine. Je n'ai rencontré qu'un petit problème: occasionnellement - deux fois, le deuxième il y a deux jours - l'appel
iSysremove: = (Logger.Filename); (* Porte de fichier local *)
il échoue et donc le fichier augmente en taille et a des en-têtes répliqués toutes les heures. SysLastError est simplement 9961200 Erreur lors de la suppression du fichier. Si j'arrête le programme, le système redémarre sans problème et la dernière fois, il a duré 10 jours.
Je pensais que cela pourrait être un problème dû au bloc FTPClient (eLLabNetworkLib_A200) cela ne libère pas le fichier et pour contourner j'ai pensé à modifier le programme afin de séparer les deux opérations (attendre la fin du ftp, suppression) avec un nouveau cas 13. Mais cela pourrait aussi dépendre du bloc StringToLogFile_v1 et j'ai donc pensé ajouter:
Logger (Enable: = TRUE, Write: = FALSE);avant Sysremove.Vous avez bien vu dans le FTPClient FB il y avait un bug qui pouvait créer le problème dont vous vous plaignez, j'ai corrigé le FB et j'ai créé la nouvelle version du programme PTP139A100, que vous pouvez télécharger depuis le site.
Dans cette version, il y a le nouveau FTPClient FB, vous pouvez ouvrir le projet et exporter le FB vers votre bibliothèque, puis l'importer dans votre projet en écrasant l'ancien FB.
J'écris parce que j'ai créé un programme pour l'enregistrement horaire sur des fichiers mensuels d'un certain nombre de quantités acquises via modbus RTU à partir de 3 séries micro PLC Schneider. SlimLine joue le rôle de concentrateur de données et d’enregistreur de données; jusqu’à présent, les fichiers sont correctement enregistrés sur la carte SD installée sur le véhicule et peuvent être consultés et téléchargés via Filezilla.
Cependant, mon client aurait besoin de télécharger automatiquement les fichiers via un script batch à partir de son serveur et ne pouvait en aucun cas se connecter au serveur FTP du slimline et télécharger, y a-t-il une solution?
Si, comme vous le dites, les fichiers sont accessibles via Filezilla mais que le script batch du serveur ne parvient pas à se connecter, le problème est dans le script utilisé.
Êtes-vous sûr d'utiliser une connexion FTP et non SFTP? Il se peut que le programme FTP utilisé dans le lot utilise des commandes FTP non implémentées dans notre serveur FTP, auquel cas j'aurais besoin d'un rapport de connexion pour comprendre quel est le problème.
Mais pourquoi télécharger des fichiers depuis un serveur alors qu'il peut être SlimLine pour les envoyer au serveur FTP dans le cloud, d'ailleurs de cette manière le transfert est possible même s'il est SlimLine il se trouve sur un réseau NATtata et n'est pas accessible depuis Internet.
J'ai besoin de transférer périodiquement un fichier au format FTP depuis un système SlimLine, J’ai écrit un fichier batch avec les commandes:
@ECHO OFF
echo Transfert FTP démarré
ftp -s: cmd.ftp 192.168.0.xxx
écho Fin du transfertVoici le contenu du fichier de commande FTP "cmd.ftp":
Administrateur
Administrateur
cd / Stockage
binaire
get /nomefile.csv
quitterMais je ne peux pas télécharger le fichier. Je ne peux pas télécharger de données sur le cloud car je n'ai pas accès à Internet, le réseau de l'usine est séparé du réseau de l'usine où Internet est présent.
la commande ftp de Windows ne gère pas le transfert passif qui est le transfert géré par le serveur FTP SlimLine. Donc, si vous souhaitez télécharger les fichiers automatiquement, vous devez utiliser un serveur Linux (qui prend en charge le transfert passif) ou un client pour Windows qui prend en charge le transfert passif.
Mais comme votre système est sur un réseau local, vous pouvez toujours avoir les données automatiquement téléchargées sur votre serveur FTP directement depuis SlimLine il n'est pas nécessaire d'utiliser le cloud, il suffit de définir l'adresse IP de votre serveur FTP.
Où puis-je trouver la dernière révision du FTPClient FB? Je demande car je suis en train d'effectuer des tests comparatifs entre les blocs fonctionnels trouvés parmi les différents messages du forum, FTPClient et FTPClient_v1 et pour l'instant seul le bloc FTPClient fonctionne sans erreur. Le bloc FTPClient_v1 en ma possession génère l'avertissement suivant lors de la compilation:
warning G0015: MOVE => Accumulator extension
et l'erreur d'exécution suivante:
[Admin]> syslog
[W] SFW184 [26/07/2018 14:52:31] 6000, User program error:10063030La dernière version de FTPClient_v1 peut être trouvée dans la bibliothèque réseau eLLabNetworkLib_B000, téléchargeable sur le site. La nouvelle version v1 par rapport à la précédente gère l'allocation dynamique des tampons mémoire (Utilisation de la fonction RMalloc). De cette manière, il est possible de dimensionner à volonté les paquets TCP échangés avec le serveur (le maximum est de 1500 octets).
L'erreur 10063030 indique que la taille de la mémoire tampon n'a pas été définie (paramètre DBSize), vous avez probablement utilisé un projet réalisé avec la version précédente et vous n'avez pas défini le paramètre. Jetez un œil auextrait du manuel et voir l'exemple illustré.
J'utilise la dernière version de la bibliothèque (eLLabNetworkLib_B100) et je compile l'exemple de programme en mode SIMULATION, j'ai l'erreur suivante:
Génération du bloc de fonction FTPClient_v1
avorté.FTPClient_v1 (394) - erreur G0129: NULL => Comparaison entre référence et non-référence
FTPClient_v1 (519) - erreur G0129: NULL => Comparaison entre référence et non-référenceAvertissements 0, erreurs 2.
J'ai ressuscité cet article parce que je prépare un système qui envoie automatiquement les fichiers de journalisation quotidiens à un serveur FTP.
En regardant la liste du programme, je comprends bien que si le serveur FTP n'est pas disponible, le programme "s'arrête" dans la condition CaseNr 11 jusqu'à ce que la connexion soit établie? Aussi pour le cas 12, si l'opération n'est pas terminée, le programme continue-t-il avec le cas n ° 12?
Le programme utilise le FB FIFO pour gérer la journalisation. Ainsi, l'enregistrement du journal est enregistré dans le fichier FIFO. Si le fichier journal est libre, il est transféré dans le fichier journal (Case 0), ce qui permet de ne pas perdre d'enregistrements. lorsque le fichier journal est occupé par un transfert FTP.
Lorsque le transfert du fichier journal vers le serveur (cas 10) est commandé, les séquences de connexion commencent ce qui pourrait aller en erreur, auquel cas la sortie serait activée Fault ce qui amène l'exécution à l'affaire 20.
En cas d'erreur, le nombre d'erreurs est augmenté et un délai est attendu avant de réessayer l'envoi.
Donc oui, bien sûr, le programme reste verrouillé dans Case 11 jusqu'à ce que la connexion au serveur soit établie, mais en cas d'échec de la connexion après le délai défini dans le paramètre. Timeout (Voir FTPClient_v1) la sortie est activée Fault. Il en va de même pour le cas 12 où le transfert complet du fichier est attendu.
J'ai raté la ligne 70 de la liste PDF du programme, pensant à tort que toute la gestion des transferts FTP était dans la déclaration CASE. OK, maintenant je comprends tout et tout fonctionne aussi.
Je sauvegarde les données d’un fichier de la carte SD (il y en a donc) et dès que le jour change, le programme envoie le fichier précédent au serveur FTP.
Merci pour la clarification de l'aide toujours à l'heure.
Permettez-moi de revenir à la liste du programme (en supposant que j'en utilise un autre légèrement différent), mais en supposant que je suis dans le cas 20, je me retrouve Store = FALSE. Nous passons au cas 21 et après 10 minutes je passe au cas 10. Essayez la connexion et passez au cas 11. Ici, s'il n'y a pas de serveur disponible (dans mon test, j'ai déconnecté le câble réseau) après un certain temps de Timeout passe en défaut.
Cependant, la ligne 70 vérifie qu'il y a Store à TRUE etFault à TRUE pour aller au cas 20 et gérer l'erreur de connexion. Le magasin ne devient vrai qu'après la connexion au cas 11. J'ai effacé le vrai chèque du magasin à la ligne 70 et tout semble bien fonctionner.
Le FB FTPClient, s'il a Connect = TRUE, tente de se connecter au serveur FTP s'il échoue (comme dans le cas où vous avez déconnecté le câble) après que le délai a généré une erreur. 10063050 désactive la connexion et se réhabilite en réessayant.
S'il n'y a pas de connexion, il est inutile de passer aux cas suivants, de sorte que le programme ne bascule pas délibérément vers le cas 20 mais continue d'attendre pour terminer la connexion. Si vous reconnectez le câble, tout devrait recommencer.
Bien sûr, dans cette condition, étant arrêté au cas 11, je continuerais à bloquer le fichier journal local et les enregistrements de journal satureraient le FIFO. Mais si vous ne pouvez pas vous connecter au serveur FTP, il n'y a pas grand chose à faire.
Dans votre cas, si vous avez supprimé le contrôle sur Store, passez à la synchronisation de la requête 20, puis réessayez et, après que 3 tente de reprendre l'enregistrement dans le fichier journal local, essayez à nouveau de l'envoyer à la prochaine échéance. Cela peut être une solution pour les problèmes de connexion qui durent longtemps. Mais si le câble réseau se débranche, vous continuerez à enregistrer dans le même fichier journal en le saturant. En cas d’avertissement, émettez un avertissement, peut-être avec des témoins lumineux ou autre.
- Vous devez être connecté pour répondre à ce sujet.