Hvordan tester I motion control i specialmaskiner før FAT?

En PLC-forbindelse viser kun, at tags kan udveksles mellem styring og tvilling. En motion-test spørger, om modellen svarer på kommandoer med den timing, de tilstande, grænser og fejl, som produktionssekvensen forventer. Så bliver en pæn animation ikke forvekslet med, at idriftsættelsen er i hus.

Brug PLC-platformguiden til opsætning, kommunikation og tilordning af tags. Brug den her guide til at beslutte, hvor detaljeret modellen skal være, hvilke kommandoer og tilbagemeldinger aksen skal have, hvordan I tester genstart efter fejl, og hvad der stadig hører til fysisk FAT.

Tvillingen skal reagere på kommandoer som enable, home, move, halt, abort og reset. Den skal melde standstill, homed, busy, in position, aborted og error. Den må ikke skjule en ugyldig kommando eller melde succes efter en kollision eller efter at en grænse er overskredet.

Vælg, hvor detaljeret I går, for hver test, ikke som ét niveau til hele projektet. Simulerede signaler uden bevægelse kan være nok til at se, om sekvensen vælger den rigtige vej. I skal have positioner og zoner i modellen, når det ændrer resultatet, om armen kan nå, om der er plads, eller om flere akser rammer hinanden i tid. En model med kræfter, eller hardware-in-the-loop, kan først betale sig, når last, timing i styringen eller en bestemt drevadfærd indgår i det, I skal bevise.

Skriv det valgte niveau og det, det ikke dækker, ind i testen. Hvis slør, resonans, termisk drift eller momentrespons ikke er i modellen, må resultatet ikke bruges som bevis for de ting.

Hold det, I beder aksen om, adskilt fra det, den faktisk melder tilbage. Kommandoer kan være power eller enable, home, absolut eller relativ bevægelse, halt, abort og reset. Parametre kan være målposition, hastighed, acceleration, deceleration og jerk. Tilbagemeldinger bør være aktuel position, standstill, homed, busy, in position, aborted, error og et fejl-id.

Tag en transfer med flere akser som eksempel. MoveAbsolute sætter busy, positionen kører gennem modellen, og in position bliver først sand inden for den aftalte tolerance. Skifter en afskærmning eller et interlock, eller overskrides en softwaregrænse, melder modellen den tilhørende fejl eller abort. Sekvensen skal derefter følge den dokumenterede reset eller home igen.

Det er bevidst mindre end en fuld drevemulator. I genskaber den grænseflade, PLC-programmet bruger, uden at påstå, at drevindstilling eller motorfysik ligger i modellen.

Genstart efter fejl er dér, hvor skjulte antagelser i motion-sekvensen plejer at komme frem. For hver test: startsituation, den fejl I lægger ind, den forventede rækkefølge af tilbagemeldinger, hvad operatøren må gøre, og den sikre sluttilstand. Bedøm resultatet på signalerne, ikke på animationen.

Et kort sæt, I kører igen efter hver relevant ændring, bør dække tabt home, move-timeout, abort under bevægelse, en softwarepositionsgrænse, drive not ready, in position der aldrig kommer, timeout i robothandshake, afbrudt CNC-cyklus og genstart efter nødstop.

Hvis en kommando er umulig, skal det ses. Afvis den, sæt en defineret fejl, eller meld kollision og grænse. Hvis målet bare rettes i det skjulte, kan det skjule den samme fejl, som senere stopper den fysiske maskine.

På en robotcelle udveksler PLC-programmet typisk mode, zone, tilladelse, start, busy, complete og fault med robotstyringen. En forenklet bevægelsesmodel kan teste det handshake, når baner og robotspecifik logik ligger uden for opgaven. I skal have aktuel cellegeometri, når spørgsmålet er, om armen kan nå, eller om der er plads.

På en CNC-station modellerer I handshake mod linjen: ready for load, clamped, cycle start, cycle active, cycle complete, alarm og reset. Simulér ikke G-kode eller spåntagning, medmindre en konkret accepttest afhænger af det.

Versionen af robot- og CNC-programmet har stadig betydning. Bind grænsefladetesten til PLC-version, parametersæt, robot- eller CNC-programversion, version af tvillingen og signallisten, så en timingændring ikke kan godkendes mod et gammelt grundlag.

Hold fire ting adskilt. Hardwaregrænser kommer fra fysiske endestop eller drevindgange. Softwarepositionsgrænser er indstillede positioner, der får styring eller drev til at reagere. Zoner beskriver tilladt eller forbudt geometri. Safety-funktioner som STO, SS1, SOS og SLS har en defineret adfærd i sikkerhedssystemet.

Tvillingen kan køre den almindelige styresekvens omkring de betingelser og kan melde simuleret status til test. Den beviser ikke certificeret sikkerhedshardware, hvor hurtigt maskinen stopper, hvor afskærmningen sidder, eller sikkerhedsberegningen.

Knyt hver modelleret grænse og zone til den tegning eller det parametersæt, den kommer fra. Når slaglængde, værktøj, frames eller afskærmning ændres, skal modellen og de berørte tests følge med.

Fra tvillingen bør I gemme grænsefladedefinition, scenarieinput, forventede og faktiske tilstandsskift, softwareversioner, afvigelser og acceptkriterier. Gem nok til at køre en fejlet test igen efter en ændring i PLC eller model.

Fysisk FAT tjekker stadig drevindstilling, følgefejl under last, slør, mekaniske tolerancer, vibration, termisk adfærd, stop, afskærmning, sensorer, kabling og sikkerhedsfunktioner. Det virtuelle resultat sænker integrationsrisikoen. Det beviser ikke noget, I aldrig har lagt ind i modellen.

neexo skriver motion- og integrationslogik og kobler den til en testbar maskinmodel. Hvem der ejer robot- og CNC-programmering aftales pr. projekt, sammen med det I forventer fra virtuel idriftsættelse og fra fysisk FAT.