Vier cyclustijden voor hetzelfde onderdeel

Welke vier cyclustijden bestaan er voor één bewerking?

Neem een freesbewerking op een blok aluminium 6082, in twee opspanningen, voor een serie van 25 stuks. De calculator schat de cyclustijd uit het procesplan. Later leest de programmeur een tijd uit de kop van het NC-programma, een simulatie geeft een derde getal en de besturing van de machine legt vast wanneer het programma startte en stopte. Alle vier heten cyclustijd.

Ze komen van vier bronnen, met vier eigenaren en elk een eigen soort onzekerheid, en ze liggen zelden op elkaar. Dat ligt niet aan de calculator of de programmeur; het volgt uit wat elke bron wel en niet meeneemt. Het probleem begint pas als de vier in één veld belanden en niemand meer kan zien welke erin staat.

Instellen en programmeren tellen hier niet mee: dat zijn eenmalige tijden per serie, die je over de stuks verdeelt. De cyclustijd telt per stuk. Wat dat met de stukprijs doet, staat in waarom een kleine serie zoveel per stuk kost.

Hoe bereken je een cyclustijd uit het procesplan?

Bij de offerte is er nog geen CAM-project. Per bewerking volgt dan een theoretische snijtijd uit snijsnelheid, voeding per tand, snedediepte en snedebreedte (Vc, fz, ap en ae), zoals de tabellen van de gereedschapsleverancier ze geven. De machine begrenst toerental en voeding.

Bij frezen is het toerental n = Vc × 1000 / (π × Dcap) in omw/min, met Vc in m/min en Dcap de snijdiameter op snedediepte in mm. De tafelvoeding is vf = fz × z × n in mm/min, met z het effectieve aantal tanden. De snijtijd is Tc = lm / vf in minuten, met lm de bewerkingslengte. Bij draaien reken je het toerental met de bewerkte diameter Dm, en wordt de snijtijd Tc = lm / (fn × n), met fn de voeding per omwenteling.

Die snijtijd is alleen de tijd in het materiaal. De tijd per stuk krijgt er ijlgang en gereedschapswissels bij, en laden, lossen, tasten en tussentijds meten als die bij elk stuk terugkomen. Laden met de hand gebeurt buiten het programma. Het staat dus niet in de kop van het NC-programma en niet in de programmalooptijd van de besturing; tel het apart op.

Met die optelling heb je de fysische helft. De fabrieksspecifieke helft zit er nog niet in: de werkelijke machine, de toestand van het gereedschap en de stijl van de programmeur. Daarom hoort een geschatte tijd een bandbreedte te dragen, afgeleid uit de historische afwijking voor die productfamilie. Een tijd zonder band is schijnprecisie.

Hoe groot is het verschil tussen CAM-tijd en werkelijke tijd?

In de kop van het NC-programma staat de tweede tijd. Het CAM-pakket of de postprocessor schrijft hem weg bij het uitposten, berekend uit de afgelegde weg en de geprogrammeerde voeding. Die som gaat ervan uit dat de machine overal de geprogrammeerde voeding haalt.

Dat doet ze niet. Ward, Sencer, Jones en Ozturk (2021) modelleerden hoe de besturing haar voeding plant en legden de uitkomst naast gemeten tijden en naast de tijden uit een commercieel CAM-pakket. In hoeken en op korte segmenten remt de besturing af, en hoeveel hangt af van de baantolerantie die in het programma staat. De CAM-berekening rekent met afgelegde weg en ideale voeding, en verandert dus niet als die tolerantie verandert.

Op hun luchtvaartdeel lag de CAM-tijd daardoor 36 tot 62 procent onder de gemeten cyclustijd: hoe krapper de tolerantie, hoe groter het verschil. Bij een trochoïdale kamer werd de gemeten tijd ruim twee keer zo lang toen de tolerantie van 50 naar 10 µm ging. Een CAM-tijd is dus pas bruikbaar als je weet welke kant hij op afwijkt en hoe ver op je eigen machines.

Welke cyclustijd zet je in de offerte?

Bij de eerste offerte de geschatte tijd met zijn band, na programmeren en simulatie de gesimuleerde tijd. De kale CAM-tijd hoort er niet in. Die gesimuleerde tijd draagt geen band meer, alleen een vaste toeslag voor het eerste stuk en de gereedschapswissels.

Welk van de twee offertemomenten definitief is, volgt uit een regel van de werkplaats: de orderwaarde, of het onderdeel nieuw is en hoe ver geschatte en gesimuleerde tijden voor dit soort werk eerder uit elkaar liepen. Wijkt de gesimuleerde prijs daarna meer dan de toegestane marge af van een offerte die al verstuurd is, dan blijft de prijs voor de klant staan en registreer je het verschil intern.

Wie toch de CAM-tijd in de offerte zet, mist in het voorbeeld hieronder bij 25 stuks 100 minuten machinetijd. Bij een uurtarief van € 120 is dat € 200 op één bewerking, en in een staffel van 10, 25 en 50 stuks groeit dat verschil met elk stuk mee.

Wanneer is een gemeten cyclustijd bruikbaar?

De werkelijke cyclustijd ontstaat pas in productie. Veel besturingen leggen zelf vast wanneer het programma startte en stopte, de programmalooptijd; een stopwatch bij de machine of een geboekt uur in het ERP doet hetzelfde met minder precisie. ‘Ongeveer anderhalf uur’ op een werkbon is geen meting.

Gemeten is nog niet representatief. Een gebroken boor, een storing, een ingreep van de operator of een uitzonderlijk lange insteltijd zitten allemaal in de geklokte of geboekte tijd. Subduxion onderscheidt daarom drie soorten afwijking: representatieve procesvariatie, een verklaarbare uitzondering en een onverklaarde afwijking. Wie een gemeten tijd wil gebruiken voor de volgende schatting, legt eerst vast onder welke omstandigheden hij ontstond.

Eén order die uitloopt, is één gebeurtenis. Laten drie opeenvolgende orders op hetzelfde onderdeel dezelfde overschrijding bij het frezen zien, dan is dat een signaal en pas je alleen de norm van die bewerking aan, niet de calculatie van het hele onderdeel.

Eén veld verbergt wat de nacalculatie zoekt

Nacalculatie vergelijkt per bewerking, niet op ordertotaal; anders vallen een te ruime en een te krappe bewerking tegen elkaar weg. Een uitgewerkt voorbeeld staat in voor- en nacalculatie per bewerking. Het werkt alleen als beide kanten hun herkomst dragen.

Een ERP bewaart wat er geboekt is, niet welke tijd de prijs heeft bepaald. Staat in één veld ‘cyclustijd’ de ene keer een schatting, de andere keer een CAM-kop en soms een geklokte tijd, dan laat de calculatie zich niet controleren: je vergelijkt een gok met een meting en trekt er een conclusie uit. De kwaliteit hangt af van de echte herkomst, niet van het bronsysteem: geschat, uit CAM, gesimuleerd of gemeten.

Neem het rekenvoorbeeld hierboven. Stond de CAM-tijd van 8 minuten in de offerte en meet de besturing 12, dan kost die ene bewerking bij 25 stuks € 200 marge. In één veld zie je daarna niet of de calculatie te krap was of dat het verkeerde getal erin stond, en de volgende offerte voor dat onderdeel herhaalt de fout.

Daarom hoort elke offerte de status van haar cyclustijdbasis te dragen. Een interval krijgt bij Subduxion alleen het dekkingspercentage dat de meting geeft, nooit een rond getal dat beter klinkt.

Vier tijden, vier bijschriften

Subduxion houdt de vier tijden uit elkaar: geschat, uit CAM, gesimuleerd en gemeten. Ze worden nooit samengevoegd tot één getal, ook niet als dat op de offerte overzichtelijker oogt. Een schatting houdt haar band, een CAM-tijd zijn bekende afwijking, een simulatie haar vaste toeslag en een meting de omstandigheden waaronder ze ontstond.

Blake rekent eerst de geschatte tijd. De volgende stap is de CAM-afgeleide en de gesimuleerde tijd naast die schatting, elk met een eigen bijschrift. Daarna volgt kalibratie op werkelijke uren, die de band per productfamilie smaller maakt. Wat er niet komt, is een veld waarin de vier samenvallen.