O uso profissional da internet e seus desafios dentro de pequenas e médias empresas.

O uso da Internet já está incorporado ao dia a dia de grande parte da população mundial. Dentro do ambiente de trabalho, a separação entre o pessoal e o profissional pode ser um problema diante de tantos recursos disponíveis na grande rede.

Nas pequenas e médias empresas, onde a "cultura coorporativa" não é tão definida frequentemente as pessoas confundem trabalho e uso pessoal e acabam perdendo muito de seu tempo e produtividade com derivações mais diversas.

Dentre os principais problemas conhecidos podemos destacar alguns que constantemente são citados por gestores de empresas como causadores de problemas:

• Redes Sociais: Apesar de úteis e constantemente citadas por marqueteiros o uso das redes sociais dentro das empresas raramente está ligado aos interesses da mesma. Existem perfis de usuários totalmente “viciados” , pessoas que postam sua vida inteira dentro de ferramentas como facebook, Orkut ou twitter e são capazes de perder horas vendo as últimas postagens do “cachorro da vizinha” que também tem um perfil na Internet. Diversas empresas optam por bloquear o acesso a estes sites, porém a popularização de outros meios de acesso a rede como celulares, wifi abertos, tornam esses bloqueios não efetivos. Outra questão é que dentro da própria internet são criados sempre recursos novos para burlar esses bloqueios, (Proxies remotos e endereços alternativos) fazendo com que o pessoal de tecnologia tenha o enfadonho trabalho de monitorar e bloquear essas atividades. Além dos problemas de perda de tempo e produtividade as redes sociais são conhecidos meios de propagação de malwares, trazendo impactos negativos as redes locais das empresas.

• Comunicadores instantâneos: ferramentas de comunicação instantânea (MSN,Skype,Google Talk etc) são extremamente úteis para as empresas. O setor comercial pode ter acesso imediato ao cliente, representante, ou ao vendedor que não se encontra nos limites físicos da empresa, além disso permitem troca de arquivos, conversação (VOIP), sem trazer problemas significativos de uso de largura de banda. O problema dos comunicadores instantâneos novamente reside no fator humano, quando o recurso é utilizado para fins pessoais, bate papo com amigos. Novamente perda de tempo e produtividade. Da mesma maneira que as redes sociais muitas empresas optam por bloquear serviços de comunicação instantânea. Esses bloqueios também são muitas vezes ineficazes, pois existem muitas ferramentas para este fim.

• Streaming (Youtube,rádios,TV online). Cuidados especiais devem ser tomados com relação a utilização de sites de conteúdo de mídia digital,principalmente áudio e vídeo, conhecidos ladrões de largura de banda. Empresas que possuem links estreitos com poucos kbps podem ter problemas sérios já que normalmente tais arquivos consomem muitos Mbytes em sua transmissão e são responsáveis por boa parte do conteúdo baixado em termos de quantidade de dados baixados diariamente. Bloqueios para estes sites são comuns também em muitas empresas.

• Grandes portais: Os grandes portais tais como terra,UOL, g1, ig entre outros estão  sempre entre os endereços mais acessados. Quase todos eles oferecem além de notícias, conteúdo de mídia digital em formato de áudio e vídeo. Muitas empresas têm políticas severas para uso de portais e optam por bloqueá-los.

• Emails. Certamente o recurso mais antigo e mais utilizado pelas empresas. Ferramenta importantíssima, mas que quando mal usada também pode causar em muitos problemas. Novamente aqui esbarramos no usuário. Pessoas que recebem e encaminham emails de piadas, correntes, vídeos, PPTs etc, utilizam anexos sem verificar o tamanho e assim por diante...

• Vejamos estudo de caso:

Usuário A: Recebe um email de 10Mbytes com um vídeo de piada.

O mesmo usuário A encaminha este email para 5 pessoas da empresa através de um servidor externo (situação onde a empresa não tem um servidor de emails local). Este email chega ao servidor e volta para rede agora multiplicado por cinco (50Mbytes).

A empresa em questão têm um link de apenas 512Kbps.

O recebimento destes emails custaria em tempo algo em torno de 15 minutos de uso do link se o mesmo for utilizado apenas para baixar estes emails. É muito tempo perdido, principalmente se a empresa emite faturamento eletrônico para SEFAZ. Paradoxo! Vamos faturar mais devagar para  poder receber as piadas!!

A situação acima é um exemplo crítico e 512Kbps é um link baixíssimo para os padrões de banda larga existentes hoje, mas ainda existem muitas empresas trabalhando com links de 512Kbytes ou 1Mbps ou até menores dependendo da região ou recursos do local onde estão localizadas.

Os desafios são grandes. A verdade é que sempre esbarramos na quantidade de recursos tecnológicos disponíveis e no “fator humano”. Durante alguns anos usando ferramentas como ISA, Squid entre outras, pude concluir que a melhor política do ponto de vista de gestão de rede é conhecer a rede. Bloqueios de rede, e estudo de listas de acesso acabam levando a situações vexatórias para empresa e para os usuários e bloqueios frequentes de recursos levam os colaboradores a desconfiar da empresa e se sentirem vigiados causando desconforto. Conhecer a rede não implica ficar olhando listas de acesso, que também pode ser um trabalho moroso e chato além de invasivo. Claro que dependendo dos casos isso é necessário.

O trabalho desenvolvido abaixo visa demonstrar que é possível conhecer bem o fluxo de informações da rede preservando a segurança da informação.

O desenvolvimento da solução que utilizo atualmente demorou algum tempo e foi adaptado segundo as ideias e situações que apresentadas acima.

 

Conhecimento da rede

Discutimos acima alguns dos problemas comuns no assunto gerência de redes locais. Quase todos eles esbarram em posições que a empresa deve adotar e no modo do usuário ou colaborador em utilizar os recursos. Por um lado as organizações não gostam de tomar atitudes restritivas e criar um ambiente de desconfiança em que as pessoas sentem-se vigiadas de outro estão os colaboradores que não se corrigem e aproveitam sempre qualquer brecha para o uso pessoal. A situação é complicada e exige reflexão das duas partes, e claro, depende do perfil de cada empresa, mas todas estão igualmente sujeitas a estes problemas.

O conhecimento da rede permite saber os comportamentos padrões de sua LAN e através de análises reconhecer problemas de abuso, mau uso, ou mesmo ignorância operacional do usuário. 

Pode-se ainda identificar invasores, problemas com “malwares” e orientar os esforços de TI para corrigir os problemas onde eles estão. Estas características não são novidades para empresas de grande porte que utilizam tecnologia de ultima geração e roteadores/swiches de alto padrão, mas certamente são desconhecidas do público que contrata links de banda larga e simplesmente compartilha o recurso em sua rede através que pequenos roteadores, servidores e switches não gerenciados.

Buscando resolver estes problemas de gerência de LANs em pequenas redes, desenvolvi algumas soluções de baixo custo que foram capazes de fornecer o nível de controle eficaz com recursos para que até o leigo consiga compreender.

Removi meu antigo servidor linux com Squid/Sarg e iptables, optei por usar uma conhecida ferramenta do mercado de provedores de rádio. O RouterOS ou Mikrotik (http://pt.wikipedia.org/wiki/Mikrotik#RouterOS). Não irei entrar aqui nos detalhes técnicos da ferramenta. Existe muito material disponível na internet. Vale salientar que é uma ferramenta muito poderosa e não deixa a desejar quando comparadas as "grifes" do mercado de network mas exige certo conhecimento para poder aplicar. Uma vez configurado é extremamente estável e requer muito pouca manutenção.

A ferramenta descrita a seguir é capaz de receber “logs” programados do routerOS coletando as mais diversos dados da rede. Foram criadas diversas analises e relatórios que se mostraram eficazes nas tomadas de decisão e no gerenciamento de eventos da LAN.

Os dados de navegação de sites, largura de banda utilizada, tempos de acesso, arquivos baixados, uso de banda por protocolo e por IP, são gravados diariamente em banco de dados proporcionando uma visão de acompanhamento segura, facilitando identificação de pontos "fora da curva".

Existe ainda um recurso de captura automática e bloqueio de IPs externos que realizam portScan ou enviam comandos ICMP para rede provindos da Intenet.

Esses IPs fichados também são gravados no banco de dados. Existem relatórios com os quais se pode listá-los e identificar a sua origem (país) e a quantidade de vezes que o evento se repete.

 

O software .NETLAN Report

 

O modelo de rede abaixo será usado para mostrar algumas características da ferramenta.

 

Arquitetura exemplo

 

São duas redes fisicamente separadas. Empresa matriz e filial. Ambas ligadas por uma VPN. Todas as solicitações de clientes da LAN1 para internet geram “logs” no Proxy do RouterOS1. O Router1 envia essas informações em tempo real para o servidor (.NETLAN Report). O mesmo ocorre com a LAN2, logo todos os logs de acesso são reportados ao servidor (.NETLAN Report). Os roteadores também estão programados como marcadores de pacotes e listas de bloqueio. Todas as informações são também enviadas ao servidor diariamente via scripts.

 



.NETLAN Captura de logs

O sistema está programado para iniciar a captura de LOGs as 6:50 da manhã, finalizar e processar as informações às 20:30 e enviar os dados ao banco de dados ás 20:50. Todo processo é feito automaticamente.

Um arquivo texto é gerado com todos os logs do dia. Parte dele é filtrada e gravada no banco de dados. O arquivo texto diário é então compactado e guardado em uma pasta do servidor para análise mais profunda caso seja necessário.

A análise detalhada do arquivo completo pode ser realizada com um relatório em forma de cubo dinâmico tal como feito em ferramentas de BI. Pelo cubo pode-se levantar e exportar dados de qualquer consulta no arquivo de dados. 
 

Utilização cubo para analise do arquivo

• Outros relatórios de análise da ferramenta

 

• Movimento totalizado de navegação (HTTP) pelo Proxy

 

• Visão geral por tipo de pacotes de navegação http (Mbytes):

 

Este relatório permite visualizar dentre os dados de determinada faixa de data a proporção de pacotes http de cada tipo, isto é dentre a informação buscada na internet, a proporção de áudio, vídeo, texto imagens etc. Uma quantidade muito grande de áudio por exemplo pode significar que muitos usuários estão escutando radio online. Proporções grandes de imagem e texto acesso a muitos sites. Proporções grandes de vídeo muito streaming de vídeo como por exemplo o site youtube.



Completando a visão acima existe outro relatório similar ao anterior com a informação por endereço, onde podemos identificar facilmente as distorções de uso. Observe o exemplo abaixo para uso de pacotes de vídeo o IP assinalado:

 

• Crackers e informação de listas de bloqueio:

 

 

Listas de IPs externos bloqueados

Utilizando este sistema podemos ainda retirar listagens de tempos de uso, downloads e relação de sites. A ferramenta tem se mostrado útil, dentro da missão de controlar o ambiente das duas redes relacionadas mantendo resguardadas informações pessoais sem deixar de ter o conhecimento dos eventos do ambiente de rede. Continuo trabalhando em ideias e aperfeiçoamentos da ferramenta, o trabalho segue para tornar outras combinações como distribuições linux com squid/iptables, pfSense

e IPCop compatívies.

Bike! Pedalando pelas noites!

Minhas voltas com as bikes são antigas... Desde moleque pedalo e admiro as magrelas, já pedalei as speed, bicicross e muitas trilhas com as mountain, porém hoje, pai de família, normalmente só me restam as noites para dar aquela saída para pedalar. Numa dessas saídas noturnas um dos malucos motorizados não me viu e quase virei asfalto! Naquele dia fiquei imaginando quantos ciclistas noturnos já passaram pelo mesmo tipo de evento. Minha bike com vários
sinalizadores tipo "olho de gato" nos raios, pedais e no canote do selim não foram o suficiente para me safar da situação de risco! Após o tradicional suador sentei e fiquei acompanhando os ciclistas da ciclovia e verificando o que cada um deles usava para sinalização durante seus passeios noturnos.
Faróis, leds pisca-pisca eram as idéias mais evidentes. Após este evento estive em uma casa especializada em venda de acessórios para comprar algo semelhante... Para minha surpresa um sinalizador led estava na faixa dos 3 dígitos! Achei caro e não comprei, pensando em fabricar eu mesmo algo em minha garagem. Navegando na net vi alguns projetos de sistemas de projeção de imagem por movimento e como já havia criado um tacômetro com o mesmo princípio achei que criar uma versão para um projeto para bikes seria legal como desafio profissional e também resolveria meu problema em meus passeios de bike noturnos, além ,é claro, principalmente me divertir com o projeto e sua utilização!

Mãos a Obra! A idéia do projeto é utilizar um sistema microcontrolado acoplado aos raios da bike que em rotação fosse capaz de exibir imagens e animações simples. Para conseguir realizar todo o projeto era necessário desenvolver o hardware, o software embarcado no microcontrolador e um software para rodar num computador comum capaz de processar, preparar e enviar as imagens para o microcontrolador. Escolhi um microcontrolador da microchip por afinidade, e ferramentas de software que eu já havia trabalhado e conheço relativamente bem.
Linguagem C para o programa embarcado no microcontrolador e .NET para aplicação PC.

Um pouco de física de movimento...

Para definir algumas grandezas do projeto se fez necessário realizar alguns cálculos básicos a fim de encontrar pontos ideais de funcionamento. Uma das variáveis iniciais importantes é a própria "persistência de visão humana". A persistência da visão humana é um fenômeno que ocorre dentro de nossa retina e define basicamente a velocidade que nossa visão consegue diferencias quadros de imagens. Através desse calculo pode-se saber qual velocidade é necessário imprimir a bike para exibir a imagem de uma maneira contínua.
Utilizando-se apenas um módulo é preciso pedalar razoavelmente rápido... Entre 20 e 40Km/h é possível conseguir uma imagem aceitável. Abaixo disso seriam necessários mais de um módulo idealmente 2 ou 3. Eu como protótipo estou usando apenas um, mas foi suficiente para realizar testes conforme poderão ver nas imagens do video mais a frente.
Com estes cálculos também se podem definir grandezas de tempo em que cada linha de 32 leds será disparada durante o ciclo de rotação em função do calculo da velocidade instantânea.
O Sensor referência é fixado a um ponto do garfo da bike e a cada 3 ciclos o microcontrolador calcula a razão correta de disparos no tempo evitando distorcer a imagem durante aceleração e desaceleração.

Hardware

O hardware é relativamente simples composto por um conjunto de microcontrolador, eeprom alguns shift-registers e uma boa dose de software! Como sabemos com a presença de microcontroladores cada vez melhores e com mais recursos a dificuldade maior neste tipo de projeto é realmente o software.

Utilizei componentes baratos e fáceis de conseguir, o que de certa forma dificultou também na produção do software. A CPU utilizada é um simples uC de 8bits da microchip 16F628, os registradores são os tradicionais e fáceis de obter 74595, e claro muitos LEDS. Sem dúvida o maior problema no quesito de hardware foi obter o sensor hall e memórias EEPROM adequadas. Esses tive que apelar e importar.

É incrível que no Brasil mesmo morando em cidades grandes ainda se encontre tantas dificuldades de comprar alguns componentes... Restando a (nem sempre barata) opção de comprar ou importar pela internet... Existem componentes que poderiam facilitar e reduzir muito este projeto, porém como citei não são facilmente encontrados aqui. Mantive a idéia inicial de produzir algo com baixo custo e componentes possíveis de se comprar.

Softwares:

Como citado anteriormente, para produzir o software do microcontrolador utilizei linguagem C, o software embarcado permite receber dados do PC e é capaz de gravar as imagens geradas no programa PC para a memória EEPROM. Cada frame de imagem de 1Kbyte e é exibido em 256 disparos durante um ciclo de rotação totalizando 8192 pixels binários.Exitem 2 modos de operação, programação e runtime.

O software do PC foi desenvolvido com tecnologia .NET ele é capaz de converter qualquer imagem bitmap 600x600 no formato necessário para carga da EEPROM, definir áreas de gravação de cada frame e claro enviar as imagens convertidas para o sistema microcontrolado.

Abaixo segue video mostrando um pouco deste trabalho... Estarei escrevendo mais detalhes deste projeto em outros posts!

Em uma das imagens do vídeo aproveito para homenagear o ótimo trabalho desenvolvido pelo pessoal do Lab de Garagem! Espero aqui a unidade da região de Campinas!

Parabéns Marcelo!

Abraço de um tb garagista!

Eduardo Duarte

Projeto: Tacômetro de LEDs

O projeto está baseado no microcontrolador de oito bits 16F628 do fabricante Microchip®, mas poderia ter sido feito com um AVR ou qualquer processador pequeno.
O experimento consta de um tacômetro que medirá a rotação (rpm) de um ventilador comum. O resultado desta medição será apresentado através de uma linha de oito LEDs acoplada ao eixo de giro do ventilador aproveitando a rotação do próprio ventilador como varredura. Os números serão então projetados pelo acionamento sincronizado dos LEDs de maneira a produzir cada um dos caracteres numéricos de 0 a 9.

Display de movimento:

O display de movimento pode ser obtido a partir do acionamento preciso de cada pixel sincronizado com o movimento de rotação (caso do experimento em questão).
O movimento de rotação funciona como varredura e o acionamento dos LEDs como estrutura do pixel (On/Off).

Hardware

 O hardware é bem simples está baseado nos testes feitos no Kit com o modulo de LEDs e o conversor série-paralelo 74HC595. O circuito desenvolvido está no anexo 2.
O Microcontrolador utilizado foi o 16F628. O hardware apresenta ainda um cristal de 4MHz, um conversor série/paralelo e um sensor de infravermelho (foto-transistor) para monitoramento o pulso de medição do período de uma volta completa do ventilador.

Software

A metodologia utilizada para desenvolvimento do sistema foi a de máquina de estado. O diagrama de estados abaixo reproduz as condições de estados do sistema.

O sistema

 O funcionamento do sistema esta baseado nas interrupções impostas pelo sensor em RB3. A cada giro do ventilador um pulso será gerado e consequentemente uma interrupção no modulo CCP.

 O SETUP de algumas variáveis importantes do microcontrolador:

    set_tris_A(0x00);

   enable_interrupts(INT_CCP1);   // Habilitação de interrupção CCP1
   enable_interrupts(GLOBAL);     // Habilitação Flag de interrupções globais
   setup_ccp1(CCP_CAPTURE_FE);    // Interrupção CCP1 (modo captura) em bordadescida
   output_high(CLEAR);            // Limpa Latch (buffer de saida)
   output_low(CLOCK);             // Garante clock em nivel lógico zero
   output_low(LATCH);                   // LATCH inicial em zero
   flagPulso=0;                                      // Flag de registro de interrupção
   flagMontado=0;                // Flag de vetor montado
   indVet=1;                              // Indice do vetor
   setup_timer_1(T1_INTERNAL | T1_DIV_BY_8);

 Habilitado flag de interrupções globais e interrupções de CCP1 (borda de descida), ainda como auxiliar na contagem será utilizado o TMR1 (sincronizado pelo clock interno do MPU) e “prescaler” divisor 8.Através do uso da variável “flagPulso” são capturadas duas medidas de TMR1 entre dois pulsos sucessivos o calculo do período de rotação do ventilador se dá através da seguinte equação

A partir da obtenção do período de rotação poderemos determinar a freqüência e sua rotação em rpm.
Depois de realizados os cálculos resta ao programa embutido exibir os resultados no display de movimento.

Exibição do vetor resultado:

Foram criados no arquivo  “numeros.h” os caracteres numéricos de 0 a 9 de maneira e serem utilizados no display. A montagem visual destes caracteres bem como o arquivo .h a ser utilizado na diretiva "#include" são mostrados na figura:

Cada caractere corresponde a uma matriz de 48bits (8 linhas x 6 colunas) e podem ser representados por uma seqüência de 6 bytes (representados na figura por seus valores hexadecimais).
O arquivo cabeçalho define cada um dos caracteres como uma constante matricial [1x6] de bytes, lembrando que cada byte pode representar 8 bits.

-numeros.h

const byte zero[6]= {

0x3C,0x42,0x81,0x81,0x42,0x3C
};

const byte um[6]= {
0x00,0x04,0x82,0xFF,0x80,0x00
};

const byte dois[6]= {
0x84,0xC2,0xA1,0x91,0x8A,0x84
};

const byte tres[6]= {
0x00,0x81,0x89,0x89,0x89,0xFF
};

const byte quatro[6]= {
0x18,0x14,0x12,0x11,0x11,0xFF
};

const byte cinco[6]= {
0x8F,0x89,0x89,0x89,0x89,0x70
};

const byte seis[6]= {
0x78,0x94,0x92,0x91,0x91,0x60
};

const byte sete[6]= {
0x01,0x01,0x01,0x01,0xFF,0x00
};

const byte oito[6]= {
0x76,0x89,0x89,0x89,0x89,0x76
};

const byte nove[6]= {
0x06,0x89,0x49,0x29,0x19,0x0E
};

const byte space= 0x00;

Agora que se têm disponíveis os caracteres para exibição no display, pode-se então através da rotação calculada, decompor o número em seus devidos caracteres de  milhar,centena,dezena e unidade.
Definidos os caracteres após decomposição monta-se um vetor-exibição que será transferido ao display através do latch 74HC595 (bit a bit) de saída série/paralelo.
Cada um dos bytes é então transferido ao latch até que se passem mais 3 interrupções quando um novo valor é inserido no vetor-exibição.

Testes:

Esquemático:

Automatizando impressão de etiquetas de código de barras

Quando se ouve falar de aplicações e dos níveis de controle e agilidade gerados por sistemas que utilizam códigos de barras, realmente não há como negar todas as facilidades que este tipo de implantação impacta. O que nunca é mencionado pelos distribuidores é que apenas investir na aquisição de equipamentos de código de barras nem sempre pode resolver imediatamente um problema de controle de material, é necessário um estudo prévio da aplicação, dos dados necessários e daqueles de que estão disponíveis.

Já observei implantações desorganizadas de equipamentos que simplesmente travaram processos dentro de fábricas porque não foram planejados adequadamente.

• Imagine a situação abaixo:

O cliente solicitou que seu produto fosse entregue com identificação de código de barras onde será informando o código do produto, nota fiscal e o lote, além de imprimir data e quantidade.

A etiqueta poderia ser semelhante à seguinte:

Que passos se devem prosseguir para evitar futuras dores de cabeça?  Este “post” traz algumas experiências pessoais que julgo relevantes avaliar quando se está perante a uma necessidade semelhante visando ajudar outras pessoas a não cometerem erros de avaliação nesse momento, e principalmente ajudar o desenvolvedor a encontrar um caminho para produzir sua solução personalizada de forma rápida e segura.

Existem vários motivos para aplicação de sistemas de código de barras: Necessidade controles em geral, organização de estoque, controles de produção, controles tipo FIFO,controles de inventário, logística de transporte de algum cliente entre muitas outras.

Vários padrões de códigos de barras estão disponíveis para os mais diversos tipos de aplicação. Os lineares como code128, code39, EAN13, Interleaved 2/5 etc para menor densidade de dados e os bidimensionais como maxcode, pdd417 e micropdf quando necessária grande densidade de dados. O primeiro grupo é mais utilizado para informações numéricas e alfanuméricas simples e onde a informação seja conhecida em origem e dimensão.

Os códigos bidimensionais oferecem uma possibilidade de compactação de dados muito maior podendo carregar muitas informações em pouco espaço. O problema dos códigos bidimensionais é que precisam de leitores com scanners próprios para decodificá-los e esses normalmente tem custo mais elevado.

 Veja alguns exemplos impressos abaixo:

Observe a otimização do padrão CODE128 em relação ao CODE39. Os códigos bidimencionais (pdf) contêm uma seqüência bem maior de caracteres:

“01234567890ABDCEF Eletrobits teste padrão pdf bidimensional”

Pensando no caso de uso do início do post, é necessário saber em seu banco de dados ou em seu sistema, onde obter as informações necessárias para enviar ao sistema de impressão, isto é, tabelas de seu banco de dados que contenham as informações relevantes de seu processo e possam ser lidas por uma aplicação e enviadas às impressoras de código de barras.

Estudando previamente as etapas acima, a escolha do equipamento é relativamente simples. A produção ou adaptação de seu software estará baseada nos equipamentos disponíveis e na análise da disponibilidade de dados. Fabricantes de impressoras sempre fornecem drivers e aplicações básicas para operar seus equipamentos, porém esses programas dificilmente atendem demanda de impressão automática em larga escala. Imagine em nosso caso de uso acima que sejam necessários emitir 300 notas fiscais por dia com 10 produtos cada uma e que cada produto seja identificado. Isso gera necessidade de imprimir 3000 etiquetas. Agora imagine que seu funcionário precise digitar essas informações antes de imprimir! Certamente a tarefa, além de impossível, também é recheada de chances de erros!

 Automatizando impressões de código de barras:

Existem inúmeros fabricantes de impressoras de código de barras, Zebra, Intermec, Eltron entre muitas outras e para complicar um pouco cada uma delas tem uma linguagem de programação própria. Zebra (ZPL Zebra printer language,ZPL2),Intermec (IPL-Intermec Printer Language),  EPL etc enfim são várias as linguagens e isso pode dificultar a vida do programador quando existem equipamentos de diferentes fabricantes em uma mesma planta. Algumas impressoras mais modernas são dotadas de emuladores capazes de interpretar linguagens de outros fabricantes, mas isso não é uma regra principalmente quando os equipamentos são menores e mais modestos ou antigos.

Quem já leu um manual de programação de qualquer uma dessas linguagens sabe que são um pouco indigestos, porém é sempre bom conhecer os comandos quando o objetivo é produzir ou adaptar um software capaz e enviar comandos diretamente a essas máquinas.

Visando facilitar a vida dos desenvolvedores os software distribuídos com essas máquinas quase sempre agregam ferramentas capazes de gerarem "arquivos fonte" em formato texto que são rapidamente adaptáveis a aplicações customizadas.

Imprimindo etiqueta para em porta arquivo

Ao imprimir nossa etiqueta anterior para arquivo teremos uma “mascara” do arquivo fonte na linguagem da impressora selecionada. Observe abaixo como esses arquivos podem ser bem diferentes. O Primeiro ZPL, o segundo EPL, são a mesma etiqueta.

Arquivo ZPL:

^XA

^MCY

^XZ

^XA

^FWN^CFD,24^PW695^LH0,0

^CI0^PR3^MNY^MTT^MMT^MD15^PON^PMN^LRN

^XZ

^XA

^MCY

^XZ

^XA

^DFR:TEMP_FMT.ZPL

^LRN

^A0N,60,60^FO28,25^FDEletroBits^FS

^BY2^FO21,120^BCN,90,Y,N,N^FD>;0123456789>6ABCDEF^FS

^BY2,2.7^FO33,441^B7N,17,0,5,0,N^FH^FD0123456789ABCDEF Eletrobits teste padrão PDF bidimensional^FS

^BY2,2.5^FO24,273^B3N,N,98,Y,N^FD0123456789ABCDEF^FS

^BY2^FO595,471^BEN,106,Y,N^FD789403222022^FS

^A0N,36,36^FO536,42^FH_^FDC_A2digos de Barra^FS

^BY7^FO388,440^BFN,5,0^FH^FD0123456789ABCDEF Eletrobits teste padrão PDF bidimensional^FS

^A0N,20,20^FO20,99^FDCode-128 (Auto)^FS

^A0N,20,20^FO22,254^FDCode-39^FS

^A0N,20,20^FO34,420^FDPDF417^FS

^A0N,20,20^FO388,421^FDMicro-PDF 417^FS

^A0N,20,20^FO594,447^FDEAN-13^FS

^XZ

^XA

^XFR:TEMP_FMT.ZPL

^PQ1,0,1,Y

^XZ

^XA

^IDR:TEMP_FMT.ZPL

^XZ

Arquivo EPL:

O

Q610,1

q695

S4

D5

ZT

JF

N

A28,25,0,4,2,3,N,"EletroBits"

B21,120,0,1,2,0,90,B,"0123456789ABCDEF"

b33,441,P,813,169,s0,c0,f0,x2,y17,r90,l5,t0,o0,"0123456789ABCDEF Eletrobits teste padrão PDF bidimensional"

B24,273,0,3,2,5,98,B,"0123456789ABCDEF"

B579,471,0,E30,2,0,106,B,"789403222022"

A536,42,0,1,2,4,N,"C¢digos de Barra"

A20,99,0,1,1,2,N,"Code-128 (Auto)"

A22,254,0,1,1,2,N,"Code-39"

A34,420,0,1,1,2,N,"PDF417"

A594,447,0,1,1,2,N,"EAN-13"

P1

De posse da mascara desses arquivos basta utilizar a ferramenta de programação de sua preferência para ler os seus dados na origem e ingressá-los nos pontos determinados na mascara do arquivo texto. Feito isso basta lançar os dados para sua impressora na porta que estiver operacional.