NC-codesimulatie na de postprocessor

De controle na de postprocessor bekijkt een ander niveau

In CAM wordt eerst de geprogrammeerde gereedschapsbaan gecontroleerd. Na het postprocessen is daaruit machine- en besturingsspecifieke NC-code ontstaan. Deze bevat asuitvoer, cycli, transformaties, gereedschapsoproepen en andere machinefuncties die in de interne CAM-gereedschapsbaan nog niet volledig zichtbaar zijn.

Een NC-codesimulatie verwerkt daarom de uitgegeven code met een interpreter en een machinemodel. Daarmee kunnen fouten worden herkend die pas bij de vertaling voor de concrete machine ontstaan. De betrouwbaarheid hangt echter sterk af van de mate waarin interpreter en model bij de werkelijke omgeving passen.

CAM-simulatie en NC-codesimulatie controleren verschillende gegevens

De CAM-simulatie controleert intern berekende bewegingen, het ruwdeel en de bewerkingsvolgorde. Een machinesimulatie kan daarnaast assen, gereedschapdragers en botsingslichamen weergeven. Of daarbij de uitgegeven NC-code of alleen interne CAM-gegevens worden gebruikt, hangt af van het betreffende systeem.

Bij een NC-codesimulatie wordt de gepostprocesste G-code of NC-code ingelezen. Pas daardoor worden machinespecifieke commando's, cycli en transformaties onderdeel van de controle. Beide soorten simulatie vullen elkaar aan omdat zij op verschillende punten in de programmaketen aangrijpen.

Na de NC-uitvoer kunnen nieuwe risico's ontstaan

De postprocessor kiest asbewegingen, commandoverlopen en besturingsspecifieke functies. Bij vijfassige machines kan dezelfde gereedschapsoriëntatie met verschillende rondasstanden worden bereikt. Een ongunstige uitvoer kan grote omzwenkbewegingen, overschrijding van asgrenzen of problematische terugtrekbewegingen veroorzaken.

Ook werkstukcoördinatenstelsels en nulpuntcommando's worden in de NC-code gekozen en uitgevoerd. De werkelijke nulpuntwaarden ontstaan echter uit het instellen, meten en de gegevens in de besturing. Simulatie en echte machine moeten daarom dezelfde aannames over coördinatenstelsels en opspanning gebruiken.

Voorbeeld van een kritische terugtrekbeweging

In CAM eindigt een freesbewerking boven het werkstuk. De postprocessor genereert daarna een terugtrekbeweging en een rondasbeweging voor de volgende bewerking. Wanneer de lineaire beweging in een ongunstige volgorde wordt uitgevoerd, kan de houder in de richting van het opspanmiddel bewegen.

De oorspronkelijke gereedschapsbaan was tijdens de snede botsingsvrij. Het risico ontstaat pas door de gegenereerde commandovolgorde tussen de bewerkingen. Een simulatie van de NC-code kan deze overgang zichtbaar maken, mits het machinemodel en de interpreter de werkelijke uitvoering voldoende nauwkeurig weergeven.

De interpreter bepaalt hoe de code wordt uitgevoerd

Een eenvoudige G-codeviewer toont vaak alleen basisbewegingen. Besturingsspecifieke cycli, transformaties en subprogramma's worden mogelijk vereenvoudigd of helemaal niet geëvalueerd. Voor complexe programma's is zo'n weergave niet voldoende.

Interpreters die bij de gebruikte besturing en het machineproject passen leveren meer betekenisvolle resultaten. Ook dan moet zijn gedocumenteerd welke commando's worden ondersteund en waar afwijkingen bestaan. Een simulatie is slechts zo nauwkeurig als de regels waarmee deze de code verwerkt.

Welke fouten kunnen worden herkend

Afhankelijk van het systeem kunnen botsingen tussen gereedschap, houder, werkstuk, opspanmiddel en machine worden herkend. Andere controles betreffen asgrenzen, rondasbewegingen, gereedschapswissels, onverwachte ijlgangbewegingen en niet-ondersteunde commando's. Ook restmateriaal en cyclustijd kunnen worden geëvalueerd wanneer de benodigde gegevens aanwezig zijn.

Niet elk systeem dekt al deze punten af. Voor gebruik moet daarom worden gecontroleerd welke machinefuncties en besturingscommando's daadwerkelijk worden geëvalueerd. Een lange functielijst in een gegevensblad zegt nog niets over de nauwkeurigheid waarmee het eigen machinemodel is uitgevoerd.

Botsingsvrij betekent niet dat de verspaning stabiel is

Een simulatie kan een botsingsvrij proces tonen terwijl gereedschap of werkstuk tijdens de bewerking trilt. Ook spaandvorming, thermisch gedrag, slijtage en werkelijke spankracht worden vaak niet of slechts vereenvoudigd meegenomen. Deze invloeden moeten worden aangevuld met technologische ervaring en echte procesgegevens.

NC-codesimulatie vermindert daarmee bekende risico's, maar vervangt niet elke controle op de machine. In hoeverre het inlopen naar voren kan worden gehaald, hangt af van werkstuk, machine, modelkwaliteit en proceskennis. Voor standaarddelen kan het aandeel groter zijn dan bij nieuwe of instabiele bewerkingen.

Referentieprogramma's tonen de werkelijke controlediepte

Voor de invoering moeten programma's worden gebruikt waarvan het gedrag op de machine bekend is. Daaronder horen eenvoudige standaardgevallen en bewust kritische bewegingen. Zo kan worden vastgesteld welke fouten het systeem herkent en op welke plaatsen handmatige controles nodig blijven.

Meetwaarden kunnen inlooptijd, ontdekte fouten, machinebezetting en het aantal handmatige NC-wijzigingen omvatten. Pas deze gegevens laten zien of de simulatie in het eigen proces tijd bespaart. Een overtuigende weergave met een vreemd demodeel levert dit bewijs niet.

Veelgestelde vragen over NC-codesimulatie

**Wat is het verschil tussen CAM-simulatie en NC-codesimulatie?**
CAM-simulatie controleert hoofdzakelijk intern berekende gereedschapsbanen en bewerkingsstanden. NC-codesimulatie verwerkt na de postprocessor de uitgegeven machine- en besturingsspecifieke code.

**Kan een G-codesimulatie botsingen volledig uitsluiten?**
Nee. Het resultaat hangt af van interpreter, machinemodel, gereedschapsgegevens en opspanning. Afwijkingen tussen de virtuele stand en de echte machine kunnen nog steeds tot niet-herkende risico's leiden.