INÍCIO > Fórum > Programação IEC 61131 (LogicLab) > Realize DataLogger com historicização no servidor de FTP
etiquetadas: aviso ftpClient ftp
- Este tópico tem 19 respostas, 1 participante e foi atualizado pela última vez 4 anos, 2 meses atrás da Sergio Bertana.
-
autorPublique
-
Abril 4, 2016 em 9: 17 am #35987Sergio BertanaAdministrador do fórum
Recebi pedidos de clientes que desejem usar nossos produtos SlimLine e Netsyst para criar um DataLogger. Na prática, a necessidade é adquirir valores analógicos e digitais ou ler dados de instrumentos via Modbus e registrá-los em intervalos regulares em um arquivo csv no sistema local.
Para este requisito facilmente alcançável usando o FB StringToLogFile_v1 (Tema), Adicionei a possibilidade de transferir o arquivo de log do disco local do sistema para um servidor remoto na nuvem via protocolo FTP usando o FB FTPClient (Tema).
O problema a ser superado neste aplicativo é salvar os registros de log enquanto a operação de transferência do arquivo local para o servidor FTP está em andamento. Este problema é facilmente superado com o FB FIFOFile, que permite que os dados sejam armazenados no arquivo e depois extraídos quando possível (Tema) Como você pode ver, o programa de exemplo historiciza os dados no FIFO a cada minuto e, ao mesmo tempo, se o arquivo de log local estiver livre, ele lê do FIFO e salva no arquivo csv.
A conexão com o servidor remoto é feita a cada hora (no exemplo é no site AlterVista) e o arquivo local é transferido para o servidor remoto. O nome do arquivo no servidor remoto é criado compondo o valor Data / Hora a que o log se refere (Teremos arquivos do tipo 20160404-23.csv, 20160405-00.csv, etc ...).
O programa fonte é fornecido para que todos possam modificá-lo de acordo com suas necessidades (Programa de impressão, Download do programa).
Fevereiro 9, 2017 em 12: 25 pm #39839SergioparticipanteEu tenho usado o programa Ptp139a000 por alguns meses depois de modificá-lo para as necessidades do meu cliente na parte de geração de strings, mas a lógica de estado permaneceu a original. Eu só encontrei um pequeno problema: ocasionalmente - duas vezes, a segunda há dois dias - a ligação
iSysremove: = (Logger.Filename); (* Porta de arquivo local *)
ele falha e, portanto, o arquivo aumenta de tamanho e tem cabeçalhos replicados a cada hora. SysLastError é simplesmente 9961200 Erro ao excluir o arquivo. Se eu interromper o programa, o sistema reinicia sem problemas e da última vez continuou por 10 dias.
Eu pensei que poderia ser um problema devido ao bloco FTPClient (eLLabNetworkLib_A200) que não libera o arquivo e para contornar pensei em modificar o programa a fim de separar as duas operações (aguardar final do ftp, exclusão) com um novo caso 13. Mas também poderia depender do bloco StringToLogFile_v1 e então pensei em adicionar:
Logger (Habilitar: = TRUE, Write: = FALSE);antes de Sysremove.Fevereiro 9, 2017 em 1: 51 pm #39840Sergio BertanaAdministrador do fórumVocês viram bem no FTPClient FB que havia um bug que poderia gerar o problema que você reclama, corrigi o FB e criei a nova versão do programa PTP139A100, você pode baixar do site.
Nesta versão existe o novo FB FTPClient, você pode abrir o projeto e exportar o FB para a sua biblioteca, depois importá-lo para o seu projeto sobrescrevendo o FB antigo.
Fevereiro 24, 2017 em 9: 54 am #39854PierluigiparticipanteEscrevo porque criei um programa para o registro de hora em hora em arquivos mensais de um certo número de quantidades adquiridas via modbus RTU de 3 micro séries PLC Schneider, SlimLine atua como um concentrador de dados e registrador de dados, até agora, os arquivos são salvos corretamente no cartão SD instalado no veículo e podem ser consultados e baixados via Filezilla.
No entanto, meu cliente precisaria baixar os arquivos via script em lote de seu servidor automaticamente e não conseguiu se conectar ao servidor FTP do slimline e baixar, existe uma solução?
Fevereiro 25, 2017 em 8: 24 am #39855Sergio BertanaAdministrador do fórumSe, como você disse, os arquivos podem ser acessados através do Filezilla, mas o script em lote do servidor não consegue se conectar, o problema está no script usado.
Tem certeza de que está usando uma conexão FTP e não SFTP? Pode ser que o programa FTP usado no lote use comandos FTP não implementados em nosso servidor FTP, caso em que eu precisaria de um relatório de conexão para entender qual é o problema.
Mas por que baixar arquivos de um servidor quando pode ser SlimLine para enviá-los para o servidor FTP na nuvem, aliás desta forma a transferência é possível mesmo que seja SlimLine ele está em uma rede NATtata e não pode ser acessado pela Internet.
Fevereiro 27, 2017 em 1: 58 pm #39865PierluigiparticipantePreciso transferir periodicamente um arquivo para FTP de um sistema SlimLine, Escrevi um arquivo em lotes com os comandos:
@ ECHO OFF
Echo transferência FTP iniciada
ftp -s: cmd.ftp 192.168.0.xxx
eco final da transferênciaAqui está o conteúdo do arquivo de comando FTP "cmd.ftp":
Administrador
Administrador
cd / armazenamento
binário
obter /nomefile.csv
desistirMas não consigo baixar o arquivo. Não consigo fazer upload de dados para a nuvem porque não tenho acesso à Internet, a rede da fábrica é separada da rede da fábrica onde a Internet está presente.
Março 6, 2017 em 7: 24 am #39866Sergio BertanaAdministrador do fórumo comando ftp do Windows não lida com a transferência passiva que é a transferência gerenciada pelo servidor FTP SlimLine. Portanto, se você deseja baixar os arquivos automaticamente, você deve usar um servidor Linux (que suporta transferência passiva) ou um cliente para Windows que suporta transferência passiva.
Mas como o seu sistema está em uma rede local, você sempre pode ter os dados baixados automaticamente para o seu servidor FTP diretamente do SlimLine não há necessidade de usar a nuvem, basta definir o endereço IP do seu servidor FTP.
Julho 27, 2018 em 6: 46 am #45166AnônimoinativoOnde posso encontrar a revisão mais recente do FTPClient FB? Pergunto porque estou realizando alguns testes comparativos entre os blocos de função encontrados entre os vários posts do fórum, FTPClient e FTPClient_v1 e por enquanto apenas o bloco FTPClient funciona sem entrar em erro. O bloco FTPClient_v1 em minha posse gera o seguinte aviso durante a compilação:
warning G0015: MOVE => Accumulator extension
e o seguinte erro de tempo de execução:
[Admin]> syslog
[W] SFW184 [26/07/2018 14:52:31] 6000, User program error:10063030Julho 27, 2018 em 6: 57 am #45171Sergio BertanaAdministrador do fórumA versão mais recente do FTPClient_v1 pode ser encontrada na biblioteca de rede eLLabNetworkLib_B000, para download no site. A nova versão v1 em comparação com a anterior gerencia a alocação dinâmica de buffers de memória (usando a função RMalloc). Desta forma, é possível dimensionar conforme desejado os pacotes TCP trocados com o servidor (o máximo é 1500 bytes).
Erro 10063030 indica que o tamanho do buffer não foi definido (Parâmetro DBSize), provavelmente você usou um projeto feito com a versão anterior e não definiu o parâmetro. Dê uma olhada noextrato do manual e veja o exemplo mostrado.
Agosto 29, 2019 em 6: 06 am #49451fedeleparticipanteEstou usando a versão mais recente da biblioteca (eLLabNetworkLib_B100) e compilando o programa de exemplo em modo de SIMULAÇÃO, tenho o seguinte erro:
Gerando bloco de funções FTPClient_v1
abortada.FTPClient_v1 (394) - erro G0129: NULL => Comparação entre referência e não referência
FTPClient_v1 (519) - erro G0129: NULL => Comparação entre referência e não referênciaAvisos 0, erros 2.
Setembro 19, 2019 em 9: 22 am #49760RuboxparticipanteRessuscitou esta postagem porque estou preparando um sistema que envia automaticamente arquivos de log diários para um servidor FTP.
Olhando a lista do programa, entendi corretamente que se o servidor FTP não estiver disponível, o programa "para" na condição CaseNr 11 até que a conexão seja estabelecida? Também para o caso 12, se a operação não for concluída, o programa continua com o CaseNr 12?
Setembro 19, 2019 em 9: 44 am #49786Sergio BertanaAdministrador do fórumO programa usa o FIFO FB para gerenciar o registro. Dessa maneira, o registro de log é salvo no arquivo FIFO e, se o arquivo de registro estiver livre, é transferido para o arquivo de log (Caso 0), permitindo não perder registros quando o arquivo de log estiver ocupado por transferência FTP.
Quando a transferência do arquivo de log para o servidor (Caso 10) é comandada, começam as sequências de conexão que podem entrar em erro, caso em que a saída seria ativada Fault que traz execução ao Caso 20.
No caso de um erro, o número de erros é aumentado e um tempo é aguardado antes de tentar novamente o envio.
Portanto, sim, é claro que o programa permanece bloqueado no Case 11 até que a conexão com o servidor seja estabelecida, mas se ele não conseguir se conectar após o tempo definido no parâmetro Timeout (Veja FTPClient_v1) a saída é ativada Fault. O mesmo vale para o Case 12, onde a transferência completa do arquivo é esperada.
Setembro 19, 2019 em 4: 12 pm #49787RuboxparticipantePerdi a linha 70 da listagem em PDF do programa, pensando erroneamente que todo o gerenciamento de transferência FTP estava na instrução CASE. OK, agora eu entendo tudo, e tudo funciona também.
Eu faço o backup dos dados em um arquivo no cartão SD (para que haja alguns) e, assim que o dia muda, o programa envia o arquivo anterior para o servidor FTP.
Obrigado pelo esclarecimento da ajuda sempre na hora certa.
Setembro 20, 2019 em 6: 20 am #49790RuboxparticipantePermita-me voltar à listagem do programa (supondo que estou usando outro um pouco diferente), mas supondo que estou no caso 20, acho Store = FALSE. Vamos para o caso 21 e depois de 10 minutos vou para o caso 10. Tente a conexão e vá para o caso 11. Aqui se não houver nenhum servidor disponível (no meu teste desconectei o cabo de rede) depois de um tempo de tempo limite vai para falha.
No entanto, a linha 70 verifica se há Armazenar em TRUE e Falha em TRUE para ir para o caso 20 e tratar o erro de conexão. Store torna-se verdadeiro somente após conectar ao caso 11. Limpei a verificação true Store na linha 70 e tudo parece funcionar bem.
Setembro 20, 2019 em 6: 32 am #49792Sergio BertanaAdministrador do fórumO FTPClient FB, se tiver Connect = TRUE, tentará se conectar ao servidor FTP, se falhar (como no caso em que você desconectou o cabo) após o tempo limite gerar o erro 10063050 desativa a conexão e reabilita novamente tentando se conectar.
Se não houver conexão, é inútil ir para os casos subsequentes, então o programa não muda deliberadamente para o caso 20, mas continua esperando para completar a conexão. Se você reconectar o cabo, tudo deve começar novamente.
Certamente, nesta condição sendo interrompida no caso 11, eu continuaria a ter o arquivo de log local bloqueado e os registros de log saturariam o FIFO. Mas se você não consegue se conectar ao servidor FTP, não há muito mais o que fazer.
No caso de você ter removido o controle nos saltos da loja para o tempo do caso 20, tente novamente e depois que o 3 tente retomar o salvamento no arquivo de log local, tente novamente enviá-lo para o próximo prazo. Pode ser uma solução para problemas de conexão que duram muito tempo. Mas se o cabo de rede sair, você continuará salvando no mesmo arquivo de log saturando-o. No caso de fornecer um aviso, talvez com lâmpadas de sinalização ou outras.
-
autorPublique
- Você deve estar logado para responder a este tópico.