Aquest article compara les solucions de sistemes de control de dos robots industrials, el manipulador i el robot mòbil, i n'introdueixen les característiques.
La classificació anterior es basa en l'objecte de l'aplicació. A més, al mercat hi ha controladors de moviment més generals, és a dir, aquells que controlen equips no estàndard.
1 Solució de nivell inferior del controlador 1.1 Tipus de manipulador El controlador del tipus manipulador es va desenvolupar anteriorment i és relativament madur. Fem una ullada a la solució de nivell inferior del sistema de control existent. 1.2 Tipus de robot mòbil El controlador del robot mòbil pertany a una direcció relativament nova. Els robots mòbils industrials tenen forma d'AGV, maquinària d'enginyeria no tripulada, etc. La solució de nivell inferior del sistema de control és la següent:
1.3 Comparació
El manipulador té alts requisits de precisió i estabilitat de moviment, de manera que la quantitat de càlcul és gran i el cicle és curt, que generalment és d'1 a 2 ordres de magnitud superior al dels robots mòbils. Els robots mòbils generalment no tenen requisits elevats per a la precisió de la sincronització i la seva configuració és relativament baixa.
El manipulador generalment funciona en una àrea fixa i el seu controlador se sol col·locar al xassís, de manera que el nivell de protecció no és alt, generalment IP20. Els robots mòbils han de ser impermeables i a prova de pols perquè s'han de moure amb freqüència, especialment la maquinària d'enginyeria a l'aire lliure, per la qual cosa han de considerar la impermeabilització i la protecció contra la pols. El seu nivell de protecció és més alt, generalment IP67.
2 Introducció a CoDeSys 2.1 Composició de CoDeSys
Trobareu que molts programaris de control de robots s'implementen amb l'ajuda de CoDeSys, doncs, què és CoDeSys?
CoDeSys és un programari de desenvolupament de PLC suau de pagament. En poques paraules, consta de dues parts: sistema de desenvolupament i sistema d'execució. Development System és la interfície de programari utilitzada per a la programació (igual que Visual Studio, Eclipse i un altre programari, que també es pot anomenar IDE). El disseny, la depuració i la compilació de programes PLC es duen a terme a l'IDE, que és la part amb la qual sovint tracten els usuaris;
Després d'escriure el programa PLC, s'ha de transferir al dispositiu de maquinari perquè funcioni. Tanmateix, el programa PLC generat no pot executar-se per si mateix en aquest moment. Ha de funcionar en un entorn de programari determinat. Aquest entorn és el Runtime System, que és invisible per als usuaris.
Les ubicacions d'instal·lació dels dos solen ser diferents. L'IDE generalment s'instal·la a l'ordinador de desenvolupament i Runtime System es troba al dispositiu de maquinari que té un paper de control. Els dos generalment estan connectats per cables de xarxa i el programa es descarrega a Runtime a través del cable de xarxa per funcionar.
CoDeSys no és molt conegut a la Xina, però té una reputació de llarga data a Europa, especialment en el camp del control industrial. Moltes empreses de robots que hem esmentat anteriorment utilitzen els seus productes, com ara KEBA, Beckhoff, Googol i gairebé tots els fabricants de controladors de robots mòbils.
3S, l'empresa que va dissenyar CoDeSys, només ven programari, no maquinari. El circuit de maquinari ha de ser dissenyat per l'usuari i 3S és responsable de portar el sistema d'execució al maquinari del client. El sistema d'execució es pot executar nu al maquinari, però normalment s'executa al sistema operatiu, i la configuració del sistema operatiu també és feina del client.
Si el client ho requereix, l'IDE de CoDeSys es pot personalitzar per canviar el logotip i l'aparença del client, per això trobareu que les plataformes de desenvolupament de diferents fabricants semblen diferents, però els estils són relativament similars.
Per descomptat, els usuaris també poden utilitzar altres IDE. Per exemple, Beckhoff utilitza Visual Studio de Microsoft, mentre que el nucli i la biblioteca de funcions que hi ha darrere del compilador encara fan servir la solució de CoDeSys.
El temps d'execució de CoDeSys té una gran adaptabilitat i és compatible amb la majoria de sistemes operatius i arquitectures de xips de maquinari.
2.2 Principi d'execució de CoDeSys
La part IDE de CoDeSys és gratuïta i podeu descarregar-la des del seu lloc web oficial per experimentar-la. La càrrega real és el sistema d'execució Runtime System.
Al començament del seu disseny, CoDeSys va dividir les funcions en diversos mòduls de components, com ara pila de protocols de bus, interfície visual, control de moviment, control de seguretat, etc. Els usuaris poden triar els mòduls necessaris per construir el seu propi sistema com els blocs de construcció, i finalment formar una plataforma de programari de control personalitzada.
Alguns usuaris que són nous a PLC suau poden no estar familiaritzats amb aquesta part, però de fet aquest mètode de disseny és molt comú. Per exemple, la caixa d'eines en temps real (Real-Time) de MATLAB Simulink funciona d'aquesta manera. Els usuaris dissenyen programes de control arrossegant i deixant anar a la interfície gràfica de Simulink i després els descarreguen al maquinari real per executar-los. Podeu aprendre-ne aquí.
També hi ha una manera d'utilitzar com Beckhoff. Els usuaris programen a TwinCAT IDE i després els descarreguen al controlador de Beckhoff. De fet, un temps d'execució està preinstal·lat al controlador. Siemens STEP7 també és un IDE i el seu PLC també té un temps d'execució coincident.
El programa PLC escrit per l'usuari és com l'aplicació del nostre ordinador. S'executa al sistema d'execució i el sistema d'execució s'executa al sistema operatiu.
El sistema d'execució es troba entre l'aplicació i el sistema operatiu. Així que es pot anomenar middleware. En el programari del robot, ROS, OROCOS (Real-Time Toolkit), etc. es troben en la mateixa posició.
El control del robot, com les màquines eina CNC, requereix un rendiment en temps real, de manera que el sistema operatiu que triem és preferiblement un sistema operatiu en temps real (RTOS). Malauradament, els sistemes operatius que fem servir sovint no són en temps real, com Windows i Linux. Però, afortunadament, algú els ha modificat, és a dir, ha afegit pedaços en temps real.
Els sistemes operatius en temps real més utilitzats inclouen: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs, etc. Tenint en compte que hi ha molts usuaris de sistemes operatius Windows i Linux, CoDeSys ha llançat un pedaç en temps real (RTE) corresponent per estalviar als usuaris els problemes de modificació.
Per obtenir més informació sobre CoDeSys Runtime, podeu llegir el document oficial [Error de processament matemàtic] [1][2][1][2].
2.3 Inconvenients de CoDeSys
CoDeSys aporta comoditat al desenvolupament del nostre controlador i ens estalvia la molèstia de començar des de zero. Tanmateix, també hi ha molts desavantatges en el desenvolupament dels nostres propis productes de controlador basats en programari comercial com CoDeSys:
(1) L'algorisme subjacent no està obert
Els components de control de moviment i les piles de protocols de bus integrades per CoDeSys estan tots encapsulats. Els usuaris no poden entendre els seus detalls interns, ni els poden personalitzar i optimitzar segons les seves necessitats específiques. Només poden trucar-los simplement. Els usuaris només poden confiar en la plataforma CoDeSys i els costa formar la seva pròpia tecnologia bàsica.
(2) Funcions limitades i difícils d'ampliar
Les noves tecnologies representades per la visió artificial, la intel·ligència artificial i la conducció autònoma estan avançant a passos de gegant, mentre que moltes tecnologies de control industrial tenen encara 20 anys. Prenent com a exemple l'escena de navegació en un robot mòbil, el mètode de navegació basat en visió o làser necessita recollir una gran quantitat de dades i processar-les, la qual cosa implica molts càlculs matricials.
Ara el PLC només pot realitzar càlculs digitals unidimensionals cap enrere, cosa que dificulta la implementació d'algorismes complexos. En contrast amb l'estil de codi obert de la comunitat d'intel·ligència artificial, la comunitat de control industrial està tancada entre si. Ningú està disposat a obrir les seves pròpies biblioteques de funcions. Hi ha molt poques biblioteques de funcions de codi obert (OSCAT). Fins i tot els algorismes de filtratge i els càlculs de matrius més bàsics s'han d'escriure des de zero. A més, les funcions bàsiques que ofereixen els estàndards internacionals són massa limitades i no poden adaptar-se en absolut als nous escenaris. Tenen una necessitat urgent d'ampliació.
(3) Difícil d'actualitzar
A causa de la total dependència de CoDeSys, l'actualització del maquinari del producte propi dels clients s'ha de personalitzar i trasplantar, la qual cosa comporta un augment dels costos.
3 Solucions de codi obert
Actualment, hi ha algunes solucions de sistemes de control de codi obert, com ara Beremiz, Orocos, OpenPLC, OpenRTM i ORCA.
Desenvolupar controladors de robot és una tasca pesada. Cal aclarir una sèrie de requisits de rendiment, el primer dels quals és el rendiment en temps real.
El rendiment en temps real és generalment necessari per als robots industrials, però no necessàriament per als robots de servei o d'entreteniment. És fàcil que la gent comuna confongui el "rendiment en temps real" amb un processament ràpid o una velocitat de resposta, però de fet "rendiment en temps real" significa "determinisme" en el temps. Per exemple, el temps de retard de la resposta a la interrupció o la commutació del procés al sistema operatiu en temps real (RTOS) ha d'estar dins d'un interval de temps.
Els sistemes operatius que utilitzem habitualment (Windows, Linux) no són sistemes operatius en temps real, perquè estan dissenyats per a un rendiment i no poden garantir que cada esdeveniment es processi dins d'un interval determinat. Per exemple, la velocitat de transmissió de l'Ethernet estàndard és molt més ràpida que la de l'Ethernet industrial en temps real, però tampoc és en temps real, perquè tampoc no pot garantir que les dades es transmetin en un temps determinat.
No és difícil d'entendre en temps real, però quines tasques del robot s'han d'executar en temps real? Com determinar l'interval de temps per a l'execució del programa segons els requisits de rendiment del robot (1 ms o 10 ms)? El temps real depèn del maquinari o del programari?
Com triar maquinari i programari específics basats en temps real (ARM o X86, Linux RTAI o VxWorks)? Hi ha una manca de discussió en profunditat sobre aquest aspecte a Internet, i els principals fabricants de robots no revelaran els seus resultats de proves i experimentals. Sembla que aquest aspecte es basa principalment en l'experiència i l'assaig i error.
Aquí només puc proporcionar uns quants indicadors. Actualment, el cicle de control dels braços de robot industrial és d'aproximadament 1 ms, i el cicle de control del bucle de posició d'un servoaccionament d'alt rendiment pot arribar als 125 [Error de processament matemàtic] mu sμs. PLCopen defineix alguns estàndards per al control de servo i moviment, inclòs el llenguatge de programació, blocs de funció bàsics de control de moviment, paràmetres d'interfícies d'entrada i sortida, etc. [Error de processament matemàtic] ^{[3]}
[3] Els detalls específics del codi d'implementació els proporcionen diversos fabricants.
