General informations
The runability of a COMSOL device requires a loadable firmware (LFW) as well as a suitable configuration by default. 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/
Below the root directory, the folder structure is continued according to a specific scheme (see figure).
For each device a sub-directory 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 proceedure requires, that the target device has been recognized by the oposite 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 proceedure 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 / 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 applicative 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