robEdit - um antigo editor de linguagem ABB Rapid

Dia desses estava revendo umas anotações antigas e acabei me lembrando do robEdit, um editor para programas escritos em linguagem Rapid que teve seu primeiro beta liberado por volta de 2005., um pouco antes das primeiras versões do RobotStudio 5, para o então também recém-lançado controlador IRC5, chegarem ao mercado.

Fui dar uma conferida e, para minha surpresa, o site está online e, além disso, o programa ainda está sendo comercializado. Mas só na Europa.

O detalhe mais curioso disso tudo é que, aparentemente, o desenvolvimento do robEdit parou em 2008!

Mas eu baixei o demo da versão mais recente disponibilizada no site, fiz alguns testes, e o programa rodou liso no Windows 10.

Mesmo que o RobotStudio já esteja consolidado como a ferramenta padrão para programação de  robôs ABB, o robEdit tem algumas características que acho bem interessantes, como o tamanho reduzido do programa (menos de 30 MB), a velocidade e,  principalmente, o fato de não ser necessária instalação. Todos os arquivos de configuração ficam na mesma pasta do executável, e o programa roda até de um pendrive.

É uma pena que o projeto tenha sido interrompido. Em certos aspectos, me lembra um pouco o OrangeEdit, e acredito que uma ferramenta desse tipo teria espaço no kit de ferramentas de muitos programadores por aí.

Neste link, é possível ver um resumo dos recursos do robEdit.

http://www.robedit.com/preview/index.html

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...

RobPro - Editor de textos para robôs industriais VKR

Se editores de texto para robôs industriais já podem ser considerados um nicho bem específico, o que dizer de editores de texto para robôs industriais hipercustomizados? O nicho do nicho?

Recentemente esbarrei com o RobPro, uma ferramenta para edição e verificação de programas escritos em VKRL. 

O VKRL é um dialeto do KRL, a linguagem de programação padrão dos robôs KUKA. Os VKR são, como já disse no primeiro parágrafo, versões hipercustomizadas dos KR normais, desenvolvidas única e exclusivamente para a Volkswagen, e seus programas são escritos em VKRL.



Além das funções normais de edição, o RobPro também tem um recurso interessante, que é a verificação da conformidade do programa de acordo com o VASS, o padrão de programação mais recente utilizado pelas empresas do grupo VW, no mundo inteiro.



No vídeo abaixo, há uma rápida demonstração do programa.


O RobPro não é tão maduro e nem tem tantos recursos quanto outras ferramentas que estão no mercado há mais tempo, como os editores da Steineke ou da TekROB, mas tem algumas ideias interessantes, e estou curioso pra ver quais as novidades virão no futuro.

No site está disponibilizado para download um demo funcional de 30 dias (com o salvamento desabilitado).

Os requisitos mínimos são o Windows 7 e o .NET 4.5.

CFGEDITOR + WORDFILES PARA ULTRAEDIT

Dia desses acabei esbarrando no site (em alemão) do Paul Wolski, e encontrei dois projetos interessantes:

O primeiro é um editor para arquivos .cfg de robôs ABB, o CFGEditor. É um projeto open source e ainda está sendo desenvolvido. Espero sinceramente que seja melhor do que o finado ConfigEdit da ABB. :)

O segundo é um conjunto de wordfiles e scripts para UltraEdit que ele compartilhou.

Eu não uso o UE há bastante tempo (prefiro o Notepad++), mas o software é muito bom e os wordfiles são um dos recursos mais úteis.

EDITANDO ARQUIVOS DE ROBÔS ABB EM DISPOSITIVOS ANDROID

Já faz algum tempo que tento descobrir uma maneira de ler/editar arquivos produzidos por robôs em dispositivos móveis. Já brinquei com meus Nokias série E, e agora a bola da vez foi meu Galaxy Tab.

Existem vários editores de texto para Android, mas eu queria uma experiência mais próxima da que tenho com o notebook, e uma das condições era que fosse possível ter algum tipo de destacamento de sintaxe (syntax highlighting). Pesquisei um pouco e, até onde sei, o único editor de textos - para Android - onde existe a possibilidade de criar arquivos de configuração para linguagens de programação específicas é o Jota (que, vejam só vocês, eu já usava).

Embora eu não encoste em um TP (ou num FlexPendant) há mais de um ano, decidi criar um arquivo de destacamento de sintaxe para a linguagem Rapid, da ABB, porque esta é a mais editing friendly que eu conheço.

De início, tive um pequeno problema. Assim como o próprio Android - que para todos os efeitos é uma distro Linux - a versão do Jota na qual comecei a trabalhar era case sensitive (faz diferenciação entre letras maiúsculas e minúsculas), então um arquivo de configuração prg.sys.cfg.mod.conf seria diferente de um arquivo de configuração PRG.SYS.CFG.MOD.conf.

A questão era que os arquivos gerados pelos controladores S4(C/Plus/P) sempre são criados com todas as letras de seus nomes em maiúsculas. Mas isso não acontece com a série IRC5. Tudo bem, não se fabricam mais controladores da série S4, mas ainda existem muitos deles espalhados por aí. Então quando um usuário quisesse editar um arquivo do IRC5, teria que usar um arquivo de configuração e quando quisesse editar um arquivo do S4, teria que usar outro. Ou poderia ficar renomeando os arquivos, trocando a capitalização das letras. Nem preciso dizer que qualquer um dos dois métodos seria, no mínimo, contraproducente.

Enviei o arquivo para o desenvolvedor do Jota, mas ele disse que não disponibilizaria o mesmo junto com o software porque acredita que, embora a linguagem Rapid não seja muito popular, algumas de suas extensões são. O .prg, por exemplo, é utilizado pela linguagem FoxPro (alguém ainda usa isso?). O .mod pode ser um arquivo de vídeo ou um programa Fortran (alguém ainda usa isso?), e o .sys pode ser um arquivo de sistema do Windows. E isso poderia confundir alguns usuários. Para mim, essa argumentação fez sentido.

Ele disponibilizou o keyword file em seu site. Caso você se interesse, basta baixar o arquivo e colocá-lo em /sdcard/.jota/keyword/user/ (depois de ter instalado o Jota, obviamente).

Fiz os testes em um Galaxy Tab (Android 2.2) e em um Xperia X8 (Android 2.1), e ambos funcionaram como o esperado.

Infelizmente, não pude colocar screenshots aqui, porque sou preguiçoso demais para rootear meu GTab (ou para reinstalar o Z4root, que meu antivírus diz ser, bem, vírus).

Sei que editar um programa desses em uma tela minúscula não deve ser lá uma das experiências mais empolgantes do mundo, até mesmo pela dificuldade em transferir os arquivos entre o controlador do robô e a grande maioria dos dispositivos Android. Contudo, acho que é vantajoso ter a *possibilidade* de fazer isso em caso de emergência.

O próximo passo será criar os keyword files para as linguagens (v)krl/KUKA e tp/FANUC. 

ATENÇÃO 1: caso sua versão do Jota seja anterior a 0.2.10, provavelmente você terá aquele problema com os nomes dos arquivos em maiúsculas e minúsculas que eu mencionei acima. E a melhor maneira de resolver isso é atualizando o Jota.

ATENÇÃO 2: eu ainda NÃO carreguei nenhum arquivo editado pelo Jota em um controlador ABB, então não sei se haverá algum problema durante o upload. Acredito que não, MAS AINDA NÃO tenho certeza.  Então, caso queira impressionar seu chefe programando em seu celular, saiba que você está por usa própria conta e risco, meu chapa. Como dizem os americanos, shit happens. Faça alguns testes antes.

PSPAD 4.5.6

Foi liberada para download - no dia 11/11/11 - a versão 4.5.6 do PSPad que, na modesta opinião deste que vos escreve, é o segundo melhor editor de textos para Windows. O primeiro lugar ainda pertence ao UltraEdit, embora o PSPad tenha um feature imbatível: o preço (ou a falta dele, se você preferir assim).

Embora o ciclo de atualizações do PSPad seja lento (a versão anterior foi lançada há mais de dois anos atrás), o software é bem polido e estável.

E o que interessa aos robotistas é o fato dele já vir pré-configurado para a edição de arquivos gerados por robôs ABB (embora seja necessário fazer um pequeno tweak para habilitar essa função). Além disso, nessa versão foi corrigido um pequeno bug que não permitia a exibição das rotinas do tipo TRAP no code explorer.

E, saindo um pouco da robótica, mas ainda continuando no mundo da automação, essa versão também conta com um destacador de sintaxe para arquivos .awl gerados pelo SIEMENS Step 7.

O programa pode ser baixado gratuitamente aqui.

UEX 1.1.0.0

Pra você não se confundir, quando eu escrever UEX, estou me referindo à versão Linux. E quando for UltraEdit, estou me referindo à versão para Windows, certo?

No mundo GNU/Linux existem vários editores de texto fantásticos. Alguns deles são, inclusive, mais velhos que os próprios sistemas operacionais. Estão aí o Vim e o Emacs, com décadas de estrada, que não me deixam mentir. Entretanto, essas duas incríveis ferramentas operam num nível que remonta aos primórdios da computação, pré-mouse e mesmo pré-interface gráfica, exigindo um nível de desprendimento muito grande por parte dos usuários neófitos, e nem todo mundo está disposto a reaprender uma nova maneira de fazer algo que, bem, deveria ser uma atividade corriqueira num computador.

Além disso, como já disse em outras plagas digitais, a área de automação industrial é Windowscêntrica por natureza.

O UltraEdit é, com certeza, o editor de textos mais famoso do Windows (o Bloco de Notas é um brinquedo, e o Word, meu amiguinho, é um PROCESSADOR DE TEXTOS, an other beast, como dizem os americanos).

Comprei uma licença assim que o software saiu em novembro do ano passado, e depois de utilizá-lo numa base diária, tenho alguns comentários a respeito. Estou usando a versão 1.1.0.0 no Ubuntu 9.10 (64 bits).

CODIFICAÇÃO DOS ARQUIVOS

Por default, o UEX exibe todos os arquivos como se tivessem codificação UTF-8. Mesmo aqueles que não tem essa codificação.  Isso significa que em arquivos gerados com outras codificações (como a ISO-8859-1), os caracteres acentuados não são mostrados corretamente. E ainda há um efeito colateral: a Function List para de funcionar, a partir do primeiro caractere "estranho".

Para contornar o problema, existem, até agora, três alternativas:
1) abrir o arquivo de dentro do UEX e selecionar a codificação.
2) abrir o arquivo e, através do menu View > View As (File Encoding..) selecionar a codificação desejada.
3) criar um script bash para fazer a chamada do programa, indicando que todo arquivo deve ser aberto/visualizado como ISO-8859-1 (ou a codificação que você preferir).

Particularmente, acho isso bem contra-producente, uma vez que a idéia de trocar diversas ferramentas por uma única é justamente ganhar produtividade. No Windows, o UltraEdit tem reconhecimento automático de codificação. Até o Leafpad consegue reconhecer automaticamente a codificação dos arquivos! Se a IDM quer mesmo trazer toda a experiência do GNU/Linux para o UltraEdit, é melhor resolverem esse detalhe.

CONFIGURAÇÕES

O programa não memoriza as últimas configurações que fiz. Um exemplo simples: para editar código, eu desativo a quebra automática de linha (word wrap). Mas para editar textos simples, notas e outros agrupamentos de caracteres que não são necessariamente código para máquinas - coisa que faço com frequência, aliás - prefiro deixá-la ativada. Mas, basta fechar o programa para perder algumas dessas pequenas configurações. A partir do UltraEdit 14.00 é possível, inclusive, criar perfis de utilização diferentes, assim como importá-los exportá-los.

WORDFILE

Desde versões imemoriais, o UltraEdit trabalha com os famosos wordfiles, arquivos que contém as configurações para destacamento de sintaxe, "code folding", function lists e por aí vai.

Até a versão 14 do UltraEdit, o programa carregava um wordfile de cada vez, sendo cada wordfile capaz de armazenar as configurações para até vinte linguagens diferentes. Se, no pouco provável caso, você precisasse utilizar uma linguagem que não esteja entre as vinte pré-configuradas, basta alterar o wordfile, através de uma caixa de diálogo.

Mas a partir da versão 15, a IDW desenvolveu uma solução que considero mais esperta: agora, ao invés de vasculhar apenas um arquivo com várias configurações, o UltraEdit procura pelos parâmetros de configuração dentro de uma pasta. Então, ao surgir uma nova linguagem, basta criar um novo wordfile para ela e adicioná-la dentro dessa mesma pasta. Bem mais prático, pra quem tem que ficar trabalhando com vários tipos de linguagens e arquivos de configuração, o que, não por acaso, ocorre com a maioria dos robotistas.

Contudo, essa primeira versão do UEX, que foi lançado APÓS o UltraEdit 15, ainda manipula os wordfiles do jeito antigo. Embora não seja o fim do mundo, acho que esse era um recurso que já poderia ter sido adicionado.

Já na parte funcional, notei que, quando se altera o wordfile que está sendo usado, as alterações só são ativadas após se reiniciar o programa. Se não me falha a memória, no UltraEdit as mudanças são imediatas.

AUTO-COMPLETAR

O UEX ainda não tem o recurso de auto-completar de acordo com a linguagem. Só pra variar, o UltraEdit já tem.

ABAS COLORIDAS

Nas versões mais recentes do UltraEdit, arquivos com extensões diferentes são exibidos em abas com cores diferentes.

COMPARAÇÃO

Mais uma vez, existem ótimas ferramentas de comparação no GNU/Linux (eu uso o KDiff3).

A IDM também produz o UltraCompare, mas o UltraEdit sozinho é capaz de comparar arquivos através de uma versão lite do UltraCompare, que vem "embarcada" no programa, e seria uma boa ter o UEX também ter essa capacidade.

DOCUMENTAÇÃO

A documentação, tanto no site, quanto na própria ajuda do programa tem alguns atalhos incorretos. Ou melhor, não indicados corretamente. É que existem várias possibilidades de layout de teclado (Gnome, KDE, Windows ou Emacs), e aqueles indicados na documentação equivalem aos do Windows, enquanto o layout que default, no meu caso, que uso Ubuntu, foi o do Gnome. O atalho para inserir bookmarks, por exemplo, que no Windows (e na documentação) é Ctrl+F2, no meu computador estava como Ctrl+D. Acho que, no caso do UEX, isso deveria ficar mais explícito.

BUGS

Ao tentar abrir um arquivo .dat que estava dentro de um arquivo zipado, o UltraEdit simplesmente travou.

Se o Compiz está habilitado, o UEX, comporta-se de maneira estranha. Às vezes, começo a editar um arquivo. Aí me lembro que a quebra de linha não estava selecionada (veja em CONFIGURAÇÕES). Então seleciono a quebra de linha, continuo editando o arquivo, e quando o texto chega na borda da tela e, teoricamente, deveria continuar na próxima linha, o programa simplesmente se fecha, sem salvar o meu trabalho. Na versão 1.1 isso ficou menos frequente, e ainda não consegui identificar um padrão. Mas, mesmo assim, não dá.

CONCLUSÃO

Confesso: depois de esperar ansiosamente pelo lançamento do UEX, fiquei meio decepcionado com as primeiras impressões que tive.

Continua sendo uma ferramenta muito superior à média, e houve bastante progresso entre a versão 1.0 e a 1.1, mas ainda pode melhorar bastante.

O UEX está empacotado para quatro das principais distros GNU/Linux (Ubuntu, Fedora, OpenSUSE e Red Hat), 32 e 64 bits. Há também um .tar genérico para outras distribuições.

No momento em que publico esse post, o preço do software é de US$ 49,95, com direito a um ano de upgrades.

PSPAD 4.5.4

A versão mais recente do editor de textos conta com uma novidade que pode agradar aos robotistas. Ou, pelo menos, aos programadores de robôs ABB: agora a linguagem RAPID já vem integrada ao programa.

Na verdade, o destacador de sintaxe da linguagem RAPID (assim como o da linguagem KAREL), já estava disponível para download há muito tempo. Também é fácil escrever um arquivo de configuração para detacamento de sintaxe de uma outra linguagem qualquer.

O que realmente mudou foi que agora o Code Explorer, que não é customizável, também exibe as funções da linguagem RAPID.

O Code Explorer é uma janela lateral (chamada de Function List em outros softwares) que exibe apenas os nomes das subrotinas e funções, tornando mais fácil a navegação em programas extensos.

Infelizmente (e não sei por quê), o Code Explorer exibe apenas as PROCs e as FUNCTIONs, deixando de lado as TRAPs.

Entre outras coisas, o PSPad pode fazer a comparação de arquivos (na verdade, todo editor de texto que SE PREZE pode, de um jeito ou de outro, realizar essa operação).

Ele ainda conta com outros recursos úteis, como a criação de novos arquivos a partir do resultado de buscas e a capacidade de exportar o texto para o formato .rtf, recurso interessante para a bendita hora em que é necessário criar a documentação do robô/célula que você está integrando.

E pode ser executado direto de uma unidade de armazenamento externa (pendrive, hd externo, etc).

É possível também alterar a interface para o português brasileiro, além do site disponibilizar um dicionário para o nosso idioma.

Particularmente, acho o PSPad muito bom - e sempre utilizei-o - para editar arquivos .ini e .xml.

O PSPad é freeware (mas não opensource). E está disponível apenas para o Windows.