Utilisation des boucles dans CRBasic afin d'empêcher d'avoir des ''skipped scans''

Peut-être que vous êtes comme moi quand il s'agit des "skipped scans" (échantillons manquants). Je n'aime pas les "skipped scans" (échantillons manquants) dans mes centrales de mesure. J'ai été formé à surveiller et je fais de mon mieux pour écrire mes programmes CRBasic de manière à ce qu'ils n'apparaissent pas. Les ingénieurs d'application de Campbell Scientific me disent que les échantillons manquants ou skipped scans sont un signe de problèmes dans mon système de mesure. Quand je les vois, c'est que quelque chose ne va pas, et je dois faire une maintenance sur ma station avant de perdre trop de données.

Les skipped scans, lorsqu'ils apparaissent de cette façon, sont-ils bons ? Ils nous font savoir que quelque chose ne va pas.

Les échantillons manquants ou skipped scans nous indiquent parfois que nous avons un capteur SDI-12 qui ne répond plus correctement ou que le capteur ne délivre pas dans les temps les données. Les skipped scans peuvent également nous dire que certaines fonctions TCP/IP, telles que EmailSend () ou FTPClient (), prennent trop de temps ou ne fonctionnent pas comme elles le devraient. Ce sont d'excellentes informations de diagnostic à utiliser. (Lisez la rubrique d'articles "Trucs et Astuces : Skip Skip Houra" pour plus amples d'informations.)

La séquence d'échantillonnage principale (main scan) et chaque séquence lente ou ''Slow sequence" (jusqu'à quatre dans un programme CRBasic) ont un enregistrement dans le tableau d'état (Status table) montrant combien de fois la centrale de mesure n'a pas pu réaliser un échantillonnage complet. La ligne nommée SkippedScan dans la table d'état nous indique combien de fois l'analyse principale n'a pas été complétée. Les lignes SkippedSlowScan(x), nous indiquent la même chose pour chaque analyse lente ("x" étant le nombre de balayage lent auquel il est associé).

Ainsi, en tant que station ou opérateur de système, le suivi des skipped scans ou échantillons manquants peuvent être très bénéfiques.

Éviter les fausses analyses de Skipped Scans

Il existe des façons dont nous pouvons conserver ces statistiques d'état de sécurité tout en continuant à faire en sorte que la centrale de mesure effectue ce qu'il faut faire sans que cela n'ait donné lieu à des skipped scan erronés.

Qu'est-ce que je veux dire ? Laissez-moi vous donner un exemple.

Utilisation de la fonction EmailRelay()

Récemment, Campbell Scientific a ajouté une nouvelle fonction appelée EMailRelay(). (Vous pouvez en savoir plus à ce propos en consultant l'article du blog “Cela devient plus facile d'envoyer des courriels à partir de votre centrale de mesure !" ). Il vous permet d'envoyer un courrier électronique ou un message texte à vos utilisateurs sans avoir à passer par une configuration complexe de votre courrier électronique ou bien passer du temps avec le responsable informatique, pour avoir accès au système de messagerie du bureau. C'est une excellente fonction qui vous aide à envoyer des alertes rapidement.

Les Ingénieurs support de Campbell Scientific recommandent que les programmeurs de CRBasic ajoutent cette fonction dans l'une des séquences lentes (slow sequences) de leurs programmes. Pourquoi ? Parce qu'il y a des moments (en fonction de la vitesse du réseau, de la charge du serveur, etc.) que la fonction EmailRelay() pourrait prendre plus de temps que prévu à s'exécuter initialement. Peut-être plus longtemps que l'intervalle d'échantillonnage (scan) de la séquence lente. Lorsqu'il se déroule plus longtemps, il peut se dérouler assez longtemps pour qu'il termine sur l'échantillonnage suivant, ce qui provoque l'enregistrement de données en tant que skipped scan.

Est-ce quelque chose dont nous devons nous préocuper ? Dans ce cas, si EmailRelay() est la seule fonction exécutée dans la séquence lente (slow sequence), non. Rien n'a été perdu. La centrale d'acquisition de données pourra envoyer l'alerte. Il aura fallu attendre plus longtemps que prévu pour l'envoyer.

Alors, comment pouvons-nous contourner cela ? Nous ne voulons pas voir apparaitre des ''skipped scans'' ou des échantillons manquants, quand il n'y a pas d'erreur sur laquelle nous devons nous focaliser. Comment ne voyons-nous que des skipped scans dans la table Status, lorsqu'il y a vraiment quelque chose qui ne va pas avec notre système ?

Utilisation de l'instruction Do/Loop

C'est là où une instruction Do/Loop (Boucle) au lieu d'un Scan/NextScan dans une séquence lente (slow sequence) est très utile.

Par exemple, nous pouvons avoir un simple programme CRBasic utilisant EmailRelay() qui ressemble à ceci :

'Main program variables
Public battery_voltage
Public panel_temperature
Public temperature

'EmailRelay() constants
Const _EMAIL_ATTACHMENT = ""
Const _EMAIL_SUBJECT = "Email Message"
Const _EMAIL_TO_ADDRESS = "some.user@campbellsci.com"
Const _CR_LF = CHR(13) & CHR(10)

'EmailRelay() variables
Public email_message As String * 300
Public email_relay_server_response As String * 100
Public email_trigger As Boolean
Public email_tx_success

BeginProg
	Scan (1,Sec,3,0)
		Battery (battery_voltage)
		PanelTemp (panel_temperature,250)
		TCDiff (temperature,1,mV2_5C,1,TypeT,panel_temperature,True ,0,250,1.0,0)
    
		If temperature > 30 Then 
			email_trigger = True
		EndIf
	NextScan

	SlowSequence
		Scan(1,sec,1,0)
			If email_trigger = True Then
				email_trigger = False 'reset my trigger
				email_message = "Warning!" & _CR_LF & _CR_LF
				email_message = email_message & "This is a automatic email message from the datalogger station " & Status.StationName & ". "
				email_message = email_message & "An alarm condition has been identified." & _CR_LF
				email_message = email_message & "The temperature is " & temperature & " degrees C." & _CR_LF 
				email_message = email_message & "Datalogger time is " & Status.Timestamp
				email_tx_success = EmailRelay (_EMAIL_TO_ADDRESS,_EMAIL_SUBJECT,email_message,email_relay_server_response,_EMAIL_ATTACHMENT)
			EndIf
		NextScan
EndProg

Lorsque ce programme est en cours d'exécution et que la température dépasse 30 degrés Celsius, la centrale d'acquisition de données déclenche l'alarme en configurant la variable email_trigger sur True. Dans la séquence lente (slow sequence), qui exécute un échantillonnage toutes les secondes, l'instruction EmailRelay() s'exécute. EmailRelay() prendra certainement plus d'une seconde pour envoyer le message électronique. En fait, il peut prendre jusqu'à 70 secondes si la centrale d'acquisition de données ne peut pas communiquer avec le serveur EmailRelay. Dans les deux cas, la centrale d'acquisition de données enregistrera les échantillonnages manquants (skipped scans) pour la première séquence lente (slow sequence), que EmailRelay () soit ou non réussie.

Donc, mettons EmailRelay() dans une boucle Do/Loop à la place et utilisez CRBasic pour nous dire quand EmailRelay() n'a pas fonctionné :

'Main program variables
Public battery_voltage
Public panel_temperature
Public temperature

'EmailRelay() constants
Const _EMAIL_ATTACHMENT = ""
Const _EMAIL_SUBJECT = "Email Message"
Const _EMAIL_TO_ADDRESS = "some.user@campbellsci.com"
Const _CR_LF = CHR(13) & CHR(10)

'EmailRelay() variables
Public email_message As String * 300
Public email_relay_server_response As String * 100
Public email_relay_results_human_readable As String * 100
Public email_trigger As Boolean
Public email_tx_success

BeginProg
	Scan (1,Sec,3,0)
		Battery (battery_voltage)
		PanelTemp (panel_temperature,250)
		TCDiff (temperature,1,mV200C,U1,TypeT,panel_temperature,True ,0,250,1.0,0)
    
		If temperature > 30 Then 
			email_trigger = True
		EndIf
	NextScan

	SlowSequence
		Do
			If email_trigger = True Then
				email_trigger = False 'reset my trigger
				email_message = "Warning!" & _CR_LF & _CR_LF
				email_message = email_message & "This is a automatic email message from the datalogger station " & Status.StationName & ". "
				email_message = email_message & "An alarm condition has been identified." & _CR_LF
				email_message = email_message & "The temperature is " & temperature & " degrees C." & _CR_LF 
				email_message = email_message & "Datalogger time is " & Status.Timestamp
         
				'1st attempt
				email_tx_success = EmailRelay (_EMAILTO_ADDRESS,_EMAIL_SUBJECT,email_message,email_relay_server_response,_EMAIL_ATTACHMENT)
         
				'If EmailRelay was not successful, let us try one more time.
				If email_tx_success <> -1 Then
					'2nd attempt
					email_tx_success = EmailRelay (_EMAIL_TO_ADDRESS,_EMAIL_SUBJECT,email_message,email_relay_server_response,_EMAIL_ATTACHMENT)
				EndIf
         
				'tell my human what happened with EmailRelay in human speak instead of loggerspeak
				'  my user got this information from the CRBasic help for EmailRelay
				Select Case email_tx_success
				Case -1
					email_relay_results_human_readable = "EmailRelay server received the message from the datalogger successfully!"
				Case 0
					email_relay_results_human_readable = "The connection to the EmailRelay server failed."
				Case -2
					email_relay_results_human_readable = "Execution of the EmailRelay function did not occur due to lack of records or not enough time."
				Case -3
					email_relay_results_human_readable = "A connection to the EmailRelay server was made but there was an error in communication."
				EndSelect    
			EndIf
		Loop
EndProg

En mettant EmailRelay() dans une boucle Do/Loop à la place d'un Scan/NextScan, Do/Loop s'exécute constamment jusqu'à ce que le message email_trigger soit défini sur True. Lorsque cela se produit, le code CRBasic entre les instructions If Then et EndIf est exécuté.

Si EmailRelay() prend 10 secondes pour faire son travail ou 70 secondes pour terminer, la centrale d'acquisition de données n'écrit pas une analyse ignorée. Alors maintenant, nous évitons de voir le rouge dans l'écran Connect de LoggerNet !

Vérification des e-mails ou courriels envoyés avec succès

Comment saurons-nous si la centrale d'acquisition de données a du mal à envoyer des courriels en utilisant EmailRelay() ? Nous pouvons regarder la valeur que EmailRelay() renvoi à la centrale d'acquisition de données, ainsi que les variables de dépannage dans la fonction elle-même.

Dans notre programme en exemple, nous pouvons créer une variable appelée email_tx_success que nous et la centrale d'acquisition de données pouvons utiliser pour déterminer le succès et l'échec.

email_tx_success = EmailRelay (…

Lorsque EmailRelay() est exécuté, il renvoie une valeur à email_tx_success en fonction de ce qui s'est passé. Les détails peuvent être trouvés dans l'aide de CRBasic ou dans les relevés de cas (Case statements) ajoutés au programme CRBasic dans cet exemple.

Nous pouvons également regarder la variable email_relay_server_response pour obtenir plus de détails si nous en avons besoin. Cette variable contient les informations renvoyées à la centrale d'acquisition de données par le serveur EmailRelay(). Lors d'une communication réussie avec le serveur, email_relay_server_response peut contenir quelque chose comme ceci :

{"messagetype":"acknowledgement","message":"email-sent"}

Cette réponse est en format JSON et pourrait facilement être analysée par la centrale d'acquisition de données, si nous devions faire quelque chose avec elle et faire en sorte que la centrale de mesure agisse sur elle.

Dans notre exemple, voici comment la centrale d'acquisition de données peut réessayer d'envoyer un message défaillant en fonction de la réponse qu'il a reçue avec sa première tentative :

'If EmailRelay was not successful, let us try one more time.
 				If (email_tx_success <> -1) Then
					'2nd attempt
					email_tx_success = EmailRelay (_EMAIL_TO_ADDRESS,_EMAIL_SUBJECT,email_message,email_relay_server_response,_EMAIL_ATTACHMENT)
				EndIf

C'est un exemple simple que vous pouvez développer si vous le souhaitez.

Conclusion

Do/Loops dans les séquences lentes (slow sequence) sont un excellent moyen d'éviter de voir les ''skipped scans'' dans votre centrale de mesure. J'espère que vous trouverez ces exemples utiles. Vous pouvez télécharger l'exemple EmailRelay(), ainsi que l'exemple Do/Loop EmailRelay().

Existe-t-il d'autres façons de programmer vos centrales d'acquisition de données pour éviter les skipped scans inutiles ? Dans l'affirmative, veuillez partager votre expérience avec nous.