Skip to main content
Skip table of contents

Tug Manager - 15

Description

Driver to output tug, rig and anchor positions to the QPS Tug Display. The driver supports multiple tugs.

Beside the tug information, the position of the rig or barge and the anchor positions can be send to the Tug Display on the tug(s).

The output interval of all messages is user definable to save bandwidth on the radio link.

Driver Information

DriverTug Manager Interface Type
Driver Class Type
UTC Driver (question) NoInput / OutputOutput ExecutableDrvOutXxxManager.exe 
Related Systems
Related Pages



Interfacing Notes

The Tug Manager is developed in conjunction with the Tug Display. In operation it will probably make use of a two way radio connection.

On the tug position and heading data will be sent to the rig or barge. If this is a GGA and HDT message each updating once a second, it is advised to us the combined NMEA GGA / HDT driver.

On the barge the tug data is sent back to the tugs.

If there is a two way radio link you will get for each tug a position / heading on an I/O port and for all the tugs one I/O port for the Tug Manager output driver.

This data then needs to be split to each of the separate radio links to the tugs.

Online

Anchor State Table

Most messages contain an Anchor State value, this decimal number represents a combination of the following hexadecimal table:

flagSingleOperation

0x0000

flagMultiOperation

0x0001

flagAssigned

0x0002

flagRacked

0x0004

flagTransit

0x0008

flagDropped

0x0010

For example:

  • An anchor state value of  7 (decimal) means: 
    • The anchor is part of a multi-vessel operation, it has been assigned to a tug, but it is still racked on board the rig. (1 + 2 + 4 = 7)

  • An anchor state value of  17 (decimal) means: 
    • The anchor is part of a multi-vessel operation, it has been dropped on the seafloor, and is currently not assigned to any tug (1 + 16 = 17).

Online Qinsy will show the Tug Manager Display as displayed above.

  • Tug

    By checking / unchecking the check boxes in front of the tugs data can be sent (or not).

  • Add Tug..

    User can add a tug and set its nodes for the stern roller and the GPS antenna through the Tug Properties dialog.

  • Tug Properties...

    It is important to give each tug a unique ID so that the Tug Displays on the tugs can filter out the data meant for that tug.

    Important

    Although the user already defined tug properties (Vessel Object, Computation and Roller Node) in the Controller's Anchors Vessel Setup, it is important to select exactly the same settings for each Tug in the Tug Properties dialog.

    If the settings (Vessel Object, Computation and Stern Roller) are not the same as selected in the Controller's Anchors Vessel Setup, the outputted Anchor Id in the $PQTUC message will be -1, and therefore not recognizable by the Tug Display.

    In the future these settings will be automatically copied from the Controller, but as said, in the current version you have to select the same in this Tug Properties dialog.

  • Output...

    The driver can output various messages. The output frequency of the various message types may be changed by the user.
    Usually it will be a trade-off between available radio bandwidth and refresh frequency.

    Press the "Output..." button to activate the Output Settings dialog (see below):


    Description of available options:

    • Enable Serial output

      Switch on/off generation of serial data. Can be used to disable the output of the driver.

      • Send Delay

        The send delay is the amount of time that the driver will wait between sending two consecutive messages. This delay is introduced to give the radio modem some time to recover after sending a string.
        For example, when new node results are available for multiple tugs at the same time then multiple TUG messages will be sent. Between the PQTUG messages the driver will insert a delay.

      • Encapsulation (Default set to Disabled)

        Prior to output, the datastring can be 'wrapped' by other characters according to a certain protocol. 

        Only OPNA-message supported

        Currently only one protocol is supported: the OPNA-message format of a Thales Tracs TDMA Radio Link.

        Another radio link unit will then recognize this message, it 'un-wraps' the original data string and passes it through to other devices.

        • The OPNA protocol (ASCII) has the following format description:

          Format
          $PRPS,OPNA,ddd< ascii data>*hh<cr><lf>
          

          Format Description

          Field

          Format

          Description

          Values, Range, Units


          ddd

          destination ID (000 if a broadcast message)



          <data>

          1 to 482 characters. This is the original datastring. Each char must be in the range 20H to FFH with the exception that the following control characters can be used.
          STX (02H) is converted to CR (0DH) for transmission, ETX (03H) is converted to LF (0AH) for transmission. This is to allow CRLF to be added to strings sent over the air.



          *hh

          Checksum


    • Output Tug info - $PQTUC

      • Mode:

        • Off

        • Every user definable second

        • Every position update


      • Use compressed PQTUC Format ( default
        The much smaller PQTUC message is sent instead of the legacy, bulkier (but more precise) PQTUG message. 
        In order to save bandwidth in multiple tug anchor management we advise the usage of PQTUC.


    • Output Rig Info - $PQRIG

      • Mode 

        • Off

        • Every user definable second

        • Every position update. 

        This will change the output of the $PQRIG message.

        Can be used to visualize a rig or barge shape onto the tug display(s).


    • Output Anchor Info - $PQANC

      • Mode

        • Off

        • Changes + Time interval.

          Single PQANC message is generated whenever a change in anchor state occurs (e.g. it is dropped or picked up). 

          • Every ... seconds
            All anchors are transmitted every user defined number of seconds. 
            This is useful for (re-)starting tug displays or whenever an anchor message is not received properly when it changed.
            This message can be used to visualize the actual anchor positions onto the tug display(s).

            Will only output when

            The Anchor Information can only be outputted when the Rig Information is outputted at the same time.

            This is because the Tug Display needs the rig position to calculate one end of the anchor wire.

Additional Information

History

Driver version:

  • 8.10.2012.10.04.1
    • The (user-defined) anchor state colors is now part of the $PQANC message, so a possible connected Tug Display can use the same anchor state colors as seen on the main Qinsy computer.

      • There will be a registry key "OutputAnchorColorState" that an advanced user may set to zero in case the Tug Display should stick to the default anchor state colors:

        • Blue: dropped

        • Green: transit

        • Yellow: racked

    • Prevented outputting tug messages (at startup) with non-valid tug positions. These messages could crash a connected Tug Display.

    • Added text in the title bar of the dialog when all output has been disabled by the user.

Further Reading

Please read the 'How-to Anchor Handling'  which is available in the Qinsy Knowledge Base.

 

 

 

 

 

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.