[Sergio Bertana]

Nel comando di lampade a LED a 220Vca occorre fare alcune considerazioni, l’alimentazione dei LED solitamente è ottenuta mediante trasformatori elettronici che raddrizzano la tensione di rete per poi elevarla di frequenza fino a 30/40 KHz ed in questo modo si utilizza un trasformatore molto piccolo per ridurla alla tensione necessaria alla accensione dei LEDs.

Abbiamo riscontrato in alcuni costruttori che il circuito di ingresso della lampada presenta una bassissima impedenza (Abbiamo supposto che vi siano delle capacità in parallelo) e questo provoca una corrente di spunto molto elevata, questo indipendentemente dalla potenza effettiva della lampada (Vedi oscillogrammi).

Come si vede dal primo oscillogramma si ha una corrente elevata (Lo spunto è di 20 Volts pari a 60 Amp) per un tempo significativo e questo provoca “l’incollaggio” del contatto del relè di uscita. Inserendo una resistenza da 47 Ohm 1/2 Watt in serie alla lampada non si ha più lo spunto di corrente (Il segnale che si vede è il disturbo sulla chiusura del relè che fà partire il trigger dell’oscilloscopio). La resistenza in serie non ha effetti sulla luminosità della lampada in quanto la caduta di tensione ai sui capi e trascurabile ed è compensata dall’alimentatore intelligente presente nelle lampade.

In merito ai relè utilizzati sui moduli di espansione I/O a relè, sono il modello PA1A-5Vdc della Panasonic (Vedi datasheet). Il relè è disponibile presso RS-Components con il codice 156-5126.

[Sergio Bertana]

Intanto per aggiungere porte seriali ad un PC che ne è sprovvisto consiglio di utilizzare un convertritore USB-Seriale, ci sono modelli semplici ad RS232 e modelli con uscita mista RS232, RS422, RS485 anche isolati galvanicamente. Questi convertitori agiscono esattamente come una porta COM fisica del PC e non vi sono limiti nel funzionamento.

Per quanto riguarda i convertitori sia Ethernet-Seriale che WiFi-Seriale, agiscono tutti con un software di virtualizzazione che installa una COM aggiuntiva nel PC, ma mentre con l’USB non si hanno ritardi nella comunicazione, utilizzando il protocollo TCP/IP si hanno ritardi che a volte possono portare alla non funzionalità del protocollo di comunicazione seriale. I ritardi sono ancora maggiori passando sul WiFi.

Per quanto riguarda la comunicazione WiFi tra PC e convertitore, puoi utilizzare un access point, in tal caso il PC ed il convertitore si scambiano dati all’interno di una rete WiFi esistente. Se invece non hai l’access point puoi creare una rete ad-hoc tra PC e convertitore (Topic).

[Sergio Bertana]

Non capisco poi quando dici che il software del macchinario non accetta le porte virtuali, la porta virtuale è un software che installi sul PC e ti fà vedere il convertitore ATC-1000 connesso al tuo macchinario come una porta COM fisica del PC. Non devi installare nulla sul macchinario.

[Sergio Bertana]

Non scrivi nel TCP Mode che port number hai impostato, deve essere la stessa per  entrambi i dispostivi. Nel convertitore settato come server non occorre impostare l’IP del remote server. Se così è la configurazione che hai fatto è corretta quindi divrebbe funzionare, ma quando dici che non funziona vuoi dire che testi direttamente il funzionamento del software di connessione con la macchina e non và, oppure che hai fatto una semplice prova di echo caratteri seriali con un emulatore di terminale (Esempio Toolly) ?

Per minimizzare il traffico dati sulla rete nel caso di funzionamento paired consiglio di utilizzare il protocollo UDP che non prevede l’ack sui pacchetti inviati. In una connessione seriale tra due apparecchiature il controllo sulla congruità dei dati è già svolto dal protocollo seriale.

Per accertare il funzionamento proverei con il terminale di Toolly ad inviare caratteri sulla seriale del PC (Dove è connesso l’ATC-1000) e cortocircuitando tra di loro i pin 2 e 3 del connettore seriale dell’altro ATC-1000 verificare se ricevo l’echo dei caratteri inviati (Vedi foto).

Ricordo che accertata la funzionalità della connessione paired tra i due dispositivi, il funzionamento della connessione con la macchina è condizionato da altri fattori come ad esempio i ritardi della comunicazione sulla rete ethernet, il possibile frazionamento dei pacchetti, ecc…

[Sergio Bertana]

Anche se la tua richiesta è Off-topic, in questo topic si parla di connessioni multicast cioè della possibilità di creare connessioni multipunto tra diversi convertitori Ethernet-Seriale, cerco di illustrare la situazione.

Tutti convertitori Ethernet-Seriale possono essere utilizzati (Grazie ad un programma di virtualizzazione porta COM) come se fossero una porta seriale aggiuntiva del PC. Quindi è evidente che se il tuo inverter permette una connessione multipunto in RS485 tutti i convertitori che dispongono di una RS485 in uscita possono soddisfare la tua richiesta.

Naturalmente non mi stuferò mai di sottolinearlo il passare tramite rete LAN con i dati seriali comporta una latenza sulla comunicazione che in alcuni casi per fortuna rari potrebbe portare ad un mancato funzionamento del protocollo di comunicazione. Inoltre se tra i nostri modelli scegli i modelli più economici avrai di conseguenza anche una minore velocità di elaborazione del convertitore.

Scenario completamente diverso con i convertitori USB-Seriale dove invece i tempi di latenza sono minori e la seriale in uscita dal convertitore si comporta esattamente come una seriale nativa del PC.

[Sergio Bertana]

a) Abbiamo avuto segnalazione del problema da un paio di clienti con PC (Windows 7 e Windows 8) ma non siamo riusciti ad isolare il problema, ipotizziamo qualcosa sull’installazione sul PC cliente.

b) Il trend in tempo reale visualizza la curva dal momento dell’accensione del pannello (Il trasferimento del programma è considerata una nuova accensione) allo spegnimento del pannello.

d) Ipotizzando di impostare LW100 come controllo storico aggiungere un oggetto pulsante opzioni nel quale come variabile impostare LW100, come tipo “elenco a discesa” e come sorgente dati “da file storici” data sampling poi posizionare l’oggetto. In questa combo box sarà possibile selezionare il giorno che si vuole visualizzare a video.

[Sergio Bertana]

Per illustrare meglio il concetto di funzionamento del meccanismo di spionaggio utilizzo un semplice programma (Stampa) che con una FB ModbusMaster esegue la lettura in modbus RTU.

Nell’esempio utilizzo le due porte seriali di un modulo CPU ARM7 interconnesse tra di loro (Attenzione per interconnetterle occorre usare un adattatore Null-Modem su di una porta ed un adattatore modem sull’altra).

La FB ModbusMaster ha al suo interno chiamate alla funzione SysSpyData, queste chiamate possono essere abilitate forzando a TRUE l’ingresso SpyOn della FB così come ho fatto nell’esempio. Se con il programma in funzione ci colleghiamo con il terminale Telnet di Toolly ed abilitiamo la console di spionaggio vedremo i pacchetti Modbus RTU scambiati (Screenshot).

Come  si vede nella prima parte la comunicazione è attiva invio un frame di Tx e dopo 4mS viene ricevuto il frame Rx  di risposta. Siccome nel programma ho inserito il Delay a 1Sec il successivo frame di Tx verrà inviato dopo un secondo. Il frame di Tx esegue la richiesta di 4 registri, così ho evidenziato nel frame Rx il valore ritornato dei 4 registri ed il CRC finale.

Ho scollegato il cavo di alimentazione e sono visibili solo i frame di Tx, il tempo di ritardo tra un frame e l’altro è pari al tempo impostato in Timeout 500mS più il tempo di Delay. Ho modificato il programma richiedendo un indirizzo di registri fuori range, e come si vede viene ricevuto un frame di risposta con errore (Codice 16#83) seguito dal codice di errore 16#02 e poi dal CRC 16#C0F1.

Il codice di errore 02 è un codice di Illegal data address, infatti l’indirizzo richiesto 16#AFC7 (44999 che con offset 1 diventa 45000) è fuori range per il sistema SlimLine (Download programma).

[Sergio Bertana]

Per il servizio tecnico On-Line si utilizza TeamViewer, per utilizzare il servizio occorre disporre del programma TeamViewer scaricabile da questa pagina oltre ad una connessione Internet affidabile.Il servizio permette grazie all’utilizzo di TeamViewer ai nostri tecnici di “agire” sul PC dell’utente e di effettuare verifiche e modifiche per risolvere i problemi che il cliente incontra. Il nostro tecnico agisce mantenendo un contatto telefonico e/o tramite il VOIP integrato con il cliente, il quale così può vedere quello che il tecnico stà facendo e può discutere con lui sulle manovre effettuate.Ecco quindi che è possibile lavorare in tandem Tecnico/Cliente testando i problemi con l’obbiettivo di raggiungere nel minor tempo possibile la soluzione. Molti clienti con questo servizio hanno potuto apprendere stando tranquillamente seduti alla loro scrivania come programmare i dispositivi PLC, i terminale operatore, oltre alla configurazione di tutti gli altri prodotti da noi gestiti.

I costi del servizio sono disponibili a questo link.

[Sergio Bertana]

Sul forum abbiamo scritto di tutto e di più sull’argomento Modbus ti consiglio di fare un giro con cerca mettendo argomento Modbus per trovare risposte alle tue domande (Topic (1), (2), (3)).

Intanto accertati che i parametri di comunicazione seriale siano corretti, che l’indirizzo di nodo sia corretto, e che i cablaggio sia corretto (Consiglio di provare anche ad invertire i due cavi non si sà mai, danni non se ne fanno).

L’errore più banale che si commette è non considerare l’offset di 1 sull’indirizzo del registro, l’FB ModbusMaster in accordo alle specifiche sottrae 1 all’indirizzo quindi se l’inverter non somma 1 ti trovi un indirizzo errato. Prova a sommare 1 all’indirizzo da leggere passato alla FB.

Di vitale importanza è l’uso dello Spy (Topic), permette di vedere da Telnet cosa succede sulla porta RS485 di comunicazione ed interpretando le risposte Modbus capire che tipo di problema si stà avendo. Informazioni su come funziona lo spionaggio dei dati le trovi nel manuale di programmazione SlimLine.

[Sergio Bertana]

Aggiungo un post separato per rispondere all’ultimo punto della tua domanda, dove dici Se al posto del controllore utilizzo un PC anche le risposte del server vengono ricevute correttamente.

Qui bisogna ricondursi alla tecnica del IP masquerading o NAT dinamico (Cito testalmente Wikipedia). Ciascuna connessione TCP o UDP viene gestita individualmente, quando la connessione viene iniziata, il router NAT mantiene una tabella di corrispondenze tra porte sull’indirizzo esterno e corrispondenti porte e indirizzi IP privati. Quando riceve un pacchetto TCP o UDP sull’indirizzo IP esterno, consulta la tabella per sapere a quale host interno e su quale porta inviarlo. Il router NAT deve quindi tenere traccia di tutte le connessioni TCP e UDP attive tra la rete interna e quella esterna (e preoccuparsi di eliminare le voci inutilizzate da questa tabella mediante un meccanismo di scadenza).

Quindi se non hai configurato il NAT del router, se la comunicazione inizia dal dispositivo sotto il router vero il dispositivo su IP pubblico dovrebbe essere possibile per il dispositivo dall’IP publico reinviare i dati indietro al dispositivo su IP privato. Certo devi essere certo di utilizzare sempre le stesse porte perchè se rispondi verso una porta diversa da quella da cui è partita la comunicazione il pacchetto è bloccato dal router.

Il fatto che con il PC funzioni potrebbe essere legato a chi inizia per primo la comunicazione durante i test che hai eseguito è possibile ?

[Sergio Bertana]

Abbiamo applicazioni presso alcuni clienti che utilizzano lo scambio dati in UDP tra sistemi SlimLine (Viene utilizzato l’FB UDPDataTxfer, UDP data transfer), ed in alcune applicazioni questo scambio avviene mediante utilizzo di routers (ADSL, UMTS, Satellitari). Vediamo allora di elencare i possibili tests da effettuare.

L’utilizzo del ping (FB SysIPReach) è indispensabile, perchè è solo con il ping che viene inserita la voce ARP nella ARPTable (IP destinatario su LAN, IP del gateway su WAN, verificare con comando ARPTable da telnet). Lo scambio funziona anche senza il ping solo se si accede al sistema (Telnet, Modbus o WEB) dall’IP del destinatario pacchetti UDP su rete LAN o da Internet su rete WAN e non si lascia più scadere il tempo di vita.

Utilizzando un router è possibile creare un VPN tra le parti, ed in tal caso non vi sono problemi il tutto agisce come una rete LAN veicolata su rete WAN.

Se non usi la VPN dal dispositivo connesso alla rete LAN del router puoi raggiungere l’IP pubblico (La connessione viene iniziata dal dispositivo). Ma per permettere all’IP pubblico di raggiungere il dispositivo devi configurare il NAT (O port forwarding) del router. Dal tuo post non si evince se questa configurazione è stata fatta.

[Sergio Bertana]

Il file di esempi è un file compresso (*.zip) scompattandolo ci si trova con una cartella al cui interno vi è il file Program sources.pro (File di progetto CODESYS), aprendo CODESYS dal menù Open è possibile aprire il file progetto e si presenterà una videata del tipo riportata nello screenshot.

Può essere che a causa della dversità dei percorsi nella configurazione del programma venga visualizzato un errore nell’apertura della libreria di sistema eSLineC2SysLib_A000.lib, per correggere il problema, aperto il progetto selezionare il percorso corretto della libreria (Potrebbe essere C:Programmi (x86)3S SoftwareCoDeSys V2.3TargetsSlimLine Mps052Library) Screenshot.

Ora hai il progetto aperto con tutti i files di esempio così come riportato sul manuale di programmazione CODESYS. Naturalmente consiglio di esportare dal progetto i files di esempio che desideri utilizzare (Screenshot) per poi importarli nel tuo progetto.

[Sergio Bertana]

Vediamo di rispondere ai vari punti.

a) Non capisco esattamente cosa tu intenda, ma mi sembra comunque ti riferisca solo ad un problema di editing, perchè poi nel funzionamento tutto è Ok. Non mi dici se anche nella simulazione On-Line su PC il funzionamento è Ok.

b) Occorre abilitare data e ora e non scala tempo.

c) Raggiunto il numero di registrazioni impostate se non è spuntata fermata automatica il pannello sovrascrive le registrazioni più vecchie, se spuntata la fermata si ferma sino al nuovo giorno.

d) Il pannello automaticamente sovrascrive i file se si imposta il numero di giorni da mantenere, sul pannello sono salvati 7 file 1 per giorno. Per visualizzarli devi utiizzare un trend in tempo storico o visualizza dati storici e tramite l’oggetto pulsante ->opzioni puoi gestire la variabile controllo storico per decidere quale giorno visualizzare.

e) Toccando il trend in un determinato punto viene tracciata una linea verticale che interseca le registrazioni dati, il valori intersecati vengono resi disponibili nella variabile linea di controllo.

[Sergio Bertana]

Per dare una idea dei valori di tensione in gioco e per avere uno strumento di test del cablaggio realizzato, ecco un programma che utilizzando lo stesso collegamento visto nel post precedente permette di verificare la correttezza del cablaggio (Screenshot programma).

Siccome per acquisire le celle di carico gli ingressi del modulo A/D sono configurati hardware per segnali 0÷1.17V, occorre che la tensione di alimentazione della cella non superi 1V. Come si vede dallo screenshot del programma ho impostato una uscita sul D/A a 2mA che con la cella di carico utilizzata (415Ω) genera una tensione di 0.83V (Infatti dal canale di acquisizione 3 leggo 0.827V).

Siccome la cella genera 2mV/V a 20Kg di carico avrei in uscita una tensione di 0.00164V (1.64mV) (0.827*(2/1000)). Al peso caricato sulla cella 200gr il valore in volt acquisito sarà 100 volte inferiore cioè 0.0000164V (0.0164mV). Per poter leggere questo valore in  modo stabile ho dovuto inserire un FB di Average con un coefficente di filtro elevato. Tutte queste operazioni sono però già svolte dal blocco funzione StrainGaugeAcq.

Ecco quindi che per acquisire valori di tensione dell’ordine di pochi mV è importantissima la precisione e “pulizia” del segnale di alimentazione strain gauge e la cura del cablaggio utilizzando cavi schermati e twistati.

Allego il progetto sorgente che può essere utilizzato per testare la connessione da voi realizzata, ricordo di impostare correttamente la corrente di uscita sul D/A in base alla resistenza dello strain gauge utilizzato per non superare 1V .

[Sergio Bertana]

Siccome l’acquisizione celle di carico per avere buoni risultati deve essere affrontata con i dovuti carismi, ho realizzato un semplice progetto per dare una tracccia di come si possa operare. Nel mio esempio utilizzo uno strain gauge da 20 Kg di cui riporto il datasheet.

Come si vede, lo strain gauge ha una impedenza di ingresso di 415Ω, volendola alimentare a 4,5Volt occorre una corrente  di 10.84mA, l’uscita D/A del nostro modulo espansione I/O analogico può erogare massimo 10mA, quindi ho optato per utilizzare una uscita in corrente (Corrente massima 20mA). Ricordo che non è tanto importante la precisione del valore di tensione di alimentazione dello strain gauge, viene compensata mediante la lettura effettuata sul canale 3 (AI03-/AI03+), ma è importante la stabilità e pulizia del segnale.

Come  si vede dallo screenshot del programma, alimento lo strain gauge dal canale 0 del modulo D/A (Corrente di 10.9mA), dal canale 4 del modulo di acquisizione A/D eseguo la lettura del peso. In accordo alle specifiche dello strain gauge il valore di SGaugeFullScale è 20Kg, mentre lo SGaugeRatio è 2mV/V. Avendo impostato il valore di fondo scala in grammi avrò tutte le definizioni di peso nella stessa unità di misura.

Taratura offset: A cella scarica si attiva DoOfsCalibration che salva nella variabile RETAIN OfsCalibration il valore di offset.
Taratura scala: Carico la cella con un peso di riferimento, il più preciso possibile e più vicino posibile al fondo scala (Nel mio esempio per semplicità ho utilizzato un pesetto da 400gr anche se avrei dovuto usarne uno da 19Kg). Il valore del peso di riferimento và definito in FSReference. Si attiva DoFSCalibration che salva nella variabile RETAIN FSCalibration il valore di offset.

Terminata la taratura il sistema è pronto alla pesatura come si vede nella foto stò pesando un pesetto da 200gr. Nel mio sistema in test mi sono preso la libertà di usare fili non schermati per la connessione dello strain gauge, ma nella realtà sono indispensabili fili twistati e schermati, allego programma sorgente.

[Autore]

Post