Přejít na hlavní obsah
PRO VÝVOJÁŘE

CutOptim Engine API

Deterministické jádro pro optimalizaci řezání, volatelné přes HTTP: stejný požadavek vrací vždy stejný plán řezání — takže ho můžete auditovat, cenit podle něj, urovnat s ním spor a znovu spustit loňskou zakázku a dostat loňský plán. Je to stejné jádro, které pohání CutOptim, napříč třemi obdélníkovými režimy (2D desky, 1D lineární materiál a dřevo s přiřazením průřezu), plus nesting podle skutečného tvaru pro nepravidelné polygonální díly — POST /v1/optimize/nest, pro řezání laserem, plazmou a vodním paprskem. Pošlete díly a materiál a zpátky dostanete celé rozvržení, plán řezání i využití — připravené k zapojení do ERP, kalkulačního nástroje nebo vlastního softwaru stroje.

Zobrazit celý benchmark → · Naměřeno, ne tvrzeno

Proč na tom stavět

DETERMINISTICKÉ

Stejný vstup vrací vždy stejný výstup — žádná náhoda, žádné hodiny v algoritmu. Výsledky můžete cachovat a v testech je porovnávat.

SKUTEČNÝ PLÁN ŘEZÁNÍ

Nejen obdélníky: gilotinová sekvence řezů, řezy versus průjezdy pily, délka řezu a příznak, který říká, zda je plán vyrobitelný na formátovací pile.

MYSLÍ NA FORMÁTOVACÍ PILU

Šířka řezu (kerf), ořez po jednotlivých hranách, tolerance, režim nákladů, skupiny vzoru dřeva, limit fází řezání, minimalizace otáčení — stejné volby, jaké nabízí aplikace.

Co API dělá

Čtyři režimy řezání

Po jednom volání pro 2D desky, 1D lineární materiál, dřevo s párováním průřezu a nesting nepravidelných polygonů podle skutečného tvaru — POST /v1/optimize/2d, /1d, /wood a /nest.

Nesting podle skutečného tvaru

POST /v1/optimize/nest rozmisťuje libovolné polygony (i s otvory) na pevné desky a zaklesává díly do vzájemných konkávních kapes — 6 desek tam, kde tytéž díly podle opsaného obdélníku potřebují 9. Pro řezání laserem, plazmou a vodním paprskem. Součástí jsou i vyloučené zóny po jednotlivých deskách (vada, upínka).

Zohledňuje materiál

Označte díly a zásobu štítkem material a optimalizátor rozdělí úlohu: každý material se řeže jen z vlastní zásoby. V každém režimu; vrací se souhrn podle material.

Olepování hran

Pojmenujte typ hrany pro každou hranu (2D) a odpověď sečte běžné metry podle typu — na díl a na zakázku. Metadata: díl nikdy neposune.

Inline export (SVG · DXF · CSV)

Požádejte o include:["svg","csv","dxf"] a odpověď ponese rozvržení jako hotový soubor, přímo v ní — samostatný 2D výkres SVG, DXF ve formátu R12/AC1009 nebo seznam řezů v CSV. Žádné úložiště, žádné druhé volání.

Průchod metadat

Připojte objekt meta — číslo artiklu z vašeho ERP, id řádku zakázky, referenci zákazníka — k jakémukoli dílu nebo řádku materiálu a vrátí se doslovně u každého umístěného kusu i u každé desky/tyče, takže plán sedí s vaším systémem.

Validace zdarma

POST /v1/validate/{2d,1d,wood} zvaliduje stejné tělo vůči schématu bez výpočtu — bez klíče, bez kvóty. Ověřte, že požadavek nebude odmítnut, a získejte upozornění na proveditelnost dřív, než utratíte volání.

Náklady, nebo odpad

minimizeCost řadí podle nejnižší celkové ceny napříč naceněnými velikostmi zásoby a mísí formáty; výchozí nastavení minimalizuje materiál. Oba spouštějí stejný guillotine algoritmus.

Priorita zásoby a omezená zásoba

Označte zásobu, která se spotřebuje jako první, považujte množství za tvrdý limit pomocí respectStock a označte díly nutné k řezání, které při nedostatku materiálu získají místo na desce.

Skutečný plán řezání

Nejen obdélníky: gilotinová sekvence řezů s pozicemi dorazu pro každý krok, řezy versus průjezdy pily, délka řezu a příznak vyrobitelnosti na formátovací pile.

Parametry formátovací pily

kerf, ořez po jednotlivých hranách, tolerance, grain groups, maxCutStages a minimalizace otáčení — stejné volby, jaké nabízí aplikace.

Deterministické & OpenAPI

Stejný vstup vrací vždy stejný výstup — cachujte jej a porovnávejte. Připnutelná verze enginu a dokument OpenAPI 3.1 popisují celý kontrakt.

Díly z CAD souborů

Pošlete SVG nebo DXF místo souřadnic: parts[].source načte obrys a jeho otvory z výkresu a POST /v1/import/nest nejprve rozdělí soubor s více díly. Nic se neukládá — soubor se zpracuje v paměti a zmizí spolu s odpovědí.

Který engine obsluhuje který režim

Endpoint, na který posíláte POST, určuje režim; parametr engine určuje algoritmus. Výchozí engine heuristic obsluhuje 2D, 1D i dřevo; balanced a asynchronní engine max jsou pouze pro 2D; a nesting podle skutečného tvaru běží na vlastním enginu lbf. Stejný engine jako v aplikaci, přes HTTP.

Režim · endpointEngine · algoritmus2D desky/v1/optimize/2d1D lineární/v1/optimize/1dDřevo · průřez/v1/optimize/woodNesting podle skutečného tvaru/v1/optimize/nestheuristicvýchozí · synchronníbalancedvolitelný · pouze 2Dmaxasynchronní · pouze 2Dlbfnesting · sparrow v plánuU 1D a dřeva je balanced pouze aliasem pro heuristic (odpověď to uvádí).
  • heuristic — Výchozí — gilotinový packer s více strategiemi. Nejvyšší výtěžnost, každé rozvržení je řezatelné na pile a vždy vrací plán řezání. Obsluhuje 2D, 1D i dřevo.
  • balanced — Volitelný MaxRects free-nester pro 2D. U velmi velkých úloh výrazně rychlejší za mírně nižší výtěžnost, jeho rozvržení však často nelze rozřezat od kraje ke kraji, takže neobsahují plán řezání.
  • max — Asynchronní stromové prohledávání pro 2D. Dosahuje prokazatelného optima u mnohem více úloh, za několik sekund až minutu na výpočet — úlohu odešlete a výsledek získáte dotazováním GET /v1/jobs/{id}. Stále deterministické a řezatelné na pile.
  • lbf — Engine pro nesting podle skutečného tvaru. Zaklesává nepravidelné polygony do vzájemných kapes pro laser, plazmu a vodní paprsek; plánuje se build sparrow s vyšší hustotou.

Který endpoint pro který materiál: ploché desky — překližka, MDF, sklo, akrylát, plech — jdou na /v1/optimize/2d; tyče, trubky, roury a profily na /v1/optimize/1d; konstrukční dřevo (50×150 jen z 50×150) na /v1/optimize/wood; nepravidelné polygony pro laser, plazmu a vodní paprsek na /v1/optimize/nest.

Jedno volání, celý plán

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"
  }'

Vrátí se:

{
  "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
}

Kompletní podoba požadavku a odpovědi, všechny volby, všechny chybové kódy a všechna tři jádra:Reference API →

Fast, nebo hustě? Vyberte jednou volbou

Volba effort vyvažuje čas výpočtu proti využití. Tady je ten kompromis, změřený na jedné náročné zakázce — každé číslo pochází ze skutečného packeru.

Přepínač effort: využití materiálu vs čas výpočtuPřepínač effort: využití materiálu vs čas výpočtu. fast: 350 desky · 76.2% · ≈1.9 s. balanced: 330 desky · 80.8% · ≈4.8 s. max: rezervováno — hustěji chce pomalejší hledání. U většiny (menších) zakázek jsou oba totožné; rozdíl se objeví jen u velkých zakázek, jako je tato. balanced je výchozí a nikdy není hustší, než dokáže fast.Přepínač effort: využití materiálu vs čas výpočtuJedna náročná zakázka — zhruba 1 550 dílů na desce 2,07 × 5,6 m. Každé číslo změřené na skutečném packeru.74%76%78%80%82%84%02 s4 s6 sčas výpočtu · rychleji →využití materiálu · hustěji ↑⇄ přepínač effort+4,6 p.b. využití · −20 desek−5,7 % materiálu · ≈2,5× pomalejšífast350 desky · 76.2% · ≈1.9 s★ balanced · výchozí330 desky · 80.8% · ≈4.8 smaxrezervovánohustěji chcepomalejší hledání
U většiny (menších) zakázek jsou oba totožné; rozdíl se objeví jen u velkých zakázek, jako je tato. balanced je výchozí a nikdy není hustší, než dokáže fast.

A tak jako tak je to rychlé: i největší výrobní zakázky — 2000 dílů a více — se na výchozím enginu vyřeší v řádu sekund, pohodlně v časovém rozpočtu API.

Ceník

€49/měsíc
10,000 požadavků / měsíc — pevný strop, žádné přeplatky, žádná nečekaná faktura
14denní zkušební období · fakturace v EUR · po vyčerpání stropu vracejí volání 402, dokud nezačne nový měsíc

Větší objemy. 10,000 požadavků za měsíc je standardní tarif, ne strop toho, co dokážeme provozovat. Pokud potřebujete více — vyšší objem, oddělené klíče pro staging a produkci nebo individuální řešení — napište nám svá čísla a naceníme to individuálně. Napište nám svůj objem →

Běžné tarify CutOptim (Zdarma / Pro / Dílna) s API nijak nesouvisejí — optimalizátor v aplikaci v nich zůstává zahrnutý. Ceník aplikace →

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.

Materiál ke stažení
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
Stáhnout PDF

Často kladené otázky

Má CutOptim API?
Ano — API CutOptim Engine zpřístupňuje stejný řezací engine přes HTTP, pro ERP, cenotvorný nástroj nebo strojní software, ve všech třech režimech aplikace: 2D desky, 1D lineární a dřevo s párováním průřezu.
Existuje API pro laserové, plazmové nebo vodní řezání?
Ano — true-shape vnořování nepravidelných polygonů je čtvrtý režim API Engine, POST /v1/optimize/nest. Každý díl posíláte jako polygonový obrys (s volitelnými otvory) spolu se skladovými deskami; engine zaklíní díly do konkávních kapes ostatních a vrátí umístění každé kopie, takže laserová, plazmová nebo vodní zakázka se skládá mnohem těsněji než ohraničující obdélník — na reprezentativní zakázce 272 dílů 6 desek tam, kde stejné díly podle ohraničujícího obdélníku potřebují 9. Vylučovací zóny pro každou desku (vada, upínka) a plynulé otáčení jsou součástí. Funguje dnes přes API Engine; samotná aplikace stále řeže obdélníky.
Je Engine API deterministické?
Ano. Stejný vstup vrací stejný výstup, takže odpovědi jsou cacheovatelné a testovatelné, a verzi enginu lze připnout pro reprodukovatelné výsledky.
Co obsahuje odpověď optimalizace?
Kompletní rozvržení, gilotinový plán řezání s pozicemi zastavení pro každý krok a metriky (počet desek, výtěžnost, řezné linie, průchody pily, řezaná délka). 2D endpoint vrací také metry hranění podle typu a každý endpoint přijímá materiálový tag a vrací souhrn podle materiálu. Rozvržení si můžete vyžádat také jako inline SVG, DXF nebo CSV a k dílům a skladu připojit objekt meta, který se vrátí doslovně.
Umí API poskytnout výkres, ne jen souřadnice?
Ano. Přidejte include:["svg","csv","dxf"] do požadavku na optimalizaci a odpověď nese rozvržení jako hotový soubor, inline: samostatný 2D SVG výkres, DXF R12/AC1009 nebo CSV seznam řezů. Žádné ukládání a žádné druhé volání. SVG je pouze 2D; požadavek 1D nebo dřevo místo toho vrátí varování.
Mohu k dílům připojit vlastní ID a přečíst je zpět?
Ano. Každý řádek dílu nebo skladu může nést objekt meta — vaše ERP číslo artiklu, id řádku objednávky nebo referenci zákazníka —, a vrací se doslovně u každého umístěného dílu a každé desky nebo tyče, takže se plán řezání sesouhlasí s vaším systémem. Nikdy neovlivňuje rozvržení.
Mohu ověřit požadavek, aniž bych spotřeboval volání?
Ano. POST /v1/validate/2d, /1d nebo /wood validuje podle schématu stejné tělo, jaké přijímá odpovídající optimalizační endpoint, bez řešení — bez klíče a bez kvóty. 400 pojmenuje přesné chybné pole a získáte varování o proveditelnosti (díl, který se nevejde do žádného skladu), než spotřebujete skutečné volání.
Existují SDK, webhooky nebo asynchronní úlohy?
Žádné SDK a žádné webhooky — ale je k dispozici specifikace OpenAPI 3.1, na kterou lze nasměrovat generátor kódu pro typovaného klienta. Většina volání optimalizace je prosté synchronní HTTP, které vrací hotový plán přímo. Jedinou výjimkou je asynchronní engine max (pouze 2D): POST /v1/optimize/2d s engine:"max" vrací 202 Accepted s jobId a vy dotazujete GET /v1/jobs/{id}, dokud neskončí — pro případ, kdy dosažení prokázaného optima stojí za jednotky sekund až minutu výpočtu.
Jaké jsou limity požadavku?
Až 2 000 dílů, 50 skladových řádků a 1 MB těla požadavku na volání. I ty největší výrobní úlohy se vyřeší v jednotkách sekund, pohodlně v časovém rozpočtu.
Správa API klíčů