Sergio Bertana
Risposte nei forum create
-
AutorePost
-
Sergio Bertana
Amministratore del forumIntanto alcune precisazioni, il blocco funzione per la gestione del protocollo Modbus master ha subito diverse revisioni ed affinamenti (Topic). L’ultima versione il ModbusMaster gestisce tutti e tre i tipi di protocollo Ascii, RTU e TCP/IP, ti consiglio di utilizzare questa versione al posto del precedente ModBusRtuMaster.
Poi come in tutti i miei esempi in LD, utilizzando il FB ModbusMaster non servono gli I/O EN/ENO, pertanto ti consiglio di eliminarli dalla grafica (Topic).
Detto questo, dalla tua descrizione non mi è chiaro il tuo problema, il modo migliore è di inviare alla mail di supporto (Vedi link) il tuo progetto in modo che io possa capire il tuo problema.
Sergio Bertana
Amministratore del forumVisto che hai già esperienza di programmazione di altri prodotti, credo che il passaggio all’ambiente LogicLab sia semplice, inoltre come hai detto tu la guida PLC in pratica è un ottimo supporto. Nel forum troverai inoltre molti esempi di programmi in codice sorgente pronti per il download.
Per quanto riguarda la tua domanda sulla comunicazione tra il pannello HMI ed il PLC, utilizzando EasyBuilder Pro puoi sviluppare il progetto HMI e poi testarlo direttamente connesso al modulo CPU (Il simulatore funziona per 15 min). In questo topic un progetto di esempio, il progetto è sviluppato con il vecchio tool EasyBuilder 8000 ma lo puoi importare in EasyBuilder Pro.
Consiglio… Se acquisti un modulo CPU per delle prove ti consiglio il modello Compact con ethernet, così puoi testare tutte le funzionalità del prodotto e nella simulazione con l’HMI utilizzando la ethernet puoi eseguire contemporaneamente il debug della applicazione PLC con LogicLab.
Inoltre se dovessimo attivare un supporto tecnico On-Line la connessione ethernet permette a noi di “vedere” tutti i dispositivi da remoto.
Sergio Bertana
Amministratore del forumLa crittografia sulla comunicazione WiFi è attivabile in tutte le configurazioni, e sicuramente anche in configurazione access point e stations che è là più utilizzata per la distribuzione del segnale WiFi.
Il fatto che la rete degli SlimLine sia connessa ad router ADSL di fatto non incide sulla sicurezza, il problema nasce solo se tu configuri il router per avere accesso in NAT dalla rete Internet verso la rete locale magari per la programmazione remota dei dispositivi SlimLine.
In questo caso se dai accesso da Internet alla porta del Modbus per evitare che i dispositivi SlimLine vengano programmati da eventuali hackers dovrai disabilitare da Telnet il protocollo modbus (Comando sysconfig -mtcpd). Potrai abilitarlo solo quando vuoi accedervi tu per la programmazione (Comando sysconfig -mtcpe).
Sergio Bertana
Amministratore del forumSui sistemi programmabili con LogicLab come hai fatto giustamente notare esiste una libreria per la completa gestione del modem. Non abbiamo fatto il porting della libreria con CODESYS ma credo che puoi trovare librerie analoghe già pronte sul mercato.
Eventualmente puoi gestire direttamente da programma ST i comandi AT del modem per gestire l’invio dei messaggi SMS (Topic).
Aprile 9, 2015 alle 6:05 am in risposta a: Strane differenze tra simulazione e risultati reali #38876Sergio Bertana
Amministratore del forumInformato Axel del problema, posto la risposta ricevuta.
Abbiamo effettivamente verificato, non funziona il cast implicito di una costante come parametro a una funzione. La soluzione, per ora, è appoggiare il paramentro su una variabile (o aggiungere .0 alla costante). Apriamo il ticket #LL-1418: Wrong implict conversion to REAL of a costant, passed as function’s argument
Aprile 7, 2015 alle 8:02 am in risposta a: Strane differenze tra simulazione e risultati reali #38875Sergio Bertana
Amministratore del forumHo visto il tuo progetto e l’errore che hai commesso è nella definizione dei valori di limite alla funzione ValueScale, la funzione vuole un valore di tipo REAL che vanno sempre definiti con l’indicazione del decimale. In pratica non devi scrivere 0 ma 0.0, non 10 ma 10.0, ecc…
Probabilmente il compilatore sul simulatore è in grado di convertire il formato in REAL mentre il compilatore sul target non esegue la conversione. Farò presente questa discrepanza alla Axel.
Ecco lo screenshot del programma in esecuzione sul sistema target (SlimLine con modulo espansione 20I/O mixed signal), allego programma sorgente.
Sergio Bertana
Amministratore del forumEsame superato a pieni voti… Con il FB IOEncoder si possono utilizzare due ingressi digitali per acquisire segnali da un encoder in quadratura. Naturalmente essendo la gestione tutta software occorre che il ciclo macchina di esecuzione del FB sia compatibile con la frequenza massima dell’encoder da acquisire.
Dovendo campionare i segnali encoder almeno 4 volte per ciclo, se ne deduce che la frequenza massima dell’encoder nel caso di FB eseguita ogni 1 mS è di 200 Hz.
Il FB SysGetEncoder invece utilizza un circuito hardware presente nei moduli di I/O che permette di acquisire segnali fino a 50 KHz. Standard è possibile gestire un encoder per modulo di espansione, ma su richiesta possiamo fornire packages hardware specifici per poter gestire più encoders sullo stesso modulo di I/O.
Sergio Bertana
Amministratore del forumSicuramente la tua esposizione è corretta il sistema è fattibile nei termini in cui lo hai esposto. Per la lettura encoder devi usare il FB SysGetEncoder che acquisisce l’encoder tramite il circuito hardware del modulo di estensione. Puoi utilizzare il PWM out del modulo CPU (In questo topic alcune considerazioni in merito).
Per le rampe di accelerazione e decelerazione puoi utilizzare il FB LRamp, Linear Ramp. Ora se il tuo problema è di fare solo un posizionamento e non hai problemi di velocità, concordo con te che è fattibile. Calcoli la traiettoria di rallentamento per arrivare un pò in anticipo sulla quota e poi percorri l’ultimo pezzo in velocità lenta per avere la precisione sulla quota.
Però la tendenza generale è quella di utilizzare drivers intelligenti, il PLC dialoga con il driver (Esempio in modbus), ed è il driver che gestisce il posizionamento. Esistono drivers anche per piccoli motori sia stepping (Topic) che brushless.
In questo topic un programma spartano per la gestione del posizionamento di un asse.
Sergio Bertana
Amministratore del forumLo scenario da te descritto è sicuramente realizzabile, la visibilità ottica tra le tre stazioni e la distanza ridottissima sono garanzia di avere connessioni veloci ed affidabili. Nessun problema sulla velocità delle connessioni TC/IP è normale avere molte connessioni al secondo tra i dispositivi. Come configurazione di rete utilizzando dispositivi Ubiquiti, vedrei bene un Bullet con la sua antenna omnidirezionale per la stazione centrale configurato come access point. Nelle altre stazioni metterei delle NanoStation configurate come Station. Tutti i dispositivi vanno configurati in modalità Bridge.Poi certo sull’unità centrale puoi montare un piccolo switch per collegare il tutto al router ADSL (Magari il router stesso ha già alcune porte in switch).Per lo scambio dati tra i diversi sistemi SlimLine puoi utilizzare il FB UDPDataTxfer (Topic), naturalmente avrai 2 istanze del FB sul nodo centrale per scambiare dati con gli altri 2 sistemi. Un argomento simile al tuo è trattato in questo topic.
Sergio Bertana
Amministratore del forumImpossibile avere certezze nei collegamenti radio, 23 Km sono già una bella distanza da coprire, ma se c’è la perfetta visibilità ottica è realizzabile.
Ubiquiti permette di verificare la possibilità di connessione tra i due punti con l’utility Airlink, definendo le coordinate GPS dei due punti da collegare ed il tipo di apparato che si desidera utilizzare, l’utility tramite Google Earth determina la fattibilità del collegamento. Tramite l’utility è possibile calcolare anche l’altezza dell’antenna dal terreno (Screenshot).
Quindi ti consiglio di verificare la possibilità con l’Airlink e poi vista la distanza e visto l’utilizzo di parabole abbastanza grandi ti consiglio di usare un buon sostegno per gli apparati. Molte volte gli apparati sono montati su pali che a causa del vento si muovono facendo perdere l’allineamento peggiorando la connessione.
Marzo 30, 2015 alle 3:25 pm in risposta a: Come verificare ricezione di interrogazioni Modbus #38866Sergio Bertana
Amministratore del forumSe vuoi utilizzare il FB ModbusSlave sulla porta 502, devi da pagina web di configurazione modificare la porta in ascolto della gestione Modbus embedded.
Però attenzione con la gestione da FB non puoi effettuare nè debug nè programmazione, quindi dovresti utilizzare il FB sulla porta 502 per le interrogazioni Modbus e la gestione embedded su di un’altra porta per le operazioni di debug e programmazione.
Ma se il tuo problema è verificare il funzionamento del router 3G, perchè non usi semplicemente un ping ad un IP pubblico, esempio il DNS di Google (Topic). Solo se il router funziona ed è connesso ad Internet il ping ritorna esito positivo, così ti eviti tutto il lavoro di modifica sul protocollo Modbus.
Sergio Bertana
Amministratore del forumLa mia esperienza con i modem è nata dallo svilupo del blocco funzione di gestione modem per i nostri sistemi SlimLine (Topic). Nella nostra libreria è il PLC che interroga il modem per verificare se ha ricevuto messaggi SMS con il comando AT+CMGR, e dopo avere letto il messaggio lo cancella con il comando AT+CMGD.
Quello che ho visto con i messaggi lunghi è che in testa al messaggio vi sono uno o più caratteri “0” che vengono interpretati dalle funzioni stringa del PLC come terminatore di stringa e questo porta a problemi nella interpretazione della stringa. Non sò se questo è riferibile al tuo problema.
Marzo 30, 2015 alle 9:19 am in risposta a: Collegamento inverter PowerOne convertitore Ethernet/Seriale #38863Sergio Bertana
Amministratore del forumIl convertitore ATC-1000 và impostato come server TCP e fà da gateway tra il TCP/IP e la seriale. Quindi certo devi connetterti al suo indirizzo IP ed alla porta TCP che hai configurato dalla pagina web del convertitore.
Sergio Bertana
Amministratore del forumNella nostra gamma di prodotti non abbiamo un convertitore di protocollo per l’OpenTherm, però cercando in Internet ho trovato dei convertitori di protocollo.
Ho anche visto che esiste la documentazione del protocollo ed anche un progetto realizzato ad-hoc. Ho dato una occhiata veloce al protocollo, la comunicazione è a 1000 Bit/Sec. Quindi connettendo il bus con una opportuna interfaccia hardware a degli I/O logici di un PLC ed eseguendo una scansione degli stessi almeno ogni 250 uS credo che con un pò di tempo a disposizione sia anche possibile gestire direttamente il protocollo.
Ad esempio con la nostra famiglia di sistemi programmabili SlimLine è possibile gestire gli I/O in una task fast eseguita ogni 250 uS. Nel forum troverai esempi di programmi che trattano l’argomento (Topic, topic).
Marzo 30, 2015 alle 6:41 am in risposta a: Come verificare ricezione di interrogazioni Modbus #38860Sergio Bertana
Amministratore del forumA differenza del blocco funzione ModbusSlave dove il bit Done si attiva per un loop ad ogni ricezione di stringa di interrogazione, per la funzione slave embedded nel sistema operativo non è prevista alcuna segnalazione. Per risolvere il tuo problema hai due possibilità.
Utilizzi il FB ModbusSlave, per fare questo puoi abiltare il FB su una porta diversa dalla 502, in questo modo hai anche la possibilità di abilitare il protocollo Modbus solo sull’area di memoria che vuoi modificare, mentre la gestione embedded opera su tutta l’area della DB 100.
Se invece vuoi utilizzare la gestione embedded, puoi gestire una variabile UINT che dovrai scrivere dal sistema master. Ad esempio la puoi azzerare da master mentre il programma SlimLine la valorizza ad 1. Se la variabile rimane valorizzata per il tempo di controllo significa che il master non ha fatto accessi.
-
AutorePost