Sender/Receiver Troubleshooting Guide (version 24)
The following article mentions the Sender & Receiver services that may still be used if a Collector is running a pre-24 version. Although the Historian is still compatible with the Sender & Receiver, all Collectors of version 24 or newer will use the Store and Forward (SaF) service. The Sender and Receiver were combined into this one service in v24. A SaF service is paired with a Collector as well as the Historian for both sending and receiving data. Therein, the following article can help troubleshoot if using either form of data collection.
The Sender & Receiver services are used to route data from the Collectors to the Historian. The data may flow through multiple Sender/Receiver nodes if proxy servers are in place before reaching the Historian. The first Sender is co-located with the Collector service and the last Receiver is co-located with the Historian service. The Sender can buffer data to the local disk if it cannot be forwarded through to the Historian or proxy. The Sender also has the ability to duplicate the data stream and send to multiple Receiver services.
By default, the Sender tries to make an anonymous connection to the remote Receiver on port 55255. If this fails, it will then attempt to connect on the secure port, 55256.
The following scenarios are presented to help troubleshoot data flow issues.
Issue: The Sender/Receiver service(s) are not running.
Solution:
Open the Canary Admin>Services tile and try starting the services.
If the service does not start, check the message log for errors. The service may be unable to start due to a "Duplicate Certificate" error. If two certificates have the same subject name, the service will not be able to determine which one to use, and therefore not start.
There will be a corresponding error in Windows Event Viewer>Application Log.
In this instance, one of the duplicate certificates must be removed from the personal folder within the computer certificate store.
Issue: The Sender cannot establish a connection to the Receiver causing data to buffer in the Sender.
If the Sender cannot connect to a remote Receiver, the following error will be thrown:
Additionally, the Sender's buffer count will start to grow as new updates are logged:
Solution:
- Verify the Receiver and Historian services are running.
- Try restarting both the Sender service and the Receiver service.
- Verify the historian/proxy server name (or IP address) is configured correctly in the Collector. This name (or IP address) will appear as the first branch in the Sender Session name.
If the server name is incorrect, the session can be purged as it is not going to the correct destination. - Is there a firewall on the Receiver server preventing the connection? Temporarily disabling the firewall for inbound traffic is a good test to verify if it is a firewall issue. If so, a firewall rule may need added to allow traffic on port 55255 (anonymous) or 55256 (secure).
Issue: The total number of tags which the historian can log has been exceeded.
If the tag limit is exceeded, the following error is thrown and ALL data from ALL sources will buffer until the tag count is less than or equal to the licensed limit. 
The License tile will display the tag limit and the Historian tile will display the current number of licensed tags.
Solution:
- Ensure that the historian is licensed by opening the Canary Admin>License tile on the historian machine. (See How to License Canary System Components)
- If the historian is licensed, it is typically the latest Sender Session that has pushed the tag count over the limit. Tags will need to be removed from any one of the collectors that is currently trying to log data to the historian or from a "dormant" dataset that is no longer receiving current data. If wishing to remove tags from a dormant dataset...
- The dataset itself can be removed by opening the Canary Admin>Historian tile>Configuration tab. Select the appropriate dataset and click the 'Remove' button.
- Or, individual tags can be obsoleted. (See Obsoleting Tags From a DataSet). Once tags are obsoleted, the dataset will need manually rolled over to pick up the new tag count. To force a roll-over, drill into the appropriate dataset and select the down arrow in the 'DATASET' window.
Issue: The Sender can connect anonymously to the Receiver, but not securely.
Solution:
- Check to make sure the secure port is enabled on the Receiver machine.
- If the Sender is configured to use the 'Identity' option (which it is by default), it will first appear on the 'DENY' list in the Receiver tile>Configuration>Senders tab and need to be allowed.
If the Sender is configured to use the 'User' option (uncommon) and security is enabled within the Views service on the historian machine, ensure the user has been granted permissions within the Views tile. (See Sender Credentials: Identity vs. User) - If still unable to connect, check to make sure there is no firewall blocking the secure port, 55256.
Issue: Tag names in the Logger Administrator (OPC DA Collector) are red.
Solution:
- Check the message log for errors regarding the Logger and Sender. It's possible there is a communication issue between the Logger and the OPC server.
- The first branch in the 'Name' column of the Logger must be the dataset name. The logger is the only Canary Collector in which the dataset MUST be created prior to logging data. If the dataset does not exist or the dataset does not match (it is case-sensitive), the tags will appear red and the following error will be thrown:
(See Creating, Deleting, and Renaming DataSets if the dataset does not exist.) - If only the quality column is red, it is possible the Item ID is incorrect and the tag cannot be found in the OPC Server.
Issue: Data is buffering in the Sender and a 'Blocking' error is thrown indicating the "tag is currently being logged by an archive".
The same tag cannot be logged twice using the same Sender service. All tags must be unique.
Solution:
- Check the message log on the Historian server for a warning concerning "Trimmed Trailing Space".
If the warning exists, it is likely that the tag is being logged twice - one instance with a trailing space in the tag name and one instance without a trailing space. The Historian does not allow spaces at the end of a branch or tag name and trims them as they are logged. In this scenario, once the tag is trimmed it becomes a duplicate of the other tag which causes the blocking error to be thrown. To remedy the issue, one of the tags needs removed from the Collector. Additionally, the Sender's tag file must be edited in order to flush the buffer. It is recommended to contact Canary's support team for assistance in this matter.
Print this page