Roboguide secret text editor

(Published originally in Portuguese here) 

 

It's not that secret, and it is well described in the Roboguide help. But who reads the help, after all? 😀

However, as with other FANUC IDE resources, its location is not evident, and many people are unaware of this feature.

Editing programs in Roboguide is often a laborious activity. Even with the use of shortcuts, virtual TP may not be the most comfortable way to write a program.

And there comes the text editor.

With it, it is possible to edit any text file (or ASCII, using the FANUC nomenclature) recognized by a robot from the manufacturer, within the Roboguide itself.

 

The best way to use it is to gather all “source” files that are in text / ASCII format (.ls, .kl, .cm, etc.) in a folder on the PC, which we will call a repository. Put a name that is easy to remember. If you have more than one robot in the cell, create a repository for each one.

In the project tree (Cell Browser), inside each controller, there is an item called Files.

Right-click on it, and click on the Add option.

 

 Select the files you want to upload to the project, and change them using the editor.

 

 

Note that they will appear in the project tree, under the Files item.

Every time you double-click on that file, the editor will open.

After making the necessary edits, click on the Build button.

Once this is done, the program will be converted to the corresponding binary format, and will be saved in the repository and will also be loaded into the virtual controller, as if a LOAD was made through the robot's file manager.

In case of syntax error, the program will not be compiled, and a failure message will appear, indicating the line and column where the error is located.

Please note that this method has some limitations.

There is no synchronization between the repository and the Roboguide Files list. Every time a file is placed in the repository through Windows Explorer, it is necessary to manually add it to Files.

There is also no synchronization between ASCII files (Files) and binary files (Programs). The development direction should always be ASCII> Build> Binary> Tests.

This can be somewhat obvious in the case of Karel files, which cannot be edited via TP, but  can be confusing in the case of conventional programs.

If you edit an ASCII file, build it, and then continue editing it through the virtual Teach Pendant, the source file will NOT be updated with these changes. If you want to keep your repository up to date, you will need to export the program as ASCII from within the virtual robot, and overwrite it within the repository.

On the other hand, deleting a file in Cell Browser does not delete it in the repository, which ends up creating an extra layer of security.

In addition to the files that are recognized by the robot, it is also possible to create .txt files. In these it is not possible to give a Build. But you can, for example, create a file called Notes.txt, add it to the Files list, and use that file as a notepad for that project, editing it from within Roboguide itself.

 

Although it seems like a good idea, I don't think it's safe to leave the repository inside the robot's cell because, in some cases, when it is necessary to "clean" the cell, Roboguide often deletes the files, or restores a previous backup.

I believe that Roboguide would be even more useful for heavy programming tasks if it had two more small features:

1) when clicking on a program in the project tree, it could be automatically converted to .ls and opened in the editor, instead of opening in the virtual TP. In fact, I'm not even sure about the need for conversion, since the MD: of the virtual robot already has the files converted to .ls format. This would also help in the synchronization of files, since every time a program is edited via TP (real or virtual), its copy in .ls format is saved on the MD.

2) open individual files in Roboguide, as in RobotStudio, for example. Today it is necessary to create a cell, and load the program inside the virtual robot.

Questions, comments, suggestions about this post or about the blog content?

Show up in our Telegram group!

P.S .: My sincere thanks to Douglas, who warned me of the problem with the images in the post. Thanks bro!

O editor de textos secreto do Roboguide

Não é tão secreto assim, pra falar a verdade. Além disso, está bem descrito no help do Roboguide. Mas quem lê o help, né? 😀

Entretanto, como acontece em outros recursos da IDE da FANUC, sua localização não é evidente, e muita gente não sabe dessa possibilidade.

Editar programas no Roboguide costuma ser uma atividade trabalhosa. Mesmo com o uso de atalhos, o TP virtual pode não ser a maneira mais confortável de escrever um programa.

E aí entra o editor de textos.

Com ele, é possível editar qualquer arquivo de texto (ou ASCII, usando a nomenclatura da FANUC) reconhecido por um robô do fabricante, dentro do próprio Roboguide.

A melhor maneira de utilizá-lo é reunir os arquivos “fonte” que estão em formato texto/ASCII (.ls, .kl, .cm, etc) em uma pasta no PC, que vamos chamar de repositório. Coloque um nome que seja fácil de lembrar. Se você tem mais de um robô na célula, crie um repositório para cada um.
Na árvore do projeto (Cell Browser), dentro de cada controlador, há um item chamado Files.

Clique no mesmo com o botão direito, e clique na opção Add.

Selecione os arquivos que vocẽ deseja carregar no projeto, e alterar usando o editor.

 

 Note que os mesmos aparecerão na árvore do projeto, sob o item Files.

Toda vez que você der um duplo clique nesse arquivo, o editor já vai abrir.

Após fazer as edições necessárias, clique na tecla Build.

Feito isso, o programa será convertido para o formato formato binário correspondente, e será salvo no repositório e também será carregado no controlador virtual, como se fosse feito um LOAD através do gerenciador de arquivos do robô.

Em caso de erro de sintaxe, o programa não será compilado, e vai surgir uma mensagem de falha, indicando a linha e a coluna onde está localizado o erro.

Note que esse método tem algumas limitações.

Não há nenhum tipo de sincronia entre o repositório e a lista Files do Roboguide. Toda vez que se colocar um arquivo no repositório através do Windows Explorer, é necessário adicioná-lo manualmente no Files.

Também não há nenhum tipo de sincronização entre os arquivos ASCII (Files) e binários (Programs). O sentido do desenvolvimento deve ser sempre ASCII > Build > Binário > Testes.

Isso pode ser meio óbvio no caso dos arquivos Karel, que não podem ser editados via TP, mas pode ser meio confuso no caso de programas convencionais.

Se você faz edita um arquivo ASCII, faz o Build, e depois continua editando o mesmo através do Teach Pendant virtual, o arquivo fonte NÃO será atualizado com essas mudanças. Se você quiser manter seu repositório atualizado, será necessário exportar o programa como ASCII de dentro do robô virtual, e sobrescrever o mesmo dentro do repositório.

Por outro lado, apagar um arquivo no Cell Browser não apaga ele no repositório, o que acaba criando uma camada de segurança extra.

Além dos arquivos que são reconhecidos pelo robô, também é possível criar arquivos .txt. Nesses não é possível dar um Build. Mas você pode, por exemplo, criar um arquivo chamado Notas.txt, adicioná-lo na lista Files, e usar esse arquivo como um bloco de notas referente àquele projeto, editando o mesmo de dentro do próprio Roboguide.

Embora pareça uma boa ideia, não acho seguro deixar o repositório dentro da célula do robô pois, em alguns casos, quando é necessário dar um “clean” na célula, muitas vezes o Roboguide apaga os arquivos, ou restaura um backup anterior.

Acredito que o Roboguide ficaria ainda mais prático se tivesse mais duas pequenas funcionalidades:

1) ao clicar em um programa na árvore do projeto, o mesmo poderia ser convertido automaticamente para .ls e já ser aberto no editor, em vez de abrir no TP virtual. Na verdade, nem estou certo sobre a necessidade da conversão, visto que no MD: do robô virtual já existem os arquivos convertidos para formato .ls. Isso também ajudaria na sincronização dos arquivos, visto que toda vez que um programa é editado via TP (real ou virtual), sua cópia em formato .ls é salva no MD.

2) abrir arquivos individuais no Roboguide, como acontece no RobotStudio, por exemplo. Hoje é necessário criar uma célula, e carregar o programa dentro do robô virtual.

Dúvidas, comentários, sugestões sobre esse post ou sobre o conteúdo do blog?

Cola lá no grupo do Telegram!

P.S.: meus sinceros agradecimentos ao Douglas, que me avisou do problema com as imagens do post. Valeu, mano!

Robot Whispering - livro sobre programação de robôs FANUC

Jay Strybis, fundador da ONE Ronotics e autor do excelente blog da empresa, acaba de anunciar o lançamento de seu livro Robot Whispering, The Unofficial Guide To Programming FANUC Robots.

Como o próprio Jay menciona em seu site, existem basicamente três maneiras de se aprender a programar um robô FANUC (ou qualquer outro equipamento):

1. Fazer um treinamento na FANUC (caro e demorado)
2. Ler os manuais (tedioso e demorado)
3. Tentativa e erro (exige muita sorte)

O livro é uma tentativa de encurtar e facilitar esse(s) caminho(s). O autor trabalhou alguns anos na FANUC, e tem bastante expertise na área. Detalhe: o conteúdo é mais voltado para aplicações de manipulação e sistemas de visão.

O livro está em inglês, e para os padrões brasileiros, pode ser considerado bem caro. Mas se tiver metade da qualidade dos posts publicados no blog, recomendo fortemente.

Mais detalhes sobre o livro aqui:

https://www.onerobotics.com/robot-whispering/

Gostaria de ver mais iniciativas como essa. Inclusive em português.

RCML - Robot Control Meta Language

Esbarrei no RCML (https://toolkit.rcml.tech/) hoje, e só posso dizer que achei a ideia muito interessante.

O WORA (write once, run anywhere) foi um slogan criado pelo pessoal da Sun Microsystems, para descrever o código Java, que uma vez escrito, pode ser executado em qualquer sistema operacional que tenha um interpretador Java disponível.

Naquela época, linguagens interpretadas já não eram novidade, mas esse pequeno bordão ajudou muita gente de fora do meio a entender o poder desse conceito.

O RCML é, como o nome diz, uma meta linguagem, e bebe na fonte das linguagens interpretadas, só que ao contrário!

A grande sacada do RCML toolkit é que ele converte as linguagens de alguns fabricantes de robôs industriais (até agora, ABB, KUKA, FANUC e Motoman) em RCML, e através de alguns APIs, pode controlar os braços mecânicos executando o código RCML, que pode depois ser reutilizado em robôs de outras marcas, ou mesmo fracionado/reorganizado, de acordo com a necessidade.

As possibilidades de uso são imensas.

No segundo vídeo linkado abaixo, por exemplo, o cara cria um programa em um KRC4 . Pega esse programa, carrega no RCML toolkit, que por sua vez traduz o código KRL da KUKA em RCML e depois comanda o robô executando o código RCML recém-criado.

E para sapatear na cara da sociedade da robótica industrial, após uma pequena alteração em um arquivo de configuração, o MESMO código RCML criado a partir do KRL é utilizado para controlar um robô FANUC, que inclusive está montado em uma posição diferente da do KUKA.

Vídeo explicando o conceito (narração em russo! Mas dá pra ligar as legendas).



Vídeo (curto) mostrando a implementação do RCML.



Versão estendida do vídeo anterior, mostrando todos os passos em detalhes.



Até pouco tempo atrás, era comum que as empresas optassem por utilizar uma única marca de robôs industriais, para facilitar manutenção, treinamento e aquisição de peças de reposição, por exemplo.

Mas nos tempos atuais, com essa enxurrada de robôs de baixo custo invadindo o mercado e com o chão de fábrica ficando cada vez mais diversificado, o RCML faz muito sentido.

Existem outras iniciativas do mesmo tipo, como o ROS-Industrial, que está há mais tempo na praça. Mas pelo pouco que vi, me pareceu que o RCML está um pouco mais maduro para ser utilizado em ambientes industriais.

*Para conhecimento: continuo não gostando do Java.

Eric's Robot Backer Upper - ferramenta para backup de robôs FANUC

Tempos atrás falei da ONE Robotics Backup Tool V2.

Agora me deparei com outra ferramenta para gerenciar backups de FANUC, chamada Eric's Robot Backer Upper, ou, para facilitar, ERBU.

Além do gerenciamento de backups em si, o ERBU tem outras funções interessantes, como a execução remota de scripts .cm, por exemplo.

O manual (em pdf) descreve todos os recursos, em detalhes.

Ainda não tive oportunidade de testar o ERBU, mas o farei assim que possível.

O software pode ser utilizado em modo demo (apenas um projeto, contendo um robô). Mas a licença custa apenas 10 US$. Para quem trabalha muito com robôs FANUC, acho que é uma ótima pedida.

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.

ONE ROBOTICS BLOG: SOBRE PROGRAMAÇÃO DE ROBÔS FANUC

Recentemente, acabei esbarrando no excelente blog da empresa ONE Robotics (em inglês).

O blog é mantido por Jay Strybis, que já trabalhou na FANUC NA, e é uma ótima referência para tópicos relativos à programação desses robôs.

Ele, inclusive, criou um dialeto da linguagem TP, chamado TP+.

Vale a pena a leitura.

NOVO CONTROLADOR FANUC R-30IB

O novo controlador R-30iB, da FANUC.

Não ligue para a voz... robótica do narrador (aliás, isso parece ser uma marca registrada dos vídeos da FANUC).

Entre as novidades, o tamanho reduzido, menos consumo de energia, opções de software que eram extras e agora já vem integradas, e um novo iPendant com "gráficos 4D" (seja lá o que isso for).

Pelo que andei lendo por aí, vai estar no mercado em 2013.

Mais informações (em inglês), aqui.

P.S.: Aliás, dia desse, dando uma lida numa brochura sobre o R-30iA, achei interessante a observação:

• Virus-free (not PC based)

Obviamente, isso foi uma alfinetada em uma certa konkorrente alemã. Enfim...

IREX 2011

Semana passada aconteceu no Japão a IREX (International Robot Exhibition) 2011, considerada a maior feira de robótica do planeta.

Entre outras coisas, foram exibidos o um service robot da Motoman/Yaskawa controlado via Kinect (tava demorando):



O FANUC M2000iA, que sofreu um pequeno upgrade e, segundo o fabricante é o maior robô industrial do mundo. O payload na flange, aumentou de 1200kg para 1350kg. Além disso, ele entrou na onda da sustentabilidade e conta com um interessante sistema de "realimentação" (na falta de um termo melhor), que pode economizar até 30% de energia.



(Só para constar, há uma variante do KUKA Titan que chega perto disso, com um payload de 1300kg.)

Por último, ainda há os robôs humanóides da série NEXTAGE, da Kawada Industries. Clicaram aí no link à esquerda? Se ligaram na boça do robô que ilustra o site do fabricante? Pois é.

A diferença entre os humanóides NEXTAGE e os outros modelos da mesma categoria é que os primeiros JÁ estão sendo utilizados na indústria japonesa, trabalhando lado a lado com humanos, sem qualquer tipo de isolação, pelo que andei lendo por aí.



E só para provar que essa é uma feira REALMENTE japonesa, fiquem com a imagem que estampa o site, este ano.

Roubei todas essas notícias no excelente GetRobo.

COMO NASCEM OS FANUCS

Esbarrei nesse vídeo (que não está no canal oficial da empresa), onde são mostradas várias etapas da fabricação de um robô Fanuc.

O interessante é que, com algumas poucas exceções, há apenas robôs fazendo robôs.

De todos os vídeos e prospectos que já vi detalhando a fabricação de robôs industriais, esse é o que mostra menos trabalho manual.



P.S.: achei um barato a voz "robótica" da locutora.

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.