Hplc E Ir Da Supervisione

[Kerby]

Ciao a tutti, ho un problema nel controllare da supervisione il trasmettitore IR (RSIR3U). Dunque da ladder ho semplicemente messo un ingresso (%MX400.7) ed un'uscita (%MX223.7), nella riga seguente ho semplicemente inserito un OUTPUT_R settato sull'indirizzo dell'ingresso della riga precedente.

Provando direttamente da ladder su R/W Registers noto che settando su 1 l'ingresso non accade assolutamente nulla... provando da un pulsante in un html il modulo invia un segnale ogni 4-5 pressioni del pulsante.

Invece la cosa non accade se elimino completamente la riga da ladder con il reset dell'ingresso, però in questo caso ho bisogno di fare un reset lato supervisione del bit.

C'è un modo per resettare il tutto da ladder? In alternativa posso da javascript resettare un'intera word?

[del_user_56966]

se inizi col dirci gli indirizzi dei moduli che hai (master e nodo) e cosa vuoi fare fose riesco a capirci qualcosa...

[Kerby]

Eheh in effetti... dunque gli indirizzi sono quelli di default, master 1 (simulato sull'hplc) e nodo 42 per il trasmettitore IR. Vorrei semplicemente poter usare il trasmettitore da web, faccio un semplice esempio: se clicco il pulsante della mia pagina html senza il reset del bit da ladder il trasmettitore invia il segnale ma poi sono obbligato a resettare il bit da supervisione (con difficoltà per invii consecutivi), invece se lascio da ladder il reset l'invio del segnale non funziona.

[del_user_56966]

invece se lascio da ladder il reset l'invio del segnale non funziona.

il ladder lavora in modo sequenziale dall'alto a sinistra esegue la prima riga poi passa alla seconda e cosi via..

questo significa che se fai un attuazione di un relè il suo reset deve stare sempre più in basso nello schema altrimenti viene

eseguito prima il reset che non l'attuazione....

se poi hai uno screen shoot del tuo schema.. magari si fa molto prima a capire cose che non va...

[Kerby]

Certo, ecco lo screenshot

Nelle prime due righe c'è il set-reset mentre nella terza riga c'è l'esempio funzionante senza reset.

[del_user_56966]

secondo me è troppo immediato il reset per poter permettere il trasferimento su Bus, prova a mettere un delay

prima del reset dell'%MX400.7

e se cosi ti funziona

puoi ottimizzare facendo un reset ritardato su 16 relè in contemporanea tramite una WRE16... ciosi eviti di scrivere più programma e sprechi meno memoria...

[Kerby]

Nulla, anche provando con un ritardo da lo stesso problema, anche spostandoli uno al primo rigo ed uno all'ultimo.

Il problema è proprio in presenza del reset, funziona una volta su 6-7 con il reset da ladder.

[del_user_56966]

Il problema è proprio in presenza del reset, funziona una volta su 6-7 con il reset da ladder.

adesso non riesco ma domattina magari faccio una prova e tiro già uno schema funzionante!!...

[AVC_Veronica]

kerbi , fai una prova, scrivilo alla rga prima il reset

alias prima resetti condizionato da bit Mx223.xx alto

e alla riga sotto alzi il bit Mx223.xx come fai ora.

[Kerby]

Grazie mille ad entrambi ma purtroppo nemmeno la soluzione di Veronica va..

[del_user_56966]

Allora... ti do una soluzione testata e funzionante!!

la prima prova che avevo fatto è questa...

il coil di uscita sta attivo fino a che il relè %MX400.0 è attivo!

il relè cade dopo in un tempo di 1 secondo perchè resettato dal Flag di sistema %MX848.13

e già cosi funzionava...

[del_user_56966]

il problema è che il flag di sistema ha un duty_cycle di 500 mS attivo e 500 mS non attivo...

per questo non sempre lo schema funzionarebbe...

allora basta inserire un trigger su fronte per fare in modo che l'evento di reset sia immediato e non prolungato a 500 mS!

e lo schema potrebbe essere questo..

chiaramente se devi fare più comandi invece di resettare il singolo relè %MX400.0 conviene usare un reset a Word dell'intera %MW400

tramite la WRE16 cosi da usare un solo trigger e un solo flag di sistema ogni 16 attuazioni...

[vtalamo]

Ciao a tutti.

Se permettete mi intrometto nel topic per chiedere ad Aleandro qualche informazione in più sugli oggetti da lui utilizzati nella seconda soluzione. Io infatti ho sempre qualche problema quando tento di utilizzarli.

Innanzitutto, purtroppo non riesco a leggere se il trigger utilizzato è un F_TRIG o un R_TRIG. Se non ho capito male la logica dello schema, immagino sia un R_TRIG.

Mi sfugge però ancora una cosa. L'input di tipo P e l'R_TRIG non dovrebbero fare la stessa cosa? Non dovrebbero, cioè, attivare l'uscita per la durata di un solo ciclo di scansione, indipendentemente dalla durata dell'impulso reale sulla risorsa che rappresentano? Come mai li hai messi entrambi in cascata?

Devo dire che l'input di tipo P non sono riuscito ad utilizzarlo. Mi funzionano invece gli x_TRIG. Quando ho visto il tuo schema mi è sorto il dubbio che vadano utilizzati insieme.

Ti ringrazio anticipatamente per i consueti chiarimenti che ci fornirai.

Ciao.

Vittorio.

[del_user_56966]

Innanzitutto, purtroppo non riesco a leggere se il trigger utilizzato è un F_TRIG o un R_TRIG. Se non ho capito male la logica dello schema, immagino sia un R_TRIG.

dato che lo scopo è ottenere l'annullamento del tempo di Duty Cycle in cambio di un impulso breve (1 ciclo macchina)

vanno bene entrambi i fronti....

Mi sfugge però ancora una cosa. L'input di tipo P e l'R_TRIG non dovrebbero fare la stessa cosa? Non dovrebbero, cioè, attivare l'uscita per la durata di un solo ciclo di scansione, indipendentemente dalla durata dell'impulso reale sulla risorsa che rappresentano? Come mai li hai messi entrambi in cascata?

figurati che non me ne ero neppure accorto...

a volte faccio le cose talmente veloci tra un rigo e l'altro del mio lavoro che mi scordo di verificare... si fanno la stessa cosa probabilmente

li avevo inseriti in tempi diversi e non mi sono accorto..

Devo dire che l'input di tipo P non sono riuscito ad utilizzarlo. Mi funzionano invece gli x_TRIG. Quando ho visto il tuo schema mi è sorto il dubbio che vadano utilizzati insieme.

è possibile che in alcuni casi il comportamento sia differente questo è dovuto alla differenza di dati da trattare, i dati getsiti solo in memoria

hanno un tempo gestione diverso da quelli in arrivo/partenza per il Bus.. quindi i fronti sono differenziati tra loro dall'uso dell'area da %MW900 (Delay memory)...

e se hai fatto il corso HomePLC questa differenza dovrebbero averla accennata...

Modificato: 22 febbraio 2012 da Aleandro2008

[vtalamo]

Innanzitutto grazie per la solita disponibilità.

Si, ho fatto il corso base alla NET. Sicuramente accennarono all'area delay ma nel mare di informazioni che assorbimmo nei due giorni, ti dico, sinceramente che non ricordo affatto come funziona.

Devo inoltre dire che in un altro post avevi già accennato a questa cosa proprio relativamente ai fronti e mi ero ripromesso di approfondire. Purtroppo non ne ho avuto ancora il tempo.

Se ti va, appena hai un pò di tempo, potresti spiegarci (uso il plurale per non sentirmi l'unico ignorante... ) qualcosa di più sull'uso di quest'area di memoria. Per esempio, ecco alcune domande. In cosa consiste il ritardo a cui si accenna ("delay memory")? In quali casi è opportuno utilizzare questi registri per memorizzare una risorsa di input?

Grazie ancora e ciao.

Vittorio.

Modificato: 22 febbraio 2012 da vtalamo

[del_user_56966]

Se ti va, appena hai un pò di tempo,

ok, appena ho tempo volentieri... magari ricordamelo nel fine settimana...

[Kerby]

Grazie Ale, l'ho appena provato e funziona alla grande!! Grazie ancora...

[del_user_56966]

Grazie Ale, l'ho appena provato e funziona alla grande!! Grazie ancora

la differenza tra la teoria e la pratica... se ti rispondo senza provare e solo teoria... con un buon 50% di possibilità di commettere qualche errore...

testando la funzione invece si passa alla pratica e il rischio di errori è marginale... come dire si può migliorare ma comunque VA!!...