Ugrás a tartalomhoz
FEJLESZTŐKNEK

CutOptim Engine API

Determinisztikus vágásoptimalizáló motor, HTTP-n hívhatóan: ugyanaz a kérés mindig ugyanazt a vágástervet adja vissza — így auditálhatod, árajánlatot készíthetsz belőle, vitát zárhatsz le vele, és újrafuttathatod a tavalyi rendelést, hogy a tavalyi tervet kapd. Ugyanaz a motor, amely a CutOptimot működteti, a három téglalapos módjával (2D lap, 1D lineáris és faanyag keresztmetszet-párosítással), plusz valódi alakú nesting a szabálytalan poligon darabokhoz — POST /v1/optimize/nest, lézeres, plazmás és vízsugaras munkához. Beküldöd a darabokat és az alapanyagot, visszakapod a teljes elrendezést, a vágástervet és a kihasználást — készen arra, hogy egy ERP-be, egy árazó eszközbe vagy egy gép saját szoftverébe illeszd.

Teljes benchmark megtekintése → · Mérve, nem ígérve

Olvasd el az API-referenciát →

Miért erre építs

DETERMINISZTIKUS

Ugyanaz a bemenet mindig ugyanazt a kimenetet adja — nincs véletlenszerűség, nincs óra az algoritmusban. Az eredmények cache-elhetők, és tesztekben összehasonlíthatók.

VALÓDI VÁGÁSTERV

Nem csak téglalapok: a guillotine vágási sorrend, a vágásvonalak és a fűrészelések külön, a vágáshossz, és egy jelző arról, hogy az elrendezés legyártható-e panelfűrészen.

PANELFŰRÉSZRE SZABVA

Fűrészrés, oldalankénti széllevágás, tolerancia, költség-mód, erezet-csoportok, max. vágási fázis, forgatás-minimalizálás — ugyanazok a beállítások, amelyeket az app is kínál.

Mit tud az API

Négy vágási mód

Egy-egy hívás a 2D lapokhoz, az 1D lineáris anyaghoz, a keresztmetszet-illesztéses fához és a szabálytalan poligonok valódi alakú nestingjéhez — POST /v1/optimize/2d, /1d, /wood és /nest.

Valódi alakú nesting

A POST /v1/optimize/nest tetszőleges poligonokat (lyukakkal együtt) pakol fix táblákra, egymás konkáv zsebeibe illesztve a darabokat — 6 tábla ott, ahol ugyanezek a darabok befoglaló téglalappal 9-et igényelnek. Lézeres, plazmás és vízsugaras munkához. Táblánkénti kizárási zónák (egy hiba, egy leszorító) is járnak vele.

Anyag-tudatos

Lásd el a darabokat és a készletet egy material címkével, és az optimalizáló szétosztja a munkát: minden material csak a saját készletéből vágódik ki. Minden módban; material szerinti összesítés jön vissza.

Élzárás

Nevezz meg élenként egy élzárás-típust (2D), és a válasz típusonként összegzi a folyómétert — darabonként és rendelésenként. Metaadat: egy darabot sosem mozdít el.

Beépített export (SVG · DXF · CSV)

Kérj include:["svg","csv","dxf"] értéket, és a válasz kész fájlként, beágyazva viszi az elrendezést — önálló 2D SVG rajzot, R12/AC1009 DXF-et vagy CSV vágásjegyzéket. Nincs tárolás, nincs második hívás.

Metaadat-átadás

Csatolj egy meta objektumot — az ERP-cikkszámodat, rendelés-sor azonosítót, vevői hivatkozást — bármelyik darab- vagy alapanyag-sorhoz, és szó szerint visszakapod minden elhelyezett darabon és minden táblán/rúdon, így a terv egyeztethető a rendszereddel.

Ingyenes ellenőrzés

A POST /v1/validate/{2d,1d,wood} séma-ellenőrzi ugyanazt a törzset megoldás nélkül — nincs kulcs, nincs kvóta. Ellenőrizd, hogy egy törzset nem utasítunk el, és kapj megvalósíthatósági figyelmeztetéseket, mielőtt elköltesz egy hívást.

Költség vagy hulladék

A minimizeCost a legalacsonyabb végösszeg szerint rangsorol az árazott készletméretek között, keverve a formátumokat; az alapértelmezés az anyagot minimalizálja. Mindkettő ugyanazt a guillotine algoritmust futtatja.

Készlet-prioritás és korlátozott készlet

Jelöld meg az elsőként elfogyasztandó készletet, kezeld a mennyiségeket kemény plafonként a respectStock-kal, és jelöld a kötelezően kivágandó darabokat, amelyek szűkös anyagnál elnyerik a helyet a táblán.

Valódi vágásterv

Nem csak téglalapok: a guillotine vágási sorrend lépésenkénti ütköző-pozíciókkal, a vágásvonalak és a fűrészelések külön, a vágáshossz, és egy panelfűrészen-legyártható jelző.

Panelfűrész-paraméterek

kerf, oldalankénti széllevágás, tolerancia, grain groups, maxCutStages és forgatás-minimalizálás — ugyanazok a beállítások, amelyeket az app is kínál.

Determinisztikus & OpenAPI

Ugyanaz a bemenet mindig ugyanazt a kimenetet adja — cache-eld és hasonlítsd össze. Egy rögzíthető motorverzió és egy OpenAPI 3.1 dokumentum írja le a teljes szerződést.

Darabok CAD-fájlból

Koordináták helyett küldj SVG-t vagy DXF-et: a parts[].source kiolvassa a kontúrt és a lyukait a rajzból, a POST /v1/import/nest pedig előbb szétbontja a több darabot tartalmazó fájlt. Semmi nem tárolódik — a fájl a memóriában dolgozódik fel, és a válasszal együtt megszűnik.

Melyik motor melyik módot szolgálja ki

Az a végpont, amelyre POST-olsz, választja ki a módot; az engine paraméter az algoritmust. Az alapértelmezett heuristic motor a 2D-t, az 1D-t és a fát szolgálja ki; a balanced és az aszinkron max motor csak 2D; a valódi alakú nesting pedig a saját lbf motorján fut. Ugyanaz a motor, mint az appban, HTTP-n keresztül.

Mód · végpontMotor · algoritmus2D lapok/v1/optimize/2d1D lineáris/v1/optimize/1dFa · keresztmetszet/v1/optimize/woodValódi alakú nesting/v1/optimize/nestheuristicalapértelmezett · szinkronbalancedopcionális · csak 2Dmaxaszinkron · csak 2Dlbfnesting · sparrow tervezett1D-n és fán a balanced egyszerűen a heuristic aliasa (a válasz ezt ki is mondja).
  • heuristic — Az alapértelmezés — egy guillotine több-stratégiás packer. A legmagasabb kihozatal, minden elrendezés fűrésszel vágható, és mindig ad vágástervet. A 2D-t, az 1D-t és a fát is kiszolgálja.
  • balanced — Egy opcionális MaxRects szabad-nester a 2D-hez. Sokkal gyorsabb a nagyon nagy munkákon, kicsivel alacsonyabb kihozatalért, de az elrendezései gyakran nem vághatók éltől élig, ezért nem hordoznak vágástervet.
  • max — Egy aszinkron fakeresés a 2D-hez. Sokkal több munkán éri el a bizonyítottan optimálisat, megoldásonként másodpercek–egy perc alatt — beküldöd a munkát, és a GET /v1/jobs/{id} lekérdezésével kapod meg az eredményt. Továbbra is determinisztikus és fűrésszel vágható.
  • lbf — A valódi alakú nesting motor. Szabálytalan poligonokat pakol egymás zsebeibe lézeres, plazmás és vízsugaras vágáshoz; egy nagyobb sűrűségű sparrow build tervben van.

Melyik végpont melyik anyaghoz: sík lapok — rétegelt lemez, MDF, üveg, akril, lemez — a /v1/optimize/2d végpontra; rúd, cső és profil a /v1/optimize/1d végpontra; szerkezeti faanyag (egy 50×150 csak 50×150-ből) a /v1/optimize/wood végpontra; szabálytalan poligonok lézeres, plazmás és vízsugaras vágáshoz a /v1/optimize/nest végpontra.

Egy hívás, egy teljes terv

curl https://api.cutoptim.com/v1/optimize/2d \
  -H "Authorization: Bearer co_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "parts": [
      { "name": "Door",    "w": 600, "h": 400, "qty": 4 },
      { "name": "Shelf",   "w": 800, "h": 300, "qty": 6 }
    ],
    "stock":   [{ "w": 2440, "h": 1220, "price": 42 }],
    "options": { "kerf": 3, "effort": "balanced" },
    "engine":  "heuristic"
  }'

A válasz:

{
  "metrics": { "sheetCount": 1, "yieldPct": 80.62, "placed": 10, "total": 10,
               "cutLines": 10, "sawPasses": 13, "cutLength": 10720, "totalPrice": 42 },
  "sheets":  [ … ],
  "cutPlan": [{ "sheet": 0, "step": 1, "axis": "h", "pos": 400, "length": 2440, "stage": 1 }, … ],
  "guillotineValid": true,
  "engineVersion": "1.0.0+10e0c941",
  "deterministic": true
}

A teljes kérés- és válaszszerkezet, minden beállítás, az összes hibakód és mind a három motor:API-referencia →

Fast vagy sűrű? Válaszd egy beállítással

Az effort beállítás a számítási időt mérlegeli a kihasználással szemben. Íme ez a kompromisszum, egyetlen igényes munkán mérve — minden szám a valódi pakolóból származik.

effort kapcsoló: anyagkihasználás vs számítási időeffort kapcsoló: anyagkihasználás vs számítási idő. fast: 350 tábla · 76.2% · ≈1.9 s. balanced: 330 tábla · 80.8% · ≈4.8 s. max: fenntartva — a sűrűbbhez lassabb keresés kell. A legtöbb (kisebb) munkán a kettő azonos; a különbség csak az ilyen nagy munkákon nyílik meg. A balanced az alapértelmezett, és sosem sűrűbb annál, mint amit a fast el tud érni.effort kapcsoló: anyagkihasználás vs számítási időEgy igényes munka — nagyjából 1550 darab egy 2,07 × 5,6 m-es táblán. Minden szám a valódi pakolón mérve.74%76%78%80%82%84%02 s4 s6 sszámítási idő · gyorsabban →anyagkihasználás · sűrűbben ↑⇄ az effort kapcsoló+4,6 pont kihasználás · −20 tábla−5,7% anyag · ≈2,5× lassabbfast350 tábla · 76.2% · ≈1.9 s★ balanced · alapértelmezett330 tábla · 80.8% · ≈4.8 smaxfenntartvaa sűrűbbhezlassabb kereséskell
A legtöbb (kisebb) munkán a kettő azonos; a különbség csak az ilyen nagy munkákon nyílik meg. A balanced az alapértelmezett, és sosem sűrűbb annál, mint amit a fast el tud érni.

És amúgy is gyors: még a legnagyobb gyártási munkák — 2000 darab és több — is másodpercek alatt megoldódnak az alapértelmezett motoron, kényelmesen az API időkeretén belül.

Árazás

€49/hó
10,000 kérés / hó — kemény plafon, nincs túlhasználat, nincs váratlan számla
14 napos próbaidő · EUR-ban számlázva · a plafon elérése után a hívások 402-t adnak, amíg át nem fordul a hónap

Nagyobb volumen. A havi 10,000 kérés a standard csomag, nem annak a plafonja, amit ki tudunk szolgálni. Ha többre van szükséged — nagyobb volumenre, külön kulcsra a stagingre és az éles rendszerre, vagy egyedi megállapodásra —, írd meg a számaidat, és egyedileg árazzuk. Írd meg a volumenedet →

A szokásos CutOptim csomagok (Ingyenes / Pro / Műhely) nem kapcsolódnak az API-hoz — az appban futó optimalizáló továbbra is a részük. Az app árai →

Solutions by industry

The same engine, positioned for the way one trade cuts. Each page shows the endpoint, a request and a response, and the fields that matter for that material.

Letölthető anyag
Engine API one-pager

The why, what and how of the CutOptim Engine API on two pages — the three modes, a request and response, determinism and pricing. Print-ready, with a QR back to this page.

PDF2 pagesFree
PDF letöltése

Gyakran ismételt kérdések

Van a CutOptimnak API-ja?
Igen — a CutOptim Engine API ugyanazt a vágómotort teszi elérhetővé HTTP-n, ERP, árajánlat-eszköz vagy gépi szoftver számára, mindhárom módban, amit az app tud: 2D tábla, 1D lineáris, és fa keresztmetszet-illesztéssel.
Van API lézer-, plazma- vagy vízsugárvágáshoz?
Igen — a szabálytalan poligonok true-shape neszelése az Engine API negyedik módja, a POST /v1/optimize/nest. Minden alkatrészt poligon-kontúrként küldesz (opcionális lyukakkal) a készlet-lapokkal együtt; a motor egymás konkáv zsebeibe illeszti a darabokat, és visszaadja minden példány elhelyezését, így egy lézer-, plazma- vagy vízsugár-munka sokkal sűrűbben pakol, mint a befoglaló téglalap — egy reprezentatív 272-darabos munkán 6 lap, ahol ugyanaz befoglaló téglalappal 9 lapot igényel. Lap-szintű kizárt zónák (egy hiba, egy leszorító) és folytonos forgatás jár hozzá. Ma az Engine API-n él; maga az app továbbra is téglalapokat vág.
Determinisztikus az Engine API?
Igen. Ugyanaz a bemenet ugyanazt az eredményt adja, így a válaszok cache-elhetők és tesztelhetők, a motor verziója pedig rögzíthető a reprodukálható eredményekhez.
Mit tartalmaz az optimalizálási válasz?
A teljes elrendezést, a guillotine szabástervet lépésenkénti megállási pozíciókkal, és a metrikákat (táblaszám, kihozatal, vágásvonalak, fűrészmenetek, vágott hossz). A 2D végpont az élzárás méterét is visszaadja típusonként, és minden végpont elfogad anyag-címkét, és anyagonkénti összesítést ad. Kérheted az elrendezést inline SVG, DXF vagy CSV formában is, és csatolhatsz egy meta objektumot az alkatrészekhez és a készlethez, amelyet szó szerint visszakapsz.
Ad az API rajzot, nem csak koordinátákat?
Igen. Adj hozzá include:["svg","csv","dxf"] elemet egy optimalizálási kéréshez, és a válasz kész fájlként, inline hordozza az elrendezést: önálló 2D SVG rajz, R12/AC1009 DXF vagy CSV szabásjegyzék. Nincs tárolás és nincs második hívás. Az SVG csak 2D; egy 1D vagy fa kérés helyette figyelmeztetést ad vissza.
Csatolhatok saját azonosítókat az alkatrészekhez, és visszaolvashatom őket?
Igen. Bármely alkatrész- vagy készletsor hordozhat egy meta objektumot — az ERP cikkszámod, rendelési sor azonosítód vagy ügyfél-hivatkozásod —, és szó szerint visszatér minden elhelyezett darabon és minden táblán vagy rúdon, így a szabásterv egyezik a saját rendszereddel. Az elrendezést soha nem befolyásolja.
Ellenőrizhetek egy kérést hívás elköltése nélkül?
Igen. A POST /v1/validate/2d, /1d vagy /wood ugyanazt a törzset séma-validálja, amelyet a megfelelő optimalizálási végpont fogad, megoldás nélkül — kulcs és kvóta nélkül. Egy 400 megnevezi a pontos hibás mezőt, és megvalósíthatósági figyelmeztetéseket kapsz (egy alkatrész, amely egyetlen készletbe sem fér) mielőtt valódi hívást költenél.
Van SDK, webhook vagy aszinkron feldolgozás?
SDK és webhook nincs — de van OpenAPI 3.1 specifikáció, amelyre ráállíthatsz egy kódgenerátort tipizált klienshez. A legtöbb optimalizálási hívás egyszerű szinkron HTTP, amely közvetlenül visszaadja a kész tervet. Az egyetlen kivétel az aszinkron max motor (csak 2D): a POST /v1/optimize/2d engine:"max"-szal 202 Accepted választ ad egy jobId-vel, és a GET /v1/jobs/{id}-t pollozod, amíg elkészül — akkor, ha a bizonyított optimum elérése megér másodperc–egy perc megoldási időt.
Milyen kérés-korlátok vannak?
Hívásonként legfeljebb 2 000 alkatrész, 50 készletsor és 1 MB kérés-törzs. A legnagyobb gyártási feladatok is egyszámjegyű másodperc alatt lefutnak, bőven az időkereten belül.
API-kulcsok kezelése