Skip to Content
CTech Digital
  • Home
  • Odoo services
  • AI services
  • Contact us
  • 0
  • Nederlands (BE) English (UK) Français
CTech Digital
  • 0
    • Home
    • Odoo services
    • AI services
    • Contact us
  • Nederlands (BE) English (UK) Français

15/5/2025

  • All Blogs
  • Daily blog
  • 15/5/2025
  • 15 May 2025 by
    CTech Metrology, Luc Wens

    Still working on logging.....


    Taking the decision to not add stack tracing to the proxies since their functionality does not go very deep. overhead of coding is not worth the effort.

    A bit on events and warnings

    For Proxies there is a TCPGRAM_CODE_EVENT, which includes warnings and events coming from devices.

    In the engine we can call CStateManager::SendWarning to forward this to the UI.

    The UI receives a CCommandWarning which triggers OnWarning in responders.cpp. Onwarning set the orange icon and displays a text.


    Currently these are the command classes 


    Not sure what I was thinking🤔 but make a class for each and every possible command, really.... There are a number of commands that relate to laser trackers, those should really not be there.

    Question is of course if we can/should change this here and now.

    How would we do it if we had to do this all over:

    • Having a command derived from CNode we can keep since it allows us to put automations in a configuration
    • But one CCommand would be sufficient. The command with all the parameters should be in a JSON structure, which can be converted to Text for saving/loading and sending over TCP

    In the same way we could organize events, although these don't need to be derived from CNode, as they are not part of a configuration.


    After a conversation with Gemini: we could make a Message class that serves both commands and events. 

    I made a test project at F:\BoostJsonCommand\BoostJsonCommand.sln to investigate the concept.

    At the receiving end we can have a map that links the event/command to a lambda. It is already more or less like this in the responder files from CTrack. This could lead to a 2-tier response function:

    • First respond to the type of telegram based on the binary code (5th char of the telegram)
    • If it is of message type, then use the identifier to execute a certain action.

    This approach would allow also to continue using the sharing of TCP support classes between CTrack at one side, and the proxies at the other side, because this is where it is running stuck now.


    in Daily blog
    11/5/2025
    Copyright © CTech
    Nederlands (BE) | English (UK) | Français
    Powered by Odoo - The #1 Open Source eCommerce