Scatole diverse, una sola promessa da verificare
Un responsabile di produzione deve spedire scatole diverse sullo stesso pallet. Un video mostra un robot velocissimo, ma la domanda utile è un’altra: riuscirà a completare il nostro lavoro entro il turno, con tutte le prese, le attese e i cambi necessari? Questo articolo insegna a mettere alla prova quella promessa prima di confrontare preventivi. Il risultato sarà una soglia comprensibile: quanto può durare mediamente un ciclo senza perdere la produzione richiesta.
L’analisi usa una fabbrica interamente immaginaria, tre tipi di scatola e aritmetica eseguita con Python. Non abbiamo provato un robot, una pinza o un sistema di visione. Tempi, disponibilità e costi sono ipotesi didattiche, non misure o prezzi. Mostreremo che un progetto può sembrare conveniente sul foglio dei costi e risultare insufficiente per un solo secondo aggiunto a ogni ciclo. È una conseguenza del modello dichiarato, non una prestazione industriale osservata.
Che cosa deve rappresentare un ciclo
Palletizzare significa disporre colli su una piattaforma per la movimentazione. La pinza è l’utensile che trattiene il collo; la ricetta definisce una configurazione di lavoro. Per confrontare due proposte fissiamo prima lo stesso confine: un ciclo comincia quando la macchina è pronta a prelevare e termina quando torna pronta per il collo successivo. Se una proposta conta soltanto il tragitto di andata, confrontarla con un ciclo completo favorisce artificialmente quella proposta.
Nel nostro conto il tempo di ciclo include presa, trasferimento, deposito e ritorno. Le attese ricorrenti vanno incluse qui oppure sottratte dal tempo disponibile, mai in entrambi. I cambi di formato sono invece una voce separata. Non stiamo progettando le traiettorie: stiamo costruendo un bilancio di tempo che potrà essere riempito con misure reali. Un bilancio coerente non rende realistica un’ipotesi sbagliata; rende visibile quale ipotesi bisogna misurare.
Prima ancora dei secondi serve una condizione logica: ogni scatola prevista deve poter essere movimentata nella configurazione proposta. Massa, ingombri, superficie e posizione cambiano la presa. Universal Robots, nella sezione Maximum Payload consultata, distingue massa dell’utensile e del pezzo, baricentro e inerzia: il solo numero di chilogrammi non descrive l’applicazione. Non prendiamo da quella pagina limiti da applicare a un robot immaginario.
Perché la media deve seguire le scatole
Immaginiamo che su dieci scatole cinque siano A, tre B e due C. I cicli completi ipotizzati durano rispettivamente 6, 10 e 14 secondi. La media aritmetica dei tre numeri è 10 secondi, ma risponderebbe a un altro ordine: quantità uguali dei tre tipi. Per il nostro ordine contiamo prima il tempo di tutte e dieci le scatole: 30 più 30 più 28, cioè 88 secondi. Dividere per dieci dà 8,8 secondi per scatola.
La formula seguente risponde precisamente a «quanto tempo richiede mediamente una scatola di questo ordine?». Indichiamo con pᵢ la frazione di scatole del tipo i, senza unità, e con tᵢ il suo tempo completo in secondi per scatola. Le frazioni devono sommare a uno. Non sono probabilità stimate da un esperimento: qui sono una composizione fissata dall’autore per rendere il calcolo verificabile.
In parole, ogni tempo pesa in proporzione a quante volte serve davvero. Su 2400 scatole la composizione esatta è 1200 A, 720 B e 480 C: il lavoro richiede 21120 secondi. Il calcolo non dipende dall’ordine delle scatole soltanto perché abbiamo ipotizzato tempi indipendenti dalla sequenza. Se il passaggio A→C richiede un cambio utensile o una modifica di ricetta, quel costo di transizione deve entrare nel modello: la media da sola non basta.
Otto ore di turno non sono otto ore di lavoro utile
Fissiamo un turno H di 28800 secondi, cioè otto ore. Assumiamo che una frazione a=0,85 sia disponibile prima dei cambi di formato, e sottraiamo separatamente S=1200 secondi per quei cambi. Il tempo produttivo T diventa 23280 secondi, pari a sei ore e ventotto minuti. La disponibilità dell’85% non è stata osservata: è un ingresso da sostituire con dati di reparto. La definizione «prima dei cambi» evita di sottrarre lo stesso fermo due volte.
Dividere il tempo disponibile per il tempo medio dà una capacità continua equivalente di circa 2645,45 scatole. Non esistono frazioni di scatola spedita: questo numero non è un conteggio simulato di cicli completati. Il conteggio intero dipende dalla sequenza finale e dagli eventuali vincoli del pallet. Per verificare il nostro ordine di 2400 colli non occorre arrotondare quella capacità: confrontiamo direttamente i 21120 secondi necessari con i 23280 disponibili, lasciando 2160 secondi di margine nel modello.
È un bilancio necessario, non sufficiente. Se tutte le scatole arrivano negli ultimi venti minuti, la stessa quantità giornaliera non è lavorabile nello stesso modo. Un turno può avere capacità totale e perdere comunque una finestra di spedizione. Qui supponiamo disponibilità regolare dei colli e nessun vincolo intermedio di consegna. Per un ordine reale bisogna conservare gli orari di arrivo e le scadenze, non soltanto il totale giornaliero: servono una simulazione temporale o un piano verificato, non un altro arrotondamento.
Il secondo che cambia la decisione
Adesso immaginiamo che la conferma di presa e il rilascio richiedano complessivamente un secondo in più per ogni scatola, oltre ai tempi già inclusi. Non sosteniamo che accada su una particolare pinza. È un’analisi di sensibilità: cambiamo una sola ipotesi, lasciando tutte le altre fisse, per capire quanto sia fragile la conclusione. Il ciclo medio sale da 8,8 a 9,8 secondi e il lavoro richiesto sale a 23520 secondi: ne mancano 240 per finire entro il turno.
Per evitare di discutere se quel secondo sembri grande o piccolo, ricaviamo la soglia direttamente dalla domanda. N è il numero richiesto di scatole, qui 2400. Se N moltiplicato per il ciclo medio non deve superare T, dividendo per N positivo otteniamo il ciclo massimo compatibile. Nel nostro esempio vale 9,7 secondi per scatola. Il margine sul ciclo iniziale è soltanto 0,9 secondi. Questa è la quantità da discutere con chi propone l’impianto, insieme alle condizioni in cui dovrebbe valere.
| Secondi extra/ciclo | Ciclo medio (s) | Capacità continua (scatole) | Compatibile (1/0) |
|---|---|---|---|
| 0 | 8.8 | 2645.45 | 1 |
| 1 | 9.8 | 2375.51 | 0 |
| 2 | 10.8 | 2155.56 | 0 |
Nella figura la linea della domanda resta a 2400 scatole; le barre rappresentano capacità continue equivalenti, non osservazioni di una macchina. La prima barra supera la linea, le altre due no. Il passaggio decisivo è il confronto con la domanda, non la bellezza della barra più alta. La tabella usa 1 per «compatibile con il solo bilancio di tempo» e 0 per «incompatibile». Nessuno dei due valori certifica la movimentazione fisica o la sicurezza.
Una media cambia quando cambia l’ordine
La composizione 50/30/20 non è una proprietà del robot: appartiene al lavoro richiesto. Se tutte le scatole fossero C, il ciclo ipotetico diventerebbe 14 secondi e la capacità continua scenderebbe a circa 1662,86 scatole nello stesso tempo produttivo. Non serve inventare un guasto per perdere il vantaggio: basta un ordine diverso. Per questo una prova sul solo formato facile non convalida una promessa su scatole miste. Il dato importante è la copertura delle combinazioni richieste.
In un modello più completo si scrive il tempo totale come somma dei cicli delle singole scatole più somma dei cambi tra tipi consecutivi. Se un cambio dipende dalla direzione, A→B e B→A vanno distinti. Raggruppare i formati può ridurre i cambi, ma può violare l’ordine di spedizione o il disegno del pallet. Il problema diventa una pianificazione con vincoli. Non abbiamo risolto quella pianificazione e non attribuiamo al nostro piccolo codice un ottimizzatore che non contiene.
Quando il conto economico dice sì e il turno dice no
Solo dopo il vincolo di capacità introduciamo un confronto economico didattico. Supponiamo un costo mensile fisso F di 4500 euro per la soluzione robotizzata, un costo variabile v di 0,03 euro per scatola e un costo manuale evitabile m di 0,18 euro per scatola. Sono tutti numeri inventati; F non è il prezzo di un braccio e m non è automaticamente il salario risparmiato. Il confine deve comprendere ciò che cambia realmente tra alternative comparabili.
La domanda della formula è: con questi soli costi, a quale volume mensile i due conti coincidono? Per n scatole, il costo robotizzato è F+vn e quello manuale mn. Eguagliandoli e raccogliendo n si ottiene F/(m−v), purché m sia maggiore di v. Qui il pareggio è 30000 scatole al mese. Se m fosse minore o uguale a v e F positivo, aumentare il volume non recupererebbe il costo fisso in questo modello. La condizione matematica evita una falsa promessa di scala.
Su ventidue turni identici ipotetici la domanda è 52800 scatole e il confronto restituisce 6084 contro 9504 euro al mese. La differenza aritmetica è 3420 euro, non un risparmio dimostrato. Con il secondo aggiuntivo la stessa domanda mensile resta sopra il pareggio, ma ogni turno manca di capacità. Usare comunque il costo unitario per tutte le scatole equivale ad acquistare capacità che il modello non concede. Servirebbero un’altra organizzazione, più tempo o un progetto diverso, con costi da rifare.
Un preventivo reale dovrebbe separare acquisto e finanziamento, integrazione, utensili, manutenzione, energia, assistenza e lavoro residuo. Non si somma l’intero acquisto alla quota di ammortamento dello stesso periodo. Il personale può essere riallocato invece che eliminato: allora cambia il valore del lavoro, non necessariamente l’esborso. Non abbiamo dati per quantificarlo. Anche il prodotto danneggiato o un pallet rifatto consuma capacità e denaro: lasciarlo fuori da entrambe le colonne è un confine esplicito, non la prova che sia trascurabile.
Confrontare alternative che risolvono lo stesso problema
Un’alternativa senza AI potrebbe usare scatole presentate in posizioni fisse, identificazione da codice e ricette deterministiche. Un’altra può migliorare il confezionamento o la disposizione della postazione manuale. La visione con AI diventa un’ipotesi interessante quando resta una variabilità che quelle soluzioni non gestiscono adeguatamente; deve essere valutata sul risultato finale, non soltanto sul riconoscimento delle immagini. Il nostro bilancio non dimostra che l’AI sia necessaria: aiuta a fissare quanto tempo può consumare qualunque soluzione.
Anche «robot più grande» non è una risposta automatica. Un utensile diverso può cambiare ingombri e tempi; un layout diverso può ridurre un trasferimento e complicare il rifornimento. Nella guida Robotiq consultata, lo spazio necessario all’apertura delle ganasce e i tempi effettivi di presa e rilascio appartengono alla valutazione del ciclo. Qui non adottiamo le sue impostazioni come istruzioni universali: il confronto deve restare specifico alla configurazione offerta e alle verifiche dell’integratore.
Che cosa verificare con una prova reale
Per passare dal calcolo alla decisione proponiamo, senza affermare di averlo eseguito, un protocollo: registrare per ogni scatola tipo, orari di inizio e fine, posizione nel pallet, esito e motivo di eventuale intervento. Conservare separatamente fermi, cambi e attese con definizioni che escludano sovrapposizioni. Raccogliere l’intero ordine rappresentativo, comprese le condizioni meno favorevoli concordate. Misurare soltanto dieci cicli riusciti e scartare tutti gli altri non permetterebbe di stimare il lavoro richiesto.
La media serve al carico totale; i tempi lunghi e l’ordine degli eventi servono alle scadenze. Riportare entrambi permette di capire se una proposta ha poco margine oppure se dipende da una distribuzione favorevole. Il nostro esempio non produce intervalli di confidenza perché non contiene campioni casuali misurati. Se si raccoglieranno più turni reali, andranno analizzati anche variazione del mix e dipendenza tra eventi. Inventare un intervallo statistico sui numeri scelti dall’autore aggiungerebbe precisione apparente, non evidenza.
Risposta finale e codice riproducibile
Per il nostro ordine immaginario la domanda iniziale ha una risposta precisa e limitata: il bilancio di tempo ammette 2400 scatole soltanto se il ciclo medio non supera 9,7 secondi nelle condizioni fissate. L’ipotesi 8,8 passa quel controllo; 9,8 lo fallisce anche se il pareggio economico sembra favorevole. Questo consente di chiedere una verifica mirata prima dell’investimento, non di approvare un impianto. Presa, stabilità del pallet, dinamica, collisioni, protezioni e conformità restano fuori dal modello e richiedono verifiche proprie.
EL-AI considera la robotica una direzione da esplorare: questo articolo non documenta un prodotto, una prova o un’installazione dell’azienda. Il codice seguente riproduce esclusivamente l’aritmetica didattica. Decimal conserva gli ingressi decimali dichiarati; le asserzioni controllano media, tempo utile, soglia e cambio di esito. La complessità cresce linearmente con il numero dei tipi per la media e con il numero degli scenari per la sensibilità; non comprende alcuna ricerca di traiettoria. I risultati esportati distinguono esplicitamente ipotesi e misure assenti.
Universal Robots — Maximum Payload, SW10.8, full section; accessed 30 October 2026.
"""Invented workload arithmetic, not robot dynamics or hardware measurements."""
import json,sys
from decimal import Decimal as D
from pathlib import Path
# Each cycle includes assumed grip, travel, release and return, in seconds.
cycles={"A":D("6"),"B":D("10"),"C":D("14")}
weights={"A":D("0.5"),"B":D("0.3"),"C":D("0.2")}
assert sum(weights.values())==1
mean=sum(weights[k]*cycles[k] for k in cycles)
horizon=D("28800") # 8 hours
availability=D("0.85") # assumed fraction of planned time available for work
changeovers=D("1200") # excluded from available work time, once
productive=horizon*availability-changeovers
assert productive>0
capacity=productive/mean
required=D("2400")
max_cycle=productive/required
# Consequence of an extra second of grip/release on EVERY box.
sensitivity=[dict(extraSeconds=str(e),meanCycleSeconds=str(mean+e),capacityBoxes=str(productive/(mean+e)),meetsDailyDemand=productive/(mean+e)>=required) for e in [D(0),D(1),D(2)]]
assert mean==D("8.8") and productive==D("23280") and max_cycle==D("9.7")
assert sensitivity[0]['meetsDailyDemand'] and not sensitivity[1]['meetsDailyDemand']
# Monthly comparison on the SAME demand. Prices invented, not a vendor quote.
fixed=D("4500"); manual=D("0.18");variable=D("0.03")
threshold=fixed/(manual-variable)
monthlyDemand=required*D(22)
assert threshold==30000 and monthlyDemand==52800
assert required*mean==21120 and productive-required*mean==2160
assert required*(mean+1)-productive==240
assert (manual*monthlyDemand)-(fixed+variable*monthlyDemand)==3420
allC=productive/D('14')
result=dict(allCContinuousCapacity=str(allC),python=sys.version.split()[0],scope="Synthetic deterministic arithmetic only; no robot, gripper, simulation of trajectories, safety validation, human timing, measured uptime, vendor quote or measured saving",cycleSeconds={k:str(v) for k,v in cycles.items()},mix={k:str(v) for k,v in weights.items()},meanCycleSeconds=str(mean),shiftSeconds=str(horizon),availabilityAssumed=str(availability),changeoverSeconds=str(changeovers),productiveSeconds=str(productive),requiredDailyBoxes=str(required),maxMeanCycleSeconds=str(max_cycle),sensitivity=sensitivity,economics=dict(fixedEuroPerMonth=str(fixed),manualEuroPerBox=str(manual),robotVariableEuroPerBox=str(variable),continuousBreakEvenBoxesPerMonth=str(threshold),demandBoxesPerMonth=str(monthlyDemand),robotEuroPerMonth=str(fixed+variable*monthlyDemand),manualEuroPerMonth=str(manual*monthlyDemand),warning="Economic threshold is not sufficient: extra one-second cycle violates daily capacity. Manual unit cost must mean actually avoidable cost, not wage automatically saved. Static screening is separate and does not establish any feasible robot."))
Path(__file__).with_name("results.json").write_text(json.dumps(result,indent=2),encoding="utf8")
print(json.dumps(result))
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 30 ottobre 2026.