Regole dell'ombra

Nel CODESYS in linea di principio è consentito utilizzare lo stesso identificatore per elementi diversi. Ad esempio, un blocco e una variabile possono avere lo stesso nome. Tuttavia, per evitare confusione, questo dovrebbe essere evitato.

Esempio 306. Esempio

Esempio negativo: nel frammento di codice seguente, un'istanza di blocco funzione locale ha lo stesso nome di una funzione:

In un caso come questo, non è chiaro se l'istanza o la funzione venga chiamata nel programma.

FUNCTION YYY : INT
;
END_FUNCTION

FUNCTION_BLOCK XXX
;
END_FUNCTION_BLOCK

PROGRAM PLC_PRG
VAR
    YYY : XXX;
END_VAR
YYY();
END_PROGRAM

Comportamento del compilatore durante lo shadowing

Il compilatore non segnala errori o avvisi se lo stesso identificatore viene utilizzato per elementi diversi. Invece, il compilatore cerca nel codice in un ordine specifico la dichiarazione dell'identificatore. Se viene trovata una dichiarazione, il compilatore non cerca altre dichiarazioni altrove. Se esistono altre dichiarazioni, vengono "ombreggiate" per il compilatore. La sezione seguente descrive le regole di shadowing (ovvero l'ordine di ricerca utilizzato dal compilatore durante la ricerca della dichiarazione per gli identificatori). La sezione "Accesso ambiguo e accesso qualificato" fornisce modi per impedire l'accesso ambiguo e aggirare le regole di shadowing.

Come prevenire l'ombra

Per assicurarti che i nomi siano sempre univoci, dovresti seguire le convenzioni di denominazione, come alcuni prefissi per le variabili.

Per ulteriori informazioni, vedere: Designazione dell'identificatore

Le convenzioni di denominazione possono essere verificate automaticamente utilizzando l'analisi del codice statico di CODESYS. L'analisi statica del codice potrebbe anche rilevare l'uso duplicato del nome YYY e segnalalo come errore.

Anche attraverso l'uso coerente dell'attributo qualified_only per enumerazioni ed elenchi di variabili globali e utilizzando librerie qualificate è possibile evitare situazioni non univoche.

Per assicurarsi che una POU con lo stesso nome nel file Dispositivi vista non viene chiamata quando una POU in POU vista viene chiamato, l'operatore __POOL deve essere anteposto quando viene chiamato il nome della POU.

Esempio: svar_pou := __POOL.POU();

Ordine di ricerca nell'applicazione

Quando il compilatore rileva un singolo identificatore nel codice di un'applicazione, cerca la dichiarazione corrispondente nel seguente ordine:

Variabili locali
1. Variabili locali di un metodo
2. Variabili locali nel blocco funzione, nel programma o nella funzione e in qualsiasi blocco funzione di base
3. Metodi locali della POU
Variabili globali nell'applicazione, se il qualified_only l'attributo non è impostato nell'elenco delle variabili in cui sono dichiarate le variabili globali
1. Variabili globali nell'applicazione, se il qualified_only l'attributo non è impostato nell'elenco delle variabili in cui sono dichiarate le variabili globali
2. Variabili globali in un'applicazione padre, se il qualified_only l'attributo non è impostato nell'elenco delle variabili in cui sono dichiarate le variabili globali
3. Variabili globali nelle librerie di riferimento quando né la libreria né l'elenco delle variabili richiedono un accesso qualificato
POU o nomi dei tipi
1. POU o digitare i nomi dall'applicazione (ovvero, nomi di elenchi di variabili globali, blocchi funzione e così via)
2. POU o digitare i nomi da un'applicazione padre
3. POU o digitare i nomi da una libreria
Biblioteche
1. Spazi dei nomi di biblioteche riferite localmente e biblioteche pubblicate dalle biblioteche
Variabili globali nel POU vista, a meno che il qualified_only l'attributo è impostato nell'elenco delle variabili in cui sono dichiarate
1. Variabili globali nel POU vista, a meno che il qualified_only l'attributo è impostato nell'elenco delle variabili in cui sono dichiarate
2. POU o digitare i nomi da POU vista (ovvero nomi di elenchi di variabili globali, blocchi funzione e così via)
3. Biblioteche da POU

Suggerimento

Biblioteche che vengono inserite nel Gestore Biblioteche del POU vista vengono rispecchiate in Library Manager in tutte le applicazioni del progetto con la risoluzione del segnaposto appropriata. Queste librerie formano quindi uno spazio dei nomi comune con le librerie nell'applicazione. Pertanto, non vi è alcuna ombreggiatura delle librerie nel pool da parte delle librerie nell'applicazione.

Ordine di ricerca in libreria

Quando il compilatore incontra un singolo identificatore nel codice di una libreria, cerca la dichiarazione corrispondente nel seguente ordine:

Variabili locali
1. Variabili locali di un metodo
2. Variabili locali nel blocco funzione, nel programma o nella funzione e in qualsiasi blocco funzione di base
3. Metodi locali della POU
Variabili globali
1. Variabili globali nella libreria locale, se il qualified_only l'attributo non è impostato nell'elenco delle variabili in cui sono dichiarate le variabili globali
2. Variabili globali nelle librerie di riferimento quando né la libreria né l'elenco delle variabili richiedono un accesso qualificato
Biblioteche
1. POU o tipi di nomi dalla libreria locale (ovvero nomi di elenchi di variabili globali, blocchi funzione e così via)
2. POU o digitare i nomi da una libreria referenziata
3. Spazi dei nomi di biblioteche referenziate localmente e biblioteche pubblicate da biblioteche referenziate localmente

Accesso ambiguo e accesso qualificato

Nonostante questi ordini di ricerca, può ancora verificarsi un accesso ambiguo. Ad esempio, questo è il caso in cui una variabile con lo stesso nome esiste in due elenchi di variabili globali che non richiedono l'accesso qualificato. Tale caso viene segnalato dal compilatore come un errore (ad esempio: Uso ambiguo del nome XXX).

Questo tipo di utilizzo ambiguo può essere reso univoco tramite accesso qualificato, ad esempio accedendo tramite il nome dell'elenco delle variabili globali (esempio: GVL.XXX).

L'accesso qualificato può essere sempre utilizzato anche per evitare regole di shadowing.

Il nome dell'elenco delle variabili globali può essere utilizzato per accedere in modo univoco a una variabile nell'elenco.
Il nome di una libreria può essere utilizzato per accedere in modo univoco agli elementi della libreria.
Il THIS puntatore può essere utilizzato per accedere in modo univoco alle variabili in un blocco funzione, anche se esiste una variabile locale con lo stesso nome in un metodo del blocco funzione.

Per trovare in qualsiasi momento la posizione della dichiarazione di un identificatore, utilizzare il Modifica → Sfoglia → Vai a Definizione comando. Questo può essere particolarmente utile se il compilatore produce un messaggio di errore apparentemente oscuro.

Ricerca nei percorsi di istanza

Gli ordini di ricerca descritti sopra non si applicano agli identificatori che esistono come componenti in un percorso di istanza o agli identificatori utilizzati come input nelle chiamate.

Per l'accesso del seguente tipo yy.component, dipende dall'entità descritta da yy dove la dichiarazione di component è cercato.

Se yy denota una variabile con un tipo di dati strutturato (ovvero, type STRUCT o UNION), poi component viene cercato nel seguente ordine:

Variabili locali del blocco funzione
Variabili locali del blocco funzione di base
Metodi del blocco funzione
Metodi del blocco funzione di base

Se yy denota un elenco di variabili globali o un programma, quindi component viene cercato solo in questo elenco.

Se yy denota uno spazio dei nomi di una libreria, quindi component viene cercato in questa libreria esattamente come descritto nella sezione precedente "Ordine di ricerca nella libreria".

Solo nel secondo caso il compilatore decide se è consentito l'accesso all'elemento trovato, cioè se la variabile è accessibile solo localmente o se un metodo è privato. Se l'accesso non è consentito, viene generato un errore.

In questa sezione: