COMUNICAÇÃO ABERTA TCP/IP VIA

ETHERNET INDUSTRIAL PARA CLP

SIEMENS
RODRIGO BORGES
 APRESENTAÇÃO:
Nome: Rodrigo M. Borges

Especialista de automação

10 anos de experiencia na área de automação e

elétrica.

Midias Sociais:
LinkedIn: https://br.linkedin.com/in/rodrigo-borges-
tecrmb
Instagram:https://www.instagram.com/rodrigomoreir
a.borges/
Youtube: https://www.youtube.com/c/InversoresCari
oca
COMUNICAÇÃO ABERTA TCP/IP VIA ETHERNET
INDUSTRIAL PARA CLP SIEMENS E “OUTROS”
DISPOSITIVOS
• A comunicação aberta TCP/IP é um recurso muito útil para interligar o CLPs
no chão de fábrica com sistemas superiores (ERP, WMS, MES) em aplicações
Desktop/Servidor, ou conexão com outros equipamentos e/ou CLPs.
• Com ela nós podemos gerar Status, Comandos e qualquer outra troca de
informações que sua aplicação necessitar.
• É muito comum encontrar esse tipo de comunicação no chão de fábrica
interligando diversos equipamentos
O QUE VOCÊ VAI APRENDER
NESSE TREINAMENTO?
• Nós vamos abordar a configuração de comunicações abertas TCP/IP
através de CLPs do Fabricante SIEMENS.
• Serão demostrado como configurar comunicações entre CLPs, Softwares
utilitários para PC, assim como tambem serão utilizados simuladores
como o simulador HRSS do robô HIWIN e tambem o software utilitário
Hercules só para citar alguns.
• Na maior parte do curso iremos utilizar o software TIA Portal v15.1
para realizar as configurações.
• Esse curso é composto por aulas teóricas e práticas que lhe
proporcionarão um entendimento completo sobre o tema proposto.
MODULO 1 -
CONCEITOS INICIAIS

• Protocolo TCP;

• Conceitos de
Cliente/Servidor;

• O Conceito de Porta;

• Three-Way Handshake.
PROTOCOLO TCP
• Protocolo TCP é um serviço de entrega de pacotes que
garante a entrega e a integridade do pacote na conexão
lógica entre dois computadores. Nesse tipo de comunicação,
ambos os computadores entram em conformidade de como
será feito o envio dos pacotes entre si.
• Quando uma informação é transmitida, mecanismos de
verificação de integridade garantem que a informação seja
recebida sem erros.
• É utilizado em transmissões onde nenhum tipo de erro é
aceitável como por exemplo http, ftp etc.
• Por conta dos vários mecanismos de verificação que ele
possui o torna relativamente mais lento se o compararmos
com o protocolo UDP que possui mecanismos de verificação
mais simples.
CONCEITOS DE CLIENTE/SERVIDOR

Os dispositivos de rede como

computadores, controladores
programáveis e muitos outros podem
exercer a função de cliente ou servidor.
Um dispositivo é considerado servidor
quando disponibiliza seus recursos na
rede e é considerado cliente quando
utiliza um determinado recurso na rede
disponibilizado por algum servidor.
CONCEITOS DE CLIENTE/SERVIDOR

• Outro aspecto importante é que um cliente pode se conectar a vários servidores e

um servidor pode disponibilizar recursos para vários clientes.
• A rede baseada em servidor possui dispositivos dedicados a execução de tarefas
específicas como por exemplo, servidor de banco de dados, hospedagem WEB,
servidores de aplicação como Apache por exemplo, servidores de email.
• O dispositivo fica dedicado apenas a executar sua tarefa, podendo também existir
a possibilidade de um dispositivo prover mais de um serviço, isto é, uma máquina
pode ser um servidor de banco de dados e páginas WEB simultaneamente.
 O CONCEITO DE PORTA

• Para cada nível da arquitetura existe um campo no

protocolo da camada que indica para quem os dados
encapsulados devem ser entregues.
• No nível de enlace, o campo Type indica qual é o protocolo
que está encapsulado no frame Ethernet (p.ex., um valor
igual a 0x0800 indica que os dados devem ser passados
para o IP).
• No nível de rede, o campo Protocol no cabeçalho do IP
identifica o protocolo para o qual o datagrama deve ser
repassado (p.ex., 17 para o UDP e 6 para o TCP).
• De maneira similar, para distinguir dentre as várias
aplicações, o nível de transporte associa um identificador a
cada processo de aplicação. Esse identificador é chamado
de “Porta” (“port number).
O CONCEITO DE PORTA

• Uma porta é um objeto abstrato, codificado por um número inteiro de 16 bits, usado
para identificar processos de aplicação.
• Para uma aplicação poder “falar” com uma outra numa máquina remota, é preciso
conhecer não apenas o endereço IP da máquina destino mas também a porta
associada à aplicação parceira.
• O UDP e o TCP fornecem um conjunto de portas que permite a múltiplos processos
dentro de uma única máquina usarem os serviços de comunicação providos pelo UDP
e TCP simultaneamente.
• Números de portas origem e destino são incluídos no cabeçalho do TCP e do UDP.
THREE-WAY HANDSHAKE
• Handshake de três vias, é responsável pelo
estabelecimento da conexão TCP.
• Como funciona:
• 1º-O Cliente envia um pacote com a flag SYN
ativa;
• 2º-O Servidor responde com um pacote com as
flags SYN + ACK;
• 3º-O Cliente responde com um pacote ACK.

• ACK = Acknowledgement(Reconhecimento).
• SYN = Synchronize(Sincronizar).
MODULO 2 - FUNDAMENTOS DE COMUNICAÇÃO
ABERTA PARA OS CONTROLADORES SIEMENS
• Visão geral da Comunicação aberta via
Ethernet industrial;
• O que é um RFC?
• Blocos de Comunicação no s7;
• TCP nativo de acordo com RFC 793;
• ISO on TCP de acordo com RFC 1006;
• UDP de acordo com RFC 768;
• Protocolos orientados a conexão e sem
conexão
 • No STEP 7 nos temos os seguintes modos de comunicação
aberta:
VISÃO GERAL
DA ➢Protocolos orientados a conexão:
COMUNICAÇÃO • TCP nativo de acordo com RFC 793.

ABERTA VIA • ISO on TCP de acordo com RFC 1006.

ETHERNET ➢Protocolo sem conexão:

INDUSTRIAL • UDP de acordo com RFC 768.
 • Acrônimo de Request for Comments (ou
"pedido para comentários" em português),
as RFCs são documentos técnicos
desenvolvidos e mantidos pelo IETF (Internet
O QUE É UM Enginnering Task Force), instituição que
especifica os padrões que serão
RFC?
implementados e utilizados em toda a
internet. Cada um deles deve detalhar o
funcionamento de todos os aspectos do
protocolo proposto.
BLOCOS DE COMUNICAÇÃO NO S7

• O STEP 7 fornece os seguintes "Blocos de Comunicação" para a troca de dados por meio do
programa do usuário com outros parceiros de comunicação compatíveis com Ethernet:
• Protocolos orientados a conexão: TCP nativo de acordo com RFC 793, ISO on TCP de acordo
com RFC 1006:
• UDT 65 "TCON_PAR" com a estrutura de dados para atribuição de parâmetros de conexão
• FB 65 "TCON" para estabelecer uma conexão
• FB 66 "TDISCON" para encerrar uma conexão
• FB 63 "TSEND" para enviar dados
• FB 64 "TRCV" para receber dados
BLOCOS DE COMUNICAÇÃO NO S7

• Protocolo sem conexão: UDP de acordo com RFC 768

• UDT 65 "TCON_PAR" com a estrutura de dados para atribuição de parâmetros
para o ponto de acesso de comunicações locais
• UDT 66 "TCON_ADR" com a estrutura de dados para atribuição de parâmetros de
endereçamento para o parceiro remoto
• FB 65 "TCON" para configurar o ponto de acesso de comunicações locais
• FB 66 "TDISCON" para fechar o ponto de acesso de comunicações locais
• FB 67 "TUSEND" para envio de dados
• FB 68 "TURCV" para receber dados
TCP NATIVO DE ACORDO COM RFC 793
• Protocolo de transporte fim - a -fim, orientado a conexão, que fornece um serviço de
transferência confiável de dados entre aplicações parceiras. Garante que os dados são
entregues livres de erro, em sequência e sem perdas ou duplicação.
• Durante a transmissão de dados, nenhuma informação sobre a duração ou sobre o início e o
fim de uma mensagem é transmitida. Isso não é um problema durante o envio, pois o
remetente sabe quantos bytes de dados enviará. No entanto, o receptor não tem meios de
detectar onde uma mensagem termina no fluxo de dados e a próxima começa. Por este
motivo, é recomendado que o parâmetro LEN do FB 64 "TRCV" (número de bytes a serem
recebidos) seja atribuído o mesmo valor que o parâmetro LEN do FB 63 "TSEND" para o
parceiro de comunicação (número de bytes a serem enviei). Se você especificou o
comprimento dos dados a serem recebidos (parâmetro LEN do FB 64 "TRCV") para ser maior
que o comprimento dos dados a serem enviados, o FB 64 "TRCV" apenas copiará os dados
recebidos na área do receptor (Parâmetro DATA) após o comprimento especificado pelo
valor do parâmetro ter sido atingido.
TCP NATIVO DE ACORDO COM RFC 793

• Isso ocorre somente depois que os dados de um trabalho seguinte foram recebidos.
Observe que, neste caso, os dados de dois trabalhos de envio diferentes estarão
localizados na mesma área de recepção. Se você não souber o comprimento exato
da primeira mensagem, não terá como detectar o final da primeira mensagem ou o
início da segunda.
• Se você especificou o comprimento dos dados a serem recebidos (parâmetro DATA
de FB 64 "TRCV") seja menor que o comprimento dos dados enviados, o FB 64
copiará tantos bytes no intervalo do receptor quanto você especificou no parâmetro
LEN. Depois disso, ele definirá NDR como TRUE e escreverá RCVD_LEN com o valor
de LEN. A cada chamada adicional, você receberá outro bloco de dados enviados.
 ISO ON TCP DE ACORDO COM RFC 1006

• RFC 1006 intitulado "Serviço de transporte ISO em

cima do TCP" é uma extensão de protocolo para o
protocolo TCP. Aqui, mais informações são transferidas
entre os nós, além dos dados TCP, a fim de fornecer
serviços adicionais para o usuário (serviços ISO como
extensão do TCP).
• O protocolo S7 (RFC 1006) permite a conexão de
dispositivos de automação S7 com qualquer parceiro de
comunicação. Ele fornece acesso direto à memória do
usuário S7 sem alterações no próprio aplicativo do
usuário. Conforme mostrado na figura ao lado, o protocolo
S7 (RFC 1006) suporta uma variedade de métodos de
transporte diferentes. Para o uso de TCP / IP, apenas uma
unidade de comunicação (CP) para conexão Ethernet ou,
alternativamente, uma interface Ethernet onboard que
suporte ISOonTCP ( RFC1006) deve estar disponível.
ISO ON TCP DE ACORDO COM RFC 1006

• O protocolo S7 (RFC 1006) permite o endereçamento de todos os internos no

lado do PLC, ou seja, sem limitação nos blocos de dados (DB). Dependendo
do PLC, apenas pequenas ou nenhuma alteração de configuração deve ser
feita para suportar o protocolo S7 (RFC 1006) . A série SIMATIC® S7
suporta o protocolo ISO-on-TCP nativamente em modo passivo, ou seja, opera
como servidor e aceita conexões de cliente.
ISO ON TCP DE ACORDO COM RFC 1006

• Durante a transmissão de dados, também são transmitidas informações sobre o

comprimento e o final da mensagem. Se você especificou o comprimento dos dados
a serem recebidos (parâmetro LEN de FB 64 "TRCV") para ser maior do que o
comprimento dos dados a serem enviados, FB 64 "TRCV" copiará os dados
recebidos completamente para a faixa do receptor . Depois disso, ele definirá NDR
como TRUE e escreverá RCVD_LEN com o comprimento dos dados enviados. Se você
especificou o comprimento dos dados a serem recebidos (parâmetro DATA de FB 64
"TRCV") seja menor que o comprimento dos dados enviados, o FB 64 não copiará
nenhum dado para a faixa do receptor, mas em vez disso fornecerá as seguintes
informações de erro: ERROR = 1, STATUS = W # 16 # 8088 ou 80C9.
UDP DE ACORDO COM RFC 768

• O User Datagram Protocol (UDP) é um padrão TCP/IP e está definido pela RFC
768. O UDP é usado por alguns programas em vez do TCP para o transporte
rápido de dados entre hosts. Porém o UDP não fornece garantia de entrega,
ordenação, controle de fluxo e controle de congestionamento. Essa solução pode
parecer pouco ortodoxa, porém em determinadas situações é a melhor opção para
a camada de transporte, principalmente pelo fato de o UDP ser muito mais rápido e
gerar menos tráfego na rede, uma vez que não faz verificações e não estabelece
sessões.
• As funcionalidades fornecidas pelo TCP devem ser realizadas pela a camada de
aplicação quando a mesma utiliza o UDP como protocolo de transporte e necessita
desses cuidados.
UDP DE ACORDO COM RFC 768

• Ao contrário do TCP nativo e do ISO nos protocolos TCP, com UDP você não
estabelece uma conexão. Neste caso, ao chamar o bloco emissor FB 67
"TUSEND" deve-se especificar os parâmetros de endereço do receptor
(endereço IP e número da porta). Da mesma forma, após a conclusão do
bloco receptor FB 68 "TURCV", você receberá uma referência aos
parâmetros de endereço do remetente (endereço IP e número da porta). Para
poder usar os FBs 67 "TUSEND" e 68 "TURCV", primeiro você deve ligar para
o FB 65 "TCON" tanto no lado de envio quanto no lado de recepção. Esta
etapa é necessária para configurar o ponto de acesso de comunicação local.
UDP DE ACORDO COM RFC 768

• Com cada nova chamada do FB 67 "TUSEND", você referencia novamente o

parceiro remoto especificando seu endereço IP e seu número de porta. Durante a
transmissão de dados, também são transmitidas informações sobre o comprimento e
o final da mensagem. Se você especificou o comprimento dos dados a serem
recebidos (parâmetro LEN do FB 68 "TURCV") para ser maior que o comprimento
dos dados a serem enviados, o FB 68 "TURCV" copiará os dados recebidos
completamente para o intervalo do receptor . Depois disso, ele definirá NDR como
TRUE e escreverá RCVD_LEN com o comprimento dos dados enviados. Se você
especificou o comprimento dos dados a serem recebidos (parâmetro DATA do FB 68
"TURCV") para ser menor que o comprimento dos dados enviados, o FB 68 não
copiará nenhum dado para o intervalo do receptor, mas em vez disso fornecerá o
seguinte informações de erro: ERROR = 1, STATUS = W # 16 # 8088.
PROTOCOLOS ORIENTADOS A CONEXÃO E SEM
CONEXÃO
• Os seguintes tipos de protocolos são diferenciados na comunicação de dados:
 • Protocolos orientados a conexão: Eles estabelecem uma
conexão lógica com o parceiro de comunicação antes do início
da transmissão de dados. Depois que a transmissão de dados
for concluída, eles encerrarão a conexão, se necessário. Os
protocolos orientados a conexão são usados para transmissão
de dados quando uma entrega confiável e garantida é de
PROTOCOLOS particular importância. Em geral, muitas conexões lógicas
podem existir em uma linha física.
ORIENTADOS • Os seguintes protocolos orientados à conexão são suportados
A CONEXÃO: com FBs para comunicação aberta via Ethernet Industrial:
• - TCP/IP nativo de acordo com RFC 793 (com tipos de
conexão B # 16 # 01 e B # 16 # 11).
• - ISO on TCP de acordo com RFC 1006 (com tipo de conexão
B # 16 # 12).
 • Funcionam sem conexão, portanto, não há
estabelecimento e encerramento de uma conexão
com um parceiro remoto. Os protocolos sem conexão
transmitem dados não confirmados, sem entrega
confiável e garantida ao parceiro remoto. O
PROTOCOLOS seguinte protocolo orientado à conexão é suportado
SEM com FBs para comunicação aberta via Ethernet
Industrial:
CONEXÃO: • UDP de acordo com RFC 768 (com tipo de conexão
B # 16 # 13)
MÓDULO 3 – CONHECENDO OS BLOCOS DE
CONEXÃO
• Estabelecendo uma conexão com FB 65 "TCON“
• Terminando uma conexão com FB 66 "TDISCON"
• Envio de dados via TCP nativo e ISO on TCP com
FB 63 "TSEND“
• Recebendo dados via TCP nativo e ISO on TCP
com FB 64 "TRCV"
• Estrutura TSAP
• Enviando dados via UDP com FB 67 "TUSEND“
• Recebendo dados via UDP com FB 68 "TURCV“
• TSEND_C: Estabelecendo uma conexão e
enviando dados
• TRCV_C: Estabelecendo uma conexão e
recebendo dados
 • Usando com TCP nativo e ISSO on TCP: Ambos os parceiros de comunicação
chamam FB 65 "TCON" para estabelecer a conexão de comunicação.
• Nos parâmetros, você especifica qual parceiro é o ponto de transmissão de
comunicações ativo e qual é o passivo.
•
ESTABELECENDO Para obter informações sobre o número de conexões possíveis, precisamos consultar
os dados técnicos de nossa CPU.
UMA CONEXÃO • Após o estabelecimento da conexão, ela é monitorada e mantida automaticamente
COM FB 65 pela CPU.
• Se a conexão for interrompida, por exemplo, devido a uma quebra de linha ou
"TCON" devido ao parceiro de comunicação remoto, o parceiro ativo tenta restabelecer a
conexão.
• Neste caso, não é necessário chamar o FB 65 "TCON" novamente.
• Uma conexão existente é encerrada quando o FB 66 "TDISCON" é chamado ou
quando a CPU entra no modo STOP. Para restabelecer a conexão, você terá que
ligar novamente para o FB 65 "TCON".
 • Usando com UDP: Ambos os parceiros de comunicação
ligam para o FB 65 "TCON" para configurar seu ponto de
ESTABELECENDO acesso de comunicação local.
UMA CONEXÃO • Uma conexão é configurada entre o programa do usuário
COM FB 65 e o nível de comunicação do sistema operacional.
"TCON" Nenhuma conexão é estabelecida com o parceiro remoto.
O ponto de acesso local é usado para enviar e receber
quadros de mensagens UDP.
 • FB 65 "TCON" é um FB de funcionamento assíncrono, o que significa que seu
processamento se estende por várias chamadas FB.
• Para iniciar o estabelecimento de uma conexão, ligue para FB 65 com REQ
= 1.
• O status do trabalho é indicado nos parâmetros de saída RET_VAL e BUSY.
• STATUS corresponde ao parâmetro de saída RET_VAL de SFCs de
funcionamento assíncrono.

FUNÇÃO • A tabela a seguir mostra as relações entre BUSY, DONE e ERROR.

• Usando esta tabela, você pode determinar o status atual do FB 65 ou
quando o estabelecimento da conexão for concluído.
PARÂMETROS
INFORMAÇÃO DE ERRO
 • Usando com TCP nativo e ISO on TCP: FB 66
"TDISCON" finaliza uma conexão de
comunicação da CPU para um parceiro de
TERMINANDO comunicação.
UMA
CONEXÃO • Usando com UDP: O FB 66 "TDISCON"
COM FB 66 fecha o ponto de acesso de comunicação
"TDISCON" local. A conexão entre o programa do
usuário e o nível de comunicação do sistema
operacional é encerrada.
 • FB 66 "TDISCON" é um FB de funcionamento assíncrono, o que significa que
seu processamento se estende por várias chamadas FB.
• Para começar a encerrar uma conexão, ligue para FB 66 com REQ = 1.
• Após o FB 66 "TDISCON" ter sido chamado com sucesso, o ID especificado
para o FB 65 "TCON" não é mais válido e, portanto, não pode ser usado
para envio ou recebimento.
• O status do trabalho é indicado nos parâmetros de saída RET_VAL e BUSY.
FUNÇÃO • STATUS corresponde ao parâmetro de saída RET_VAL de SFCs de
funcionamento assíncrono. A tabela a seguir mostra as relações entre BUSY,
DONE e ERROR. Usando esta tabela, você pode determinar o status atual
do FB 66 ou quando o estabelecimento da conexão for concluído.
PARÂMETROS
INFORMAÇÃO DE ERRO
ENVIO DE DADOS VIA TCP NATIVO E ISO ON TCP
COM FB 63 "TSEND"
PARÂMETROS LEN E DATA
 • FB 63 "TSEND" é um FB de funcionamento assíncrono, o que significa
que seu processamento se estende por várias chamadas FB.
• Para começar a enviar dados, ligue para FB 63 com REQ = 1.
• O status do trabalho é indicado nos parâmetros de saída BUSY e
STATUS. STATUS corresponde ao parâmetro de saída RET_VAL de
SFCs de funcionamento assíncrono.
• A tabela a seguir mostra as relações entre BUSY, DONE e ERROR.
FUNÇÃO Usando esta tabela, você pode determinar o status atual do FB 63
ou quando o estabelecimento da conexão for concluído.

• Nota Devido à função assíncrona do FB 63 "TSEND", você deve

manter os dados na área do emissor consistentes até que o
parâmetro DONE ou o parâmetro ERROR assuma o valor TRUE.
PARÂMETROS
INFORMAÇÃO DE ERRO
RECEBENDO
DADOS VIA
TCP NATIVO E
ISO ON TCP
COM FB 64
"TRCV"
MODOS DE RECEPÇÃO DE “TRCV”
VARIANTES DO PROTOCOLO
 • Função:
• FB 64 "TRCV" é um FB de funcionamento assíncrono, o que significa que seu
processamento se estende por várias chamadas FB.
• Para começar a receber dados, chame FB 64 com REQ = 1.
RECEBENDO • O status do trabalho é indicado nos parâmetros de saída BUSY e STATUS.
DADOS VIA • STATUS corresponde ao parâmetro de saída RET_VAL de SFCs de
funcionamento assíncrono. A tabela a seguir mostra as relações entre BUSY,
TCP NATIVO E DONE e ERROR. Usando esta tabela, você pode determinar o status atual
do FB 64 ou quando o processo de recebimento for concluído.
ISO ON TCP
COM FB 64
"TRCV"

• Nota Devido à função assíncrona do FB 64 "TRCV", os dados na área

do receptor só são consistentes quando o parâmetro NDR assume o
valor TRUE.
PARÂMETROS
INFORMAÇÃO DE ERRO
ESTRUTURA TSAP

• Introdução:
Para uma conexão ISO-on-TCP, os pontos de acesso do serviço de transporte
(TSAPs) devem ser atribuídos a ambos os parceiros de comunicação. TSAP IDs
são atribuídos automaticamente após a criação de uma conexão ISO-on-TCP.
Para garantir a exclusividade de TSAP IDs em um dispositivo, você pode alterar
os TSAPs pré-atribuídos na atribuição de parâmetro de conexão.
ESTRUTURA DE TSAPS:

• Você deve cumprir certas regras ao atribuir TSAPs. Um TSAP deve conter um
certo número de bytes, que podem ser exibidos e inseridos como valores
hexadecimais (TSAP-ID) ou como caracteres ASCII (ASCII-TSAP):

• As entradas ou alterações do TSAP-ID ou ASCII-TSAP nos campos de entrada

correspondentes sempre têm efeito no outro formato de exibição também.
ESTRUTURA DE TSAPS:
• Se um TSAP não contiver caracteres ASCII válidos, o TSAP será exibido
apenas como TSAP-ID e não como ASCII-TSAP. Este é o caso depois que uma
conexão é criada. Os primeiros dois caracteres hexadecimais como TSAP-ID
identificam o tipo de comunicação e o rack / slot. Como esses caracteres não
são caracteres ASCII válidos para uma CPU, o ASCII-TSAP não é exibido
neste caso.

• Além das regras de comprimento e estrutura de TSAPs, você também deve

garantir a exclusividade do TSAP-ID. Os TSAPs atribuídos não são
automaticamente exclusivos.
COMPRIMENTO E CONTEÚDO DOS TSAPS
• Estrutura do TSAP ID com extensão TSAP:
• Válido para CPU S7-1200 firmware V1
• Comprimento = 2 a 16 bytes
• x_tsap_id [0] = 0xE0 (comunicação aberta do usuário)
• x_tsap_id [1] (bits 0 a 4) = número do slot da CPU
• x_tsap_id [1] (bits 5 a 7) = número do rack da CPU
• x_tsap_id [2 ... 15] = qualquer caractere (extensão TSAP, opcional)
• (x = loc (local) ou x = rem (parceiro))
VÁLIDO PARA FIRMWARE CPU S7-1500 E S7-1200 A
PARTIR DE V2

• Comprimento = 2 a 16 bytes
• x_tsap_id [0] = 0xE0 (comunicação aberta do usuário)
• x_tsap_id [1] = 0x00 a 0xFF
• x_tsap_id [2 ... 15] = qualquer caractere (extensão TSAP, opcional)
• (x = loc (local) ou x = rem (parceiro))
ESTRUTURA DO TSAP ID COMO ASCII TSAP:

• Válido para CPU S7-1200 firmware V1

• Comprimento = 3 a 16 bytes
• x_tsap_id [0 ... 2] = 3 caracteres ASCII (0x20 a 0x7E)
• x_tsap_id [3 ... 15] = qualquer caractere (opcional)
• (x = loc (local) ou x = rem (parceiro))
VÁLIDO PARA FIRMWARE CPU S7-1200 A PARTIR DE V2

• Comprimento = 3 a 16 bytes
• x_tsap_id [0 ... 2] para conexão ativa = 3 caracteres ASCII (0x00 a 0xFF) ou
qualquer string de bits *
• x_tsap_id [0 ... 2] para conexão passiva = 3 caracteres ASCII (0x20 a 0x7E)
ou qualquer string de bits *
• x_tsap_id [3 ... 15] = qualquer caractere (opcional)
• (x = loc (local) ou x = rem (parceiro))
VÁLIDO PARA CPU S7-1500

• Comprimento = 3 a 16 bytes
• x_tsap_id [0 ... 2] = 3 caracteres ASCII (0x00 a 0xFF) ou qualquer sequência de
bits *
• x_tsap_id [3 ... 15] = qualquer caractere (opcional)
• (x = loc (local) ou x = rem (parceiro))

• * As cadeias de caracteres ASCII não devem começar com "SIMATIC-"

A TABELA A SEGUIR MOSTRA A ESTRUTURA
ESQUEMÁTICA DE VÁRIOS TSAP IDS:

• * Uma CPU S7-1200 é normalmente inserida no rack 0 e slot 1, e uma CPU S7-300 / 400 no rack 0 e slot 2. Por este motivo, o valor
hexadecimal 01 ou 02 é válido para a segunda posição do TSAP ID com extensão. Se o parceiro de conexão for uma CPU não especificada,
por exemplo, um dispositivo de terceiros, o valor hexadecimal 00 também é permitido para o endereço do slot.

• Nota
Para parceiros de comunicação não especificados, o TSAP-ID local e o parceiro TSAP-ID podem ter um comprimento de 0 a 16 bytes, em que
todos os valores hexadecimais de 00 a FF são permitidos.
EXEMPLOS DE ATRIBUIÇÃO TSAP

• Os exemplos a seguir mostram o processamento dos TSAPs para CPUs do S7-

1200 / 1500 (CPU no slot 1) sob vários pontos de vista:
• Exemplo 1: Criação de uma nova conexão para comunicação PLC-PLC
• Exemplo 2: entrada de um ASCII-TSAP local
• Exemplo 3: entrada de uma extensão TSAP no TSAP-ID
• Exemplo 4: Edição incorreta do TSAP-ID
• Exemplo 5: entrada de um ASCII-TSAP por meio do campo de entrada
"TSAP-ID"
 • Depois de criar uma nova conexão com dois PLCs para a comunicação aberta do
usuário, a extensão TSAP "ISOonTCP-1" é atribuída automaticamente.
• Esta extensão TSAP produz o TSAP-ID E0.01.49.53.4F.6F.6E.54.43.50.2D.31, que é
inserido automaticamente na descrição de conexão DB e nos campos de entrada do
local e do parceiro TSAP. Os campos de entrada dos ASCII-TSAPs permanecem vazios:

EXEMPLO 1:
CRIAÇÃO DE
UMA NOVA
CONEXÃO PARA • Você pode alterar os valores nos campos de entrada do TSAP-ID e do ASCII-TSAP a

COMUNICAÇÃO •
qualquer momento.
O campo de entrada do TSAP-ID mostra o TSAP completo armazenado no bloco de
PLC-PLC dados da descrição da conexão. O TSAP-ID com extensão TSAP, que é limitado a 16
caracteres, não é exibido no campo de entrada "TSAP (ASCII)" porque o caractere E0
não representa um caractere válido para o ASCII-TSAP.
• Se o TSAP-ID exibido for um ASCII-TSAP válido, ele será exibido no campo de entrada
"TSAP (ASCII)".
• As alterações nos campos de entrada para TSAP-ID e ASCII-TSAP afetam o outro
campo.
EXEMPLO 2: ENTRADA DE UM ASCII-TSAP LOCAL

• Se você criou uma nova conexão e atribuiu um valor ASCII para o TSAP local
no campo de entrada "TSAP (ASCII)", por exemplo, "ISOonTCP-1", o TSAP-ID
resultante será criado automaticamente.
• Quando você sai do campo de entrada "TSAP (ASCII)", o número de
caracteres ASCII é verificado automaticamente para conformidade com o
limite (3 a 16 caracteres) e o TSAP-ID resultante é inserido no campo de
entrada correspondente:
EXEMPLO 3: ENTRADA DE UMA EXTENSÃO TSAP
NO TSAP-ID
• Se, após a criação de uma conexão e a entrada de um ASCII-TSAP no campo de entrada do
TSAP-ID local, você adiciona o prefixo "E0.01" ao valor TSAP, o ASCII-TSAP não será mais
exibido quando o campo de entrada for encerrado.

• Depois de sair do campo de entrada do TSAP-ID, uma verificação é executada

automaticamente para determinar se o primeiro caractere do TSAP-ID é um caractere ASCII
válido. Visto que o caractere "E0" agora presente no TSAP-ID não é um caractere válido
para o ASCII-TSAP, o campo de entrada "TSAP (ASCII)" não exibe mais um ASCII-TSAP.
• Se um caractere ASCII válido for usado, a verificação de conformidade com a especificação
de comprimento de 2 a 16 caracteres segue.
EXEMPLO 4: EDIÇÃO INCORRETA DO TSAP-ID

• Se você remover o valor hexadecimal "E0" de um TSAP-ID que começa com

"E0.01", o TSAP-ID agora começa com "01" e, portanto, não está mais em
conformidade com as regras e é inválido:

• Depois que o campo de entrada é encerrado, uma mensagem é gerada

porque o TSAP-ID não é um ASCII-TSAP válido (isso teria que ter um valor
hexadecimal no intervalo de 20 a 7E como o primeiro valor) ou um TSAP-ID
válido (isso teria que ter o identificador "E0" como o primeiro valor).
EXEMPLO 5: ENTRADA DE UM ASCII-TSAP POR MEIO DO
CAMPO DE ENTRADA "TSAP-ID"

• Se você remover o valor "01" além do valor "E0" do TSAP-ID incorreto no

exemplo 4, o TSAP-ID começará com o valor hexadecimal 49. Este valor está
dentro do intervalo permitido para ASCII-TSAPs:

• Quando você sai do campo de entrada, o TSAP-ID é reconhecido como um

ASCII-TSAP válido e o ASCII-TSAP "ISOonTCP-1" resultante é gravado no
campo de entrada "TSAP (ASCII)".
ENVIANDO DADOS VIA UDP COM FB 67 "TUSEND"

• Descrição:
• FB 67 "TUSEND" envia dados via UDP para o parceiro remoto especificado
pelo parâmetro ADDR.

• Ao enviar dados separados em sequência para diferentes parceiros, você só

precisa ajustar o parâmetro ADDR ao chamar o FB 67 "TUSEND". Não é
necessário chamar os FBs 65 "TCON" e 66 "TDISCON" novamente.
 • FB 67 "TUSEND" é um FB de funcionamento assíncrono, o
que significa que seu processamento se estende por várias
chamadas FB. Para começar a enviar dados, ligue para FB
67 com REQ = 1. O status do trabalho é indicado nos
parâmetros de saída BUSY e STATUS. STATUS corresponde
ao parâmetro de saída RET_VAL de SFCs de
funcionamento assíncrono. A tabela a seguir mostra as
relações entre BUSY, DONE e ERROR. Usando esta tabela,
você pode determinar o status atual do FB 67 ou quando o
FUNÇÃO processo de envio (transmissão) é concluído.

• Devido à função assíncrona do FB 67 "TUSEND", você deve

manter os dados na área do emissor consistentes até que o
parâmetro DONE ou o parâmetro ERROR assuma o valor TRUE.
PARÂMETROS
INFORMAÇÃO DE ERRO
RECEBENDO DADOS VIA UDP COM FB 68 "TURCV"

• Descrição:
• FB 68 "TURCV" recebe dados via UDP. Após a conclusão bem-sucedida do FB
68 "TURCV", o parâmetro ADDR mostrará o endereço do parceiro remoto (o
remetente).
 • FB 68 "TURCV" é um FB de funcionamento assíncrono, o
que significa que seu processamento se estende por várias
chamadas FB. Para começar a enviar dados, ligue para FB
68 com REQ = 1. O status do trabalho é indicado nos
parâmetros de saída RET_VAL e BUSY. STATUS
corresponde ao parâmetro de saída RET_VAL de SFCs de
funcionamento assíncrono. A tabela a seguir mostra as
relações entre BUSY, DONE e ERROR. Usando esta tabela,
FUNÇÃO você pode determinar o status atual do FB 68 ou quando o
processo de recebimento for concluído.

• Devido à função assíncrona do FB 68 "TURCV", os dados na

área receptora só são consistentes quando o parâmetro NDR
assume o valor TRUE.
PARÂMETROS
INFORMAÇÃO DE ERRO
 • Descrição: A instrução "TSEND_C" configura e estabelece
uma conexão de comunicação. Uma vez que a conexão foi
configurada e estabelecida, ela é automaticamente
mantida e monitorada pela CPU. A instrução é executada
TSEND_C: de forma assíncrona e tem as seguintes funções:
ESTABELECENDO • Configurando e estabelecendo uma conexão de
UMA CONEXÃO comunicação

E ENVIANDO • Envio de dados por meio de uma conexão de

comunicação existente
DADOS
• Encerrando ou reiniciando a conexão de comunicação
Internamente, a instrução "TSEND_C" utiliza as instruções
de comunicação "TCON", "TSEND", "T_DIAG", "T_RESET" e
"TDISCON".
 • A conexão de comunicação é configurada e estabelecida com CONT = 1.
• Para obter informações sobre o número de conexões de comunicação possíveis, consulte
as especificações técnicas de sua CPU.
• A descrição da conexão especificada no parâmetro CONNECT é usada para
configurar a conexão de comunicação. Os seguintes tipos de conexão podem ser
usados:
• Conexões programadas (estrutura de conexão via "TCON"):
•
CONFIGURANDO •
TCP/UDP: descrição da conexão por meio do tipo de dados do sistema TCON_IP_v4
TCP/UDP com comunicação segura: descrição da conexão por meio dos tipos de dados
E do sistema TCON_IP_V4_SEC ou TCON_QDN_SEC

ESTABELECENDO • ISO-on-TCP: descrição da conexão por meio do tipo de dados do sistema

TCON_IP_RFC
UMA CONEXÃO • ISO: Descrição da conexão através do tipo de dados do sistema TCON_ISOnative (CP
1543-1/CP 1545-1)
DE • Conexões de telecontrole para clientes SMS: Descrição da conexão através do tipo de
COMUNICAÇÃO dados do sistema TCON_PHONE. Para este tipo de conexão, a estação requer acesso
à rede móvel através de uma rede móvel CP.
• Conexões FDL do S7-1500 com CM 1542-5 a partir de V2.0 com o tipo de dados do
sistema TCON_FDL
• Conexões configuradas:
• Especifique uma conexão existente no tipo de dados do sistema TCON_Configured.
Uma conexão existente é encerrada e a conexão que foi configurada é removida
quando a CPU entra em modo STOP. Para configurar e estabelecer a conexão
novamente, você deve executar "TSEND_C" novamente.
ENVIO DE DADOS POR MEIO DE UMA CONEXÃO
DE COMUNICAÇÃO EXISTENTE
• O trabalho de envio é executado quando uma borda ascendente é
detectada no parâmetro REQ. Conforme descrito acima, a conexão de
comunicação é estabelecida primeiro. Você especifica a área de envio com o
parâmetro DATA. Isso inclui o endereço e o comprimento dos dados a serem
enviados. Não use uma área de dados com o tipo de dados BOOL ou Array
de BOOL no parâmetro DATA. Com o parâmetro LEN, você especifica o
número máximo de bytes enviados com um trabalho de envio. Se você usar
uma área de envio com acesso otimizado no parâmetro DATA, o parâmetro
LEN deve ter o valor "0". Os dados a serem enviados não devem ser
editados até que o trabalho de envio seja concluído.
ENCERRANDO E REINICIANDO A CONEXÃO DE
COMUNICAÇÃO
• A conexão de comunicação é encerrada quando o parâmetro CONT é
colocado em "0", mesmo que uma transferência de dados em andamento
ainda não tenha sido concluída. Isso não se aplica se você estiver usando uma
conexão configurada para "TSEND_C". A conexão pode ser reiniciada a
qualquer momento, definindo o parâmetro COM_RST para "1". Isso encerra a
conexão de comunicação existente e uma nova conexão é estabelecida. Se os
dados estiverem sendo transferidos neste momento, isso pode levar à perda
de dados.
PARÂMETROS
• A tabela a seguir mostra os parâmetros da instrução "TSEND_C":
• REQ: Entrada BOOL - Inicia o trabalho de envio em uma borda ascendente.
• CONT: Entrada BOOL - Controla a conexão de comunicação: (0): Desconectar a conexão de comunicação. ,(1): Estabeleça e
mantenha a conexão de comunicação.
• LEN: Entrada UDINT - Parâmetro opcional (oculto), Número máximo de bytes a serem enviados com o trabalho.
• CONNECT: InOut - Ponteiro para a estrutura da descrição da conexão
• DADOS: InOut - Ponteiro para a área de envio contendo o endereço e o comprimento dos dados a serem enviados.
• ADDR: InOut - Parâmetro opcional (oculto), Reinicia a conexão: 0: irrelevante,1: A conexão existente é reiniciada. O
parâmetro COM_RST é resetado após avaliação da instrução "TSEND_C" e não deve, portanto, ser interligado
estaticamente.
• DONE: BOOL - O parâmetro de saída DONE é definido se uma etapa intermediária foi concluída com sucesso durante o
processamento.
• BUSY: BOOL - Parâmetro de status .
• ERRO: BOOL - Parâmetro de status de erro.
• STATUS: WORD - Estado da instrução "Parâmetros ERROR e STATUS".
 PARÂMETROS REQ, CONT E COM_RST
• O parâmetro CONT controla o estabelecimento da conexão da instrução "TSEND_C" independentemente do parâmetro REQ. O comportamento
do parâmetro CONT depende parcialmente se uma conexão programada ou configurada é usada:
• Com CONT = "0": Nenhum dado é enviado (independentemente de se usar uma conexão programada ou configurada).
• Ao alterar CONT = "0" para "1":
• Com uma conexão programada, é estabelecido com "TCON".
• Com uma conexão configurada, é verificado com "T_DIAG".
• Com CONT = "1":
• Enquanto nenhum dado for enviado (REQ = "0"), a conexão é verificada com "T_DIAG".
• Se as instruções de comunicação usadas internamente sinalizam que não existe um ponto final de conexão, a conexão é restabelecida
automaticamente com "TCON".
• Ao alterar CONT = "1" para "0":
• Com uma conexão programada, é finalizado com "TDISCON".
• Com uma conexão configurada, é redefinido com "T_RESET". O parâmetro COM_RST reseta a conexão ao mudar de "0" para "1":
• Se uma conexão for estabelecida, ela é redefinida com "T_RESET" (independentemente se uma conexão programada ou configurada é usada).
• Se nenhuma conexão for estabelecida, a configuração do parâmetro não terá efeito.
• Os parâmetros REQ e COM_RST só têm efeito se CONT for definido como "1".
TIPO DE DADOS DO SISTEMA PARA CONEXÕES
CONFIGURADAS
• Para conexões configuradas no parâmetro CONNECT, use a seguinte
estrutura para descrição da conexão para TCON_Configured:
 • Descrição: A instrução "TRCV_C" é executada de
forma assíncrona e implementa as seguintes funções
em sequência:
TRCV_C: • Configurando e estabelecendo uma conexão de
ESTABELECENDO comunicação
UMA CONEXÃO • Recebendo dados por meio de uma conexão de
E RECEBENDO comunicação existente
DADOS • Encerrando ou reiniciando a conexão de
comunicação Internamente, a instrução "TRCV_C"
utiliza as instruções de comunicação "TCON",
"TRCV", "T_DIAG", "T_RESET" e "TDISCON".
 • A conexão de comunicação é configurada e estabelecida com CONT = 1. Para obter
informações sobre o número de conexões de comunicação possíveis, consulte as especificações
técnicas de sua CPU.

• A descrição da conexão especificada no parâmetro CONNECT é usada para configurar a

conexão de comunicação. Os seguintes tipos de conexão podem ser usados: •

• Conexões programadas (estrutura de conexão via "TCON"):

• TCP/UDP: descrição da conexão por meio do tipo de dados do sistema TCON_IP_v4

CONFIGURANDO • TCP/UDP com comunicação segura: descrição da conexão por meio dos tipos de dados do
E sistema TCON_IP_V4_SEC ou TCON_QDN_SEC

ESTABELECENDO • ISO-on-TCP: descrição da conexão por meio do tipo de dados do sistema TCON_IP_RFC

•
UMA CONEXÃO ISO: Descrição da conexão através do tipo de dados do sistema TCON_ISOnative (CP 1543-1
/ CP 1545-1)

DE • Conexões de telecontrole para clientes SMS: descrição da conexão através do sistema

TCON_PHONE tipo de dados tem Para este tipo de conexão, a estação requer acesso à rede
COMUNICAÇÃO móvel através de uma rede móvel CP

• Conexões FDL do S7-1500 com CM 1542-5 a partir de V2.0 com o tipo de dados do sistema
TCON_FDL

• Conexões configuradas

• Especifique uma conexão existente no tipo de dados do sistema TCON_Configured. Uma

conexão existente é encerrada e a conexão que foi configurada é removida quando a CPU
entra em modo STOP. Para configurar e estabelecer a conexão novamente, você deve
executar "TRCV_C" novamente.
RECEBENDO DADOS POR MEIO DE UMA CONEXÃO
DE COMUNICAÇÃO EXISTENTE
• A recepção de dados é habilitada quando o parâmetro EN_R é definido com
o valor "1". Os dados recebidos são inseridos em uma área de recepção.
Você especifica o comprimento da área de recepção com o parâmetro LEN
(se LEN <> 0) ou com a informação de comprimento do parâmetro DATA (se
LEN = 0), dependendo da variante do protocolo em uso. Se você usar valores
puramente simbólicos no parâmetro DATA, o parâmetro LEN deve ter o valor
"0".
MODOS DE RECEPÇÃO DE TRCV_C:

• TCP (modo Ad-hoc): O modo ad-hoc está disponível apenas com a variante do protocolo TCP. Você usa o modo ad-hoc para
receber dados com comprimento dinâmico com a instrução "TRCV_C". Você define o modo ad-hoc atribuindo o valor "1" ao
parâmetro ADHOC. Todos os tipos de dados podem ser usados para blocos de dados com acesso padrão quando você usa
o modo ad-hoc. Apenas ARRAY de BYTE ou tipos de dados com comprimento de 8 bits podem ser usados para blocos de
dados com acesso otimizado (por exemplo, CHAR, USINT, SINT, etc.). O comprimento dos dados realmente recebidos é
emitido no parâmetro RCVD_LEN.
• TCP (recebimento de dados com comprimento especificado): Atribua o valor "0" ao parâmetro ADHOC para recebimento de
dados com comprimento especificado. Se o modo ad-hoc for desativado, a recepção de dados não será concluída até que o
comprimento de dados especificado no parâmetro LEN tenha sido completamente recebido. Só então os dados ficam
disponíveis na área de recepção (parâmetro DATA). O comprimento dos dados realmente recebidos em bytes no parâmetro
RCVD_LEN corresponde ao comprimento dos dados no parâmetro LEN após o recebimento.
• ISO - em - TCP (transferência de dados orientada para mensagens): Os blocos de mensagem completos são enviados por
meio de uma conexão com a variante do protocolo ISO - on - TCP; estes são reconhecidos como tal pelo destinatário. A área
de recepção é definida pelos parâmetros LEN e DATA. Se o buffer de recepção (parâmetro DATA) for muito pequeno para
os dados enviados, "TRCV_C" sinaliza um erro. O comprimento dos dados realmente recebidos em bytes no parâmetro
RCVD_LEN corresponde ao comprimento dos dados no parâmetro LEN após o recebimento.
ENCERRANDO A CONEXÃO DE COMUNICAÇÃO

• A conexão de comunicação é encerrada quando o parâmetro CONT é

colocado em "0", mesmo que uma transferência de dados em andamento
ainda não tenha sido concluída. Isso não se aplica se você estiver usando uma
conexão configurada, no entanto. A conexão pode ser reiniciada a qualquer
momento, definindo o parâmetro COM_RST para "1". Isso encerra a conexão
de comunicação existente e uma nova conexão é estabelecida. Se os dados
estiverem sendo transferidos neste momento, isso pode levar à perda de
dados.
 • EN_R: BOOL - constante Receber habilitar

• CONT: BOOL - Controla a conexão de comunicação: • 0: Desconectar a conexão

de comunicação. • 1: Estabeleça conexão de comunicação e faça a manutenção
após o recebimento dos dados.

• LEN: UDINT - Comprimento máximo dos dados a receber

• AD HOC: BOOL - Parâmetro opcional (oculto) Use o modo ad-hoc para a variante
do protocolo TCP. ADHOC deve ter o valor FALSE se nenhum protocolo TCP for
usado.

• CONNECT: InOut - Ponteiro para a descrição da conexão

PARÂMETROS • DADOS: InOut - Ponteiro para a área de recepção.

• ADDR: InOut - Parâmetro oculto que precisa ser usado, no entanto, com UDP.

• COM_RST: InOut - Parâmetro opcional (oculto) Reinicia a conexão

• DONE: BOOL - O parâmetro de saída DONE é definido se uma etapa

intermediária foi concluída com sucesso durante o processamento

• BUSY: BOOL - Parâmetro de status

• ERRO: BOOL - Parâmetro de status

• STATUS: WORD - Status da instrução

• RCVD_LEN: UDINT - Quantidade de dados realmente recebidos em bytes

 • O parâmetro CONT controla o estabelecimento da conexão da instrução "TRCV_C"
independentemente do parâmetro EN_R. O comportamento do parâmetro CONT depende
parcialmente se uma conexão programada ou configurada é usada:

• Com CONT = "0": Nenhum dado é recebido (independentemente de ser utilizada uma
conexão programada ou configurada).

• Ao alterar CONT = "0" para "1":

• Com uma conexão programada, é estabelecido com "TCON".

• Com uma conexão configurada, é verificado com "T_DIAG".

PARÂMETROS •
•
Com CONT = "1":

Enquanto nenhum dado for recebido (EN_R = "0"), a conexão é verificada com "T_DIAG".
EN_R, CONT E • Se as instruções de comunicação usadas internamente sinalizam que não existe um ponto final

COM_RST •
de conexão, a conexão é restabelecida automaticamente com "TCON".

Ao alterar CONT = "1" para "0":

• Com uma conexão programada, é finalizado com "TDISCON".

• Com uma conexão configurada, é redefinido com "T_RESET". O parâmetro COM_RST reseta a
conexão ao mudar de "0" para "1":

• Se uma conexão for estabelecida, ela é redefinida com "T_RESET" (independentemente se

uma conexão programada ou configurada é usada).

• Se nenhuma conexão for estabelecida, a configuração do parâmetro não terá efeito. Os

parâmetros EN_R e COM_RST só têm efeito se CONT for definido como "1".
TIPO DE DADOS DO SISTEMA PARA CONEXÕES
CONFIGURADAS
• Para conexões configuradas no parâmetro CONNECT, use a seguinte
estrutura para descrição da conexão para TCON_Configured:
PARÂMETROS BUSY, DONE E ERROR

• Você pode verificar o status do trabalho com os parâmetros BUSY, DONE,

ERROR e STATUS. O parâmetro BUSY indica o status do processamento. Com
o parâmetro DONE, você pode verificar se ou não um trabalho foi executado
com sucesso. O parâmetro ERROR é definido se ocorrerem erros durante a
execução de "TRCV_C". A informação do erro é emitida no parâmetro
STATUS.
CAPÍTULO 04 – EXEMPLOS PRÁTICOS
COMUNICAÇÃO CLP/PC COM SOFTWARE
HERCULES
 UTILITÁRIO HERCULES

• O utilitário Hercules SETUP é um terminal de porta serial útil (terminal RS-485

ou RS-232), terminal UDP/IP e terminal de servidor cliente TCP/IP.

• Ele foi criado apenas para uso interno do grupo HW, mas hoje inclui muitas
funções em um utilitário e é Freeware!

• https://www.hw-group.com/software/hercules-setup-utility
COMUNICAÇÃO UDP ENTRE CLP S7 E ARDUINO

UDP
DISPOSITIVOS E SOFTWARES
USADOS NO PROJETO:
• S7 1211C;
• Arduino Mega;
• Shield Ethernet W5100;
• IDE Arduino v1.8.13;
• TIA Portal v15.1.
COMUNICAÇÃO TCP S7 1200 E SIMULADOR DE
ROBÔ HIWIN

TCP
 DIAGNÓSTICO DA COMUNICAÇÃO

• Para efeito de debug de primeiros testes e para obter um

diagnóstico durante operação segere-se a implantação
de programa de usuário adicional para processar as
variáveis de saída dos blocos de comunicação.
• Em geral estes programas complementares contabilizam
os registros de done e error para determinar se a
comunicação está funcionando ou não.
• Uma armadilha para memorizar o estado da variável
status durante um evento de erro pode ser usada para
obter a causa de uma eventual falha de comunicação.
EXEMPLO DE IMPLEMENTAÇÃO
T_DIAG: VERIFICANDO A CONEXÃO

• Descrição: Você usa a instrução "T_DIAG" para verificar o status de uma conexão e ler mais
informações sobre o ponto de extremidade local desta conexão.
• A conexão é referenciada pelo parâmetro ID. Você pode ler os pontos finais de conexão
configurados no editor de conexão e os pontos finais de conexão programados (por
exemplo, com a instrução "TCON"). Os pontos finais de conexão temporários (por exemplo,
pontos finais criados quando você se conecta a uma estação de engenharia) não podem ser
diagnosticados, pois nenhum ID de conexão é gerado neste processo.
• As informações de conexão lidas são armazenadas em uma estrutura referenciada pelo
parâmetro RESULT.
• O parâmetro de saída STATUS indica se foi possível ler as informações de conexão. A
informação de conexão na estrutura no parâmetro RESULT só é válida se a instrução "T_DI-
AG" foi completada com STATUS = W # 16 # 0000 e ERROR = FALSE. As informações de
conexão não podem ser avaliadas se ocorrer um erro.
PARÂMETROS
PARÂMETRO STATUS
ESTRUTURAS TDIAG_STATUS
CONFIGURAÇÃO (OUC) COM SIMATIC MANAGER E
S7 300
CONTROLE DO
COMPRIMENTO DOS
DADOS
• Regras para enviar dados através
de TCP, ISO-on-TCP e UDP.
• Em TCP o tamanho do campo
“DATA” deve ser igual ou maior
que o campo “LEN”.
• Em ISO-on-TCP e UDP o tamanho
do campo “DATA” tem que ser
igual ao tamanho do “LEN”.
CONFIGURAÇÃO BROADCAST
 • Você pode habilitar um Web Server nos
CLPs da SIEMENS para que você possa
verificar o estado de todas as suas
conexões criadas com os protocolos TCP,
VISUALIZANDO ISSO-on-TCP e UDP.
AS CONEXÕES • Ele vai ser muito útil quando for necessário
realizar algum diagnóstico em suas
conexões.
ENCERRAMENTO!

• Muito obrigados a todos! Desejo muito

sucesso em suas carreiras.
• Gostou do treinamento?
• Conheça mais sobre o meu trabalho
acessando outros cursos que ministro
aqui na plataforma e tambem venha
conhecer meu canal do Youtube sobre
redes Industriais.
• Te espero lá! Um braço....