Comunicazione Su Rs485

[gene89]

Salve a tutti. Cerco di esporre brevemente il mio problema, sperando che qualcuno più preparato di me mi dia delucidazioni.

Il mio obbiettivo è comunicare con il plc (s7200 cpu224) al fine di leggere e modificare le variabili durante l'esecuzione del programma.

Sono in possesso di un'interfaccia rs485, rs232 to etherneth (USR-TCP232-24) di cui allego un'immagine e il manuale.

Da quello che ho capito il plc sul connettore db9 ha due pin dedicati alla rs485 (3 e 8), ma sembra che il termine rs485 faccia riferimento solo allo standard elettrico, mentre il protocollo di comunicazione, se non erro resta MPI.

Ora la mia domanda è, posso connettere il plc a questa scheda direttamente, utilizzando i due pin? Ad essere sincero ci ho già provato ma non riesco a far in modo che step7 veda il plc (la porta com virtuale è correttamente configurata).

Se non posso fare in questo modo, qual'è la soluzione? E' necessario per forza un cavo mpi rs232? Perchè non posso usare la rs485?
Grazie in anticipo e se ho detto qualche eresia perdonate la mia ignoranza.

Manuale USR-TCP232-24

[pomat]

Tutto questo perché non hai la db9 sul pc e/o non vuoi comprare un convertitore MPI o per altri scopi?

Modificato: 26 marzo 2015 da pomat

[gene89]

No per altri scopi. Per programmare da pc ho il cavo MPI - usb della siemens. Il mio problema è che vorrei avere un controllo da rete lan in modo da poter poi sviluppare una app per android. Il plc è il cervello di un impianto antintrusione e il mio obbiettivo ultimo è di poterne controllare lo stato da smartphone senza un pc costantemente acceso; inoltre lo smartphone potrà poi funzionare anche da modulo gsm per le chiamate in caso di allarme. Il plc mi ha permesso di personalizzare al massimo l'impianto adattandolo alle mie esigenze e ho fatto tanto per ridurre al minimo i consumi. Ora vorrei aggiungere questa funzionalità ma non vorrei spendere 350 euro per un modulo etherneth della Siemens.

Modificato: 26 marzo 2015 da gene89

[pomat]

Ora è più chiaro. Il fatto che lo step 7 non veda il plc attraverso la virtual com non vuol dire che non si possa programmare uno scambio dati "custom" via seriale rs485 (gli altri utenti sono più esperti di me in materia).

Ad ogni modo, in modalità PPI a 19.2 kbit/s dovrebbe essere possibile incapsulare in TCP/IP configurando opportunamente il serial server che stai usando ed "ingannare" così lo step 7 con la virtual com.

Attendiamo il parere dei grandi

[gene89]

Ok attendo con ansia. Oltre che per risolvere il problema, per imparare qualcosa di nuovo.

[gene89]

Nessuno che mi aiuti??

[pomat]

Ciao, le mie ricerche confermano che in modalità PPI è possibile (magari non banale) collegarsi direttamente in rs485, mentre in modalità MPI è praticamente fuori discussione bypassare l'adattatore Siemens.

Riporto un testo significativo dal sito della Digi, che si riferisce in particolare ai prodotti Digi e al software com virtuale Digi Realport, ma che dovrebbe essere applicabile alla maggior parte dei serial server e dei software virtual com esistenti:

Both PPI and MPI work fine via Digi Realport to the Siemens supplied EIA-232 to PPI/MPI converters. The Digi should be set to Low-Latency optimization.

PPI is standard EIA-485, and many people have seen speed improvements by NOT using the Siemens EIA-232/PPI cable but instead directly connecting the Digi product to the EIA-485. Because the S7-200 puts out 24vdc on its DB9 connector - be careful when making this cable. Some products - such as the Kepware OPC server - very nicely encapsulate PPI in TCP to any Digi product.

MPI requires special hardware and a co-processor. These are included within the Siemens EIA-232/MPI cable, which is why it is not cheap. So when using Digi Realport to this cable, we are NOT really moving MPI but a special point-to-point linking protocol between the Siemens driver and this cable. So you cannot by-pass or eliminate this cable.

Tra le altre cose, qui fa riferimento a prodotti esistenti che incapsulano PPI nel TCP. Devi tener conto che questo incapsulamento lo dovrai comunque fare lato smartphone, il che potrebbe non essere così semplice come usare direttamente la libreria Snap7 o suoi port, a meno di non addossare se possibile qualche piccola elaborazione aggiuntiva al serial server. Questo perché, se il serial server si limita a incapsulare e "decapsulare", i pacchetti lato PLC potrebbero non contenere delle parti attese, e i pacchetti lato "client" potrebbero ritrovarsi pezzi aggiuntivi inattesi. Ad esempio, faccio un'ipotesi banale, presumo che lato PPI vi sia un checksum a livello di datagramma S7, per dirla in parole povere, mentre se capisco bene le librerie basate su ethernet non si preoccupano del checksum perché c'è già il controllo d'errore a livello TCP. Penso questo perché è una delle cose che succede (non proprio in questi termini) nel passaggio da Modbus RTU a Modbus TCP (precludendo l'uso di serial server "normali"), magari nel caso del protocollo S7 non succede e sto complicando inutilmente, spero che Davide Nardella possa darci delucidazioni su questo.

Altra cosa: parli di smartphone quindi cos'hai in mente? Android? Smartphone che si connette in locale via WiFi o da remoto?

inoltre lo smartphone potrà poi funzionare anche da modulo gsm per le chiamate in caso di allarme

Cioè vuoi usare lo smartphone come modulo gsm che effettua le chiamate ad altri numeri in caso di allarme?? Uno smartphone sempre acceso che ti faccia da server praticamente, magari connesso alla WLAN? Mi sembra un po' inverosimile...

[pomat]

@gene89 ci hai rinunciato??