Antifurto Inim - gia installato qualcuno

[eb89]

si ho capito cosa vuoi dire comunque diciamo che se uno la sa programmare bene rispetta le norme.

[eb89]

E' talmente possibile che t da la possibilita di tralasciare particolari importanti.

Ad esempio io posso fare l'impianto piu sicuro al mondo ma se poi mi dimentico di mettere la richiesta di autorizzazione per il tasto di disinserimento tutta la sicurezza se ne va p..... (come gia si diceva)

Questa è una cosa da fare presente alla INIM

Perche uno che non sa questo piccolo dettaglio o lo dimentica rovina l'intero impianto.

[fisica]

non e' proprio questo che sto dicendo, se fosse cosi' tu dovresti sapere a menadito la norma, invece e' la centrale che non deve permetterlo.

[eb89]

non ci capiamo eheh comunque sto dicendo la stessa cosa (credo), la centrale ti permette di non rispettare la norma, quindi o tu la sai e la programmi come si deve o altrimenti puoi avere tutte le certificazioni del mondo ma non valgono nulla

[fisica]

siccome la domanda iniziale era "se veniene certificata", se consente di uscire dai paletti non puo' troppo...

[eb89]

vedremo in futuro cosa faranno per certificarla.

Per ora non ho altre informazioni

[Nikiki]

Dalle normative è espressamente richiesto che il Bus viaggi su RS485, perchè questo permette il polling delle periferiche e quindi di tutte le variazioni di stato entro un determinato tempo T.

Questo credo che sia errato, conosco centrali che NON usano una rs485 per il bus e sono certificate IMQ e EN50131. Sicuramente le normative richiederanno un polling entro un determinato tempo, ma non credo che la normativa richieda "espressamente" una 485, l'aspetto fisico del bus dovrebbe essere una facoltà del costruttore.

Confermo quanto dici, una 485 può arrivare a 1Km. Sul fatto del cavo posso affermare che il cavo di allarme va benissimo, meglio ancora se è schermato. Per le sezioni rifarsi ovviamente alle normative elettreche. Io utilizzo solitamente 2*0,75+4*0,22 con doppio isolamento per esterno e fino ad ora ho coperto tratte massimo di 800 m senza incorrere in problematiche. Speriamo che continui ad essere così

Non hai specificato la velocità, ma se parliamo di 115 kbps e hai fatto 800 metri con un cavo da allarmi posso affermare con assoluta certezza che sei stato moooolto fortunato!

Lo standard RS485 parla chiaro, è un bus bilanciato, i conduttori devono essere twistati e il bus deve essere lineare (senza stelle), la sezione non è importante, le correnti in gioco sono ridicole, la cosa più importante è la capacità del cavo, ecco perchè un buon cavo è fondamentale. Tutti fanno riferimento al Belden, anche se ovviamente non è l'unico buon cavo, ma quello da allarmi è assolutamente quello meno indicato sia per la capacità che per il fatto di non essere a coppie twistate.

Che poi venga usato spesso si sa, spesso si fanno stelle e nella maggiorparte delle applicazione funziona, ma su tratte relativamente corte e a velocità relativamente basse, non 800 metri a 115 Kbps.

[Livio Orsini]

Che poi venga usato spesso si sa, spesso si fanno stelle e nella maggiorparte delle applicazione funziona, ma su tratte relativamente corte e a velocità relativamente basse, non 800 metri a 115 Kbps.

Come ho scritto in precedenza, senza amplificatori-ripetitori, a 115 kBuade il km o anche solo 800 m non sono taggiungibili, almeno con un minimo di affidabilità.

La RS485 è un protocollo fisico esattamente definito e certificato. Si può scaricare dal sito il diagramma della distanza massima ammessa in funzione dell velocità di trasmissione.

Il degrado del segnale dipende esclusivamente dalla capacità parassita del cavo, capacità tra i conduttori e capacità verso massa. Queste capacità degradano i fronti sino a rendere il segnale non più comprensibile.

Può essere che l'uso di un comune doppino non intrecciato presenti, casualmente, capacità parassite inferiori a quelle di un ottimo cavo schermato; questo collegamento non è comunque migliore, anzi, espone il segnale a tutti i disturbi elettrici e magnetici, quindi l'affidabilità del colelgamento è praticamente inesistente. E' la condizione peggiore perchè non si ha una condizione di funzionamento stabile e sicura.

Detto in italiano corrente: la trasmissione ti può "piantare" nel momento in cui ne hai veramente bisogno.

[dama70]

Prendetela come una critica costruttiva e non come polemica per favore, prima di parlare di normative accertatevi di quello che state per scrivere

[eb89]

A che cosa ti riferisci?

[IL SAGGIO]

Ola a tutti, ecco un pezzo della norma 79-2 che possa servire a tutti. Mi spiace ma io non conosco molte Seriali per il collegamento delle periferiche che non siano degli standard e pu cui non 232 o 485. Se qualcuno ne conosce altri, sono tutto orecchie:

Norma:

Circuiti di ricezione dei segnali provenienti dai rivelatori

Sono i circuiti presenti nella centrale o nei satelliti ad essa collegati aventi la funzione

di realizzare la connessione della centrale stessa con i rivelatori dell’impianto.

Per la configurazione a satelliti è richiesto che il trasferimento dei dati dagli stessi

all’unità di elaborazione avvenga in forma sicura, cioè adottando una modalità di

colloquio dello stesso livello di quello impiegato per il collegamento dei sensori

(vedi Scheda di qualificazione n° 1).

Se sono presenti rivelatori dotati di uscita per la segnalazione dei guasti, è raccomandato

che detti circuiti siano in grado di rivelare anche tale stato.

Se i rivelatori forniscono segnali di tipo impulsivo, la centrale deve considerare

come allarme un segnale di durata superiore a 400 ms, non deve essere considerato

allarme un segnale di durata inferiore a 50 ms (1).

Il tempo di acquisizione dello stato di un rivelatore non deve essere comunque

superiore ad 1 s.

Nel caso in cui la centrale preveda collegamenti seriali, il tempo di acquisizione

dello stato di un rivelatore non deve essere superiore a 10 s.

A seconda della tecnica impiegata, si possono avere circuiti di ricezione basati su

tecniche analogiche o numeriche.

Il permanere dello stato di allarme di uno degli ingressi non deve impedire il corretto

funzionamento degli altri ingressi.

In ogni caso la centrale deve essere in grado di discriminare il fronte di passaggio

dallo stato di riposo a quello di allarme dei rivelatori

Grazie a tutti

[fisica]

come vedi non si parla di standard, una norma generalmente ti lascia liberta' di impiccarti come preferisci.

Esempi di altri? calma un attimo. tu mescoli la RS485 con la RS232. uno e' un criterio di trasporto dati, l'altro e' un protocollo. uno trasporta le cose che butti dentro e le riconsegna si spera intatte, dall'altra parte. rs232 invece ti dice anche come devi fare, come pacchettizzare ecc ecc

altri sistemi di trasporto? c'e' chi usa il 1-wire CAN, c'e' chi usa trasporti simili all'ethernet, oppure il sistema connex, c'e' chi ha usato il LIN. ce ne sono a bizzeffe e tutte costano di piu'.

Per questo la gente usa la RS485, penso.

[Nikiki]

Nelle righe che hai citato si parla soprattutto di caratteristiche dei circuiti (per circuiti sono intesi gli ingressi, detti anche zone).

Per quanto riguarda il bus si richiede che il tempo di acquisizione dello stato non sia superiore a 10 secondi, ma non vedo riferimenti al tipo di bus usato.

In 10 secondi si riescono ad acquisire moltissime informazioni, anche a velocità relativamente basse tipo 9600 bps, la scelta di velocità alte nel caso di Inim è dettata solamente dalla necessità di trasferire l'audio (molto pesante in termini di dati), è ovvio che tale scelta va a influire sulle distanze copribili dal bus.

Ad ogni modo, se l'installatore ha la facoltà di scegliere la velocità non vedo il problema. Sarà l'installatore a scegliere la velocità in funzione dell'impianto che deve realizzare, ma 800 metri a 115kbps la vedo dura.

[Nikiki]

rs232 invece ti dice anche come devi fare, come pacchettizzare ecc ecc

no, tra rs232 e 485 cambia solo il mezzo di trasporto, un filo riferito a massa con livelli +-12 per il primo, e bilanciato su coppia twistata per il secondo. Non ci sono protocolli definiti da questi standard. Di solito la 232 usa 1 bit di start 8 bit di dati e 1 bit di stop, non so se questo è definito dallo standard ma è comunque una sincronizzazione piuttosto comune usata anche con la 485.

Comunque alla fine se non c'è necessità di interfacciamento con il mondo esterno (ad esempio con un PC), il produttore ha la facoltà di usare il protocollo che vuole e il mezzo di trasporto fisico che vuole.

Entrambi sono comunicazioni asincrone, alcune centrali invece ad esempio usano comunicazioni sincrone con linea clock e linea dati, oltre ai vari bus menzionati da fisica.

[eb89]

Siamo un po usciti dal discorso INIM.

[fisica]

direi di no, si parla di come funziona. pero' giustamente si potrebbe chiuderla qui, sia la parte tecnica che quella pubblicitaria

[eb89]

chiuderla no, penso che se qualcuno ha problemi con la inim puo chiedere qui. Quella pubblicitaria si, direi che imparte e colpa mia anche se l'ho fatto senza volerlo alla fine mica c guadagno qualcosa eheh!!!

Pero se mi trovo bene con un prodotto mi piace consigliarlo agli altri.

[del_user_56966]

Di solito la 232 usa 1 bit di start 8 bit di dati e 1 bit di stop,

il "di solito" sulla RS232 non esiste, forse il "di solito" va bene per un dispositivo in particolare che la utilizza...

sia la seriale RS232-C (Standard EIA) che la V.24 (Standard CCITT) a 9 o 25 PIN sono liberamente configurabili quindi non hanno preconfigurazioni prestabilite ne raccomandate!

non so se questo è definito dallo standard ma è comunque una sincronizzazione piuttosto comune usata anche con la 485.

tu stai facendo confusione tra gli standard e un dispositivo finale in particolare!

la RS232 può supportare nei casi più comuni tre parità EVEN, ODD, NONE, i bit di stop possono essere di due tipi,

1 bit di stop, due bit di stop e i dati possono essere sia 8 che 7 ripeto questi sono quelli ultimamente di comune utilizzo

ma se poi entriamo nella descrizione completa riferita alla V.24.... servirebbe un trattato sull'argomento...

Entrambi sono comunicazioni asincrone,

cosa intendi per asincrone?

la RS232 è una comunicazione full duplex mentre la RS485 è una Half duplex

la prima è una comunicazione punto-punto quindi essendo fullduplex può essere anche asincrona,

ma la RS485 essendo multidrop in half duplex se la comunicazione TX/RX non viene sincronizzata non può funzionare!

[Nikiki]

Questo è l'ennesimo intervento inutile, consiglio i lettori di saltarlo per evitare di annoiarsi...

il "di solito" sulla RS232 non esiste, forse il "di solito" va bene per un dispositivo in particolare che la utilizza...

sia la seriale RS232-C (Standard EIA) che la V.24 (Standard CCITT) a 9 o 25 PIN sono liberamente configurabili quindi non hanno preconfigurazioni prestabilite ne raccomandate!

tu stai facendo confusione tra gli standard e un dispositivo finale in particolare!

la RS232 può supportare nei casi più comuni tre parità EVEN, ODD, NONE, i bit di stop possono essere di due tipi,

1 bit di stop, due bit di stop e i dati possono essere sia 8 che 7 ripeto questi sono quelli ultimamente di comune utilizzo

ma se poi entriamo nella descrizione completa riferita alla V.24.... servirebbe un trattato sull'argomento...

Nel nostro caso non serve nessun trattato, stavamo parlando di altra cosa.

Io non faccio confusione, conosco bene l'argomento.

Il "di solito" così come lo intendo io rappresenta la maggior parte dei casi, quindi possiamo affermare che ESISTE. Significa che su 1000 applicazioni almeno 999 utilizzano 1 bit di start, 8 bit di dati e 1 bit di stop. Applicazioni che usano solo 7 bit di dati sono rare, giusto quelle che trasportano un set ridotto di caratteri ascii ma anche nei protocolli ascii nessuno va a complicarsi la vita con 7 bit. Stessa cosa per i 2 bit di stop... significa solo trasmettere un bit in più per niente e quindi non lo usa quasi nessuno. Io non ho parlato ne di configurazioni prestabilite ne di raccomandazioni, semplicemente di casi più frequenti.

Quelli a cui fai riferimento tu sono le impostazioni a livello applicazione, mentre noi stavamo parlando di differenze a livello fisico. Se vogliamo parlare di parità parliamo di 1 bit (quando presente) che può essere calcolata pari o dispari, ma ovviamente non c'entra niente con quello di cui stavamo discutendo.

cosa intendi per asincrone?

la RS232 è una comunicazione full duplex mentre la RS485 è una Half duplex

la prima è una comunicazione punto-punto quindi essendo fullduplex può essere anche asincrona,

ma la RS485 essendo multidrop in half duplex se la comunicazione TX/RX non viene sincronizzata non può funzionare!

Non c'entra niente il full duplex. Si intende una seriale asincrona quella che non ha una linea di sincronizzazione. Il sincronismo è dettato dal tempo, per questo le comunicazioni avvengono ad una velocità fissa predeterminata. Ad esempio a 9600 bps un bit dura 104 uS, chi riceve il dato si sincronizza con il bit di start (il passaggio da stato logico 1 a 0) e sa che dopo 104 uS sulla linea dati troverà il primo bit trasmesso, dopo altri 104 uS il secondo bit, e così via fino al bit di stop.

In una seriale sincrona invece i dati sono sincronizzati da una linea di clock, a seconda del protocollo il dato viene convalidato dal fronte di salita del clock piuttosto che il fronte di discesa, in questo caso non è necessario mantenere una velocità costante nella trasmissione dei dati.

Sono comunicazioni asincrone la 232, la 485, la CAN, ecc. Sono comunicazioni sincrone la maggiorparte dei bus tra dispositivi, come la I2C, la SPI. La stessa parallela dei PC è sincrona perchè il dato viene sincronizzato dal pin "strobe".

Rimanendo in tema di Bus di centrali di allarme (quello di cui stavamo parlando), esistono centrali che hanno una linea di dati e una linea di clock, usano quindi una comunicazione sincrona. In questo caso non si usa cavo twistato. Era solo per sottolineare che non tutti usano la 485.

[del_user_56966]

Significa che su 1000 applicazioni almeno 999 utilizzano

Uno standard si descrive per come viene proposto, non penso che ne per la EIA ne per le V.24 vi siano configurazioni "consigliate"

posso portarti moltissimi produttori che usano configurazioni diverse, per esempio Notifier sulle centrali usa E,8,1 oppure Panasonic su tutta la linea O,8,1 e cosi via ...

non darei per scontato una sola configurazione...

La gestione a 7 bit è usata per estendere lo standard ASCII a ulteriori 128 caratteri quindi tutti i protocolli con ASCII esteso usano 7 Bit.

Il sincronismo è dettato dal tempo,

Anche questo è un uso particolare ma non riferito allo standard EIA, per lo standard la RS232 si gestisce tramite Handshaking harware

(mediante i pin RTS, CTS, DTR, DSR, DCD) oppure via software mediante il controllo di flusso X-ON e X-OFF.

[Nikiki]

Fermati quì, non è il caso che tu vada avanti. E' fin troppo chiaro che non conosci l'argomento!

non penso che ne per la EIA ne per le V.24 vi siano configurazioni "consigliate"

Ancora una volta, ma chi ha parlato di "configurazioni consigliate"? Io parlo di dati statistici, quello che più comunemente viene adottato!

Tutta questa rottura di scatole per aver usato l'espressione "di solito"...

per esempio Notifier sulle centrali usa E,8,1 oppure Panasonic su tutta la linea O,8,1 e cosi via ...

bene... significa che notifire usa un bit di parità pari e panasonic un bit di parità dispari... e allora?

Comunque visto che tu sei uno pignolo, 8,E,1 e 8,O,1.

La gestione a 7 bit è usata per estendere lo standard ASCII a ulteriori 128 caratteri quindi tutti i protocolli con ASCII esteso usano 7 Bit.

... mi sarebbe scappata una battutaccia, anzi... l'avevo già scritta, ma sono troppo educato e l'ho cancellata.

Rileggi quello che hai scritto, probabilmente non ti renderai conto della castroneria che hai scritto ma almeno provaci. E smettila di andare a cercare informazioni in rete, altrimenti poi sbagli a scriverle e fai brutta figura.

Anche questo è un uso particolare ma non riferito allo standard EIA, per lo standard la RS232 si gestisce tramite Handshaking harware

(mediante i pin RTS, CTS, DTR, DSR, DCD) oppure via software mediante il controllo di flusso X-ON e X-OFF.

Altra castroneria, rileggiti anche questa.

Evidentemente l'elettronica non è la tua materia, giustamente un integratore (se non sbaglio è così che ti sei definito) certe cose non le conosce, in questo caso ti posso aiutare io

Stai ancora facendo confusione tra il livello fisico e il livello applicazione, il controllo di flusso si usa per regolare il flusso dei dati poichè in certi momenti l'host potrebbe non essere pronto a ricevere il dato, per cui in questo caso l'APPLICAZIONE deve interrompere la trasmissione (questo è il controllo di flusso).

Quello di cui parlo io invece è il parsing dei bit scandito dal tempo, e non è un uso particolare ma OBBLIGATO se vuoi ricevere il dato. Ma questo è compito dell'UART, all'applicazione non gliene può fregar de meno, lei prende il dato dal buffer e lo processa.

Tanto per fare un esempio a prova di bambino, è la differenza che c'è tra un chimico e la casalinga, il chimico crea il prodotto per la pulizia e la casalinga lo usa per pulire. Alla casalinga non gli frega niente di com'è fatto il prodotto si limita ad usarlo. Se non fosse chiaro la casalinga è l'applicazione.

Allo stesso modo tu probabilmente sai gestire una comunicazione seriale a livello applicazione (in questo caso tu sei la casalinga), ma non hai idea di come i dati vengono trasportati.

Per concludere, sperando che questa pagliacciata non prosegua oltre, ribadisco ancora una volta che la discussione sulle seriali riguardava le differenze FISICHE tra una RS232 e una RS485, più altri metodi FISICI di trasporto. Noi eravamo già abbastanza OT, tu come al solito c'hai messo del tuo.

P.S.

Ai tutti i lettori: chiedo umilmente scusa per avervi sottoposto a questa lettura estenuante e pallosa.

Pace a amore a tutti... (anche ad Aleandro)

[del_user_56966]

Direi che per essere un tecnico fai molti contorni che di tecnico non hanno nulla... va be!...

Io spero di essere più professionale perché riporto solo fonti autorevoli e non i miei pensieri...

Comunque visto che tu sei uno pignolo, 8,E,1 e 8,O,1.

lascio perdere Microsoft che nei suoi S.O setta la COM cosi..

MSComm1.Settings = "115200,n,8,1" ' Le impostazioni della seriale

perché potrebbe non essere alla tua altezza, ma cito la fonte dati:

Byron W Putman - La RS232

Edizione - Tecniche Nuove

Pag. 146 recita:

La struttura fondamentale del comando è Mode COM Baudrate, parità, bit dati, bit stop, opzione P

Ora sono stato non solo pignolo ma inequivocabile...

mi sarebbe scappata una battutaccia, anzi... l'avevo già scritta, ma sono troppo educato e l'ho cancellata.

Rileggi quello che hai scritto, probabilmente non ti renderai conto della castroneria che hai scritto ma almeno provaci. E smettila di andare a cercare informazioni in rete,

A parte la dicitura che non ha nulla di tecnico la mia risposta è, in rete forseci vai tu!..

dalla stessa fonte dati:

Byron W Putman - La RS232

Edizione - Tecniche Nuove

Pag. 29 recita:

Codice ASCII esteso a 8 Bit

Può stupire che il codice ASCII sia costituito da soli 7 Bit quando la dimensione standard dei dati è di 8 Bit, i produttori di computer utilizzano

l'ottavo bit per definire personali espansioni allo standard ASCII ecc..ec...

Se io dico castronerie sono quelle dell'autore Byron W Putman, ma penso a tutti piacerebbe tanto sapere le tue di affermazioni su cosa si basano...?

[Nikiki]

A parte la dicitura che non ha nulla di tecnico la mia risposta è, in rete forseci vai tu!..

dalla stessa fonte dati:

Byron W Putman - La RS232

Edizione - Tecniche Nuove

Pag. 29 recita:

Codice ASCII esteso a 8 Bit

Può stupire che il codice ASCII sia costituito da soli 7 Bit quando la dimensione standard dei dati è di 8 Bit, i produttori di computer utilizzano

l'ottavo bit per definire personali espansioni allo standard ASCII ecc..ec...

Come volevasi dimostrare...

sei andato a cercare informazioni che ti mancavano e poi le hai trascritte male.

Per il set ascii di base sono sufficienti 7 bit, perchè con 128 caratteri (128 sono le combinazioni che si ottengono con 7 bit) si rappresentano tutti i numeri, lettere minuscole, maiuscole e altri caratteri di contorno. Con 8 bit usi un ascii esteso (non con 7 bit). Prova a rileggere quello che avevi scritto nel reply precedente.

La struttura fondamentale del comando è Mode COM Baudrate, parità, bit dati, bit stop, opzione P

Ora sono stato non solo pignolo ma inequivocabile...

Questa te la posso anche passare , comunque per la cronaca io non mi riferivo a come microsoft ha impostato il comando "mode", ma all'ordine in cui i bit stanno nel frame trasmesso: vengono trasmessi nell'ordine il bit di start, i bit di dati, il bit di parità e infine il bit di stop.

Se io dico castronerie sono quelle dell'autore Byron W Putman, ma penso a tutti piacerebbe tanto sapere le tue di affermazioni su cosa si basano...?

Si basano su anni di esperienza, su ore e ore di sbattimento e migliaia e migliaia di righe di codice, per molto tempo scritte in assembly finchè non ho deciso di convertirmi al C. Si basano sul fatto che quando ho cominciato ad usare i microprocessori non avevano un cavolo di UART a bordo e ho dovuto scrivere un bel po' di codice per realizzare una comunicazione seriale asincrona, quindi se permetti posso affermare di sapere con assoluta certezza ed in modo inequivocabile come avviene una trasmissione seriale.

Io non capisco perchè perdo tempo alle 2.00 di notte a scrivere certe cose su un forum pubblico, che probabilmente non interessano a nessuno. Te lo chiedo per favore... finiamola qui.

[del_user_56966]

Con 8 bit usi un ascii esteso (non con 7 bit). Prova a rileggere quello che avevi scritto nel reply precedente.

Si in effetti nello scrivere ho messo 7 al posto di 8 mi sembrava talmente logico e scontato che non ho riletto correttamente... pardon!...

comunque per la cronaca io non mi riferivo a come microsoft ha impostato il comando "mode",

Io invece mi riferisco proprio a come lo si usa tutti i giorni sia per programmare che per impostare gli apparati da software!

Si basano su anni di esperienza, su ore e ore di sbattimento e migliaia e migliaia di righe di codice,

Quindi su esperienza personale, nulla da togliere al merito, ma tralasciando le esperienze personali io porto

dei riferimenti ben precisi e non espongo opinioni personali.....

[Nikiki]

Le mie non sono opinioni, sono fatti, sui quali potrei mettere mano sul fuoco. L'hardware da me sviluppato ha sempre funzionato, funziona ancora, e di solito non va mai oltre la Versione 1.0 . Tu sei libero di pensare quello che vuoi, ma per quanto mi riguarda io non ho bisogno di andare a cercare informazioni su un libro, almeno per ciò che riguarda le comunicazioni seriali, io parlo di argomenti che conosco e non dico mai cose per sentito dire... non so se mi spiego.

Comunque io insisto a dire che le nostre discussioni nascono sempre inutilmente, perchè tu introduci sempre concetti che non hanno niente a che vedere col discorso, e ancora una volta torno a dire che stavamo parlando delle differenze fisiche tra la 232 e la 485 (questa è almeno la terza volta che lo scrivo).

Ma dove sono i moderatori?... com'è possibile che ci facciano continuare questo infinito OT? Sono tutti in vacanza o se la stanno ridendo, pensando: "ma guarda questi due... uno più testone dell'altro!"?