sábado, 31 de dezembro de 2016

Editores de texto para robôs VKR

Editores de texto específicos para robôs industriais constituem um nicho bem específico.

Mas editores de texto criados única e exclusivamente para uma determinada customização são o quê? Um metanicho?

Uma certa montadora alemã, da qual não posso mencionar o nome - digamos apenas que começa com Volks e termina com Wagen - utiliza versões bem customizadas de robôs industriais ABB, FANUC e KUKA, sendo que no último caso, poderíamos dizer que é uma ultra customização, visto que até o fabricante diferencia os dois produtos. KR para robôs "normais", VKR para robôs VW.

A customização da VW passa por aspectos estéticos (a cor do controlador, emblemas, etc), por diferenças no hardware e por fim - e é aqui a parte que nos interessa - diferenças no software.

Todos os robôs FANUC VW vem com a opções ASCII e ASCII upload, então o processo de extrair, ler, editar externamente e carregar programas não é muito diferente do que já estamos acostumados.

Eu ainda não tive a oportunidade de trabalhar com robôs ABB VASS, mas imagino que o processo de edição dos programas/módulos também não seja muito diferente do que ocorre em um ABB standard.

Já com os KUKA, a coisa é um pouco diferente.

Em vez de serem programados usando a linguagem KRL (KUKA Robot Language), os VKR usam uma outra linguagem - ou melhor, um dialeto - chamado VKRL (Volkswagen KUKA Robot Language).

E é aqui que os problemas começam...

VKRL

Arquivos KRL normalmente tem instruções que podem ser aninhadas (folded) dentro de uma única linha. Isso, até certo ponto, melhora a legibilidade do código.

Além disso, algumas partes do código KRL/VKRL são geradas automaticamente, e costumam ficar ocultas. O que aparece na tela do TP não é necessariamente o que aparece na tela de um editor comum.

No caso de robôs KUKA "comuns" existe uma ferramenta excelente chamada OrangeEdit, que reproduz o comportamento de um KCP/SmartPad, ou seja, são exibidas apenas as instruções que apareceriam em um terminal de programação, e também é possível editar os programas preenchendo formulários inline, como acontece em um robô real.

Mas as diferenças entre o KRL e o VKRL fazem com que o OrangeEdit seja capaz apenas de EXIBIR código VKRL, mas não editá-lo da maneira correta.

Na teoria, o VKRL é mais simples que o KRL. Mas essa simplicidade "trava" a programação, obrigando o usuário a tomar algumas decisões estranhas, caso seja necessário elaborar uma lógica mais complexa.

Um exemplo: no VKRL, o sinal de."+" é contextual. Caso seja usado entre duas variáveis numéricas, funciona como o sinal de adição, mas caso seja usado entre duas variáveis booleanas, funciona a como um OU.

Além disso, instruções VKRL são indexadas internamente nos arquivos. Não adianta editar apenas uma ocorrência.

Veja as imagens abaixo.

Aqui temos um programa muito simples, aberto no SmartPad de um VKRC4, sem as folds abertas

Agora, esse mesmo programa, com as folds abertas.



Contando o comentário, temos cerca de 8 linhas de programa.

Agora, esse mesmo programa, aberto como um arquivo de texto comum.

  
Repare que ainda não acabou.


Ou seja, 8 linhas de programa de usuário são na verdade 432 linhas de código! Todas esse conteúdo adicional foi gerado e indexado automaticamente.

Enfim, editar código VKRL manualmente é uma tarefa no mínimo ingrata.

E note que estou falando em programação offline. Não em simulação e geração automática de trajetórias.

A questão é que, com o passar do tempo, algumas empresas perceberam que havia uma lacuna a ser preenchida, e começaram a desenvolver soluções específicas para a edição de código VKRL.

Contudo, embora alguns desses produtos já estejam no mercado há anos, eles são relativamente desconhecidos dos programadores brasileiros, e por isso resolvi fazer este post.

STEINEKE

É o mais tradicional de todos e, segundo consta, é a ferramenta "oficial" indicada pela VW para esse tipo de trabalho.

Na minha opinião, é o mais estável de todos. Nunca tive problemas com ele.

Entretanto, o VKRCEdit pode ser um pouco intimidador para alguns programadores, pois sua interface está disponível apenas em alemão.

Além disso, ele só edita arquivos .src de usuário (Folgen, UPs e makros).

A Steineke também tem um outro editor para robôs FANUC VW, mas sinceramente não achei tão útil como o editor VKR.

Os dois editores são oferecidos com três modalidades de licenciamento:

Básica: todas as funções de edição.
ProgDebug: análise de conformidade com o padrão VASS.
Comissionamento virtual: linka o editor a algumas ferramentas de comissionamento virtual.

Mais informações em:

http://www.steineke.de/vkrc-editor.php

TEKROB

O que acho interessante no TekRob é que, além dos arquivos VKR, ele pode editar programas dos FANUC customizados. Também tem ferramentas - ainda limitadas - para se trabalhar com arquivos de KR e também de ABB.

Isso com a mesma licença.

Entre todos os quatro editores, só perde em número de recursos para o DrAmaT. Alguns, como as listas de referência, a importação de makros em formato .txt e a edição de instruções VW_User através de formulários inline são muito úteis.

Das quatro opções comentadas aqui, é a única que permite a edição FÁCIL de QUAISQUER arquivos de texto que estejam dentro de um backup, seja um $config.dat, seja um VW_User.

Mais informações em:

http://tekrob.de/en/vkrc-fanuc-editor-en

ROBPRO

Assim como o VKRCEdit da Steineke, o RobPro edita apenas arquivos .src de usuário.

Possui alguns recursos interessantes, como a edição de instruções VW_User através de formulários inline, ou ainda a análise de conformidade com o padrão VASS, através de um plugin que deve ser adquirido separadamente.

Mais informações em:

http://www.robpro.de/en/

DRAMAT

A quantidade de recursos do DrAmaT supera a do TekRob.

Entre os mais interessantes, estão a edição de instruções VW_User através de formulários inline, a checagem de conformidade com o padrão VASS ou a geração automática de documentação dos robôs.

Além de arquivos VKR, o DrAmaT também pode editar individualmente - ou seja, sem qualquer tipo de referência cruzada - arquivos .ls (FANUC) e .mod/.sys (ABB), e arquivos de sistema dos VKR.

E, prestem atenção nisso, ele também roda em sistemas GNU/Linux!

Mais informações em:

http://dramat.eu/

À MODA ANTIGA

Ok, vamos supor que você ou a empresa para a qual você trabalha estejam mais quebrados que arroz de terceira, e agora talvez não seja o momento ideal para investir algumas centenas de euros em uma ferramenta desse tipo.

Nem tudo está perdido!

Os robôs VKR tem um recurso chamado Upgrade Manual, que permite exportar seus programas de usuário (Folgen, UPs e Makros) em formato .txt, com um aspecto bem mais próximo do que é exibido nos KCPs/SmartPads.

Uma vez que os arquivos .src são convertidos, o processo é o mesmo. Edite no computador, faça upload no controlador e cruze os dedos.

O grande problema de se carregar arquivos .txt nos VKR é que não há qualquer tipo de aviso sobre erros de reconversão. O robô compila tudo aquilo que reconhece. Instruções que ele não reconhece são simplesmente ignoradas. Então não é raro termos casos de programas com instruções ou, pior, linhas de movimento faltando. Eu mesmo já fui “vítima” desse tipo de fatalidade.

UM ÚLTIMO DETALHE

Todas as empresas citadas nesse texto são integradoras, ou seja, essas ferramentas foram desenvolvidas para uso interno e acabaram amadurecendo o suficiente para se tornarem produtos comerciais.

E quando eu falo para os meus amigos desenvolvedores que há um mercado para esse tipo de aplicação, eles riem da minha cara...

quinta-feira, 20 de outubro de 2016

ONE Robotics Backup Tool V2

Jay Strybis, fundador da ONE Robotics, liberou um preview da nova versão da sua ferramenta, o FANUC Backup Tool.


Já usei as versões anteriores e o software é uma mão na roda.

Caso você tenha interesse, pode se inscrever em um formulário no final dessa página, para ser notificado do desenvolvimento da ferramenta.

segunda-feira, 10 de outubro de 2016

KUKA WorkVisual

O KUKA WorkVisual (ou KUKA.WorkVisual) é uma software de configuração/programação que foi lançada junto com os KRC4.

O objetivo da ferramenta é ser uma solução tudo-em-um, uma IDE, no mesmo estilo do ABB RobotStudio ou do FANUC RoboGuide, embora, por enquanto, o WoV tenha menos recursos.

De qualquer maneira, não é possível comissionar um KRC4 sem o WorkVisual, e uma pergunta que sempre vem à tona é: qual a versão do WorkVisual devo usar?

Obviamente, a palavra final deve ser a da KUKA, mas dentro das experiências que tive até hoje, a resposta está entre duas possibilidades:

1) se é um robô "normal", você deve usar a versão que veio junto com o robô. Invariavelmente, em um CD.

2) se é um robô customizado, como os utilizados por grandes montadoras, você deve utilizar a versão indicada pela KUKA e/ou pelo cliente. Ponto final. Nesses casos, a versão do WorkVisual deve "casar" com uma determinada versão do KSS/VSS. O grande problema é que, com o passar do tempo, robôs novos vão chegando às fábricas, e aí é necessário manter duas ou três versões paralelas do WoV para atender todas as áreas. Nunca ouvi uma explicação sólida sobre a necessidade de se proceder dessa maneira, a não ser a boa e velha incompatibilidade. Entretanto, já vi uma tabela - antiga - onde eram apontadas quais versões do WorkVisual eram compatíveis com quais versões do KSS e dos Technology Packages, e também já ouvi casos de programadores que tiveram que fazer upgrades ou mesmo downgrades no WorkVisual para que fosse possível configurar os robôs nos quais estavam trabalhando.

Uma curiosidade: nunca encontrei nenhum vídeo sobre o WorkVisual no Youtube. Existem diversos sobre o Office Lite ou o KUKA.Sim, mas com o WoV, nada. Presumo que o motivo seja o fato do módulo de simulação (que seria semelhante ao KUKA.Sim ou a outros programas do tipo) ainda não ter sido implementado, mesmo após esses 5 anos de mercado.

Já publiquei essa informação no blog, mas não custa nada lembrar. As versões mais atuais do WorkVisual (4.x) podem ser baixadas nesse link, mediante um pequeno cadastro.

segunda-feira, 3 de outubro de 2016

Células robóticas compactas

Tenho acompanhado com interesse essa comoditização de sistemas robóticos industriais.

O Welding to Go 1200, por exemplo.

Desenvolvido pelo integrador alemão von der Bank Schweisstechnik, em parceria com a KUKA, pode ser transportado em cima de um pallet industrial comum.


A integradora brasileira Rapack & Teixeira também desenvolveu uma solução com conceito semelhante, mas usando um UR em vez de um KUKA. Visto que os UR são robôs colaborativos, isso é um passo além, o que significa mais segurança e flexibilidade.

A própria KUKA vem testando algumas outras aplicações do tipo, com robôs IIWA, e outros fabricantes também já mostraram produtos parecidos.

A redução do tamanho (e também do preço) desse tipo de equipamento abre leques interessantes, principalmente para pequenas empresas.

P.S.: Já sei o que vou pedir ao Papai Noel..

quarta-feira, 23 de março de 2016

MANUAIS MOTOMAN - DOWNLOAD

Enquanto algumas empresas são completamente paranóicas em relação à distribuição de documentação dos seus produtos na internet, acabei de descobrir que a Yaskawa disponibiliza uma boa coleção dos seus próprios manuais. Vale uma conferida.

http://www.motoman.com/motomedia/manuals/usermanuals.php

terça-feira, 22 de março de 2016

LIAM

O vídeo é interessante por si só mas, como um programador robô, eu gostaria de saber qual é a marca do braço mecânico da Apple. Foxconn?