Vai al contenuto

Sergio Bertana

Risposte nei forum create

Stai visualizzando 15 post - dal 2,551 a 2,565 (di 4,281 totali)
  • Autore
    Post
  • in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38768
    Sergio Bertana
    Amministratore del forum

    Si hai inteso bene, con la funzione Sysfopen apri lo stream I/O di comunicazione che è di tipo FILEP, lo stream va passato poi al blocco funzione di gestione Modbus. Se lo stream di I/O è una seriale si deve utilizzare come nell’esempio il FB SysSerialPort, se invece si tratta di un socket TCP si utilizzerà il FB SysTCPClient o SysTCPServer. Fai riferimento al manuale programmazione IEC61131-3 dove troverai esempi di utilizzo del Modbus master sia su connessione  seriale che TCP client, e del modbus slave sia su seriale che su più socket TCP server.

    in risposta a: Gestione data/ora sui termometri IP HWg-STE #38766
    Sergio Bertana
    Amministratore del forum

    Il termometro IP HWg-STE non ha al suo interno una batteria per il real time clock, quindi alla accensione viene impostata l’ora acquisita tramite una connessione al server NTP. Inoltre è possibile impostare un periodo di sincronismo al server NTP che può essere fissato ogni ora oppure ogni 24 ore (Screenshot).

    Per il corretto funzionamento occorre avre impostato il server NTP corretto ed occorre che l’STE possa accedere ad Internet, nel caso in cui l’STE non possa accedere ad Internet occorre avere nella propria rete locale un server NTP a cui connettersi. Può essere utilizzato il server di rete basta definirne l’IP nel campo SNTP Server. Agendo sul tasto Sync è possibile eseguire la sincronizzazione.

    Per avere l’accesso ad Internet occorre che l’STE sia configurato correttamente con l’indirizzo IP del gateway di rete e del server DNS (Screenshot).

    in risposta a: Integrare SlimLine in un impianto domotico #38765
    Sergio Bertana
    Amministratore del forum

    Da quello che scrivi a pelle sceglierei sicuramente la soluzione b), intanto sulla a) non dici che protocollo si utilizza per dialogare con i cronotermostati, perchè se è un protocollo proprietario non sarebbe possibile interfacciarsi.

    La soluzione b) ti permette di avere lo SlimLine in rete e di poterlo programmare ed eseguire il debug mentre stà funzionando connesso al tuo sistema domotico. Se il server supporta il modbus TCP (A volte viene chiamato Modbus over IP ma sono la stessa cosa) non ci sono problemi a dialogare con lo SlimLine. Lo SlimLine agisce da server Modbus ed il sistema domotico sarà client, la funzione “Electron Drive” mi sembra di capire serve proprio a questo. Ed è normalissimo per gli SCADA interrogare più dispositivi su IP diversi.

    In più lo SlimLine grazie al suo Web server potrebbe avere pagine di servizio accessibili da browser che lavorano in parallelo al sistema domotico. Puoi anche aggiungere dei pannelli operatore per gestire funzioni accessorie.

    Purtroppo non ho esperienza sugli IR, so che esiste un progetto LIRC per Linux che tratta l’argomento, magari ti può essere utile.

    in risposta a: Utilizzo convertitore WiFi-Seriale ATC-1000WF #38764
    Sergio Bertana
    Amministratore del forum

    Con i vari convertitori Ethernet-SerialeWiFi-Seriale viene solitamente fornito un software di virtualizzazione per porta seriale. Il software di virtualizzazione installa nel PC una porta COM aggiuntiva che in realtà è la porta seriale del convertitore. Questi programmi di virtualizzazione alcune volte vanno in conflitto con la configurazione software del PC e si incontrano problemi nella installazione.

    Tra le case da noi distribuite, la HWgroup, ha realizzato un software di virtualizzazione porte COM che nella versione da 1 porta è utilizzabile gratuitamente. Il programma HW VSP3 è basato sul driver Eltima che è uno dei drivers software più utilizzati e più compatibili. Ecco l’utilizzo del VSP3 con un convertitore ATC-1000WF (Screenshot).

    in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38763
    Sergio Bertana
    Amministratore del forum

    Abbiamo citato le Oscat in quanto molti costruttori di prodotti basati su CODESYS ne fanno un gran strombazzare. Queste librerie rappresentano un lodevole impegno nel campo del software libero applicato alla automazione industriale. Anche se personalmente preferisco “costruirmi” la mia libreria di funzioni e FB, trovo apprezzabile il lavoro svolto e mi è succeso di rifarmi alle Oscat per trarre ispirazione su particolari esigenze che poi ho applicato anche per librerie in LogicLab.

    Per quanto riguarda il Modbus sono anni che lo utilizziamo in LogicLab ed è stato normale eseguirne il porting in CODESYS. Lo SlimLine CODESYS è pensato per essere “trasparente” alla versione LogicLab tant’è che lo abbiamo fornito dello stesso set di funzioni ed FB embedded presenti sulla versione LogicLab.

    Lo spirito del forum è di supportare i clienti e certo possiamo farlo nel modo migliore solo se si utilizzano le nostre funzioni ed FB. Però non vogliamo neanche chiuderci nel nostro cortile, e ben vengano esperienze con altre librerie ogni segnalazione è uno stimolo a cercare ed a migliorarsi.

    Sono contento che la battuta a te apparsa sarcastica (In realtà voleva essere ironica) non ti abbia urtato, non è certo mia intenzione urtare le persone. Magari Oscat è il cognome di una bella tedescona… e una telefonata ci può anche stare…

    in risposta a: Definire gli I/O logici in un programma #38760
    Sergio Bertana
    Amministratore del forum

    Consultando il manuale hardware del modulo (Area download in basso alla pagina prodotto) trovi le informazioni riguardo le connessioni degli I/O dei moduli di espansione.

    In generale gli ingressi digitali veloci possono essere utilizzati come tutti gli altri ingressi, sono anche loro mappati nella immagine di  processo degli ingressi. A differenza degli altri, non hanno il doppio diodo LED all’interno e quindi possono solo operare con comune a massa ed ingresso positivo. In più hanno la particolarità tramite opportuni ponticelli di operare anche a 5 volt.

    Quando parli di tramettitore di segnale attivi o passivi ti riferisci a trasduttori con uscita in corrente 4÷20 mA. Da quel poco che ne sò, gli attivi sono alimentati e generano la corrente in uscita, i passivi si alimentano dal circuito di uscita. Ma entrambi possono essere acquisiti dai nostri moduli di ingresso analogico.

    Common o differential sono riferiti al modo di acquisizione del segnale, non c’entrano nulla con attivo e passivo. Qualsiasi tipo di trasduttore può essere acquisisto sia in modo comune che in differenziale. Quando possibile si consiglia il modo differenziale perchè utilizzando un cavo twistato è possibile minimizzare i distrurbi EMI.

    in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38758
    Sergio Bertana
    Amministratore del forum

    Le funzioni a cui ti riferisci non c’entrano nulla con il Modbus, si tratta di funzioni di sistema per gestire le connessioni TCP. Per il modbus i nostri FB sono MobusMaster (Equivalente alla MB_Client) e MobusSlave (Equivalente alla MB_Server).

    A differenza delle FB di Oscat che sono solo TCP/IP e UDP, le nostre possono operare su un qualsiasi stream di I/O (Anche la porta seriale) e gestiscono tutti e 3 i tipi di Modbus (Ascii, RTU, TCP).

    Detto questo quale FB usare è una tua scelta, se usi le nostre FB puoi chiedere informazioni a noi, se usi le Oscat devi rivolgerti al Sig. Oscat…

    in risposta a: Apricancello da chiamata telefonica con database #38756
    Sergio Bertana
    Amministratore del forum

    Utilizzando Toolly possiamo testare il funzionamento del protocollo di comunicazione sia Voi lato server (Nel proseguo Sv) che io lato Modem Machine (Nel proseguo Mm), questo è molto comodo per sviluppare l’applicazione.

    Considerando che i pacchetti UDP sono intrinsecamente sicuri grazie al controllo di checksum del datagramma (Come indicato dalla RFC 768), possiamo ipotizzare uno scambio di informazioni in ASCII. Questo facilita anche il debug via Toolly trattandosi di pure stringhe di testo.

    a) Condivido la scelta di uno scambio dati ciclico (Heartbeat) tra Mm e Sv nell’ottica di garantire il controllo della funzionalità. Mm invia ogni 10 Sec Ready se tutto ok oppure Error:xx in caso di anomalia. Attende la risposta Ok da Sv.

    b) Fissato il numero di telefono su 12 cifre massimo, su ricezione chiamata telefonica, Mm acquisisce il numero ed invia Call:xxxxxx, se numero nascosto invia Call:0000000.

    c) Mm attende la risposta Allowed se accesso consentito, o Denied se non consentito, da Sv. se non riceve risposta dopo un tempo reinvia il numero.

    Su ricezione Allowed viene gestita l’apertura della porta attivando una uscita logica per qualche secondo.

    in risposta a: Estendere connessione seriale in wireless #38755
    Sergio Bertana
    Amministratore del forum

    Esistono due diverse soluzioni al problema. Radiomodem Utilizzando due radiomodem serie DL, uno connesso in RS485 al misuratore fiscale ed uno connesso in RS232 alla stampante. Scegliendo il DL868 normale o versione H non vi sono problemi a coprire i 3 Km di distanza tra i due punti anche se non vi fosse una visuale ottica tra gli stessi (Case, alberi, altri ostacoli).Pro: Semplicità di configurazione, funziona anche senza visuale ottica perfetta. Contro: permette di trasferire la sola connessione seriale.WiFi Utilizzando due NanoBeam a 5GHz è possibile realizzare una connessione WiFi tra i due punti. Connettendo alla porta ethernet delle NanoBeam due convertitori Ethernet-Seriali (Esempio ATC-1000) configurati in modalità paired (Uno server e l’altro Client) è possibile fare transitare la comunicazione seriale tra i due punti.Pro: Permette di trasferire oltre alla seriale qualsiasi comunicazione TCP/IP, Internet, telecamere, VoIP, ecc… Contro: Funziona solo se c’è perfetta visibilità ottica, più complessa la configurazione.

    in risposta a: Utilizzo porte seriali in modalità Full-Duplex #38754
    Sergio Bertana
    Amministratore del forum

    Per la connessione a SCADA e/o pannelli operatore HMI solitamente questi prodotti implementano il protocollo nativo CODESYS. Ad esempio i nostri pannelli operatore implementano il protocollo nativo (Estratto manuale).Per il Modbus nessuna preoccupazione, abbiamo sviluppato FB apposite per gestire il Modbus Ascii, RTU e TCP sia in modalità master che slave (Topic). Come vedi il FB slave opera su una propria area di memoria dove tu da programma mappi le variabili che ti interessa pubblicare sul protocollo.

    in risposta a: Definire gli I/O logici in un programma #38752
    Sergio Bertana
    Amministratore del forum

    Per la gestione dei moduli analogici abbiamo definito dei FB appositi. SysGetAnInp per acquisizione ingressi analogici e SysSetAnOut per la gestione delle uscite analogiche (Fare riferimento al manuale Programmazione IEC61131-3). Occorre istanziare un FB nel programma per ogni canale analogico da gestire.

    Analogamente alle analogiche esistono appositi FB anche per l’acquisizione di Counters, Encoders, ecc, tutti questi FB sono documentati nel manuale di programmazione.

    in risposta a: Definire gli I/O logici in un programma #38750
    Sergio Bertana
    Amministratore del forum

    Come si vede dal menù PLC configuration->Steuerungskonfiguration (Screenshot), ogni modulo di estensione I/O digitale e mappato in memoria con variabili DWORD a 32 bits. Ogni scheda può avere al massimo 32 punti di inputs e 32 punti di outputs, così sono definite 2 DWORD per ogni scheda, compreso il modulo CPU.

    Ad ogni DWORD è stato definito un nome mnemonico SysDIxx per gli ingressi e SysDOxx per le uscite dove al posto di xx vi è l’indirizzo di modulo. Unica differenza per gli I/O del modulo CPU che si chiamano SysCPUDI e SysCPUDO. Nel programma è quindi possibile riferirsi direttamente ai vari I/O indicando lo mnemonico di modulo seguito dal numero di I/O sul modulo (Esempio SysDI01.5, SysDO05.15).

    Da PLC Configuration con un doppio click sul singolo punto di I/O (Screenshot) è possibile assegnare uno mnemonico (Esempio PStart, PStop, ecc) che poi potrà essere referenziato nel programma.

    E’ anche possibile definire gli mnemonici direttamente nelle Global_Variables, in questo caso occorre rifersi alle variabili %IX e %QX (Vista la modularità 32 bits esistono 2 variabili %IX e 2 variabili %QX per ogni modulo di I/O) (Screenshot).

    in risposta a: Apricancello da chiamata telefonica con database #38748
    Sergio Bertana
    Amministratore del forum

    Noi progettiamo, costruiamo e supportiamo tecnicamente dei prodotti programmabili, quindi non forniamo un prodotto finito, ma prodotti che tramite un tool di sviluppo e con un linguaggio (non sconosciuto) ma molto ben conosciuto, e standardizzato dalla norma IEC-61131, permette di realizzare l’automazione richiesta. Come descritto precedentemente appositi FB gestiscono le operazioni complesse permettendo di ottenere velocemente il risultato.

    Il protocollo Modbus è uno standard de-facto di comunicazione ed esiste una valanga di letteratura al riguardo, la specifica è scaricabile anche dal ns sito (Reference Guide). Comunque il programmatore può sviluppare anche un’altro tipo di protocollo di comunicazione (Il forum ha esempi in merito da cui partire).

    Noi non realizziamo programmi completi, ci limitiamo al supporto del cliente nella programmazione (Anche tramite supporto remoto), desideriamo che sia il cliente “padrone” del programma e non debba dipendere da noi per le modifiche. In questo caso la soluzione che ho prospettato è quella di modificare un prodotto già esistente nel modo più generico possibile. Gestire le queries SQL vorrebbe dire stravolgere il prodotto e realizzare una applicazione “sartoriale” sulle Vs necessità.

    Visto che c’è un server dove risiede l’interfaccia di gestione delle tabelle database mi sembra naturale gestire tutto da questo server. Così sarà solo il programma del server che “conosce” l’organizzazione del database facilitando l’eventuale riorganizzazione dello stesso.

    in risposta a: Blocco funzione CTU con conteggio su variabile UDINT #38744
    Sergio Bertana
    Amministratore del forum

    Il blocco funzione CTU come definito dalla norma IEC-61131 opera su una variabile di tipo INT. Ma è estremamente semplice costruirsi un proprio blocco funzione CTU che operi sul tipo di variabile desiderato, il modo più ovvio è utilizzando l’operando ADD (Topic).

    Con LogicLab è possibile costruirsi da soli le proprie funzione e FB (Topic), così nulla vieta di costruirti il tuo CTU modificato con la variabile UDINT. Ti ho preparato un progetto con il blocco funzione MyCTU (Stampa) che altro non è che il CTU standard IEC con il tipo variabile modificato. Il progetto può essere un buon propedeutico per acquisire le tecniche di sviluppo delle proprie FB (Download progetto).

    Solitamente sviluppo le funzione ed i FB utilizzando il linguaggio ST che meglio si presta per la gestione di operazioni complesse, ma nulla vieta nel tuo caso di costruire un FB in linguaggio ladder che contiene al suo interno un ramo con l’operatore ADD.

    in risposta a: Gestione scheda I2C custom connessa come estensione #38743
    Sergio Bertana
    Amministratore del forum

    L’aggiunta di moduli custom connessi al bus è uno dei plus che offriamo, può risultare conveniente abbinare ad un PLC classico con i suoi moduli di I/O ed il suo ambiente di programmazione dei proprii moduli creati su misura per l’applicazione, ed il tuo caso lo dimostra.

    Il bus di estensione I2C viene gestito dal sistema operativo in multitasking, ed i nostri moduli di I/O hanno una logica che garantisce con il CRC sui dati la sicurezza della comunicazione. Tutti gli I/O del PLC mappati in memoria sono gestiti tramite questa interfaccia “sicura” che solo utilizzando la nostra FPGA è possibile garantire.

    Con la funzione SysI2CWrRd è possibile gestire qualsiasi periferica I2C standard, quindi non hai problemi a gestire come da tua esigenza i moduli di I/O standard, il display ed il modulo RFID.

Stai visualizzando 15 post - dal 2,551 a 2,565 (di 4,281 totali)