Resumo da ópera: a não ser que tenha um motivo muito bom pra fazer isso, não deixe projetos de WorkVisual sobrando no seu KRC4/KRC5. Eles ocupam espaço e, pior, podem ser ativados inadvertidamente, causando diversos problemas.
Opa. Resolveu ficar por aqui? Então vamos lá.
A geração KRC4 introduziu diversas novidades na linha dos robôs industriais KUKA, e uma das principais foi o WorkVisual.
Se antes o robô era configurado através de diversos arquivos de texto e software adicionais, agora todas as configurações alterações são feitas com uma única ferramenta.
Projetos do WorkVisual são o que podemos chamar de snapshots do sistema. Eles contém arquivos de programas e configurações, encapsuladas ali em determinado momento. É quase um backup dentro do backup.
Isso é muito útil durante a fase de testes e comissionamento, visto que é possÃvel deixar vários projetos com configurações diferentes dentro do mesmo robô, e ir ativando / desativando os mesmos, conforme necessidade.
Entretanto, essa conveniência pode se tornar inconveniente, depois que o robô está comissionado e funcionando.
É muito comum que projetos WoV se acumulem nos controladores. 
Mas esses projetos, além de ocuparem espaço dentro do HD/SSD do robô, ainda ocupam espaço no backup!
Um backup de um robô com KSS 8.5, com alguns opcionais básicos, costuma ter por volta de 5MB, incluindo o Projeto Ativo e o Projeto Base. Dois projetos a mais e esse tamanho pula de 5 MB para 10 MB, e assim por diante. E comum encontrar backups com 25MB de tamanho, ou até mais!
Alguns casos extremos que encontrei por aÃ:
Um backup demorou bem mais do que o normal (os backups dos KRC4 costumam ser bem rápidos). Na hora não me atentei muito para isso. Depois, quando fui abrir o backup, a surpresa
Isso mesmo. Quase 90 MB (quando normalmente seriam 5 MB), e 19 projetos, sendo que 17 não estavam sendo usados.
Um outro exemplo.
Quase 43 MB, e 30 projetos!
Embora o preço do armazenamento, tanto online ou offline, esteja caindo cada vez mais, um backup muito grande pode criar alguns problemas.
O desperdÃcio de espaço é o primeiro que me vem à cabeça.
Diversas empresas usam sistemas de backup automatizados para fazer cópias semanais, e algumas vezes até diárias.
Se um sistema desses fizesse 10 backups de 5 MB, seriam 50 MB. Se forem backups diários, renovados num ciclo mensal, serão 30 dias de backup x 50 MB = 1,5 TB. Mas suponhamos que todos os robôs estejam com projetos sobrando. 10 MB em média em cada arquivo. Então, em vez de.1,5 TB terÃamos 3 TB.
Estou falando de uma fábrica hipotética, com 10 robôs. Mas e se extrapolássemos nosso raciocÃnio para uma montadora, com um parque de 400 ou mais robôs na mesma planta?
Outro inconveniente de backups muito grandes: email. Ainda hoje, a maioria dos provedores de email não permite anexos maiores que 25MB.
Um backup maior do que isso não poderia ser enviado dessa maneira.
Existem, claro, algumas formas de contornar esse problema, seja fracionando o backup em partes menores, seja enviando apenas o projeto ativo, seja enviando através algum outro sistema de compartilhamento.
Mas a primeira opção vai demandar trabalho extra para uma operação teoricamente simples. A segunda opção vai resolver a maioria dos problemas, mas não todos, pois existem alguns arquivos que não são encapsulados dentro do projeto WoV, só vem no bakcup. E, por fim, quanto à terceira opção, qualquer um que já trabalhou conectado a uma rede corporativa sabe das dificuldades de baixar qualquer outra coisa que não venha como anexo de email.
Mas o problema mais grave causado por projetos sobressalentes, a meu ver, é a ativação de um projeto errado. Já ouvi algumas histórias de terror sobre horas de trabalho perdidas porque alguém simplesmente ativou um projeto mais antigo, ninguém percebeu, rodaram programas desatualizados, houve colisão, retrabalho e no fim, os programas corretos estavam dentro do próprio robô, mas em outro projeto.
Então, fica a dica: o robô está comissionado e funcionando bem? Apague todos os projetos que não estejam sendo utilizados.
