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

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.

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.

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!

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.

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/

RobotFaults.com - PT

Acabo de esbarrar nesse site, que reúne códigos de erros de robôs ABB e FANUC, por enquanto.

Ferramenta interessante.

https://robotfaults.com/

Creating virtual robots with ABB RobotStudio. No license required.

Wait!

This is not what you are thinking. 😁

In short: you do not need a license to create virtual controllers in RobotStudio. This functionality is part of the Basic mode, and can be very useful!

ABB's documentation is not clear on this subject, but in the latest versions of RS there are basically three types of licenses: Trial, Basic and Premium.

Trial, as the name implies, is a demo license. In the first 30 days, RobotStudio will work with all the features of Premium mode. At the end of the trial period, if the license is purchased, the Premium features are still enabled. If not, these features are disabled, and RobotStudio starts to work in Basic mode.

With RS in Basic mode, it is not possible to create 3D simulations, insert CAD objects, etc., that is, no simulation.

However, it is still possible to create a virtual robot, and access it through the virtual FlexPendant, or even make a "remote access" via RobotStudio, as it would be done in a real robot.

And what does that mean?

It means that, if you need to check some logic, see a customized screen or just practice on the virtual FlexPendant, this is possible, without the need for a license.

Below are the steps to create a virtual controller from scratch.

I tested in two installations with the expired Trial licenses, one with RobotStudio 2019.3, and the other with RobotStudio 2020.1. The screenshots below are from version 2020.1

ATTENTION!

The most current versions of RobotStudio do NOT come with any RobotWare installed, as they did in the old versions. Before starting the procedure, you must install all relevant RobotWares. For this, the computer must be connected to the internet.

Go to the Add-Ins tab, select the RobotWare tag, select the type of target controller (in our case it will be an IRC5), select the RobotWare version, click the Add button, and wait for the installation.

When the process is complete, you will see RobotWare in the column on the left side of the window, in the Installed Packages section.

Open RobotStudio, go to the Controller tab, click on the Add Controller option, and select the Start Virtual Controller option ...

In the Start Virtual Controller window, select the Manage option. In the image below, there are some virtual controllers already created.

Choose the version of Robotware to be used in the virtual robot. In this example, we will use RW 6.

Click on the "+" or the New button.

In the Create New section, give the controller a name, and choose how you want to create it. In this example, a new controller will be created.

In the next window, click Add ...

Select the type of mechanism to be used. In this example, we will select only one robot (RobotWare option).

Click Next.

 

Next again.

In this step, the model of the mechanical arm can be determined, as well as other software options. I left the standard model, an IRB-140.

In this window, after confirming that all setup options are in accordance with your choices, press Apply.

And then confirm.

 

After the creation of the virtual controller, the initial screen will appear, where it can be confirmed that it has been created.

Back on the Start Virtual Controller screen, the virtual controller we just created can be selected and started.

After it starts, note that the options on the Controller and RAPID tabs will be enabled.

The Online Monitor option also works, as if RobotStudio were online with a real controller.

It is even possible to request write access to the virtual controller.

It is also possible to create new modules.

 

By default, virtual controllers are created in the folder

C:\Users\<youruser>\Documents\RobotStudio\Virtual Controllers

And they can even be copied from one computer to another.

So, again: a virtual controller does not allow a complete simulation to be carried out, but I believe that it meets most of the demands of programmers who need to use RobotStudio.