Events

Something that is still missing in the CTrack architecture is event handling (besides error handling which is a different category).

Examples of events:

• On a Leica system 
• • the TProbe is activated
  • A different tip is inserted 
  • A different type of SMR is selected from the UI
  • A temperature warning is given

In all these case the event will originated from the proxy, will be send to the engine, which takes its actions and then resends it to UI's.

Events can be interchanged using an XML message, containing

• EVENT as tag
• NODE UUID to identify the affected object
• type of event as text attribute 
• extra information depending on the event type

Let's take the example of a tip change on the Leica system

• The event is triggered by  Targets.ActiveTipChanged by the LMF driver
• The proxy send and Event as XML to the proxy device on the engine
• The proxy device is responsible for handling the XML and knowing what to do
• • On the engine : update the tip matrix
  • On the UI:
  • • Update the CAD
    • Update the name 
    • Update ICON

The best way to test this implementation scheme is through the template proxy.

We can implement and test a number of scenarios

• Trigger a warning event
• Trigger a probe update event
• If we have a rigid body with extra markers and want to reset these:
• • we send a command to the engine with the id of the rigid body
  • the engine sends an event back to the UI to notify the definition has changed and with the new matrix
  • the ui updates the 3d view

The handling of the events should be done mainly by the affected node, so the UI receives an event with the ID of the node and the extra information that comes with the XML payload, the node then has to extract the information from the XML and act

The handle event should be a virtual member of CProxyDevice and it should accept an XML as input. If overridden, the override implementation must call the __super if not handled.

Error handling

Made the next changes to the template:

Added sending of TCPGram in catch handlers of main of proxy.

This will handle errors as they occur during a run.

However if an error occurs during a detection or an initialization, the situation is less clear.

Normally these packages work with CProxyDevice::SendCommandWaitReturn which will only respond to TCPGRAM_CODE_COMMAND types of messages.

So we could extend this to also respond to TCPGRAM_CODE_ERROR, and then we could throw an error as well.

It would be better if we can provide a set of code 

virtual bool GetReceivePackage(std::unique_ptr<CTCPGram> & ,
                               const std::set<unsigned char> &CodeSet = TCPGRAM_CODE_ALL);

with 

const std::set<unsigned char> TCPGRAM_CODE_ALL = {TCPGRAM_CODE_DOUBLES,  TCPGRAM_CODE_COMMAND,TCPGRAM_CODE_STATUS,TCPGRAM_CODE_CONFIGURATION,TCPGRAM_CODE_STRING,TCPGRAM_CODE_EVENT,   TCPGRAM_CODE_INTERRUPT,TCPGRAM_CODE_ERROR,TCPGRAM_CODE_TEST_BIG,TCPGRAM_CODE_INVALID};

We can then keep the existing GetReceivePackage with a single code and call in that one the other with the set, check if we received a warning or error, and act upon those before handling the normal execution:

bool CCommunicationInterface::GetReceivePackage(std::unique_ptr<CTCPGram> &ReturnTCPGram, const unsigned char Code)
{
    std::set<unsigned char> CodeSet = {TCPGRAM_CODE_ERROR,Code};
    bool                    bReturn = GetReceivePackage(ReturnTCPGram, CodeSet);
    if (bReturn)
    {
        if (ReturnTCPGram->GetCode() == TCPGRAM_CODE_ERROR)
        {
            throw ReturnTCPGram->GetException();
        }
    }
    return bReturn;    
}

Test with template proxy

• throw error in hard detect
• • should only show in feedback
• throw error in config detect
• • not sure what should happen : generates an error also in UI, so errors are correctly forwarded
• throw error in check init
• throw error 2 seconds in run
• throw error in post process
• give a warning during run : send and event : see proxy template in main when typing 'w'

Leaving the proxy open

Both Hard and Config detect open the proxy, get the result and close it again.

It might be better to leave the proxy open until ctrack closes or the device is no longer part of the configuration.

We could have a map of proxy names vs process handles for example. Note that the name of the proxy as key in this map is not sufficient: when we have multiple trackers of the same type, then we also need the serial number if it exists. With Leica this would be the case, but for Vicon it would not be. 

This map is a static member of CProxyDevice.