Allgemein
...
Table of Contents |
---|
General information
COMSOL device require a loadable firmware (LFW) as well as a suitable configuration. The first is provided in a firmware file (.nxf file).
Depending on the procedure described below, also the configuration in the form of one or more database files (.nxd file) is required.
For the driver to be able to handle the files, they are stored in a defined file directory. For this purpose, a root directory is created during driver installation:
- Windows: C:\Program Files\cifX Device Driver
- Linux: /opt/cifx/
Unterhalb des Stammverzeichnisses wird die Ordner-Struktur nach einem bestimmten Schema fortgeführt (siehe Abbildung). Für jedes Endgerät wird ein Sub-Verzeichnis angelegt, welches sich entweder nach Geräte-ID und Seriennummer oder nach der Slot-Nummer des Geräts richtet. Letztere erfordert die Existenz eines Slot-Schalters. Ist dieser auf größer „0“ eingestellt wird nach der „Slot-Nummer“-Methode vorgegangen:
Beim Starten des Geräts lädt der Treiber die Dateien automatisch auf das Zielgerät hoch, falls dort keine Datei existiert oder sich von der im Sub-Verzeichnis hinterlegten Datei unterschiedet. Das Ersetzten der Datei im Sub-Verzeichnis und dem Neustart des Geräts bewirkt also das Ersetzten der Dateien auf dem Ziel-Gerät.
Bei der Verwendung von Sycon.NET auf einem Windows-System findet die Datei-Verwaltung über jeweiligen Download-Funktionen automatisch statt. Ein manuelles ersetzten der Dateien ist, vorzugsweise über das cifx-Setup Tool, möglich. Dieses Vorgehen ist jedoch eher unüblich. Auf anderen Betriebssystemen wie Linux sieht die Sache ein wenig anders aus. Tools wie Sycon.NET stehen hierfür nicht zur Verfügung. Das "manuelle" Verschieben der Dateien ist hier u. U. normales Vorgehen.
TCP-Server
Entgegen der Aussage des vorausgegangenen Abschnitts kann Sycon.NET über Umwege doch außerhalb der Windows-Welt verwendet werden. Unter Verwendung eines TCP-Server kann mit Sycon.NET kann das Geräte remote konfiguriert werden. Voraussetzung ist, dass das Zielgerät vom Betriebssystem erkannt wurde und die beiden Rechner untereinander im Netzwerk erreichbar sind. Bei dieser Methode übernehmen der TCP-Server und Sycon.NET automatisch die Verwaltung der Dateiablage und ist daher am wenigsten fehleranfällig.
Target-Host Application
In allen Treiber-Paketen aller Betriebssysteme befinden sich Sourcen für eine TCP-Server Applikation. Sie kann über eine entsprechende Build-Umgebung übersetzt und gestartet werden. Die Applikation benötigt dafür schreibenden Zugriff auf das Treiber-Verzeichnis. Nach dem Start der Applikation und der erfolgreichen Suche nach installierten Geräten wird die aktuelle IP-Adresse des TCP-Servers angezeigt.
Sycon.NET - TCP-Connector
Die angezeigte IP-Adresse kann nun verwendet werden um Sycon.NET über den TCP-Server mit dem Remote-Device zu verbinden. Im ersten Schritt muss dazu ggf. der Netzwerktreiber aktiviert werden. Im Dialog „Driver“, zu finden in der Navigation Area, ist dazu der „netX Driver“ zu aktivieren. Der Netzwerk-Treiber sollte bei der Installation von Sycon.NET mitinstalliert werden.
Im darunterliegenden Dialog „netX Driver“ kann unter dem Tab „TCP-Connection“ der TCP-Connector aktiviert und konfiguriert werden. Der Dialog ermöglicht das Anlegen verschiedener Profile (IP_RANGE#), die beliebig gewechselt werden können. Durch den „+“-Button lässt sich ein Profil anlegen bzw. durch „x“ entfernen. Erst nach dem Selektieren einer IP-Range lassen sich erfolgreich Konfigurations-Paramater eintragen.
Nach dem Speichern der Parameter sollte die Geräte-Suche Ergebnisse liefern und diese im Dialog "Device Assigment" gelistet werden. Ist der normale CifX Device Driver nach wie vor aktiviert (siehe Dialog "Driver") werden ggf. auch lokale installierte Geräte angezeigt. Remote-Geräte unterscheiden sich von Ihnen durch einen anderen Access Path. Er enthält der zusätzlich die IP-Adresse des TCP-Servers an dem das Remote-Gerät installiert ist. Nach dem Selektieren des Geräts ist die weitere Vorgehensweise zur Konfiguration identisch.
Hinweis: Bei der Auswahl hinter „Device selection“ handelt es sich lediglich um einen Anzeige-Filter. Er soll helfen, mit hoher Wahrscheinlichkeit, uninteressante Geräte auszublenden. Sollte das gewünschte Gerät zunächst nicht gelistet sein kann das Umstellen des Filters auf "all" Abhilfe schaffen.
Config-Export - manuelles Kopieren
...
Below the root directory, the folder structure is continued according to a specific scheme (see figure).
For each device, a subdirectory is created, which depends either on the device ID and serial number or on the slot number set for the device.
The second requires the existence of a slot selection switch. If it is set greater than "0", the procedure follows according to the "slot number" method:
When starting the device, the driver automatically downloads the files to the target device, if there is no file installed or if the present files differ from the ones stored in the subdirectory.
Replacing the file in the subdirectory and rebooting the device will therefore replace the files on the target device.
When using Sycon.NET on a Windows system, the file management will automatically take place via the respective download functions.
A manual replacement of the files is possible, preferably via the cifx setup tool.
Each file stored in the driver directory needs to be placed into the registry as well. This is automatically done by the CIFX Setup Tool.
On other operating systems like Linux, things look a little different. Tools like Sycon.NET are not available for this purpose. The "manual" moving of the files is normal procedure here.
TCP-Server
Sycon.NET can also be used when using a Linux system, by using a TCP server.
This allows the device to be remotely configured. This procedure requires, that the target device has been recognized by the opposite operating system (Linux) and that the two computers can reach each other via the network.
With this method, the TCP server and Sycon.NET automatically take over the file storage management, making them the least error-prone.
Please find a detailed description of this procedure here:
How to connect a CIFX Card in a Linux System to Sycon.net via TCP Server
Configuration-Export - copy manually
As an alternative to the TCP server, the required files can also be moved / copied manually to the required subdirectories.
The firmware file (.nxf) is static and ready to use.
The configuration file (.nxd) need to be generated first. Sycon.NET offers an export function for this purpose, which can be found under "Additional functions -> Export -> DBM /
...
Je nach Protokoll und Rolle (Master/Slave) können durch den Export mehrere Dateien entstehen. Sie erhalten im Dateinamen einen Präfix der dem Dateinamens-Feld im Export-Dialog entspricht. Die Hauptdatei muss in „config.nxd“ benannt werden. Alle weitere Dateien müssen um den eben erwähnten Präfix bis zum letzten „_“ bereinigt werden. Alle Dateien müssen ebenso wie die Hauptdatei im Channel#0-Verzeichnis hinterlegt werden.
Applikative Konfiguration
Ein kompletter Verzicht auf Sycon.NET ist mit einer applikativen Konfiguration über das azyklische Interface der jeweilige Protokoll-API möglich. Abhängig vom eingesetzten Kommunikations-Protokoll kann dies sehr komplex werden und erfordert u. U. tiefgehende Kenntnisse des zugrundliegenden Protokolls. Falls möglich, sollte diese Methode daher nicht als bevorzugtes Vorgehen gewählt werden.
...
nxd ...". After the export, the files can be transfered to the Target-PC and stored in the corresponding channel #0 folder of the device.
Depending on the protocol and role (master / slave), multiple files may be created by the export.
You will receive a prefix in the file name that corresponds to the file name field in the export dialog. The main file needs to be renamed to "config.nxd".
All other files need to be cleaned by the just mentioned prefix until the last "_". All files must be stored in the same way as the main file in the Channel # 0 directory.
Configuration via application
A complete renunciation of Sycon.NET is possible with an application configuration via the acyclic interface of the respective protocol API.
Depending on the communication protocol used, it gets very complex and requires profound knowledge of the used protocol. If possible, this method should therefore not be chosen as a preferred procedure.
The application-specific configuration does not generate a configuration file. This only requires copying or storing the firmware file. The parameters are transferred directly to the device and processed. If the device does not have persistent memory (depending on the device type), configuration is required each time the device is restarted. The exact configuration procedure is documented in the respective protocol API documentation