Scribd
Upload
59 views29 pages

TUG Management Telemetry 2020 NP4

The document outlines the Tug Management Module within EIVA NaviSuite, detailing the setup and communication protocols between tugs and a barge. It includes instructions for defining modes, saving setup files, and configuring position outputs for both tugs and the barge. Additionally, it describes the use of a multiplexer for data transmission and the polling system for managing communication between the barge and tugs.

Uploaded by

paksi arif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
59 views29 pages

TUG Management Telemetry 2020 NP4

The document outlines the Tug Management Module within EIVA NaviSuite, detailing the setup and communication protocols between tugs and a barge. It includes instructions for defining modes, saving setup files, and configuring position outputs for both tugs and the barge. Additionally, it describes the use of a multiplexer for data transmission and the polling system for managing communication between the barge and tugs.

Uploaded by

paksi arif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

NaviPac 4 Tug Management Module

With Telemetry
Tug Management in EIVA NaviSuite
The Situation

Tug 1: Tug 2:
ID: 31 ID: 32

Barge:
ID: 30
NaviPac – Defining Mode

On the Barge, Rig/Barge mode must


be enabled.

Use as TUG Boat on the Tugs.


NaviPac – RIGSetup on the Barge I
NaviPac – RIGSetup on the Barge II

1 - Save as
RigMove
Setup file.

2 - Save as
TUG Rigmove
Setup file.
NaviPac – Rigsetup for the Tugs

[RigMove]
Barge_id=30
No winch points=8
WinchName01=W1
WinchOffset01=10.000, 60.000, 0.000
WinchName02=W2
WinchOffset02=27.000, 57.000, 0.000
WinchName03=W3
WinchOffset03=27.000, -42.000, 0.000
WinchName04=W4
WinchOffset04=5.000, -42.000, 0.000
WinchName05=W5
When saving the TUG Rigmove Setup file, the WinchOffset05=-20.000, -42.000, 0.000
warning above is given. WinchName06=W6
WinchOffset06=-42.000, -42.000, 0.000
The file NP_TUG.ini, which is generated from the WinchName07=W7
WinchOffset07=-42.000, 57.000, 0.000
RIGSetup tool (previous slide), must be copied WinchName08=W8
onto the Setup folder in EIVAHOME of each of WinchOffset08=-25.000, 60.000, 0.000

the Tugs (C:\EIVA\NaviPac\Setup).


NaviPac – Barge – Position Output
To send the position of the
Barge to the Tugs, the
following must be defined: Address of multiplexer:
127.0.0.1 (Port 5000).
NaviPac – Barge – Position Output
To send the Barge position to the Tugs, the following output must be selected:
• The IP Address should be 127.0.0.1 to send the data to the Multiplexer.
• ID of the barge position must be set to 30.
• Choose format NaviPac.
NaviPac – Tug – Receive Barge Position
To receive the barge position on the tugs, the following Dynamic positioning system must
be defined:
• The IP address: 127.0.0.1 is
pointing at the Multiplexer
program.
• The TP number of the barge is
30.
• The ID of the Barge vehicle must
be 30
NaviPac – Tug – Position Output

To send the position from


the Tug, this output must
be selected:
NaviPac – Tug – Position Output
To send the position from the Tug 1, the following output must be defined:
• The reference point (CRP) should be the stern. This is usually the anchor handling point on a tug.
• The ID must be defined as 31 (Tug 1).
• Format is NaviPac + Tug state.
NaviPac – Barge – Receive Tug Position
To receive the tug positions on the barge, the • The IP address: 127.0.0.1 is
following Dynamic positioning system must be the address of the
defined: Multiplexer.
• The TP number of Tug1 is
31.
• The TP number of Tug2 is
consequently 32.
• The ID of the tugs is 31 and
32, respectively
NaviPac – Tug1 – Receive Tug2 Position

To receive the position from


another Tug, the following
input must be defined:
NaviPac – Tug1 – Receive Tug2 Position
To receive the position from another Tug, the following input must be defined:
NaviPac – Barge – Output Anchor Pattern
To send the Anchor pattern to the Tugs, a
NaviPac format
’Data to tug boats’ output must be defined
must be chosen.
on the Barge:
NaviPac – Barge – Send Runlines
To send Runlines to the Tugs, this
output must be selected:
NaviPac – Tug1 – Receive Anchor Pattern I
To receive the anchor pattern on a The IP address: 127.0.0.1 is the
tug, a ’From Remote NaviPac – address of the multiplexer.
Control’ Misc input must be defined: Port 5020 is the port, to where the
multiplexer is distributing the anchor
pattern and the runline data.
NaviPac – Tug – Receive Anchor Pattern II

To receive the anchor pattern on the Tug, the Remote NaviPac window will be
opened automatically when entering online mode. Click on the ’TUG id’ text-box
and the window to the right will open. Now insert the ID (31 for Tug 1 etc). NaviPac
will remember this setting.
NaviPac – Messages from Tug to Barge
The operator on the tug can activate some anchor-related commands towards the barge.
The activation takes place from the Helmsman’s Display of the Tug:
• PICKED UP - The anchor has been picked up from barge (state becomes ‘Tracking’).
• DROPPED - The anchor has been dropped on the seabed (state becomes ’Laid’).
• DE-ASSIGN - The assignment is rejected from the Tug
• FIX - Various events performed on the tug (will be shown on HD of the Barge).

The commands are sent on top of the existing ‘Data to external navigation system’ output,
so no additional setup is required on the tug boat.
The data output (on the Tugs) must be selected to ‘NaviPac + Tug state’ or ‘Expanded
NaviPac’.
NaviPac – Barge - Messages from the Tug I
A ‘Misc’ input, ‘From Remote NaviPac – control’, must be defined in order to enable the
Barge NaviPac to be capable of using the in-coming tug commands.
As the data most often is overlaid the general navigation data (from the Tug) the driver
must be specified to I/O mode ‘Off’.
Note the port number – has to be 10507.
NaviPac – Messages from the Tug II

When in online mode, click on the ’TUG id’ text-box and the window to the right will
open. Now insert the ID (0 - telling that this is the barge). NaviPac will remember this
setting. The window should never be closed, as it acts as interface between the
NaviPac kernel (interpreter) and the TMS kernel (RigMon).
NaviPac – Barge – Using Multiplexer I
Three different telemetry systems
possible, each related to a
radio/frequency.
Definition of com-port and I/O settings for
the radio interface from where data is read
from/routed to.
Remote navigation data distributed to port
5010.
Tug Management data distributed to port
10507 (always).
Output port: all outputs to port 5000 (see
next slide)
Asyncronous mode selected – otherwise
Polling master on the Barge and Polling
Slave on the Tugs.
NaviPac – Barge – Using Multiplexer II

All data must be output on the same


address/port – ex 127.0.0.1 / 5000.
NaviPac – Tug – Using Multiplexer

All outputs to port 5000


Asynchronous mode
NaviPac – Barge – Polling Master
In polling mode, the Barge acts as a master
in the communication. Tugs can only
transmit within certain time-slots, when
requested. Tugs are divided into polling
groups with different polling frequencies.
Main polling frequency. A polling sequence
starts with this interval. In TMS scenario
only tracking vessels are polled with this
interval. In normal scenarios all vessels are
polled with this frequency.
Defines the time given the modems to
switch mode (Rx/Tx).
Enable ‘Send Cmd..’ if TMSMaster/
TMSSlave is used
Polling frequency for assigned vessels.
Polling frequency for all other vessels.
List of tugs to be polled. The list must be a
space separated list of object IDs.
NaviPac – Tugs – Polling Slave
If the Barge is set to Polling Master
mode, all slaves must be set to Polling
Slave mode. They are only allowed to
output data to the multiplexer when
requested. Slot allocation for this is
handled purely by the master.
The tug ID (31 here) must be defined
when in slave mode.
The slave can be configured to send an
end message (acknowledge) when all
buffered messages have been sent.
This allows the master to close the
timeslot before timeout and thereby to
optimize the use of the bandwidth.
This can be an alternative to defining
the ‘Maximum Reply Characters’ on the
polling master. The optimal solution
would be obtained by setting this value
too high and let the slave send
acknowledgements.

You might also like