Compatibilità convertitore ethernet/seriale ATC2000 in RS485

[Vittorio]

Mentre colllaudavo positivamente il Vs. ATC 2000 su RS232 nel dialogo con un vecchio modem seriale mi è capitato una occasione su EBAY e, convinto di avere un convertitore RS485 compatibile, ho comprato 2 Termoregolatori domotici Netbuilding RS485 nuovi di pacca che sono praticamente 2 cronotermostati funzionanti autonomamente ma che si possono supervisionare, configurare e gestire da PC su Bus RS485. Più precisamente, questi termoregolatori hanno una connessione RS485 e comunicano nel Bus seriale sia tramite un protocollo proprietario “XComm” (credo abbia a che fare con Windows Active x), sia tramite ModbusRTU; di default e se non swichati (via software che non ho) utilizzano e comunicano con il protocollo Xcom.

Naturalmente, ho subito messo in atto un Test con uno solo dei due termostati preventivamente scaricando ed installando il Software Configuratore e gestionale gratis del produttore (si chiama XComm ed installa nel PC un  server ABS al servizio della configurazione e della gestione di tutti gli apparati domotici Netbuiding tra cui anche i Termoregolatori), ho quindi alimentato il cronotermostato ed ho cablato gli ingressi RS485+ e RS485- del termostato con i rispettivi ingressi del ATC 2000 con una coppia di cavi interallciati come richiesti dalla scheda prodotto; non ho usato una resistenza di terminazione (Vs Post sulle reti RS48: letto) perché anche il produttore mi dice non necessaria per una connessione cavo di un metro e con un solo dispositivo nel Bus RS485.

Lato alimentazione e cablaggio dovrebbe essere tutto a posto: il termostato si accende e funziona regolarmente nella sua configurazione di default; Anche lato Software tutti i test ed i controlli effettuati anche con il fornitore sembrerebbero tutti a posto ed il Server ABS si avvia e lavora correttamente nel PC della LAN dove è installato. Il problema nasce nella comunicazione tra il PC ovvero tra il Software di configurazione eseguito in un PC della LAN (e che è lo stesso PC dove gira anche il Server ABS ed il software di configurazione)  ed il cronetermostato  in mezzo alla quale interviene la presenza e la conversione del ATC2000 anch’esso connesso nella LAN. Eppure il ATC è configurato correttamente (almeno sembra) con i parametri di comunicazione richiesti e confrontati con il produttore cioè: Serial type=RS485; Baud rate=19200; Bit=8; Parity check=none; Flow control =none; lascio in default a zero tutti gli altri parametri Force, Transmit, Delimiter e Transimision Delay time in quanto il produttore non me li dà tra i necessari parametri di configurazione.

Il Convertitore ha un indirizzi IP statico 192.168.1.5 e la porta assegnata è la 5600 che, tra l’altro è la porta di default che il Software utilizza per la configurazione del dispositivo via ethernet (Il software infatti prevede la possibilità di configurare direttamente i dispositivi sia su connessione seriale su una porta COM da indicare, sia via ethernet tramite un indirizzo IP ed una porta anch’essi da indicare); il Convertitore è pingabile e risponde correttamente.

– Prima domanda:
come faccio a sapere se il ATC2000 deve essere settato in TCP come Server o Come Client ??? in teoria dovrebbe essere ininfluente (marronata????) perché se  settato da Client con l’indicazione dell’indirizzo IP e della porta utilizzata dal software di configurazione eseguito sul  PC dovrebbe creare la seriale con lo stesso; analogamente, se settato da server ed in ascolto sulla sua porta dovrebbe creare la seriale quando il software di configurazione stabilisce la connessione sul suo indirizzo IP e sulla sua Porta; Comunque ho provato senza successo entrambe le soluzioni ; ovvero, come faccio a sapere se il convertitore magari debba essere settato con connessione UDP anziché TCP ?.

-Seconda domanda ovvero dubbio:
L’interfaccia software comunica (ovvero dovrebbe comunicare) con i Termoregolatori utilizzando oltre la porta COM (nel caso di connessione diretta) o l’indirizzo IP+Porta (nel caso di connessione in LAN) un indirizzo detto “CPU Address” che per i termoregolatori è di default il n. 3 e che nell’interfaccia software pilota la tipologia di maschera di configurazione richiamata ma credo abbia qualche effetto anche per l’indirizzamento verso il termoregolatore a livello di indirizzamento nell’ambito del BUS RS485; come faccio a sapere se e come magari nel ATC 2000 deve essere settato qualche parametro che consenta questo ulteriore indirizzamento (ammesso che sia effettivamente necessario per la comunicazione) ovvero se sia necessario  qualcuno degli altri parametri che lascio di default a zero quando setto ATC 2000 da Server TCP (Force, delimiter ecc.) ?

– Alle prime due domande il produttore non sa rispondermi dicendomi di non conoscere il convertitore ATC e le sue caratteristiche e che con i loro convertitori “ETM” ethernet/RS485 il dispositivo comunica e la configurazione funziona e quindi potrebbe essere un problema di incompatibilitaà o configurazione del ATC 2000.

-Terza domanda:
Il Termoregolatore è (credo) un dispositivo Slave che dovrebbe trasmettere nel Bus seriale RS485 i dati al PC ovvero al software di supervisione eseguito nel PC e che quindi dovrebbe fungere da dispositivo Master.
Non è che la presenza di un Convertitore in genere ovvero di ATC 2000 settato da Server  in mezzo alla connessione altera questa gerarchia ?  ovvero che il PC non viene riconosciuto come Master ? ovvero che viene a mancare quella istanza che attiva la comunicazione tra i dispositivi slave e Master collegati al bus rs485 ? Eppure anche loro usano dei convertitori Ethernet/RS485 per la Supervisione in rete dei termoregolatori.

-Ultima domanda che vale anche come spiegazione di VirtualCom per ATC2000:
Volendo escludere il passaggio della comunicazione di configurazione nella LAN ed eseguirla invece direttamente dal PC al termoregolatore connesso in RS485 al ATC 2000 tramite una Porta (Com) seriale che il PC non ha come dovrei fare ? io pensavo con Virtualcom per ATC2000 che ho scaricato e che uso ma poiché ho già provato (naturalmente utilizzando il cavo incrociato tra PC e ATC2000 anziché dritto come nel router) in tutte le salse senza successo,  mi vengono tremendi dubbi e mi chiedo e Vi chiedo: ma il software VirtualCom mi fa generare una Porta virtuale associata al Convertitore e per generarla devo indicare l’indirizzo IP e la Porta del Convertitore; io credo invece di dover generare una porta COM seriale virtuale da associare al PC che esegue il software di configurazione XComm ed il programma VirtualC non mi fa generare dal PC in cui è eseguito una porta COM da associare allo stesso PC (sto farneticando ? ovvero dove sbaglio ?).

[Sergio Bertana]

Client o Server, questo il problema… La tua configurazione deve essere Server, sarà il programma su PC ad operare come client ed a connettersi all’ATC. Non a caso sul PC imposti indirizzo IP e porta dell’ATC. Per quanto riguarda TCP o UDP nel to caso è sicuramente TCP, per altre informazioni vedi post.

Il convertitore si setta in modo Client solo nelle applicazioni peer to peer, cioè due convertitori connessi tra di loro, uno Server e l’altro Client per estendere su ethernet la porta seriale.

Il “CPU Address” è l’indirizzo che contraddistingue il regolatore nella rete RS485, ogni termoregolatore deve avere il suo indirizzo, uno diverso dall’altro. é importante che lo conosci e lo imposti nel programma altrimenti non puoi comunicare. L’ATC non ha alcuna influenza su questo parametro, se funziona con il convertitore del produttore funziona anche con l’ATC. La stranezza è che il produttore non sappia dirti come impostare l’indirizzo sul loro modulo.

La gerarchia PC Master e termoregolatore Slave non viene certo alterata dall’ATC.

Il Virtual COM installa una porta seriale virtuale vista come porta COM da Windows, ma certo devi dirgli su che convertitore Ethernet/Seriale (Indirizzo IP e porta) la porta si connette. Anche perchè potresti avere più convertitori connessi al PC e quindi più porte COM virtuali.

[Vittorio]

Ho perso diverse nottate, ho studiato approfonditamente tutto il software di configurazione e gestione dei termoregolatori e tutto il giro (compreso porte e indirizzi IP) per lo scambio dei dati tra Termoregolatore e ATC2000, tra il convertitore ed il Server ABS e tra questo e l’interfaccia di configurazione e/o gestione. Ho provato tutti i settaggi possibili ed immaginabili ma non ho tolto un ragno da un buco tranne che la convinzione (forse la certezza) che il problema non è la compatibilità di ATC2000 ma il routing interno della comunicazione e dello scambio dei dati.

La interfaccia di configurazione dei loro convertitori (ATM) – presente come funzione aggiuntiva del programma di gestione del termoregolatore – richiede infatti sia l’indirizzo IP e la Porta dove è in ascolto il Convertitore (dati che nel mio convertitore io setto in modalità SERVER e nella fattispecie IP=192.168.1.5 e porta=5600) sia l’indirizzo IP e la porta RS485 dove è in ascolto e dove deve essere inviata la risposta (il SERVER ABS e nella fattispecie IP=192.168.1.6, porta =9999) che a sua volta quando richiesti li restituisce all’interfaccia di gestione e/o configurazione;  questa configurazione nel mio convertitore la posso settare in modalità Client ma non posso contemporaneamente settare ATC2000 con entrambe le configurazioni ovvero farlo lavorare sia in modalità Server che Client e quindi penso ci sia necessità di un routing o reindirizzamento di rete sottostante (marronata???). Non è che ci possa entrare qualche cosa l’attuale Gateway di rete ovvero che debba utilizzare un altro Gateway ovvero impostare qualche routing nel router per fare in modo che ATC 2000 interrogato da un IP su una porta risponda ad un IP su una altra?? io attualmente nella scheda del ATC2000 oltre l’indirizzo IP fisso di rete del convertitore setto anche l’indirizzo del Gateway inserendo quello corrispondente al Router US Robotic che gestisce la LAN (192.168.1.1).

Sta di fatto che il Server ABS, quello che gestisce tutto e che consente di inviare dall’interfaccia le configurazioni o i dati al termoregolatore ovvero di leggere nell’interfaccia i dati ricevuti dal termoregolatore ha come sua porta interna RS485 la 9999 mentre dalla rete si fa raggiungere tramite la Porta TCP 19999. Naturalmente questo server si attiva e risulta perfettamente configurato e funzionante con tutti i riscontri che il software mette a disposizione; lo stesso prende come indirizzo IP quello del computer di rete dove è installato (192.168.1.6) che è lo stesso che usa l’interfaccia di configurazione.

Non posso neppure eseguire una riprova della compatibilità tra ATC2000 ed il termoregolatore tramite la configurazione diretta via Porta Com perché non ho un PC con porta seriale e volendo utilizzare Virtualcomm, poiché vado ad usare la scheda di rete del PC per la connessione ethernet tra PC e convertitore ATC (con Cavo cross) vado automaticamente a creare una connessione di rete che il Server ABS individua cambiando il proprio indirizzo da locale= 127.0.0.1 a quello della scheda di rete 192.168.1.6 e andando a lavorare in rete ripresenta tutte le problematiche già evidenziate.

Cosa posso fare? Quali test posso effettuare senza perdere oltre la testa?? o mi devo rasegnare a buttare alle ortiche ATC2000 , naturalmente limitatamente all’impiego in questa gestione domotica e/o applicazione???

[Massimo]

Suggerisco di chiedere al costruttore dei termoregolatori qual’e’ un frame da inviare via Rs485 al termoregolatore, dal quale si otterrà una risposta.

Poi collegherei la seriale del PC convertita in Rs485 al termoregolatore e installerei il ns. programma per PC Toolly con il quale si può inviare il frame e ricevere la risposta.

Se funziona, allora collegherei la Rs485 del termoregolatore all’ATC2000 e sempre da tooly effettuerei l’apertura di un socket TCP/IP verso l’ATC2000 (Ip e port dell’ATC2000). A questo punto inviando lo stesso comando utilizzato in precedenza, si dovrà ottenere la stessa risposta.

Ora che sembra tutto ok, riproverei con il server ABS. Un possibile problema che potrebbe esserci è legato al timeout. Normalmente inserendo un convertitore, si ottiene un piccolo ritardo tra il momento in cui il programma invia un comando e quando si ottiene la risposta. Per cui occorre verificare se nel server ABS è possibile impostare tale timeout.

[Autore]

Post