QS BHD - Setup and Interfacing

This document outlines the steps involved in setting up a BHD operation.

Setup and Interfacing - Database Setup Program

There is considerable variation in how a BHD dredger is configured in terms of sensors used, and whether all or some of the sensor data is read by Qinsy directly from the sensors themselves as opposed to being delivered via the dredger's PLC. 
Depending on your particular configuration there may not be a need to add ALL the Objects and Sensors covered in this section.
Nor do you need to adhere exactly to the order of actions laid out below. For example you can define all the sensors and variable nodes on one object before creating the next object.

The following presents one configuration which should provide sufficient guidelines to cope with alternative setups.

Objects

In the Database Setup program Start Object Wizard  .

Add a Pontoon Object, type Vessel, locating the object reference node (CoG) in an appropriate place.
In our example this is located at keel level directly under the backhoe's rotation point. 

Proceed through the Object Definition wizard. 

Define a Pontoon shape from at least a top view perspective, and a side profile perspective.
An aft view may be useful.
How detailed to make the object shape is a personal choice.

Similarly add an Object, type Link Object, for the Backhoe cab.

Similarly add Objects, type Link Object, for Boom and Stick.

Add a dredge bucket Object, type Dredging Tool, locating the object reference node (CoG) in an appropriate place.

In this case at the bucket rotation point.

In essence the dredge tool is defined as a matrix of pseudo-singlebeam echosounders, one for each cell of the matrix.
Therefore you must enter the number of rows and columns, and the actual overall width and length of the head.
Use the   button in the Object - Dredge Head Model dialog to generate the number of cells that fit the entered dimensions.
Define the maximum Z, which is the distance from the CoG  of the bucket to the cells representing the knife edge.
In our example, the knife edge and CoG  are at the same level when the bucket is oriented with a zero pitch angle.  

 A model is created in a spreadsheet type format. Each cell is then treated as a pseudo-echosounder which is used in updating the sounding grid during dredging operations.

The objective is to enter a height into each cell that represents the distance above (+ve) or below (-ve) the Bucket's CoG . In our example this is zero for all cells.
The center cell (green color) of the grid becomes the reference point that is linked elsewhere to a defined variable node, e.g. CoG .

Not all cells need be used in the calculation. In the example only the knife edge cells are enabled, all other cells disabled (red color) and are not used in updating the sounding grid.   

Return to: top of page.

Object Links

In the real world the various objects are physically linked, e.g. backhoe to pontoon, boom to backhoe etc..
The next step is to create these links in the software.

If able to display all objects mentioned above, define the appropriate Object Links.

If the pertinent variable nodes are not yet defined, you will need to define them on each object before creating the links.
This can be done via the   button (see below).

The link between the Pontoon and the Excavator is shown below:

And a link from the Excavator to the Boom:

Return to: top of page.

Sensors

Dredge Vessel

Define one or more Navigation Positioning systems, selecting the correct driver for each.

Add a variable node  and enter the correct offsets for the GNSS antenna variable node from the Reference Point ( ).

Define a Gyro system. Choose the driver and the object on which it is located.

Define a Pitch Roll Heave system, sometimes called Motion Reference Unit (MRU) or Vertical Reference Unit (VRU).

Choose the driver and add a variable node , entering the system offsets from the Reference Point ( ).

Define an Underwater Sensor system and add one or more draft observations.

For example: fore and aft draft sensors.
Add new node(s)  for their locations relative to the Reference Point ( ).

Define a Pseudo-USBL system.

Dredge Tool positions are sometimes output from the dredger's PLC in USBL format (dX/dY/dZ).
These observations are often relative to the pontoon's Reference Point ( ), i.e. the USBL Reference Point coincides with the vessel Reference Point. 

Define a Dredge Sensor System and select the appropriate driver.

Add one or more of these observations depending on the data being received from the PLC or directly from the sensors:

Production volume is not calculated for backhoe dredgers.
The most likely observations to be used are Flag and Status.

Make sure to enter the correct slot identifier values. For example:

If data input includes triggers (zero or 1) for conditions such as Excavating or Dumping add one or more Flag observations.
Typically the trigger is output by the PLC but a trigger may also be generated when connected to switches or push buttons used to trigger such items Dumping/Backfill.
The Manual Switch Driver document describes how to set up this scenario.

Define a Dredge System and select Backhoe from the list of Dredger Types.

If dredging 'Status' is received from the PLC and used in Qinsy, select that option and establish the 'Translation' table to decode the correct status.
For example: 

The Eventing System can also be used to establish status.

Set the Update Rate to Very High.

Set parameters for positioning and backfill:

Return to: top of page.

Backhoe

Determine the sensors used to position the Backhoe Cab, Boom, Stick and Bucket. 

This assumes that observations are available to the software, either from the PLC or interfaced directly. These could be:

Vertical Position

• Inclinometers to measure Boom, Stick and Bucket pitch.

• Motion Reference Units to measure Cab attitude.

The vertical position of the Bucket can be checked / calibrated by .......................

Horizontal Position

• Rotation angle sensors, designed for rotations in the horizontal plane. 

  An angular position sensor (also referred to as a rotary sensor) measures the relation by which any position with respect to any other position is established. It calculates the orientation of an object with respect to a specified reference position as expressed by the amount of rotation necessary to change from one orientation to the other about a specified axis.

Define a Positioning System when there is one located on the Cab.

Often this is a dual antenna GNSS providing both position and heading.
Define the Nodes for primary and secondary antennas. 

Define a rotation angle sensor when main positioning and heading is located on the Pontoon.

This provides the horizontal angle of the Cab with respect to the Pontoon.
Define the node at which the sensor is located.

Define inclinometers (MRU) that measure the pitch of the Boom, Stick and Bucket.

Define the nodes at which the sensors are located.

Return to: top of page.

Output Systems

Output systems are defined in a single page dialog box, requiring only a system type, a driver and network or serial interfacing details.

Positioning, Heading and Motion

Depending on the how the hardware interfacing is configured it may be necessary to define one or more data output systems.
For example, when positioning, gyro and motion sensor systems are interfaced directly to Qinsy, sending that data to the PLC may be required.

Generic Output (User-defined ASCII)

Whereas predefined output drivers send data in specific formats, there may be instances where the dredging computer (PLC) expects to receive data in a specific format not covered by existing Output Systems.
In those cases the Generic Output (User-defined ASCII) driver may be used.
The template database setup is simple: System Name, System Type: Output, Driver, and network or serial interfacing details (Serial, TCP, UDP).

Note the option to select 'Redundancy based'. See Redundancy Monitor.

When the Controller is started, the Generic Output icon  is found in the task bar.
Use the Add button in the dialog box to create the Generic Output content.
Please refer to the for detailed information about this utility.

Generic ASCII Data Logger (Controller)

In cases where ASCII data must be written to a log file in a specific format, the Generic ASCII Data Logger driver may be used.
The template database setup is simple: System Name, System Type: Output, Driver, and network or serial interfacing details.

Note the option to select 'Redundancy based'.  See Redundancy Monitor .

 The XML file, in which the output content and format is specified, is created using the Generic Layout Editor, started from the icon located in the Console's lower pane.

Please refer to  for detailed information about this utility.

Return to: top of page.

Auxiliary Systems

Tide

 When not using RTK GNSS heights define a Tide Gauge system.

Choose a driver and enter serial or network interfacing details.

Use the button which then requires selection of a Fixed Node to use as a tide station.

Use the button to add a fixed node.

In the Edit Fixed Node Parameters dialog enter:

• a name

• the coordinates of the station

• the horizontal datum

• station height

• instrument height

• and, most importantly, the Vertical Datum.

Time Synchronization

Perhaps not as critical in dredging operations, it may still be useful to define a system.

Define a Time Synchronization system, choose a driver and enter serial or network interfacing details.

Choose whether to .

This is a hardware device manufactured by QPS for converting a TTL or CLS pulse to an RS232 compatible signal.

Choose the Time Tag-Pulse Matching method. Text in the dialog box explains the three options.

Choose whether to . It is highly recommended to leave this unchecked.

Miscellaneous System

• A number of Miscellaneous System drivers are predefined in terms of what they will decode:

For example: 

Nortek Vessel Mounted Current Profiler:
Decodes current speed and direction. Used when dumping.

• Others allow you to add user-defined observations and slot identifiers to match those in the received data string. 

For example:
Generic Serial Input 
Manual Miscellaneous Input 
OPC Interface 

Redundancy Monitor 

The purpose of this driver is to perform an election process which decides which Qinsy system is the primary system for data output.
Typical use for this driver is on a larger vessel when there are multiple Qinsy computers that are part of the same network and only one computer should output data to external systems. Each Qinsy computer needs to have the driver running and correctly configured. The driver will make sure that there is only one Master Qinsy computer and this Master can be the only system to output data.

Continue to: Create Sounding Grid and Import Design Model

Return to: top of page

Return to: Quickstart - BHD