College of Technology

Course/Project

BNCS Support
Title

BNCS Overview
Contents
Overview ..................................................................................................................... 2
Introduction ..................................................................................................................................... 2
Block Diagram of a Generic System ................................................................................................. 4
Panel Application ............................................................................................................................. 5
Panel Development .......................................................................................................................... 6
CSI .................................................................................................................................................... 7
Drivers .............................................................................................................................................. 8
Generic Router Driver (GRD) .......................................................................................................... 11
GPI Driver (General Purpose Interface) ......................................................................................... 11
Info Drivers..................................................................................................................................... 11
Other Drivers.................................................................................................................................. 11
Combiner ....................................................................................................................................... 12
Fabian............................................................................................................................................. 14
Network ......................................................................................................................................... 15
Location of Software Modules ....................................................................................................... 16
Workstation Start Up ..................................................................................................................... 17
CS Deploy ....................................................................................................................................... 18
Workstation Manager .................................................................................................................... 18

Document Details
Author Hild Watts
File \I:\Training & Development Shared\BNCS Data Deposit\Training docs\bncs overview_v12_11-1-18.docx
Version Date Note
10 21/01/2013 See previous saved version for prior history
11 04/03/2014 Combined with NI version
12 11/01/18 Updated to incorporate references to versions above 4.5

Page 1 of 20 © BBC 2013

BNCS Overview BNCS Support

Overview

Control Systems Background

BNCS is a control system for broadcast equipment and systems. The first BNCS system was
aimed at controlling routers (matrices). Routers are usually supplied with some sort of control
panel. This can be connected to a router frame to provide basic control as shown in figure 1:

Panel Panel Panel

Protocol
Protocol Protocol

Router Frame Router Frame

Figure 1 Figure 2

This will allow one user to route sources to destinations for that frame (say video). This is fine
for very small applications but inflexible. To allow more than one user to control the frames
(Figure 2) requires a way of deciding who has priority.

Once you add more routers, the situation becomes more complicated. For example, to route a
studio to network may require the switching of video, two audio channels (for stereo),
talkback, red light cues, timecode etc. These are known as levels. You do not want to have to
switch each level separately. The solution is to use a control system that stores the main
sources and destinations (such as studios) and which actual sources and destinations are
needed for the various levels. The list of actual sources and destinations for a studio, say, is
known as a Package. Thus we have source packages and destination packages.

The control system also handles all the prioritising and locking (Figure 3).

2 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Panel Panel Panel Panel

Control System

Video Audio Talkback etc.

Router Router Router

Figure 3

BNCS uses a distributed system as shown in Figure 4.

Panel Panel Panel

PC PC PC

Network

PC PC
Apps/Database

Server
Video Audio

Router Router

Figure 4

The control panels could be constructed in hardware (i.e. switches and metalwork) but
touchscreens are usually used because they offer so much more functionality and flexibility.

3 College of Technology
© BBC 2018
BNCS Overview BNCS Support

BNCS Introduction
BNCS stands for Broadcast Networked Control System. It is a control system for broadcast
equipment. Originally, it was called the BBC Networked Control System, the change of name
coming when it started to be marketed outside the BBC. For a while it was also called Colledia
Control. Although this name has been dropped it still comes up in various places within the
system. BNCS was sold to Siemens with the sale of the original BBC Technology. It is now
owned by Atos, although the BBC retains the right to use it internally. We also have the right
to create new drivers, with the proviso that all new drivers we develop become the actual
property of Atos and they can let other customers use them too.

It consists of a set of software modules that run on standard PCs connected by an Ethernet
network. It can control a wide variety of equipment and the range is increasing all the time as
new drivers as written to meet the specific needs of particular projects.

Block Diagram of a Generic System

4 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Panel Application
The panel application varies:

Versions 1 to 3 Applcore.exe
Version 4.5 and above PanelMan.exe (or cut down version such as bncs_v45_host.exe)

Applcore.exe
Applcore is a control panel development system. It was the original BNCS client. It gets its
name from the fact that it is the core application behind every panel. There are three main
versions of Applcore that have been used in existing systems.

Version 1.xx is the original and evolved from conception. Version 2.xx is a much enhanced
version that behaves more like a programming language. Both versions can run side by side on
the same PC and inter-operate in the same system. Both version 1 and version 2 are 16 bit
code.

Version 3xx was not originally developed, but Version 3 is now used to designate the 32 bit
port of version 2 with some enhancements. Although version 2 will run on 32 bit operating
systems such as Windows XP and Windows 7 32 Bit, it runs in a protected 16 bit environment
and there are problems with its keeping track of time and resources.

At one stage some new installations used version 4.0, which is a development of version 2
that was designed to run on Linux as well as Windows but this was dropped.

V4.x Panel Manager

The current version of BNCS (which for many years was known as Colledia Control) is version
4.6. This is an evolution of 4.5 and is expected to have relatively frequent upgrades. Therefor
the system is generally known as 4.x as the overall structure of 4.5 and 4.6 (and 4.7 when that
comes along…) is very similar. The panel application is known as Panel Manager
(PanelMan.exe). This should not be confused with the panel manager applications written in
V3 Applcore.

It provides all the functionality of the panel – the layout of the panel is stored as an XML file. It
also provides buttons that switch between the different panels, and a menu with extra
functionality. With version 4.x there is an extra layer of configuration in the form of some xml
files. These store information about the controllable devices which means that panels can be
built with little or no coding.

5 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Other Panel Applications

It is possible to write panels and other client applications in almost any language, such as
Visual Basic, Delphi and Borland Builder although these require programming knowledge.
BNCS provides a documented interface for such purposes.

Panel Development
Applcore – Versions 1 to 3
The panel description is supplied to Applcore.exe in the form of a Windows Resource file. This
is a text file with a .rc extension. It is one way in which the visual components of a Windows
programme can be described. The Applcore programming language is entered as
text/stringtables – a type of resource that is usually used to hold the text elements of a user
interface.

BNCS uses a very old resource editor called Borland Resource Workshop. This is 16 bit
application developed originally for Windows 3.1. It can be used to edit 32 bit .exe files, but
not to compile them. For work with version 3, Resource Workshop is used to develop the .rc
file which is then compiled into v3 Applcore using a BNCS facility called V3 compile.

The reason Resource Workshop is still being used is that many BNCS /BBC custom controls
have been developed for it, which cannot easily be converted for use by a newer resource
editor. It will not run under 64 bit windows.

BNCS Visual Editor

Version 4.x uses the BNCS visual editor, an application developed by the BNCS team. Panel
layouts are stored as xml files with a .bncs_ui extension. Panels can be built with little or no
coding – these are called unscripted panels.

This is possible because of an extra layer of configuration in the form of some xml files. These
store information about the controllable devices.

If more complex functionality is needed then scripted panels are used. These add a .dll file
containing compiled C++ code.

6 College of Technology
© BBC 2018
BNCS Overview BNCS Support

CSI
CSI is the mechanism by which panels communicate with the network and share the revertive
information that comes back from the device drivers via the network. Panels register with CSI
for the revertive (tally) information that they wish to receive at any one time. CSI receives all
messages from all drivers on the network. It filters messages and only passes on those of
interest to panels who have registered for such messages.

Database Services
CSI provides database services so that panels can retrieve source and destination names for
use within the panels or change the database across the whole system. In order to do this
there must be a copy of the router driver dev_xxx.ini files in the local config directory.

Network Management
CSI also allows the remote enabling and disabling of a workstation by the Network Manager
should the need arise.

Presentation
Normally CSI is minimised at the bottom of the screen. Maximising CSI reveals a dialog box
containing various items of information.

Initialisation
When CSI starts up it establishes a connection with the network transport - NetBIOS. This is
not the same as ‘logging on’ in the conventional sense. CSI registers its workstation number,
in the form 'WORKSTATION_123, with the network so that no other CSIs that subsequently
start up can use the same number. If CSI detects another CSI with the same number on the
network then it will flag a warning via a dialog box and then closedown. CSI also registers the
generic name 'CSI' by which it receives all revertive messages.

CSI then loads local copies of the system databases into memory. This is done to provide
clients quick access to database names.

CSI version prior to 1.16 read the workstation number and the number of network buffers to
use from the APPLCORE.INI file. From version 1.16 onwards this information comes from the
CSI.INI file. It is also CSI which makes the workstation visible to the Network Manager
application.

CSI32
The current version of CSI is called CSI32. It has some new features such as:

7 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Message recovery.
Built in to CSI32 is a message recovery system. Each package of revertives (or commands) sent
out by CSI has a serial number attached. Receiving CSIs look at this serial number and if it
notices that it has missed one or received one out of turn can re-request the package from the
originator. You can also get reports of message recoveries and unrecoverable messages.

Driver Heartbeats.
Also built in to CSI32 all drivers send a heartbeat to report their TXRX state and workstation
they are running on. CSI32 has two internal infodrivers (123 and 124) which store the state of
the drivers and also the status of the workstations (uptime, messages missed, etc.).

Drivers
Drivers are programs that take BNCS packets and convert the command into the correct form
to drive a piece of equipment. A driver will appear within BNCS as one or more devices.

A device could be a simple X-Y router or a single VT machine and in these cases the driver will
appear with the system as a single device. When a driver is controlling a complex piece of
equipment such as a comms system that does routing, GPI switching, panel key assignments
and panel display labelling then it's a little more complicated. The driver, in this instance,
would appear as four devices. Each device has a particular function. A device, therefore,
represents a particular function. It presents itself to the BNCS network as a unique numeric
identifier (Id) between 1 and 999 inclusive. No two devices (with the same number) can be
present on the network. Generally a driver will refuse to run if it finds that another driver has
already registered the Id or Id's it intends to use. The only exception to this is when a driver is
run as main and reserve, when both will be on the network with the same driver number –
although only one will be in Rx/Tx mode, the other will be in Rx Only mode.

A driver is run from a command line, or more usually a shortcut. The driver number is supplied
as a command line parameter. For instance, to start a Generic Router Driver, V2GRD.exe as
device number 001, the shortcut would be something like:

c:\bncs\drivers\v2grd.exe 001

Each device is configured using an .ini file of the form Dev_xxx.ini where xxx is the device
number. In this case the file would be Dev_001.ini:
[Device]
Name=Device 001

[Database]

8 College of Technology
© BBC 2018
BNCS Overview BNCS Support

DatabaseFile_0=DEV_001.INI
DatabaseFile_1=DEV_001.INI
DatabaseFile_2=DEV_001.INI
DatabaseFile_3=DEV_001.INI
DatabaseFile_4=DEV_001.DB4
DatabaseFile_5=DEV_001.DB5
DatabaseFile_8=DEV_001.INI

DatabaseSize_0=4
DatabaseSize_1=2
DatabaseSize_2=4
DatabaseSize_3=2

[Database_0]
0001=BLACK
0002=CAM1
0003=CAM2
0004=BARS

[Database_1]
0001=MON
0002=VF

[Database_2]
0001=Black & Burst
0002=Camera 1
0003=Camera 2
0004=Colour Bars

[Database_3]
0001=Monitor
0002=Viewfinder

[Database_8]
0001=0001,0002,0003,0004
1001=0001,0002

[GRD]
Name=Default
ParkSource=0
FirstVirtual=0
SaveDelay=10
FwdBuffDelay=0
RevertiveDelay=0
DriverMode=INTERNAL
InitTallyDelay=200
TallyDelay=2000
RevertiveMode=DRIVER
NetUpdateOnStart=1
ReAssert=1
DebugMode=0
SourceToDest=1
DestToSource=0
NameLength=8
Simulation=0
BBCRCP_Levels=1
LeitchLevels=OBSOLETE
QuartzLevels=VAB
NetworkRouterType=VIDEO

9 College of Technology
© BBC 2018
BNCS Overview BNCS Support

NetworkRouterLvl=0
LeitchLevel=0

[Com_1]
MinDest=1
MaxDest=24
Protocol=QUARTZ
Speed=9600
DataBits=8
StopBits=1
Parity=N

[Com_2]
MinDest=NONE
MaxDest=NONE
Protocol=NONE
Speed=0
DataBits=8
StopBits=1
Parity=N
There are 2 parts to this file shown in blue and pink:

The blue part is known as the ‘database’ section and holds source and destination names.
[Database_0] is source names, [Database_1] is destination names. In this case databases 2
and 3 are used to hold long version of the source and destination names. The section,
[Database], specifies in which file each database is listed. You can see that in this case
databases 0 to 3 and 8 are listed in this file (namely Dev_001.ini) and databases 4 and 5 are
listed in separate files. It does not matter if the files specified in this section do not actually
exist. Database 8 is used to hold button maps and is used to create different layouts for
different panels from the same router configuration.

Higher databases are often used for features of an installed system such as source and
destination groups or pages – but their use can vary between projects.

The database section of the file can be created by copying and modifying a previous file or by
using the MDP.exe utility (Make Device Profile), or by CSI when it starts, if it detects a
dev_xxx.ini file without a database.

If you are using the MDP method, then this must be done before running the driver for the
first time. If CSI is running at the time then the DEV_XXX.ini will be created on all PCs on the
network. Be very careful if you are doing this – if you accidentally choose the wrong device
number, choose one that is already in use and CSI is running – the new, blank ini-file you’ve
just created will overwrite the real one that was in use. Not just on your machine, but on all
machines on the network. I would strongly recommend amending an existing ini-file manually
or letting CSI create a base-file for you, it is MUCH safer.

10 College of Technology
© BBC 2018
BNCS Overview BNCS Support

The pink part holds the configuration for the device, in this case the GRD. Useful things here
are Simulation, Revertive and the settings for each Com port which include the protocol for
the router being controlled. This part of the file is created when the driver is first run.

Generic Router Driver (GRD)

These can control most types of standard routers (which is one that can route one input to
any output) that can be controlled serially (RS232 or RS422/RS485 can be used depending on
the serial cards in the computer). The driver is configured using a .ini file. The main
parameters that are required to be set are the protocol (eg Probel, Quartz etc), the comm
port settings, the router size, the source and destination names and the map table (database
8).

GPI Driver (General Purpose Interface)

GPI Drivers are designed to work with off-the-shelf digital interface cards. These usually have
GPI type relay outputs and opto-isolated inputs but other types, such as open collector are
available. They allow the control of equipment that does not have a serial port. Panels can set
the state of the outputs and read the state of the inputs.

Info Drivers
Info Drivers are programs that act like simple databases. Each info driver has 4096 slots each
of which can hold text up to 1024 characters in length. They provide a way for panels to share
information. Most BNCS now use info drivers to act as an interface between the driver itself
and the panel.

Other Drivers
For a complete list of drivers currently available see the BNCS web site. The location of this
site has changed a few times. It is currently run by ATOS and is only available to registered
BNCS developers. The first drivers written were the GRD (Generic Router Driver) and the GPI
drivers. The Applcore programming language includes commands for these devices, such as
RC (Route Crosspoint) and GS (GPI switch). To avoid having too many commands and to allow
for greater flexibility, more recent drivers use an info driver as an interface between the panel
and the actual driver. This idea is sometimes known as driver externals:

11 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Device 202 PC
Info Driver
Slot
Description Notes
Number
Device 202
The following commands are
used:
1 = Stop (also issues a Standby
On)
2 = Play
Transport 3 = Rec (Crash record)
1
Command 4 = Rew
5 = F.Fwd
6 = Eject
7 = Variable(,speed) VT Driver VTR
8 = Shuttle(,speed)
9 = Jog(,speed)

This shows the actual status of Sony P2

the machine. This slot will show
what is happening even if the VT Protocol
is taken local.
Windows
1 = Stop
2 = Play
Messaging
Transport 3 = Rec
2
Status 4 = Rew
5 = F.Fwd
7 = Var
8 = Shuttle
9 = Jog
10 = Cueing

21 = At cue

The only command required in the panel is IW (Info Write). In this case, writing a ‘2’ to slot 1
will cause the machine to go into play. The transport status can be monitored from slot 2,
even if the machine is in local. When an info driver slot changes, the slot issues a revertive
(you can think of an info driver slot as a destination and the contents of the slot as the source).

The idea of driver externals can also be applied to the GRD (Generic Router Driver). The GRD
lives on the same pc as the actual router driver. They talk via Windows messaging. The GRD
responds to RC (Router Crosspoint) packets and responds with revertive. It talks to the actual
router driver to make the switch and receive tally information. Several drivers of more
modern routers work this way.

Combiner
These provide multi-level routing (video, audio, timecode etc) using packages in earlier
versions of BNCS. Packager was used in Version 1 of BNCS, and Combiner is used in later
versions – however from V4.5 onwards this has been discontinued. It is still worth knowing
about as it is used extensively in BH.

12 College of Technology
© BBC 2018
BNCS Overview BNCS Support

The Combiner actually consists of 4 BNCS modules, Combiner.exe plus 3 Infodriver.exe's and
an associated Dev_xxx.ini file (where xxx is the device ID of the Combiner). It obtains source,
destination and level mapping information from the Infodrivers and device type and ID
information from the Dev_xxx.ini file. The source and destination information is contained in
InfoDriver slots in the form a comma delimited list of numbers which is known as a ‘Package’.
The numbers themselves in the list refer to source or destination indices of actual devices. The
order in which the numbers appear in the list corresponds to the [Levels] section in the
Combiners DEV_xxx.INI file which is where the Combiner obtains the Device type and ID
information. All levels must be specified, if a level is to be omitted then a '-' should be used in
place of a source or destination.

The information stored in the Source or Destination Infodrivers can be modified by polling the
Infodriver, splitting up the comma delimited list into individual numbers, modifying those that
need changing, rebuilding the string and writing it back to the same slot.

From v4.5 onwards the same function can be achieved using code and external files, read
during execution.

13 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Fabian
FABIAN was originally developed as a "Fast Access Booking Information And Notification
System" designed to manage regional booking information and real time messaging facilities
to assist in the distribution of programme material. Since its conception however its main
function has migrated to acting as a TCP/IP link between BNCS installations. A Fabian TCP/IP
Link consists of the Fabian Control System Link module - FBCSLink.exe and the Fabian Server
module - FBServer.exe.

Both FBServer and FBCSLink interface via CSI to the BNCS environment. FBServer appears to
CSI just like any other client and FBCSLink appears like a driver. A message from a client /
ApplCore panel is passed via CSI to FBCSLink which is configured to redirect commands from
the local BNCS environment to a remote Fabian Server. The FBServer then passes it on to its
CSI for processing. Revertives are passed back from CSI to the FBServer, back to FBCSLink and
in turn to the interested clients. FBCSLink can maintain active connections with up to 64
Fabian servers at different sites. Remote device IDs can be translated into different local ID's if
there is a conflict between the two areas or the system administrator wishes to logically group
the remote sites. FBCSLink can be configured to connect to an alternative Fabian server if the
connection to the normal one fails. The configuration for this and for ID translation is held in
FBCSLink.ini.

BNCS BNCS
Network 1 Network 2

Commands

Fabian
NetBEUI

NetBEUI

TCP/IP Server
FBCSLink Network

Revertives

14 College of Technology
© BBC 2018
BNCS Overview BNCS Support

A single link, such as the one shown above will allow complete control of devices on a remote
network. If duplex control is required then FBCSLink and FB Server must be running at both
ends of the link:

BNCS BNCS
Network 1 Network 2

Commands

Fabian
FBCSLink
Server

NetBEUI
NetBEUI

TCP/IP
Network

Fabian
FBCSLink
Server
Revertives

Network
BNCS is designed to use a dedicated Ethernet network. It accesses the network using the
NETBIOS interface. The preferred protocol was originally Microsoft’s NetBEUI (Netbios
extended user interface). NetBEUI is a relatively simple protocol that was designed for small
office workgroups. It is fast, but cannot be routed onto different local area networks.

NetBEUI has not been supported since windows XP, so TCP/IP is now used. But ‘Netbios over
TCP/IP’ must be enabled.

BNCS theoretically can share network traffic with other systems but for security reasons
doesn’t. Therefore a separate network or VLAN is normally used.

15 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Location of Software Modules

Any combination of BNCS clients (panels) and drivers can be run on any machine on the
network. It is possible to run a complete system on one PC although it still needs a network
card.

The locations of files will vary from system to system. Some typical options are:

Original BNCS (V1, V2, V3):

BNCS Modules live in C:\BNCS
Config Files live in C:\Windows

Some Newer BNCS (V3)

BNCS Modules live in C:\BNCS\Lib
Config Files live in C:\BNCS\Config

The locations of the files are set in bncs_config.ini which lives in the root of C: - but be careful,
you may have problems getting Borland to work if the config and library files live anywhere
other than C:\Windows. It is possible, but may be difficult to achieve.

For V4.x systems all the files live in the BNCS folder (which in many older machines will be
called CollediaControl). There is a sub folder for the system (a machine can host multiple
systems). Current active system is set by environment variables.

So to take the (V3) system in W1 as an example:

BNCS Modules live in

BNCS Modules live in C:\CollediaControl\lobh\windows\lib
Config files live in C:\CollediaControl\lobh\config\system

16 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Workstation Start Up
When a BNCS workstation starts up, the applications need to start in the right order and often
need to wait until one application has started before starting the next.

The original BNCS used a utility called vXlaunch.exe (e.g. v3launch.ini) for this. It gets the list
of applications to start to from launch.ini. There is a section for each workstation. Prior to
running launch there is usually one or more batch files which copies the latest version of the
software and config from the Info Server. Here is a typical V3 system:

Windows starts.
In the Windows startup folder is a file called Update.bat. Here is an example from the system
in the BH control room:
net use z: \\WS_800\c$
xcopy z:\bncs\modules\*.* c:\bncs\modules /c/i/f/d/k/y
xcopy z:\bncs\panels\*.* c:\bncs\panels /c/i/f/d/k/y
xcopy z:\windows\dev_???.ini c:\windows /c/i/f/d/k/y
xcopy z:\windows\dev_???.db? c:\windows /c/i/f/d/k/y
xcopy z:\windows\global.ini c:\windows /c/i/f/d/k/y
xcopy z:\windows\launch.ini c:\windows /c/i/f/d/k/y
xcopy z:\bncs\setup\*.* c:\windows /c/i/f/d/k/y
net use z: /d /y
c:\bncs\modules\v2launch.exe

VXLaunch.exe
This runs the applications listed in Launch.ini. If the command [Wait] is included after the
application in the list then it waits for the application to start before running the next.
Typically it runs, in this order: CSI.exe, drivers, automatic panels, panels.

Each workstation has an entry in Launch.ini, so there is an identical copy of the file on each
machine.
[Workstation_041]
DebugMode=0
QuitWhenDone=1
Boot_1=<Directory> C:\BNCS\system
Boot_2=V3CSI.EXE [Wait]
Boot_3=<Directory> C:\BNCS\drivers
Boot_4=V3INFDRV.EXE 200
Boot_5=<Pause> 10
Boot_6=C:\BNCS\PANELMAN.EXE
Boot_7=
Launch executes all applications listed against entries which start Boot_X where X is a number
between 1 and 99. The first entry must be Boot_1 and there must be no gap in the
incrementing numbers.

17 College of Technology
© BBC 2018
BNCS Overview BNCS Support

If the keyword <Directory> is found then the current directory will be changed to that
following the <Directory> statement.

If the keyword <Pause> is found then launch will pause for the number of seconds indicated.
This gives critical applications time to settle down if necessary.

After the last application has been started Launch will arrange all the icons at the bottom of
the screen into a neat row and remain as an icon itself.

This is an example only. There may be variations between systems. For instance sometimes
Update.bat calls another batch file which then runs Launch.exe.

CS Deploy
This was developed in English Regions as an alternative to using batch files and launch. It
combines the functionality of both and adds additional features such as the ability to delete
files, in order to mirror a folder, and to kill applications.

Workstation Manager
This is a version 4.x application which gets the list of applications to start from a file called
launch.xml. Before running the applications it synchronises files with the server – unless it has
been configured as a stand-alone machine. Once the applications are running Workstation
manager keeps track of them and will show in red any applications that have crashed. It can
be configured to try and restart them. It can also be used to manually stop and start
applications, which can be easier than trying to find them on the taskbar.

Environment Variables
Version 4.x uses 4 environment variables, which are used to set the basic parameters of the
system:

CC_ROOT Path to main BNCS folder. e.g. C:\BNCS

CC SERVER_ROOT Full UNC Path to BNCS folder on Server e.g. \\myServer\C$\BNCS

CC_SYSTEM Name of current system and sub-folder of CC_Root e.g. Studio6_Main

CC_WORKSTATION Workstation Number e.g. 434

If these are set, the system is assumed to be a v4.x one.

18 College of Technology
© BBC 2018
BNCS Overview BNCS Support

BNCS Versions

The versions are all basically compatible at the network level.

The 16 bit versions will run on 32 bit Windows with a few issues. The 16 bit environment has a
separate system clock. If the csi time server feature is used, it will only set the 16 bit clock –
leaving the possibility that the 16 and 32 bit clocks will be out of sync. The Applcore command
that will kill panels if the system resources are low doesn’t work properly because the 16 bit
environment doesn’t correctly know about the main system resources. The 32 bit version will
run on 64 bit Windows but the 16 bit version will not.
There are some issues using Windows 7 and 8. You need to make sure that any folders on the
main system drive (usually c:) have full access permissions. And Windows 7 and 8 may not like
applications with normal user permissions writing to the root of c: which can cause problems
with bncs_config.ini which lives there. This is especially true of the BBC Desktop machines.
The latest version 3 applications can be set up not to use the Windows folders for config files
but to keep them all in a folder under the bncs folder (as pointed to by bncs_config.ini).
However some older versions have C:\windows hard coded into them so may not work
properly this way. It can be a bit hit and miss!

19 College of Technology
© BBC 2018
BNCS Overview BNCS Support

Utilities
vXCapLog.exe BNCS packet capture program. Needs a folder called c:\bncslogs and a
printer set up.

MDP.exe Makes the database part of a dev.ini file and updates all workstations
via csi

cursor.exe A utility to turn off the windows cursor

vXLaunch.exe Program for launching BNCS (or other) applications in a well ordered
way. V2, V3, V4 versions available

CSDeploy A new startup program developed in English Regions that combines

functions of Launch and the Update.bat file

Setlana.exe A utility for setting the protocol and adapter used by BNCS

aCommand A test utility that allows you to send Applcore/BNCS commands to the
network

bCommand A more modern version of aCommand. Can show revertives.

ParamTester.exe A v4.x programme that allow you to operate the drivers via the xml
config

20 College of Technology
© BBC 2018