Installation

GRD32 also requires that Gr32fix.exe and Grd32fix.dll are available in the windows command path. They directly pass the external hook-in messages that are broadcast below the range that Microsoft applications can receive. A Microsoft runtime library msvcr100.dll is also required to be in the command path and is included in the GRD32 distribution package.

For V3 systems the Grd32fix.dll file should be placed in the directory specified by SystemPath in c:\bncs_config.ini.

In a V4.5 system the Grd32fix.dll file should be placed in the �windows\lib� directory within the project specified in the workstation 'CC_ROOT' and 'CC_SYSTEM' environment variables.

This help file 'GRD32.chm' and Gr32fix.exe should be in the same directory as GRD32.exe. In V4.5 systems the drivers are stored in 'windows\bin' directory within the project, V3 systems usually have a designated directory for drivers in each project .

If you are using Windows XP and get the error message "The procedure entry point decodepointer could not be located in the dynamic link library KERNEL32.dll.", you will need to install Windows XP service pack 2 or 3.

Configuration

GRDs have a dedicated ini file, this takes the form of Dev_xxx.ini where xxx is the device number specified as a command line parameter. If this file does not exist then it is created when the GRD is first run up.

For V3 systems this file is held in the directory specified by ConfigPath in c:\bncs_config.ini.

In a V4.5 system it is in the config\system directory within the project specified in the workstation 'CC_ROOT' and 'CC_SYSTEM' environment variables.

If neither of these systems are defined, the default path for the configuration files is the OS system directory, i.e. c:\windows.

The configuration parameters used by the GRD are detailed in the table below:

Entry | Notes
[Database]
DatabaseSize_0 | The total number of sources this GRD will use
DatabaseSize_1 | The total number of destinations this GRD will use
Entry | Notes
[GRD]
Name=Audio Switcher | The name of the router is displayed on the title bar of the window
IndexMapping=0 | Cross-mapping of sources and destinations is available for Probel protocol only. For additional information see the Cross Mapping section below.
ParkSource=64 | When the GRD receives a request to route source zero to a destination it will substitute this park source instead. By default this parameter is set to 0.
FirstVirtual=0 This parameter specifies the first virtual destination. Virtual destinations loopback and appear as virtual sources with the same index number, the first virtual destination must therefore be positioned above the highest real source number.
The matrix should be dimensioned to include the virtuals; i.e., for an 8x8 matrix with 8 additional virtuals, it should be dimensioned as 16x16.
Warning: Virtual tallies are regularly saved to a disc (.dat) file but any offline changes cannot be recovered from a GRD poll of the hardware.
SaveDelay=10 | Maximum delay in minutes between saving the real and virtual tally status to disk in case of power outage.
FwdBuffDelay=0 | This defines the time out value in milliseconds for the forward buffer timer. If a Router Crosspoint command (RC) is received from the network and forward buffer delay is set to a value greater than zero, then the incoming commands are stored in a forward buffer until the max forward buffer size is reached. When the delay timer expires, the stored buffer is read and the commands processed. By default this parameter is set to 0.
RevertiveDelay=0

This defines the time out value in milliseconds for the revertive delay timer. Setting this parameter to a value greater than zero will start the delay timer. Updates from the hardware are then buffered until the next time out when all the differences between the buffer and tally table are stored, in destination order and revertives issued. By default this parameter is set to 0.

DriverMode=INTERNAL 'INTERNAL' - the GRD will initialise the configured comms connection(s) to the router and commence polling.
'EXTERNAL' - the GRD expects to host an external application that will provide the interface to the router and update the tally table. Resilience messages are forwarded to the external application and the GRD will offer to go RxOnly if its redundancy status is queried by CSI and the external application is not running or fails to respond.
InitTallyDelay =200

This value is in milliseconds, it sets the poll timer period used during the initial fast poll of the router(s) to update the internal tally table at start-up.
If the protocol type used is �NETWORK� and InitTallyDelay is set less than 10000, the value used is 10000.
TallyDelay=2000 | This value is in milliseconds, it is used to set the background poll timer period after the initial poll has completed
CommErrorLimit=5 The comms fail mechanism uses a simple TX message counter for each port, whenever a data command is transmitted via the GRD port the counter is incremented. When a message from the router is received on the same port, and successfully decoded, that counter is reset to zero. If there is no response or the message is corrupted, the counter remains incremented and when the count exceeds the CommErrorLimit, the port status flag is set to �Fail� . Comms status can be used to influence the GRD resilience modes - see GoRxOnlyOnComFail setting.
By default this parameter has a value of 5.
Revertive Mode=ROUTER This parameter governs how the GRD handles revertives.
'ROUTER' - the driver will wait until the router confirms the tally status has changed before issuing a revertive.
'DRIVER' - the revertive is returned immediately on receipt of the Router Crosspoint command. This requires reliable comms but will result in an improved revertive response time when the driver is used at slow baud rates.
NetUpdateOnStart=1 | Permissible values are either 0 or 1. The default value is 1 where the current contents of the tally table is sent in a salvo of revertives for all destinations on completion of the initial hardware poll.
InhibitNetworkOnStart=1 | Permissible values are either 0 or 1. This default value is 1 which inhibits the processing of router commands during the start up of GRD and until the initial poll is complete. During this period the text within the Rx counter shows �Inhibit� on GRD GUI. When set to 0, command processing is enabled during start up.
ReAssert=1 | This value has a default value of 1 and will reassert a router crosspoint that has already been made and issue a revertive. When set to 0, the GRD not issue a revertive if the crosspoint is already made.
DebugMode=0 | For debugging purposes only.
SourceToDest=1 | If set, routes Source to Destination.
DestToSource=0 | If set, routes Destination to Source.
Simulation=0 | If set to 1, the hardware interfacing is bypassed. Router Crosspoint commands are compared directly with the internal tally table and revertives issued for any changes.
BBCRCP_Levels=1 | This parameter is used when the device configured uses NTP or BBC Radio Capital Projects protocol and determines the number of levels to be controlled in the matrix.
LeitchLevel=0 | This parameter is used when the device configured uses LEITCH protocol. and determines which level is controlled. Leitch router levels are numbered from zero.
QuartzLevels=VAB This parameter is used when the device configured uses QUARTZ protocol and determines which levels are controlled.
This value has a default of VAB, (ie Video, audio A & audio B).
NetworkRouterType=VIDEO | This parameter is used when the device configured uses NETWORK protocol and must be set to either VIDEO for all video routers or AUDIO for all other types.
NetworkRouterLvl=0 | This parameter is used when the device configured uses NETWORK protocol and must be set to the routers NCB Address (which is 1 less than the level number).
AdrienneAddress=0 | This parameter is used when the device configured uses ADRIENNE protocol - valid 2 digit addresses are 00 - 99
SonyAddress=1 | This parameter is used when the device configured uses SONY protocol - valid addresses are 1 - 128
GoRxOnlyOnComFail=-1 | This parameter has a default value of -1. It is used to decide whether to switch to RxOnly operation if a com port fails. Either zero or a positive logical port number can be configured, zero is interpreted as being any port, i.e. if Com 2 does not respond and this value is either 0 or 2 the driver will switch to RxOnly.

The next section of the INI file is in a number of parts, one for each com port. The GRD supports large routers, the control of which may be spread across up to eight ports. All the com ports may be configured in an entirely different manner enabling several diverse makes and type of physical unit to be driven as one logical unit. Care should be taken to ensure that the minimum and maximum destination ranges do not overlap between com ports.
Note that the logical com ports within the driver can be set to any physical port on the PC

Entry | Notes
[Com_1] | This is a logical com port number within the driver. There are similar configuration sections for each of Com_1 to Com_8
Port=1 | Physical com port number assigned to this logical port
MinDest=1 | The minimum destination on this port
MaxDest=64 | The maximum destination on this port
Protocol=PROBEL | Protocol type
Speed=38400 | Data speed. By default this parameter is set to 0 which disables this logical com port.
DataBits=8 | Data bits
StopBits=1 | Stop bits
Parity=E | Parity bit

The final section to be configured relates to the workstations that are allowed to control the GRD. Don't forget to include the workstation hosting the driver!

Entry | Notes
[Security]
Access=1,9,12-20 | This driver will only accept commands from workstations 1, 9 and 12 through 20. The default setting is 'ALL'.

A section of the dev_ini file is used locally for storing the current screen position of the dialog, panel menu options and keyboard status. These are automatically saved to the ini file by the application and are used to return the dialog to the same position and user state after a driver restart.
It should not be necessary to edit any of these settings manually although they may get overwritten when the file is updated from the server.

Entry | Notes
[Dialog]
Extend=0 | If set to 1, show the Routing panel
Virtuals=0 | If set to 1, show tallies from the Virtual Table (FirstVirtual must also be set)
EnableBtn=1 | If set to 1, the Enable button is active and prevents inadvertant operation of the local routing buttons
Park=0 | If set to 1, the Park source can be routed by using the Park button or Source 0 of the listbox
SmallScreen=0 | If set to 1, the visible area of the panel is modified for use with a 800x600 screen

Dialog position is stored in TEMP\dev_nnn.tmp (where nnn is the device number, and TEMP is the temporary folder appropriate to your system configuration type) with different "profiles" depending upon the style of dialog displayed:

[DialogExtend]
x=362
y=254
w=724
h=753
[SmallList]
x=362
y=254
w=724
h=600
[SmallStatus]
x=165
y=175
w=724
h=248

In a system with V4 configuration, ie where %CC_ROOT% and %CC_SYSTEM% are specified, the temporary folder is %CC_ROOT%\%CC_SYSTEM%\temp.
In a system with V3 configuration, ie where c:\bncs_config.ini exists, the temporary folder is given by the TempPath key.
In a system with neither of the above, the temporary folder is the system temporary fodler, ie %TEMP%.

Cross Mapping

The ability to remap sources and destinations applies only to the PROBEL protocol.

The IndexMapping entry in the GRD section of the device ini file can be set to 1 causing new Dev_nnn.sourcemapping and Dev_nnn.destmapping files to be created if not present when the driver is next run. Any changes to the default one-to-one mappings are read after the next restart.

Mapping entries are of the form:

<bncs>=<real>

e.g. 0005=0022, where index 22 on the router is BNCS index 5

Warning: you must take care to ensure that there is not more than one real destination mapped to a BNCS destination.

Note that the opposite convention, i.e. real=bncs is used for indexMapping of Jupiter and Nexus routers.

Steve Lowe. � Copyright Atos 2014


Credits

Simon Dowson

The original versions of GRD including GRD, V2GRD, V3GRD, V4GRD

Dave Yates

The original Inf32fix.exe and Info32fix.dll concept from which the grd versions were derived

Steve Lowe

GRD32 - merged from V3GRD and V4GRD with a few other enhancements

This documentation includes original material from Simon and others in the BNCS team (past and present).

Steve Lowe. © Copyright Atos 2014


Document Template

Data Storage

The GRD internal tally table is periodically stored to disk in Dev_xxx.DAT file in case of power outage, where xxx is replaced with the driver number. The lock status is held in Dev_xxx.LCK file and is updated when changes occur. Tally and lock status are also saved during normal driver closedown.

The names displayed in the 'Source' and 'Destination' listboxes are populated indirectly from the Dev_XXX.CDF file which is maintained by CSI from the names held in databases 0 & 1 of the Dev_XXX.INI file. If the names should become corrupted or manual database changes not detected, delete the .CDF file and restart CSI for new Dev_XXX.CDF file to be created. Database names used with CDF files are limited to 16 chars max, longer names may be used directly from db/ini files by setting CSI to use 'UseMemoryDatabaseOnly'. Use of the Router Modify command to update Source and Destination names over the network should keep all the database files synchronised.

For V3 systems, these files are held in the directory specified by “ConfigPath” in c:\bncs_config.ini, for V4.5 systems it is in the “data” directory within the system set by CC_ROOT and CC_SYSTEM environment variables.


Dialog

User Interface

The router driver application is normally iconised but can be restored to show diagnostic information and also provide local control.

The dialog panel is shown fully extended, the lower routing panel can be shown or hidden by using the 'More/Less' button or via the 'Panel Options' menu. Small screen mode is a menu option that alters the visible area of the main dialog panel to show just the Status or Routing sections so that the dialog is still usable on a 800x600 screen. The screen location and size of the dialog are automatically saved to the ini file along with the Panel menu options and keyboard status. These settings are used to return the dialog to the same position and user state after a driver restart.

The Title bar displays: Device No. - current interface mode - version info - "Device Name"

The Driver status label will change to “External” on a dark red background when an external driver is connected. When the GRD is specifically configured to expect an external driver connection the background will be bright red if the external is not connected.

The Control status label will change to “External” on a dark red background when an external client has connected.

The network message counters at the top show the number of messages received and transmitted by the driver to and from CSI, this does not include other house keeping messages or those between externals.

If the Interface label shows ‘RxOnly’ it indicates that there is another device with the same device number on the network in ‘Tx/Rx’ mode and/or data comms to the router have failed (see Redundancy).

The serial ports section shows the status of each active port and the destinations that they are configured for. The 'Status' boxes show either OK or FAIL and indicate whether or not the driver is receiving data in response to its interrogation. It does not mean that the data being received is valid. Data validity is indicated by the 'Errors' box, in normal operation it should very rarely increment if at all, the counters are resettable from the menu bar.

The 'Sources' section displays all available sources with their index numbers in a scrollable listbox. By default a source will be highlighted and scrolled to the visible area of the listbox if it is routed to the destination selected in the 'Destination' section. The listbox is also used to select a new source for subsequent routing to a destination.

The 'Destination' section displays all available destinations with their index numbers in a scrollable listbox. Selecting a destination will highlight it and also highlight the current source feeding that destination, if any, in the source listbox. Another source may be selected and routed by pressing the 'Take' button. If the destination is locked then it is necessary to unlock it first by pressing the 'Lock' button, which will enable the 'Take' button and the route can then be made. Destination tally information from the hardware is used to update the internal tally table, if the driver is TX/RX and in a normal mode the new tally information will also be sent as a revertive (RR) on to the network. If connected, an External client can intercept, modify or ignore routing requests made from the application window.

If Virtuals are enabled, the internal routings of virtual sources and destinations are mapped in a separate internal tally table along with a copy of the direct tallies for the non-virtual routes. Selecting 'Virtual Table' using the button or via the 'Panel Options' menu will switch the tallytable used to highlight the selected source in the list so that tallies for routes made using indirect paths can also seen. A Yellow bar above the tally changeover button indicates that the routing passes through the virtual space. Selection of a virtual destination automatically enables the virtual tally view and the previously selected tally view is restored on return to a real destination. New routes can be made in the normal way whilst viewing either tally table.

The names displayed in the 'Source' and 'Destination' listboxes are populated indirectly from the Dev_XXX.CDF file which is maintained by CSI from the names held in databases 0 & 1 pointed by the Dev_XXX.INI file. Database names used with CDF files are limited to 16 chars max, longer names may be used directly from the DB/INI files by setting CSI to use 'UseMemoryDatabaseOnly'. The index numbers are prepended to the database names for listbox display purposes only. If virtual sources and destinations are configured, the source and destination index numbers in the virtual space are tagged with a ' v '.

Source Hold prevents tally updates to the source listbox and the highlighted source remains available for routing as different destinations are selected. The Source Hold button can only be enabled from the Panel Options menu. There is a coloured warning over the source listbox when Source Hold is active. The current tally of the selected destination is shown in a small box below the destination list box.

The Lock button and menu Lock tab toggle the lock status of the selected destination. A coloured bar above the Lock button indicates the destination lock status. Any destination can be locked and the lock status is periodically saved to disc in case of power failure. This feature is seldom used as Lock status cannot be determined remotely.

The Park button can be made available from the Panel Options menu. An index entry for Park is also inserted in the source listbox for selection and will be highlighted when the destination tally is zero. Use of Park will route the configured Park Source to the selected destination and is normally protected by the Enable button.

The Enable button protects the Take, Lock, Park and Undo options from inadvertant operation. Once pressed, there is a 5 second period for the user to select the required action from the available routing buttons before they are disabled again. Any destination can be locked/unlocked so the Enable button does not dim between selections. The Enable button protection can be disabled via a menu option for system commisioning etc.

Undo button - when the Take or Park button is pressed, a copy of the current destination tally is put into a single Undo memory variable. After the Take action the Undo function becomes available and is normally protected by the Enable button. The Undo tally is displayed underneath the button and the Undo option is cleared and disabled when a new destination is selected.

If a keyboard is available you can enable keyboard router control from the menu bar or by using <Alt> 'K' 'E'. Once enabled, the keyboard and navigation keys can be used to change crosspoint routes, use <Alt> 'D' to select the destination box, <Alt> 'S' to select the source box and <Alt> 'T' to make the new crosspoint. <Alt> 'U' will undo the previous routing (see Undo button). <Alt> 'P', available only when the Park option is selected, routes the configured ParkSource to the selected destination. <Alt> 'L' enables the locking and unlocking of individual destinations. While Keyboard control is enabled, <Alt>'T' etc can be issued without further enabling.

The Config menu calls a pop-up window with the configuration path used by the GRD with an option to open the configuration ini file in the default text editor.

The ‘Redundancy’ switching menu allows the user to locally set the interface mode of the GRD for testing or maintenance purposes. These changes may be temporary as only one instance of a device number on the network can be 'TxRx' and CSI will still attempt to promote a functional 'RxOnly' driver (see Redundancy).

The 'Panel Options' menu configures the panel size, displayed tally mode and sets the availability of the Enable, Park and Source Hold buttons avoiding the need to manually configure the local dialog settings in the ini file.

The About menu gives access to this integrated Help application and GRD32 version information.


Info32fix Application

gr32fix.exe

gr32fix.exe is required so that GRD32.exe can receive some broadcast messages (HWND_BROADCAST) that otherwise it would be unable to hear.

There is a difference between Borland compiler built applications and Microsoft in that Microsoft applications are totally deaf to certain ranges of messages sent from other applications with HWND_BROADCAST. Typically this is thought (not confirmed to be so…) anything below WM_APP (0xc000).

Unfortunately some of these messages are the hook-in messages required to connect external drivers with GRD_CONNECT.

The work around is to use a simple Borland-built application to receive these on behalf of the Microsoft application. All the Borland-built application does is then pass them direct onto the Microsoft application.

gr32fix.exe receives the messages, looks up the handle of the messaging window for the appropriate grd and passes the hook-in message on.

To know which numbered grd has which window handle they share this data with the grd32fix.dll. This allows for cross-process sharing of simple data such as an array of window handles.

grd32fix.dll

grd32fix.dll is a very simple DLL that is used to share data between GRD32 and gr32fix.exe.

gr32fix.exe is required to listen for broadcast messages (HWND_BROADCAST) that Microsoft applications can’t hear. When it receives a GRD_CONNECT message that it knows that GRD32 will not be able to receive it simply passes it on.

grd32fix.dll shares the window handle of running GRD32 applications. It has a 1000 slot array of window handles and two functions to get and set data within that array.

GRD32.exe explicitly sets its own window handle in the array (via the calls in grd32fix.dll) when it’s run.

gr32fix.exe pulls the data from the array when it needs it and validates the handles placed there with an IsWindow() API call.


InfoDriver32 Documentation

GRD32 Documentation

Please note that this is a guide to the BNCS GRD32 application only

Click on the lines below. Help is available for:

Introduction | Overview of the GRD32 and its modes of operation
Configuration | Installation notes and description of the ini file settings
Protocols | A list of supported protocols
Dialog | A guide to the user interface
Redundancy | Using Main and Reserve drivers
Data Storage | File types and locations

Also included for reference:

Additional files | Use of gr32fix.exe and grd32fix.dll
Full Version History | As lodged with the source code. Note that this is an internal document and may be useful but is not a polished, user-friendly document.
Credits
Steve Lowe. © Copyright Atos 2014


Introduction

The Generic Router Driver (GRD32.EXE) can control many different types of router using a variety of protocols.

The maximum number of sources or destinations GRD32 can support is 4096

Routers differ greatly in terms of the protocol they support, speed of response, inherent intelligence etc. The GRD can drive intelligent routers that have their own controller or simple routers with limited logic. The two basic commands that are common to most routers are 'Connect' to join a source to a destination and 'Interrogate' to request the identity of the source currently feeding a destination. When a serially controlled router fits this model then its protocol can be added to the GRD.

When a router has more complex functions, such as conferencing, subscriber ringing etc., a dedicated driver is required that can best exploit the features offered by the equipment.

Each router and protocol has its own particular features. Here are just a few :-
- Some routers will break away a source and put it back if asked to make the same crosspoint.
- Some routers cannot accept more than one or two commands at a time.
- Some routers have two or more married levels.
- Some routers with very simple logic cannot be interrogated
The GRD has evolved to cope with all these scenarios.

GRDs have three modes of operation, 'Normal’, ‘External Driver (Host)’ and ‘External Client’. In Normal mode it behaves as described above as a router driver. In External Driver mode the GRD acts as a host to another application. In External Client mode it has an external client connection for custom actions on 'Router Crosspoint' commands.

Normal Mode

In this mode the router crosspoints are directly controlled by clients on the network. Whenever a crosspoint change occurs a revertive message containing the updated destination information is sent back to the network via CSI and thus to all clients that are registered to receive those messages. A client can poll any destination at any time and will receive a message containing the index number of the current source routed to that destination.

External Driver (Host) Mode

In this mode the GRD is taken over by another application that hooks into it using Windows messaging. The GRD allows the external driver to read and write tally information. When a client application sends a router crosspoint request to the GRD, the message is passed to the external driver which has the opportunity to ignore, validate, modify or send to a 3rd party device before communicating with the hardware. A revertive message is only generated when the external driver updates the tally information in the GRD. The external driver can modify the tally table at any time. The GRD provides the interfacing to CSI as well as the tally data storage.

External Client Connection

The GRD can accept client (control) externals. This is to allow direct interfacing with the GRD from a single application running on the same PC. There are two separate aspects to client externals, these being speed issues and the interception of other client commands. As the client external communicates directly with the GRD the response times are reduced as there is no network jump, this allows user applications such as an automatic to be written connecting 2 drivers on the same machine with no network hops required. An example of use is when a GPI closure should make a router crosspoint change instantly. Client externals will be passed all the 'Route Crosspoint' commands sent to the GRD. It is expected that normally these will be returned to the GRD, but the client does have the option to modify or ignore the message. Figure 1 shows the flow of a 'Route Crosspoint' command as well as all other commands and revertives. An example use here would be to allow a route to be changed only when some other event is true. Applcore note: When an Applcore panel connects to an GRD with the XR command the panel automatically intercepts all 'Route Crosspoint' commands. Unless an eXternal Intercept command is issued then these commands are simply looped back into the GRD for processing as normal. See Applcore documentation for all “X” series command information.

Figure 1 Simplified GRD command and revertive flow

Driver setup

First create a configuration file or 'device profile' (DEV_xxx.INI) for the device ID you intend to use with the GRD. This can be done by either cloning an existing DEV_xxx.INI file, using a spreadsheet macro function or the ApplCore utility MDP.EXE (Make Device Profile) to create this file for you. GRD32.EXE takes a single command line parameter. This is the router driver number. It can be between 1 and 999. No two drivers may use the same number and it serves as the unique number by which a particular router is addressed from the ApplCore panels or other client applications. When GRD32.EXE is first run it will create the default GRD configuration sections in the DEV_xxx.INI file.
A single router driver would normally be used per router. That router may consist of a number of crates each with a separate port controlling a range of destinations. GRD32.EXE can manage a router whose destinations are spread across up to eight ports. Each port can have different communications parameters and protocols if required. Several router drivers can be used on the same PC providing there are sufficient com ports to support them.
The driver can be instructed, either locally by using the driver application dialog or from a networked client panel to inhibit or lock out any destination or range of destinations on a router. However, the status of destination locks within the GRD cannot be polled, other methods such as running a separate 'Lock' infodriver are used instead to store the destination lock status.

When a router driver starts up it begins to interrogate the router in order to build up an internal tally table. The driver will send out revertive information for all the destinations until its internal tally table matches the router. If any subsequent discrepancies occur the driver will immediately send the revertive for the destination in question to the network. If the driver loses communication with a router on one or all com ports it may be configured to go RxOnly such that a reserve driver can automatically take over the function of the main driver.

Control

The commands for controlling a router via a GRD are detailed in the ApplCore documentation. The basic command for making a crosspoint is:
RC <Driver Number%< <Source%> <Destination%>
Example : RC 38 17 12
The above command would instruct GRD number 38 to route source 17 to destination 12. The ApplCore documentation makes reference to a 'mask' parameter for use with some routing modules such as the Combiner and Virtual Router Driver. The GRD ignores the mask parameter.


Configuration

Protocols

The following protocols are supported by the GRD. Each protocol has one or more unique features that needs to be taken into account when configuring the GRD.

GRD32 can manage a router whose destinations are spread across up to eight ports. Each port can have different communications parameters and protocols if required.

The 'Comms Parameters' listed are those specified in the documentation for the router as being the default. When establishing communications with a router it is a good starting point, but since many routers have configurable comms parameters it is wise to check that the defaults have not been changed.

Protocol | Notes
Pro-Bel Simple Protocol Keyword = SIMPLE
Comms parameters = 8 bits, Even parity, 1 Stop bit
This is a very simple hex protocol for driving small routers. It enables simple decoding within the router. There is no error correction. The GRD continuously interrogates the router for status of its destinations.
Pro-Bel General Switcher Protocol Keyword = PROBEL
Comms parameters = 8 bits, Even parity, 1 Stop bit
This is the workhorse hex protocol for driving routers. Large routers up to 4096 can be accommodated.
NTP Protocol Keyword = NTP
Comms parameters = 8 bits, No parity, 1 Stop bit
An ASCII based protocol for driving routers and controllers. The GRD can address several levels providing they are married together. In the INI file the 'BBCRCPLevels' parameter sets the number of levels. If set to 1 only router/level 'A' is switched. If set to '3' then levels 'A,B & C' would be switched. Interrogation is done on Level 'A' only. If greater flexibility is required use the NTP controller driver GRD_NTP.EXE. If you want to bypass the controller altogether and speak to the frames directly you will the CTL_NTP.EXE driver and hardware PCB's designed by Willie Orr in Belfast.
Cox | Protocol Keyword = COX
Vistek | Protocol Keyword = VISTEK
NTP Equalizer | Protocol Keyword = NTPEQ
Simple Microcontroller Router Protocol Protocol Keyword = SIMOSRTR
Comms parameters = 8 bits, No parity, 1 Stop bit
A protocol developed to communicate with the BNCS Vision Router prototype. At the time of writing no production versions exist.
Simple Microcontroller GPI Protocol Keyword = SIMOSGPI
A protocol developed to communicate with the BNCS Microcontroller based GPI system.
BTS ASCII | Protocol Keyword = BTSASCII
BTS ESSwitch Protocol Keyword = BTSESSWITCH
This allows switching via a VM3000 controller. Crosspoint connect requests are wildcards so all levels will switch. If you require individual control of the matrices and levels you need the CTL BTS controller driver.
Quartz | Protocol Keyword = QUARTZ. The crosspoint connect request includes all configured levels however interrogation is of only the first configured level. If you require individual control of the matrices and levels you need the EVERTZ_CTL controller driver.
Network Protocol Keyword = NETWORK
This allows control of Network Electronics or Nevion VikinX routers up to 128x128 using NCB protocol.
NetworkRouterType must be set to either VIDEO for all video routers or AUDIO for all other types.
NetworkRouterLvl must be set to the routers NCB Address (which is 1 less than the level number)
InitTallyDelay should be set to 10000mS or greater.
Leitch | Protocol Keyword = LEITCH. If you require to control multiple matrices and levels you need the V3CTLLCH controller driver.
Adrienne Protocol Keyword = ADRIENNE
Valid two digit addresses are 00 - 99
Pesa | Protocol Keyword = PESA
Sony Protocol Keyword = SONY
Valid addresses are 1 - 128
Steve Lowe. © Copyright Atos 2014


Redundancy

It may be desirable to have main and reserve drivers on the BNCS system so that in the event of hardware or driver failure a reserve driver can automatically take over the function of the main driver. This is achieved by having an active driver in TxRx and non-active drivers in RxOnly running on other workstations, the router hardware should ideally have dual control ports or be connected via a serial changeover switch. The non-active drivers still receive, process and store tally information from the hardware and the network and also from any connected external devices/clients but are unable to transmit data back to the network.

CSI handles the driver redundancy mechanism on the network, passing messages between each other and to the driver applications, to negotiate the TxRx state of each of the drivers. This messaging also ensures that there can be no more than one active instance of a particular device number.

GRDs use their comms status to influence the redundancy mechanism and can be set to automatically go RxOnly if comms fail.


GRD32.exe
v1.0.0.x	12/06/12	Development started by merging v3.06.09 and v4.4.3.0 GRDs into a new MSVC6 project.
                Config paths are obtained from environment variables (V4) or bncs_cfg.ini (V3) otherwise the
                default is to use Win OS system directory.
                GUI tweaks include V3 style coloured status labels, menu bar options for integrated Help
                and new dialog panel to view Config file path and open dev.ini file in default editor.
                Dialog listboxes are now only updated if Router Modify command applies to db0 or db1.
                Adds new constant to set client messaging type at hook-in: BBC_CTRLCONNECT32_DLL (or BBC_CTRLCONNECT32
                for the original WM) and changes External control mode text to indicate IPC type in use.
                Adds RxOnly_Broken message (NB) when comms fail detected - interface mode is not changed unless
                GoRxOnlyOnCommFail is set.
                Redundancy - request return to TxRx when comms restored is now implemented in all protocols.
                Overall comms status (GoRxOnlyOnCommFail) corrected to check logical ports in response to
                redundancy queries.
                Fixed crashes during startup when using Cox or Simple protocols.
                Version information for About window and titlebar now extracted from resource file.
                Help file (grd32.chm) should be placed in the same folder as GRD32.
                Requires gr32fix.exe and grd32fix.dll to be in windows path to share the grd windows handle
                and maintain backwards compatability with externals using BBC_GRDCONNECT.

                New settings & functionality for V3 users:
                - removes dependancy on Borland custom controls
                - adds Cross-mapping of sources & destinations
                - ES/NS cmd now handles ForceTxRx
                - adds option to inhibit network command processing during startup
                - workstation number is requested from CSI (V4CSI & CSI32)

                New settings & functionality for V4 users:
                - adds Sony protocol
                - additional switch option '2' for Router Modify command to send only revertives from the changed sources

v1.0.0.1	25/06/12	Project development environment migrated into Visual Studio 2010
                Runtime library 'msvcr100.dll' is now required to be in the windows command path
                Adds buffering for client and device messages before doing any processing (IPC breakdown)
                Adds RxOnly_Broken (NB) message if an external client fails to respond. Forwarded BBC_CTRLDRIVERSTR messages
                should be acknowledged with a non-zero return from external client otherwise GRD32 checks that ext window exists.
                Forwards BBC_DEVICEIDINUSE and BBC_REQDEVGOTXRX messages to external client.
                External driver IPC breakdown checks added to CSI redundancy status queries.
                Closedown message (BBC_CSICLOSING) also sent to external client window when host closes.
                Removed config and documentation for Sony and Pesa delay settings. The timer function has been bypassed since V2.

v1.0.0.2	08/10/12	Tidies the handling of messages requiring buffering.
                Protects shared grd window handle from being overwritten during abnormal closure (ie forced closure of second instance).
                Corrects wParam value in forwarded BBC_DEVCOMMANDMSG.
                Default device 'Name' key written to GRD section of ini file if not found in GRD or Device sections.
                Window maximize button disabled.
                Revertive messages to externals now enabled in RxOnly.
                Build settings confirmed as /MD, runtime libraries 'msvcp100.dll' and 'msvcr100.dll' are both required in the windows path.

v1.0.0.3	14/03/13	Title bar elements re-ordered to make device number and status more prominent on the task bar buttons.
                Changed External driver mode text to also indicate the IPC type in use for labelling consistency.
                Listbox updates now processed individually using names passed in the RM command.
                Adds Redundancy switching menu.

v1.0.0.4	17/07/13	Revised WS Access string parsing - Bug #2377
                Adds handler for BBC_GRDSETDESTONLY message - Bug #2381
                Fixes extended Rx Inhibit at startup. Initial tally counts 'real' destinations only within comport polling loop - Bug #2388
                Amended FirstVirtual config notes in the CHM file to be more explanatory - Bug #2389
                Fixes NetUpdateOnStart by clearing tally table for 'real' destinations to generate network revertives from initial poll responses

v1.0.0.5	19/07/13	Adds updated config notes to project in CVS. No other changes.

v1.0.0.6	09/09/13	Fixed error in recent NetUpdateOnStart mod that could prevent 'virtual' tally data being read from DAT file - Bug #2450

v1.0.0.7	27/01/14	Adds button/menu option to view virtual routes - Bug #2503
                Revised GUI layout with extending panel to accomodate larger listboxes with indexed names
                Increases namelength limit for use with CSI memory databases (max 255 chars)
                Adds button to hold current source listbox position for next selection
                Reinstates original NetUpdateOnStart mechanism - Bug #2508

v1.0.0.8	27/02/14	GUI development and test version only.
                Adds optional Enable to Take functionality
                Adds simple Undo feature
                Adds optional Park source button and listbox handling for Source 0
                Adds coloured indicators for virtual paths and destination lock status
                Adds automatic Tally view switching for virtual destinations
                Modifies Listbox hold to retain previous source selection
                Adds smaller dialog size option for 800x600 screens
                Saves dialog position and menu options to ini file and restores after restart
                Rationalises dialog update calls

v1.0.1.0	07/03/14	Release version with the updated GUI

v1.0.2.0	01/04/14	Checks BBC_GRDUSERSTR messages to external driver and filters RC messages from destinations that are locked - Bug #2532

v1.0.3.0	29/04/14	Improves listbox behaviour  - Bug #2540
                Removes double revertives when using virtual table and source already routed - Bug #2544
                Returns the current tally in response to a request to route a locked destination
                Appends 'Simulation' to title bar when running in simulate.

v1.0.3.1	06/05/14	Adds files missed in previous commit.
                'Simulation' indication and locked source revertive.

v1.0.3.2	12/05/14	Finally removes double revertives when using virtual table - Bug #2544
                Corrects listbox offset with/without Park source enabled when using Source Hold option.

v1.0.4.0	29/05/14	Fixes selective tally dump after database updates to virtual source names - Bug #2547

v1.0.5.0	14/04/15	Will now return a tally if you route a virtual source to a dest that's already got the real source on there
                        (and wouldn't otherwise return a tally)

v1.0.6.0	01/05/15	changes icon to new style

v1.0.7.0	15/05/15	crashfix to out-of-range array value when using virtual dests with unset tallies
v1.0.8.0	19/05/15	GRMain_SendDestStr now returns virtual tallies rather than real tallies - it's what the 'X' client interface deals in
v1.0.9 - v1.0.11 - development versions
v1.0.12.0	01/06/15	Rudimentary resizing of dialog - no layout managers makes this tedious but the listbox sizes track
                        moves the "Config" entry to under the file manu (it's a means of accessing the config FILE)
                        moves the current tally indication to adjacent to the dest listbox label (as per older versions of GRD)
v1.0.13.0	10/09/15	Fix to 1.0.12 'cause I didn't fully understand the implications of the changes I made
v1.0.14.0	15/09/15	minor fixes to 1.0.13 regarding dialog drawing/placement
v1.0.15.0	17/09/15	further honing of 1.0.14 to persist window position between restarts (in temporary path)
v1.0.16.0	30/10/15	uses device number for the file it uses to store location and UI state
                        saves size/pos on closedown (doesn't save if dialog never got displayed e.g. error box)
v1.0.17.0	11/01/16	Now uses handleshare DLL in preference to HWND_BROADCAST
v1.0.18.0	26/01/16	Sets resize window style when changing between windows that are meant to be resized and those that aren't
v1.0.19.0	31/05/16	Fixes UI colouring that was broken when the UI was split into main & extension
v1.0.20.0	10/10/16	Passthrough of BBC_SETREDUNDANCYMASTER to CSI
v1.0.21.0	12/10/16	Fixes remaining issues arising while making the GUI size variable (Bug #2618).
v1.0.22.0	05/06/17	Adds keyboard shortcuts for "Clear Errors", "Set to TxRx" and "Enable Source Hold"
v1.0.23.0	15/12/17	Workstation number as retrieved from CSI was only being set when getting CSI's handle "the old way". Now does it every way!
v1.0.24.0	22/04/18	Small enhancement to BBC_REQDEVGORXONLY to pass on from CSI the workstation number in wParam
v1.0.25.0   24/09/18	Makes the same as infodriver in that it will accept extended device numbers
v1.0.26.0   02/10/18	Range checking of workstation number and blunt extension of workstation range support
v1.0.27.0   11/04/19    Rejects null characters on Leitch (text) protocol (BST-516)
v1.0.28.0	15/08/19	BST-547 PostMessage now checks return value to stop hanging memory allocations in extreme overload conditions
v1.0.29.0   21/11/19	BST-676 Now permits routes to locked destination when the virtual source has not changed
v1.0.30.0   10/06/20	BST-827 Crashfix on "View Config Path" menu item (buffer not long enough - particularly for >3 character device numbers)