Estou considerando que a idéia é associar cada eixo de uma CNC (X, Y, Z, ...) aos eixos que ser quer mover nesse simulador de sistema solar.
Correto.
Num CNC, define-se uma trajetória de usinagem
Bão, CNC não é sinônimo de usinagem ...
esta é executada num ciclo aberto, geralmente sem repetições.
Ao contrário ... não só a repetição de ciclos é algo muito comum, como a utilização de subrotinas, conhecidas como
canned cycles tb é ...
Nesse caso, seria um sistema periódico, que deveria gerar sinais de acionamento dos motores que se repetiriam após determinado ciclo, como nos movimentos celestes.
Correto.
A menos que se use codificação G diretamente, a alternativa seria usar um software CAM, onde geralmente os menos afeitos ao código G trabalham.
A minha idéia é codificar manualmente.
Porém, mapear esse problema num software CAM também não é trivial e nem imagino como seria, pois lida com imagens.
Não é muito diferente de qualquer outra tarefa ... há mais de uma maneira de esfolar um gato ...
Se for usar código G, se eu não estiver enganado, as trajetórias dos eixos do CNC (X,Y,Z) seriam fictícias, mas representariam a composição do movimentos que se quer simular (rotação da Lua, da Terra, ...).
As trajetórias são reais, Gil.
Acredito que esse acionamento conjugado dos eixos estaria limitado a quantidade de eixos disponível no hardware, no software CNC, aos comandos permitidos no código G (G0, G1, ...) e aos eixos normalmente associados a esses comandos, tais como: X-Y, X-Z, Y-Z, X-Y-Z (comandos de abertura de rosca), ou quem sabe até 4 eixos.
Afaste da mente a coisa da usinagem que fica mais fácil entender ... o bom e velho TurboCNC é capaz de comandar até oito eixos, por exemplo ...
Mas sempre de maneira limitada e geralmente restrita aos movimentos usuais de um CNC, para o que o código G foi originalmente desenvolvido.
O preconceito tá atrapalhando ... esqueça usinagem ... CNC é muito mais que isto ...
Talvez seja uma analogia útil considerar o código G como um
instruction set RISC ... se há limitações, elas são mais do programador ... a coisa é muito mais flexível e poderosa do que parece inicialmente ...
Mas não estou dizendo que não dê para usar, mas acho uma certa "forçação de barra", acho que seria mais ou menos como tentar fazer gráficos usando linguagem COBOL.
Não, vc é que tá forçando a barra com esta comparação, acredite ...
Medite um pouco sobre o prob e vc vai perceber que a coisa é mais simples do que parece e perfeitamente tratável com recursos simples e conhecimentos limitados, é algo que está ao alcance da maioria de nós ... a real dificuldade é superar as idéias preconcebidas ...
Dizem que pra quem só tem um martelo todos os problemas são pregos ... felizmente temos mais que martelos à disposição ...
Por outro lado, concordo que fazer isso num microntrolador tem as suas dificuldades. Mas as restrições são bem menores, e o software entendo não ser tão complexo assim, mesmo executando movimentos escalonados (um de cada vez) ou interpolados por aproximação, como num CNC.
Fosse vc que tivesse colocado o prob eu não questionaria a utilização de microcontroladores e talvez até recomendasse, tb não acho que seja nada de muito complicado, mas para alguém não familiarizado, a tarefa é um fardo bastante pesado ... nas melhores condições, mede-se em semanas, enquanto é possível ensinar a alguém os rudimentos de CNC suficientes pra produzir algum trabalho útil em minutos ou poucas horas ... considere tb a flexibilidade, a facilidade para alterar o prog e o comportamento do sistema ...
Claro que há gente aqui no fórum que poderia escrever o prog, mas eu acho sempre mais interessante ensinar a pescar que dar o peixe ...
Além das considerações mais imediatas e práticas - a solução do prob proposto pelo Macieira - considero tb o contexto mais amplo, este ambiente, um fórum fórum dedicado a CNC e por isto me parece que faz bastante sentido aproveitar a oportunidade para trazer questões e soluções que potencialmente são de interesse mais amplo para esta comunidade ...
