Debugging with LdmX¶

This guide explains how to use LdmX (Land Data Model Explorer) for debugging GVA DDS applications. LdmX is the primary tool for monitoring DDS traffic, tracking resource registration, managing alarms, and diagnosing system health issues.

When to Use LdmX¶

Use LdmX when you need to:

Getting Started¶

LdmX Interface Overview¶

When you launch LdmX, you'll see the main interface with tabs for different debugging functions:

Launching LdmX¶

cd build/bin
./ldmx

LdmX will start and automatically begin listening for DDS traffic on domain 0.

Configuring the Domain ID¶

If your system uses a different DDS domain, create a configuration file:

# Create config directory
mkdir -p ~/.config/ldmx

# Create configuration
cat > ~/.config/ldmx/config.json << 'EOF'
{
  "dds_domain_id": 1,
  "window_title": "LDMX - Domain 1"
}
EOF

Debugging Workflows¶

Workflow 1: Debugging Resource Registration¶

When an application fails to register or isn't appearing in the system:

Step 1: Start the Registry Service

./gva-qt6-registry --domain=0

Step 2: Open LdmX and go to Registry Status tab

Step 3: Start your application and watch for registration

Look for:

• ✅ New entry in "Registered Resources" table
• ✅ Resource ID assigned (non-zero)
• ✅ Descriptor mapping created (if applicable)

Common Issues:

Step 4: Verify descriptor mappings

Select a resource in the Registered Resources table, then check the Descriptor Mappings table for the corresponding mapping.

Workflow 2: Debugging Alarms¶

When alarms aren't being raised or displayed correctly:

Step 1: Start the Alarms Service

./gva-qt6-alarms --domain=0

Step 2: Open LdmX Alarms tab

Step 3: Trigger an alarm from your application

Watch for the alarm to appear in the table with:

• Correct category (Warning/Caution/Advisory)
• Correct description text
• Correct source resource ID

Step 4: Test alarm lifecycle

1. Raise - Verify alarm appears as "Active"
2. Acknowledge - Click Acknowledge, verify state changes
3. Clear - Clear the condition, verify alarm clears

Common Issues:

Workflow 3: Debugging UACM Health¶

When resources aren't reporting health correctly:

Step 1: Open LdmX UACM Monitor tab

Step 2: Look for your resource in the health table

Expected states:

• Operational - Resource is healthy
• Degraded - Resource has non-critical faults
• Failed - Resource has critical faults

Step 3: Check fault events

When a fault occurs, you should see:

• Fault event in the events table
• Health state change
• Timestamp of fault

Debugging Tips:

// Ensure your application publishes health status
void publishHealthStatus() {
    P_Platform_Configuration_PSM::C_Resource_Health_Status status;
    status.A_sourceID().A_resourceId(m_resourceId);
    status.A_healthState(P_Platform_Configuration_PSM::T_HealthStateType::L_HealthState__Operational);
    m_healthPublisher->Publish(status);
}

Workflow 4: Monitoring DDS Traffic¶

For general DDS debugging and message inspection:

Step 1: Use the Topics tab to see all active topics

Step 2: Select a topic to see message details

• Message count
• Last received timestamp
• Message content (field values)

Step 3: Filter by topic name or source

Use the filter box to focus on specific traffic.

Debugging Tips:

• High message count with low rate = batched publishing
• Zero message count = publisher not connected or wrong topic name
• Timestamps not updating = publisher stopped or network issue

Advanced Debugging¶

Debugging Multi-Domain Systems¶

If your system uses multiple DDS domains:

# Terminal 1: Monitor domain 0
./ldmx  # Uses default domain 0

# Terminal 2: Monitor domain 1 (separate config)
./ldmx --domain=1

Debugging with Verbose Logging¶

Enable Qt debug output for more detail:

QT_LOGGING_RULES="*.debug=true" ./ldmx

Capturing DDS Traffic¶

For offline analysis, LdmX can log messages:

1. Go to File > Start Logging
2. Select output file
3. Reproduce the issue
4. Stop logging
5. Analyse the JSON log file

Common Debugging Scenarios¶

Scenario: Application Can't Connect to Registry¶

Symptom: Registration times out or fails

Debug Steps:

1. Open LdmX Registry Status tab
2. Check if Registry Service is running (shows activity)
3. Verify domain ID matches
4. Check network connectivity

# Verify registry is publishing
./ldmx &
./gva-qt6-registry --domain=0 &
# Watch for Registry Service messages in LdmX

Scenario: Alarms Not Appearing in HMI¶

Symptom: Application raises alarm but HMI doesn't show it

Debug Steps:

1. Open LdmX Alarms tab
2. Trigger alarm from application
3. Verify alarm appears in LdmX
4. If yes → HMI subscription issue
5. If no → Application publishing issue

Scenario: External App Not Receiving Button Events¶

Symptom: Soft key presses not reaching external application

Debug Steps:

1. Open LdmX and monitor Display Extension topics
2. Press soft key on HMI
3. Verify Hard_Button_Event or Soft_Button_Event published
4. Verify source/target resource IDs match

Best Practices¶

During Development¶

1. Always run LdmX alongside your application during development
2. Watch registration on startup to verify initialisation
3. Monitor alarms when testing error conditions
4. Check message rates to ensure efficient publishing

During Integration Testing¶

1. Log all traffic for later analysis
2. Compare message counts between publisher and subscriber
3. Verify timestamps are synchronized across resources
4. Test failure scenarios with LDMX monitoring

During Production Debugging¶

1. Start LdmX first before reproducing issues
2. Filter to relevant topics to reduce noise
3. Note timestamps for correlation with logs
4. Export data for support requests

Quick Reference¶

Command Line Options¶

DDS Domain IDs¶

Key Topics to Monitor¶

See Also¶

• Debugging with ToolX - Video and network debugging
• Registration Service - Registration concepts
• Alarms Service - Alarm system details