Ricorsione

[claudio]

Direi di essere riuscito a risolvere il problema. Ho aumentato il tempo di watchdog (credo non si possa escludere mentre lo si può aumentare fino a 6 secondi) e poi ho aggiunto, all'iterno della funzione ricorsiva, una chiamata alla funzione RE_TRIGR(), che ricarica il watchdog. In simulazione pare funzionare tutto corettamente, domani proverò a vedere cosa accade su un PLC vero

[claudio]

Risultato dopo la verifica su PLC vero: nonostante l'inserimento della funzione RE_TRIG() dentro alla funzione ricorsiva, il PLC va comunque in STOP, come se se ne fregasse di RE_TRIG() (cercherò di trovare qualche informazione in più i rete su come dovrebbe funzionare questo comando). Direi di averle provate tutte, inserendo RE_TRIG anche in un OB di interrupt ciclico richiamato ogni 100 msec. ma niente da fare. Mi sa che vedrò di convertire la ricorsione in qualcosa di non ricorsivo perché così non ci salto fuori ...

[lucios]

Quote

 

Non sono un esperto di Siemens quindi non posso aiutarti però ti direi di controllare bene il tuo algoritmo perchè se il PLC va in stop ciò è quasi sicuramente dovuto ad un loop infinito nella ricorsione, quindi il punto di uscita dalla ricorsione stessa è errato.

Certo è che i sistemi operativi dei PLC non sono i più adatti per gestire queste tecniche di programmazione poichè il realtime ha le sue esigenze...

 

Domanda da "quasi" profano di Siemens: ma non esistono dei task che vengono eseguiti indipendentemente dal tempo di ciclo del PLC?

Io mi ricordo che nei vecchi sistemi dei CNC NUM c'era la possibilità di armare task che venivano eseguiti nel tempo inutilizzato dai task realtime, quindi il risultato si poteva ottenere dopo svariati cicli di real time clock, che dipendevano dal carico imposto dai task ciclici realtime appunto.

In genere si usavano per gestire cose "lente" quali: grafica, gestione di porte seriali, ecc.

 

 

[claudio]

Grazie del consiglio Lucios, proverò a ricontrollare meglio di non aver fatto errori nella scrittura del codice, ma non credo. Anche perchè in simulazione svolta in TIA Portal tutto funziona bene: viene si segnalato il superamento del tempo di watch-dog  ma la CPU non va in stop (non capisco il perchè, forse è un limite del simulatore). ma il risultato finale proposto è corretto (anche se ci vuole circa un minuto perchè il PLC faccia la prima mossa, tempo che poi scende a pochi secondi sulla seconda mossa del PLC e così via). Io non sono proprio esperto dell'ambiente di progettazione Siemens, quindi quello che sto per scrivere vuol preso con le molle. Ci sono degli OB che vengono eseguiti al di fuori del ciclo di scansione (ad esempio trask di interrupt) ma la loro esecuzione incide sulla durata complessiva del ciclo di scansione, allungandolo. Ad esempio se è in esecuzione OB1 e viene interrotto da OBx, al termine di OBx riparte OB1 e giunge al suo termine; ma se OBx è molto lungo, si potrebbe andare oltre il tempo di scansione e la CPU va in stop (almeno credo che funzioni così, spero mi perdonerete, e mi correggerete, se ho scritto delle idiozie)

 

[bobbalob]

Il sig. Livio mi sa che di esperto ha ben poco.

Ciò che lui chiama porcata (ossia la ricorsione) è un fondamento della programmazione, esistono linguaggi di programmazione (es. prolog) unicamente ed interamente basati sulla ricorsione.

 

Andar fiero del codice "spaghetti-like" è come essere fieri di cag**e per terra. 

Senza offesa.

 

[Livio Orsini]

Se al primo messaggio riapri una discussione ferma da oltre 2 anni, solo per insultare senza aver nemmeno capito quello che è stato scritto. già ti qualifica negativamente.

vedremo se e come proseguirà la tua participazione al forum

Modificato: 30 luglio 2020 da Livio Orsini