Enrico Viviani
Risposte nei forum create
-
AutorePost
-
Enrico Viviani
PartecipanteIn realtà Windows 11 non ha una “vera” modalità tablet. Se hai dimestichezza con lee impostazioni di sistema dovresti verificare che nel registro di sistema sulla chiave HKLM\SOFTWARE\Microsoft\TabletTip\1.7 sia impostato il valore 1 alla voce TipbandDesiredVisibility. Se non c’è la voce, va creata come valore DWORD
Un’altro controllo da fare è che tra i servizi sia attivo “Servizio di tastiera virtuale e pannello per la grafia”.
In generale però, in assenza di driver specifico, Windows 11 mostra l’icona della tastiera virtuale e non la apre automaticamente alla selezione di un campo.
Windows 11 offre una funzionalità avanzata per risolvere questi limiti che si chiama “Power Automate”
Enrico Viviani
PartecipanteRispondo per quanto ne so, e per esperienza personale. La memoria ritentiva dovrebbe essere su FeRam che promette un minimo di 10^10 cicli. Essendo simile alla DRam necessita di due cicli anche per la lettura perché quest’ultima è “distruttiva” per i dati contenuti.
Per esperienza personale, variabili ritentive riscritte almeno un migliaio di volte al giorno per, finora, quasi dieci anni non hanno causato problemi.
Luglio 3, 2023 alle 12:10 pm in risposta a: Realizzazione macchina di collaudo con lettura QRCode #72947Enrico Viviani
PartecipanteSecondo la mia personale esperienza, converrebbe usare un mini-pc che gestisca il traffico dati anche per offrire al cliente una futura espandibilità con implementazioni successive. Posso aiutare in questo con il software lato PC che usa librerie di mia concezione molto semplici e scalabili.
Enrico Viviani
Partecipante“In caso del guasto del PLC”… è più probabile che si guasti un passo-passo.
Personalmente credo che il passo-passo sia una buona scelta per il consumo e funzionalità, io uso spesso quelli di ABB che, con il comando in bassa tensione (12-24v), sono pilotabili anche con le uscite statiche dei PLC.
Se usi un doppio contatto hai anche il feedback (anche se solo meccanico), un feedback elettrico sull’effettiva alimentazione del carico sarebbe piuttosto oneroso a mio avviso ma esistono degli ssr della aukey che ho già usato che hanno ingresso 230v e uscita statica a 24v.
Per i sensori di temperatura secondo me una rete OneWire è rischiosa nel cablaggio misto (rete e segnale), se non puoi separare le tubazioni consiglio di usare una RS485 più robusta.
Enrico Viviani
PartecipanteSe posso dare un mio parere da utilizzatore dei prodotti Elsist, è molto più probabile che si guasti un sensore o un attuatore che un modulo CPU. Il primo sistema che ho acquistato è in funzione, credo, da 15 anni senza una minima incertezza praticamente all’aperto su un depuratore chimico.
Se la ridondanza è necessaria e deve intervenire in modo automatico il progetto diventa estremamente complesso proprio per il fatto che bisogna far si che non ci sia alcun elemento debole nella catena. Va quindi resa ridondante l’alimentazione e la linea di alimentazione, ecc..
Io ho dovuto affrontare un problema simile nella gestione ambientale (temperatura, umidità, alimentazione, vibrazioni) di un ced ed ho in pratica realizzato due sistemi paralleli e completamente autonomi che comunicano tra loro via ethernet il rispettivo stato, ogni 3 giorni si scambiano il ruolo di master così sono comunque entrambi in funzione e possono “autotestarsi”.
Un sistema terzo (su PC) poi fa da supervisore e gestore degli eventuali allarmi.
Enrico Viviani
PartecipanteGrazie per il supporto. A riprova di quanto discusso, dato che il Panasonic in uso non supporta il protocollo ASCII (se non usando un modulo esterno) ho provato questo:
Invertendo le porte in effetti sul Panasonic non avvengono più gli errori di trasmissione ma non riesco ad usare la funzione Gateway per accedere all’altro slave (la uso per programmarlo dato che non è fisicamente accessibile percui è indispensabile).
Portando a 25 DTROnTime e a 5 DTROffTime riesco ad eliminare completamente gli errori Modbus (1 ogni 620.000 trasmissioni è un valore accettabile), se lascio a 0 OffTime non ottengo le stesse prestazioni, inoltre ho inserito un ritardo di 10 mS sulla FB MobusMaster e mi sembra che tutto lavori correttamente.
Quindi attualmente ho l’altro SlimLine sulla COM0 e il Panasonic sulla PCOM0.0 entrambi a 19200 E 8 1 e con IFTime come da manuale a 1720, l’unica differenza che sulla PCOM ho impostato DTROnTime a 25 e DTROffTime a 5.
In un particolare momento dell’esecuzione invio di seguito 32 messaggi da 32 word (sono i parametri del Panasonic) e ne leggo 12 da 30 word in meno di 2 secondi (prima potevano occorrere anche 3 minuti dato che in caso di errore reinviavo o rileggevo lo stesso messaggio).
Enrico Viviani
PartecipantePurtroppo succede che il programma gira sulla back e sono arrivato ad un IFTime di 15000 con velocita 19200 senza ottenere esiti positivi, altri suggerimenti ?
Potrebbe essere il caso che il buffer della seriale non sia adeguato o che, siccome gestisco contemporaneamente anche le uscite analogiche la CPU del modulo “non ce la faccia ?”.
Un ulteriore nota a rafforzamento di quello che ho sperimentato, su uno dei moduli sto usando la COM in dotazione alla CPU con lo stesso programma e, pur con le impostazioni “consigliate” da manuale, non da mai come risultato l’errore citato.
Enrico Viviani
PartecipanteMa l’uso di dispositivi esterni “non industriali” esula dal senso del trattato e dell’oggetto che devo realizzare. Speravo di poter usare i vostri sistemi per una macchina in realtà piuttosto semplice ma dovrò tentare un altra strada.
Marzo 13, 2015 alle 9:19 am in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38815Enrico Viviani
PartecipanteLa domanda sul nome delle seriali è legata al fatto che sull’etichietta della cpu le due porte sono identificate come “COM0” e “COM1” mentre sul manuale è riportato un altro nome.
Marzo 12, 2015 alle 5:38 pm in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38801Enrico Viviani
PartecipanteGrazie della precisazione sul modello, l’ho scoperto anch’io adesso che mi è stato inviato il CAN e non il RS485, che in realtà volevo ordinare. Spero sia stato un mio refuso e non un vostro. Provvederò a rifare l’ordine.
Una sola altra domanda, se imposto le altre porte presenti nella cpu CODESYS come COM0 o COM1 mi da errore 9946070, se dovessi usare un convertitore come si chiamano le due porte presenti ?
Marzo 12, 2015 alle 10:29 am in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38799Enrico Viviani
PartecipanteVisto che non sò se lo strumento IME funziona ho provato un’altra strada. Possiedo una CPU SlimLine LogicLab MPS050 con RS485, ho collegato il modulo CPU CODESYS con il modulo CPU LogicLab, ho impostato la seriale dei due moduli con le stesse caratteristiche (19200,N,8,1) nodo 2, ovviamente c’è un programma stupido nella CPU LogicLab, scrive il valore 100 nella variabile word MW100.100 al primo loop e non fa altro.
Nel modulo CPU CODESYS c’è solo il programma (scaricato dal vostro sito) con la funzione master, ho impostato la porta (ho provato COM2 e COM3 e COM4), gli stessi parametri, uso la funzione 16#03 per leggere la variabile 100 ma ottengo sempre e solo l’errore 10007050. Forse mi stò perdendo qualcosa, allego screenshot programma CODESYS con lo Spy su Toolly.
Marzo 11, 2015 alle 4:07 pm in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38796Enrico Viviani
PartecipanteSi a tutte le domande, sul dispositivo non posso impostare numero di bit e stop, ma ho provato già tutte le velocità possibili e le parità possibili.
Marzo 9, 2015 alle 5:18 pm in risposta a: Disponibilità protocollo Modbus sullo SlimLine CODESYS #38791Enrico Viviani
PartecipanteSalve, sto tentando di utilizzare le funzioni modbus con un dispositivo della IME il Nemo D4-Le. Oltre a non capire se riesce la connessione o no (va sempre in timeout), leggo dal manuale che il protocollo del dispositivo prevede l’uso di un CRC nella trasmissione del messaggio. Come posso implementare tale funzione ?
Settembre 14, 2014 alle 9:14 am in risposta a: Rete di comunicazione modbus tra moduli SlimLine #38414Enrico Viviani
PartecipanteHo risolto il problema, il malfunzionamento era dovuto al guasto della porta fieldbus del “master”. Usando, infatti un convertitore RS232-RS485 e una delle seriali in dotazione al “master” la comunicazione funziona regolarmente.
Agosto 27, 2014 alle 8:54 pm in risposta a: Come gestire il cambio lingua sui terminali Weintek #38389Enrico Viviani
PartecipanteGrazie per l’aiuto e per il consiglio, la mia non era una lamentela ma solo volevo far notare la presunzione nella risposta. A volte i vostri clienti commettono degli errori e delle superficialità anche nell’utilizzo degli strumenti. Vogliate accogliere le nostre lacune e accettare la nostra ignoranza.
-
AutorePost