Leica continued

On multitracker setups

A proxy will serve one single tracker, so if we have a setup with 2 trackers, the hardware detection will record tables with names, serials and so on,... but the configuration will have 2 tracker units and 2 Leica devices, which each start their own proxy to have a single tracker communication.

This keeps things simpler, and potentially also more performant.

Regarding the manual, next sections are interesting

• 10.1 : exceptions
• 10.2 :warnings and errors as event
• 11 : persistency of tracker behavior after reconnect and reboot
• 12: use of simulator (note that multi-trackers can be simulated too)
• • targets with * or ! are not compensated
  • all settings in blue can be saved
• 14: connecting
• 15: tracker object
• • 15.2: ascynchrone commands have Async at the back and return the result by an event handler
• 16: Targets
• • T-Products are not selectable, they are detected and selected automatically
  • use tracker.Targets to access the different targets
  • 16.2 gives an overview of targets and probes
  • 16.4 overview of tips
  • 16.5: finding a target
• 17: positioning the laser and searching targets
• 18: triggers : buttons are detected by a TriggerHappened event
• 19 : different measurement methods
• • 19.2.6 : external trigger by clock source
• 20 : OVC = the Over View Camera
• 22 shutting down and controlling the laser beam
• 24 power source
• 25 inclination sensor
• 26.6 base coordinate system of different types of trackers
• 28 different timings for longer processes
• 29 PTP
• 35 probe power

Error handling and logging

This has not been handled sufficiently yet.

Currently the next files are part of the shared Library under Utilities

• errorHandling.h
• Logging.cpp and h

Main loop handler

The most outer catch handler is in the main routine and is surrounded by the main loop, so that if an error occurs, the loop continues.

These exceptions should be reported to CTrack and logged.

Local handlers

If the SDK of the hardware throws errors, then these could be handled locally.

For example for a hardware detection, when the device fails to connect, this should be reported through the Feedback string, which is returned as a TCP message.

Same for configuration detection.

If an error happens during a run, then the handler of the main routine should catch it and it should report this back to the engine.

Later on we may have extension for laser trackers where jog and target looking operations are done through this mechanism.

Actions

So we still need:

• Foresee a TCP package to wrap error information
• Check all locations where std::cerr is used and replace this with PrintError
• Update Print.. routines to log the information

TCP error telegram