Aggiornamento I/o Su Canopen

[andrea.fa]

Sono alle prese con il canopen di Schneider (isole con hardware OTB + plc premium) ed in particolare con il metodo di aggiornamento degli ingressi. Mi spiego meglio... nel sistema Schneider posso scegliere se fare aggiornare lo stato degli ingressi su "evento" (cioè ad ogni variazione dello stato di ogni ingresso) oppure a tempo (ogni n clock di sincronismo)

A suo tempo il rappresentante Schneider mi aveva consigliato di utilizzare sempre il sistema ad evento in quanto + veloce e meno "stressante" per il bus. Ora in presenza di problemi di aggiornamento (mi perdo il cambiamento di stato di 2 ingressi ogni 50/100 attivazioni ) Schenider mi consiglia di utilizzare il sistema a tempo...

Voi come vi comportate?

ciao a tutti

Andrea

[pidds]

Ciao, uso anche io le otb e le configuro quasi sempre ad evento, ma sono ingressi particolarmente veloci? io non per mai nessun segnale anch epiuttosto veloci, le avevo spesso apprezzate per questo...

Ho fatto applicazioni dove dovevo fermare un motore autofrenante con un segnale di un proxy ( poco elegante magari ma funzionale) e mi si fermava in tempi accettabili...

sei sicuro che il segnale sia compatibile con l'ingresso?

ciao

[andrea.fa]

Il segnale e' ok... anche se un po' basso (da 22.2 a 22.5V) ed è allo stesso livello di un altro centinaio di segnali che (fino ora) funzionano regolarmente. L'unica particolarita' che mi viene in mente e' che l'anomalia si verifica sempre in corrispondenza di una particolare situazione in cui quasi tutti i nodi che compongono la mia rete (12 su un totale di 14) devono aggiornare lo stato dei propri ingressi *quasi* contemporaneamente (difficile stimarlo ma penso tutto avvenga nel giro di pochissimi centesimi si secondo...)

Ovviamente ho gia' provato a sostituire il nodo incriminato ma l'anomalia persiste, allora ho chiamato Schneider che senza scomporsi + di tanto mi ha indicato la soluzione dell'aggiornamento a tempo

Andrea

[Piero Azzoni]

non conosco speciicatamente la struttura Schneider, comunque tieni presente che le specifiche can considerano una priorita' fissa e rigorosa data dall'indirizzo del nodo

verifica che il nodo cui ti riferisci non abbia un indirizzo troppo penalizzante in termini di priorita' ed eventualmente cambialo

[andrea.fa]

il nodo e' a meta' rete (indirizzo 8 su 14) e comunque potrei essere daccordo nel dovere subire un leggero ritardo nell'aggiornamento dovuto ad una momentanea saturazione del bus ma ovviamente non posso tollerare che il mio plc veda a zero un segnale che invece e' a uno fino al prossimo cambio di stato di qualche altro ingresso!!

Il tecnico Schneider ha in verita' consigliato di verificare anche la situazione del contatore di errori del nodo (cosa che pero' non mi e' stata ancora possibile) in quanto non e' escluso che in particolari situazioni qualche trasmissione potrebbe "saltare". Nel mio caso la cosa mi provoca solo qualche incastro meccanico e danneggiamento di alcuni dispositivi ma ovviamente nell'impianto ci sono anche segnali ben + "disastrosi" e se è così facile perdersi delle trasmissioni per strada forse dovrei rivedere un po' tutto il discorso...

Andrea

[Piero Azzoni]

la struttura can controlla la collisioni senza perdita di dati ed a priorita' fissa

conseguentemente un nodo a priorita' [strutturale] bassa aspetta che il bus sia disponibile se un altro (o altri) nodi a priorita' piu' alta vogliono trasmettere contemporaneamente

comunque nel can (preciso, nel can correttamente implemetato) la perdita di dati e' impossibile

[ifachsoftware]

comunque nel can (preciso, nel can correttamente implemetato) la perdita di dati e' impossibile

^^^ Confermo in pieno ; prova a pensare se in un'autovettura non arrivasse il segnale dell'airbag con la giusta priorita' ....

Probabilmente c'e' qualche errore nella configurazione ...

Ciao

[andrea.fa]

Chiudo il thread confermando che con l'acquisizione a tempo (per ora solo sul nodo incriminato) il problema non si e' piu' presentato.... speriamo bene

ciao a tutti

Andrea