sábado, 18 de setembro de 2021

robEdit - um antigo editor de linguagem ABB Rapid

robEdit

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

quarta-feira, 25 de agosto de 2021

Reis RobOffice disponível para download no site da KUKA

 

Uma curiosidade: algumas versões do RobOffice, simulador do TP dos robôs Reis, estão disponíveis no site de downloads da KUKA.

A Reis foi comprada pela KUKA em 2013, e a maioria dos seus produtos foi descontinuada, mas depois da fusão foram lançados alguns produtos interessantes, como controlador KRC4 RobotStar, um combo entre hardware e software das duas fabricantes.

Os simuladores podem ser baixados aqui.

Ainda não testei mas, se me lembro bem, o RobOffice precisava de licença, mas também funcionava em modo demo.

quinta-feira, 19 de agosto de 2021

Boston Dynamics e o ROS

Bem interessante esse vídeo da Boston Dynamics mostrando os bastidores do projeto Atlas. 

Dá pra ver que até chegarem naquele nível de excelência "parkourzeira", houve muitos tombos, vazamentos, curto-circuitos e componentes soltos.

Entretanto, uma coisa me chamou a atenção: em diversos frames do vídeo, é possível perceber que a equipe da BD usa o ROS (Robot Operation System).

Isso não deveria ser surpreendente, pois o ROS já é utilizado em outros projetos avançados que podem ser considerados o estado da arte em suas áreas. E imagino que os robôs da Boston Dynamics também devem funcionar com uma boa quantidade de software proprietário e outros segredos industriais.

Por outro lado, é sempre interessante ver esse tipo de empreendimento sendo viabilizado com o uso de ferramentas livres e que estão a um download de distância.

terça-feira, 6 de abril de 2021

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!

sexta-feira, 26 de março de 2021

Robotistas, now in English

The book is on the robot! *

Dear readers.

I keep this blog since 2009, and one of the original ideas was to publish the posts also in English.

For several reasons this idea did not go forward, until a few weeks ago. Some people have noticed that some English posts have appeared on the blog, and the intention is that this is now the default.

New posts will be published in Portuguese and then in English, and some old posts will be translated / adapted.

(At this point you may have realized that I am not exactly proficient in this language. But I will try.)

English posts will be brought together in the English tag

http://blog.robotica.massula.com/search/label/english

I invite you to take a look at the blog. 

Thanks!

* Brazilian joke. I won't even try to explain.

Identifying the version of a WorkVisual project

(Published originally in Portuguese here)

Usually, when it comes to software, the general consensus is that the newer the better.

However, in the world of industrial automation, things are not quite like that.

The stability of industrial equipment is essential for the production chain. A "novelty" used at the wrong time and place can stop a production line and cause losses of thousands or even millions of dollars.

Although the reasoning applies to different software and contexts, I will now speak specifically about KUKA WorkVisual.

The most current versions of WoV * can handle projects created in older versions.

However, whenever a newer version is used ** to open a project created in an older version, it is converted ***.

And that's where problems can start ****.

It is already common sense that the best version to edit a robot's WoV project is the one with which the project was created.

In some situations - especially where there are robots with customizations - the end customer may require that specific versions of WoV must be used. This is very common in automakers, for example.

In the past, WoV was delivered on a CD, which came with the controller documentation. In newer versions, the installation usually comes in the D: drive of the robot, as well as the KOPs (KUKA Option Package).

Checking the version that came with the robot is a good start, but nothing guarantees that the project that is working has been compiled with that version.

Below are two simple methods to check which software version a WorkVisual project was last compiled on.


WorkVisual 4.0.x and above

From version 4.0.x, things have become a little more comfortable.

WoV has a little tool with a graphical interface (not very evident), which brings various information about a project, without having to open it in WoV.

To do this, follow the steps.

Select a file associated with WorkVisual (usually a .wvs or .asz file) and right click.

Note that in the context menu there is the option Information. Click on it.



A window
containing various information about the project will open. What interests us, in this case, is the Modifications tools field, which indicates which version was used to compile the project.


WorkVisual 3.1.x and below

There is no graphical tool In older versions, but it is simple to obtain the same information.

Each time a project is compiled, some files that are automatically generated by WorkVisual have their headers changed, and one of the information is precisely the version of WoV used to compile (and not save) that project for the last time.

I always check this information in the KRC_IO.xml file, which will be present in every KRC4 controller, but it appears in other automatically generated files.

These files are usually in the folder:

...\C\KRC\Roboter\Config\User\Common

They can be opened by WorkVisual


Even if WorkVisual is not available on the computer, it is possible to open the KRC_IO.xml file (or any of the other automatically generated files) in a text editor. In the screenshots below I used Gedit and XMLNotepad, respectively. But even Windows Notepad will do the job.





Note that this method can be also used for projects created in more current versions.

I hope these tips are useful.

---

* At the time of publication of this text (english version), it is possible to download versions 4.0.31 and 5.0.10 and 6.0.15 from KUKA website.

** The WorkVisual version is always composed by three numbers. The conversion occurs when there is a change in the first or second number, for example, 3.0.7 to 4.0.31. But if the version difference is only in the third number (which usually indicates bugfixes), there is usually no problem. WoV 3.0.7 can open and edit projects created in 3.0.10, and 4.0.21 can open and edit projects created in 4.0.31. In any case, it is good to take into account the rules mentioned above. Check in which version that project was created, and when in doubt, consult the customer. This can save you several headaches.

*** When a newer version of WoV converts a project created into an older version, a copy of the original version is created. This copy is usually given the suffix "_bak".

**** And we will not even talk about versions of KOP installed on WoV that are different from those installed on the robot.

terça-feira, 16 de março de 2021

RobotFaults.com - EN

I have just come across this site, which gathers error codes from ABB and FANUC robots, for now.

Interesting tool.

https://robotfaults.com/