Jump to content
PLC Forum

barte

Modbus TCP

Recommended Posts

barte

Buonasera a tutti

Con un plc Omron NX1P2 dovrei comunicare in Modbus TCP (come client) ma non sono riuscito a capire alcune cose:

1. se questo tipo di comunicazione puo' essere fatta con questo tipo di plc

2. ho contattato Omron per chiedere come fare e mi hanno inviato alcune FB ma senza documentazione

3. ho cercato in rete ma ho trovato solo un manuale stremenzito che pergiunta parla solo di NJ

se qualcuno ha qualche dritta da darmi ringrazio anticipatamente

Buona serata

Link to post
Share on other sites

pcontini

E' possibile comunicare in Modbus TCP con NX1P2, non in maniera nativa (come puoi fare con NX1), ma utilizzando i socket direttamente o tramite FB

Per le librerie, io ho utilizzato queste https://www.support-omron.fr/details/librairie.php?id=2017-03-06 - 15-51-59 - 956985889

Anche se parla di NJ in realtà funzionano anche su NX1P2, trovi anche il pdf con indicazioni di utilizzo

 

Ciao

Link to post
Share on other sites
maxudit65

Salve, sono un pò in ritardo sulla conversazione, ma rientro or ora nel forum dopo anni di assenza. Anche io ho usato le librerie pubblicate in Omron France (internamente segnate come AGGIORNAMENTO FEBBRAIO 2020).

Occorre fare attenzione a tre "cose":

1) Tempi di risposta: con le impostazioni di default la comunicazione è lentissima, indegna di un moderno sistema. Io ho modificato la prima riga dell'FB (versione server) così:

     //Cycle:=Timer(NOT Cycle,UINT#1,CyclicTimer,Cycle,Rtime);     // check status every 100ms

     TON_Strobe(NOT Cycle, T#10ms, Cycle, RtimeT);                    // check status every 10 ms

      In questo modo al comunicazione risulta più attiva, tempi di risposta intorno ai 22 / 25 ms (rispetto ai 230 / 260 ms. di quella originale)

 

2) Se la comunicazione si impalla, e ho notato che accade se il software (io uso MODBUS per comunicare con un HMI sviluppato da me su PC) chiude a "metà" la comunicazione ad esempio quando si chiude il software o il PC o si stacca il cavo ETHERNET, è necessario spegnere e riavviare il PLC (o in alternativa metterlo in PRG e poi in RUN).

 

3) Prima di attivare l'FB di comunicazione E' NECESSARIO ATTENDERE CHE LA RETE ETHERNET SIA IN LINK (OSSIA SIA OPERATIVA CON IP ASSEGNATO E LINKATO CON UN ALTRO DISPOSITIVO ETH). Consiglio vivamente un ritardo di almeno 15 secondi dalla accensione del PLC, verificando che il PLC venga alimentato solo dopo (o almeno insieme) che il dispositivo paritario (switch eth, pc o altro) sia a sua volta già acceso.

 

Saluti a tutti.

Link to post
Share on other sites
Lucky67
2 ore fa, maxudit65 ha scritto:

Salve, sono un pò in ritardo sulla conversazione, ma rientro or ora nel forum dopo anni di assenza. Anche io ho usato le librerie pubblicate in Omron France (internamente segnate come AGGIORNAMENTO FEBBRAIO 2020).

Occorre fare attenzione a tre "cose":

1) Tempi di risposta: con le impostazioni di default la comunicazione è lentissima, indegna di un moderno sistema. Io ho modificato la prima riga dell'FB (versione server) così:

     //Cycle:=Timer(NOT Cycle,UINT#1,CyclicTimer,Cycle,Rtime);     // check status every 100ms

     TON_Strobe(NOT Cycle, T#10ms, Cycle, RtimeT);                    // check status every 10 ms

      In questo modo al comunicazione risulta più attiva, tempi di risposta intorno ai 22 / 25 ms (rispetto ai 230 / 260 ms. di quella originale)

 

2) Se la comunicazione si impalla, e ho notato che accade se il software (io uso MODBUS per comunicare con un HMI sviluppato da me su PC) chiude a "metà" la comunicazione ad esempio quando si chiude il software o il PC o si stacca il cavo ETHERNET, è necessario spegnere e riavviare il PLC (o in alternativa metterlo in PRG e poi in RUN).

 

3) Prima di attivare l'FB di comunicazione E' NECESSARIO ATTENDERE CHE LA RETE ETHERNET SIA IN LINK (OSSIA SIA OPERATIVA CON IP ASSEGNATO E LINKATO CON UN ALTRO DISPOSITIVO ETH). Consiglio vivamente un ritardo di almeno 15 secondi dalla accensione del PLC, verificando che il PLC venga alimentato solo dopo (o almeno insieme) che il dispositivo paritario (switch eth, pc o altro) sia a sua volta già acceso.

 

Saluti a tutti.

 

Scusa se mi permetto. Non so in che settore lavori ma io da fornitore del sistema o peggio ancora da cliente finale mi rifiuterei di avere un sistema così poco efficiente: lentissimo, poco stabile e con problemi a ripartire ad esempio dopo un black out...(se ho capuito bene naturalmente).

2 ore fa, maxudit65 ha scritto:

In questo modo al comunicazione risulta più attiva, tempi di risposta intorno ai 22 / 25 ms (rispetto ai 230 / 260 ms. di quella originale)

 

 Mi pare stranissimo che una Omron abbia un Modbus TCP/IP che lavora con quei tempi di risposta...Neanche un sistema seriale ha quelle perfomance!

Link to post
Share on other sites
maxudit65

Ciao, io ho una attività legata principalmente alla visione artificiale, integrata poi nell'automazione in ambito principalmente industriale. I settori in cui ho lavorato (e stò lavorando) sono praticamente tutti (dalla logistica all'alimentare, passando dall'automotive ai trasporti, ed altri che non stò ad elencare). Non è un vanto, è un orgoglio😀.

L'approccio del modbus con Omron è sempre stato alquanto "distaccato": Omron ha implementato (già dalle sue origini) altri protocolli open come Host Link e FINS. Il Modbus non è mai stato un protocollo su cui Omron ha puntato e anche i moduli Modbus Hardware all'antichità erano molto stringati come funzionalità.

Attualmente i PLC che supportano modbus in modalità hardware (con un modulo aggiuntivo) sono solo i CP1L, CP1H, CJ2M. Tutti gli altri supportano ModBus solo tramite software e quindi ovviamente le prestazioni sono quelle che sono. Non è un protocollo su cui si può "puntare" se è di vitale importanza per l'impianto averlo sempre OK.

 

Spegnimenti ed accensioni non sono un problema se vengono fatti secondo prescrizione (tipo giro l'interruttore ON/OFF e non stacco cavi). L'unico problema reale che potrebbe accadere è che il cavo Ethernet si "sganci" .... ma ciò come esperienza a me non è mai successo (certo, non bisogna lasciare cavi accessibili ovviamente).

 

Altri accorgimenti è fare il software per PC ben fatto, con tutti i santi crismi e per ultimo curare la componentistica hardware, e "il problema non c'è più".

I miei erano solo consigli, legati per di più al fatto di fare attenzione nelle prove ... altrimenti si rischia un bagno di sangue.

 

Comunque quanto ho scritto sopra ad esempio è una linea in funzione da un anno, lavora 24H 365gg compreso sabati, domeniche, Natali, etc ... senza alcun malfunzionamento importante (è monitorata H24 e qualunque malfunzionamento, come ad esempio un banalissimo calo di prestazioni viene registrato sia sul PLC che sul PC ed inviato ad un NAS esterno appena possibile).

 

In genere se "il problema" lo conosci, non è un problema.

Saluti

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...