Configure readers for your host interface
The host interface defines the reader's communication with the host system as well as basic feedback to the card holder (LED and beeper).
I have multiple reader types in my project
You may have multiple reader types with different host protocols and/or different user feedback in the same project, e.g. ACCESS200 readers for access control and ID-engine readers for time and attendance. If this is the case, you have to work with multiple configuration files to configure individual host interfaces per reader type.
Add host interface component
Open BALTECH ConfigEditor.
If you haven't installed it yet, you can download it here as part of BALTECH ToolSuite.
Open the BALCFG file of your existing configuration.
If you don't have a configuration file yet, create a new one.
Click Add > Host Interface, and select your host interface and protocol (see table below for details).
You can only configure 1 host interface per configuration.
The component will be added with default settings. Check the default settings and adjust them as necessary.
Overview of host interface components
If you're unsure which component to use, please refer to your host system documentation or ask your host system provider.
|Keyboard Emulation||Reader output emulates keystrokes and is sent autonomously to the host.|
|Virtual COM Port Undirectional||Reader sends ASCII-formatted decimal number autonomously to the host.|
|Virtual COM Port Bidirectional||Read results are buffered for the host to retrieve it. Based on BRP. This protocol also allows you to control the reader via the host application, e.g. to override the Feedback to card holder settings.|
|HID||Read results are buffered for the host to retrieve it. Based on BRP. This protocol also allows you to control the reader via the host application, e.g. to override the Feedback to card holder settings.|
|PC/SC||Interact with ISO 14443-4 cards via the PC/SC interface. Only use this component if the standard PC/SC configuration does not meet your needs.|
|Unidirectional||Reader sends data to host autonomously. No options to control the reader.|
|Bidirectional||Read results are buffered for the host to retrieve it. Based on BRP. This protocol also allows you to control the reader via the host application, e.g. to override the Feedback to card holder settings.|
|Host as Client||The host opens a connection to the readers (learn more). This component also contains settings for PKI authentication and encryption.|
|Host as Server||Readers open a connection to the host in certain events. This is recommended for large numbers of readers or readers behind a firewall (learn more). This component also contains settings for PKI authentication and encryption.|
|Wiegand||Change the default Wiegand settings on ACCESS200 or enable Wiegand on ID-engine Z.|
Lets you switch ACCESS200 readers from Wiegand to OSDP and change
default parameters if needed. Each reader is assigned bus address 1.
Alternatively, use BALTECH AdrCard to enable OSDP with default parameters and individual bus addresses.
You can also combine AdrCard and OSDP component: Then, the address set with AdrCard will be used, while the parameters from the component will apply.
Feedback to card holder (LED & beeper)
If you set up readers for an existing host appication, the settings in the Feedback to Card Holder section always apply.
If you develop a custom application, the Feedback to Card Holder settings apply as follows depending on your operation mode:
Operation mode Do Feedback to Card Holder settings apply? Autoread unidirectional Yes; you cannot override them in your application. Autoread via BRP Yes, but you can override them in your application with the UI command group All other modes No, you have to define your own LED and beeper signaling with the UI command group
In any case, you can customize the LED behavior using the custom LED component.