Ad esempio avevo visto (non usato personalmente) dei monitor touch basati su MODBUS: erano configurabili sul come mappare i diversi oggetti e icone.
L'uscita era TTL, quindi per interfacciarli, almeno in teoria serviva solo passare a RS485 nello stesso modo in cui fai già per il microcontrollore, e perdere un po' di tempo a confiurare l'interfaccia (caricare icone, definire stati ecc)
Con un protocollo proprietario non sarebbe stato possibile.
MODBUS NON è la risposta a tutte le esigenze. E' la risposta a una domanda del tipo "come faccio ad avere una comunicazione decente tra due oggetti senza perderci secoli a programmare?" Non sempre è quella la domanda che uno si fa... Sarebbe bello se ci fosse un protocollo simile ma più evoluto, supportato da tanti produttori, ma non c'è (o se c'è non lo conosco).
I protocolli proprietari non sono in sé il male assoluto (li ho usati anche io in alcuni casi!) ma hanno 2 prerequisiti.
1 non avere né ora né in futuro oggetti di terze parti connesse (o nel caso, saper scrivere il codice che possa fare da interfaccia)
2 essere certo che sia affidabile, questo è il punto dolente.
Chiunque sa prendere il serial out, trasferire su RS485 e riprendere il dato al contrario dall'altro micro.
Da una parte mandare in uscita "ACCENDI001" e "SPEGNI001" e dall'altra parte fare un semplice controllo che la stringa in arrivo sia una oppure l'altra e decide se attivare o meno un relé
Il problema (per assurdo) è proprio che una cosa cosa così funziona al primo colpo! Uno si illude che sia cosa semplice.
Però poi si va nel mondo reale e le cose funzionano bene il 98% del tempo, poi di tanto in tanto vedi il relé che si attiva senza ragioni, o ritardi anomali da quando premi il pulsante da una parte e si eccita il relé dall'altra
Un protocollo di comunicazione deve saper gestire gli errori di comunicazione. Ad esempio con un checksum.
Se dall'altra parte non hai un checksum identico, non eseguire il comando.
Però così perdi il comando...
Allora aggiungi il comando acknowledge indietro per dire ("ok ricevuto" piuttosto che "ritrasmetti")
Ma anche il comando all'indietro deve arrivare privo di errori. Cosa fa il master se non riceve acknowledge?
E se lo riceve come "ritrasmetti", deve davvero ritrasmettere? Eh sì perché se la comuncazione è un continuo rimpallarsi di "non ho capito, ritrasmetti" stai occupando tutta la banda in comunicazioni spazzatura e di fatto stai bloccando tutti gli altri dispositivi!
A proposito di altri dispositivi... come fare a far parlare uno alla volta? Come capisci che il bus è libero?
E come gestisci due che per errore hanno occupato il bus in contemporanea perché hanno visto il bus libero nello stesso momento e si sono messi a tramettere?
A chi dei due fai ritrasmettere il dato per primo? e dopo quanto tempo al secondo? Ma se il primo si dilunga perché la linea è disturbata, come ritardi ulteriormente l'attesa al secondo?
Poi ci sono fattori prettamente legati ai dati da trasmettere:
Come rappresento al meglio l'intera struttura di dati che è necessario trasferire da un controller ad un altro?
Indirizzi? quanti?
Comando fissi? Quali?
E se un domani ho bisogno di un parametro in più?
Come posso garantire la scalabilità (aggiungere funzioni senza riprogrammare tutti i dispositivi ma solo quelli strettamente interessati dalla nuova funzione)?
Come garantisco la sicurezza del dato? Mica vorrai passare il codice dell'antifurto in chiaro sui cavi???
Come recupero un dato parzialmente sporcato da disturbi? Devo per forza ritrasmettere?
Insomma... sperimentare in questo campo è molto bello e si imparano tante cose, ma come vedi non è proprio facile fare un protocollo che funzioni davvero.
E per inciso, nemmeno MODBUS ha tutte queste cose... spesso si devono fare dei compromessi, e l'accettabilità di tali compromessi è funzione del progetto e del contesto.
Quando si è passati a MODBUS su PLC, alcune delle cose che ho scritto non erano né una priorità né una esigenza. E come ti dicevo, è solo una possibilità di fare comunicazioni semplici in modo semplice, aperta facilmente ad estensioni di terze parti. NON è detto che sia quello che cerchi.