Fetch PA calibration (K-factor) history right after connecting to the printer

[ClusterM]

Summary

The PA calibration table (per-filament K-factor / pressure advance, shown as K 0.035
on the Device tab) was only requested from the printer when the user opened the
Calibration tab. As a result, opening Device first showed empty K values, and they
only appeared after visiting Calibration and switching back.

This PR makes the client request the PA calibration history automatically as soon as the
printer reports a (new) calibration version — i.e. right after connecting and the first
pushall — so the K-factor is populated regardless of which tab is opened first.

Root cause

The K-factor data is not part of the regular push status; it has to be requested explicitly
via the extrusion_cali_get command. Only two places triggered that request:

• Calibration tab — PressureAdvanceWizard::update() requests on IsVersionExpired()
  with no extra gating, so it always worked.
• Device tab — StatusPanel::update_ams() requested only when
  IsVersionExpired() && is_security_control_ready(), and only while the Status sub-page was
  visible.

The extra is_security_control_ready() gate (device certificate readiness) frequently
prevented the request on the Device tab, so the data appeared only after the Calibration tab
issued the (ungated) request.

Change

Move the request into the model layer. In MachineObject::parse_json, right after the
calibration version is parsed (DevCalib::ParseCalibVersion), trigger a PA history request
when the version is initialized, expired, and no request is already in flight:

if (m_calib && m_calib->IsVersionInited() && m_calib->IsVersionExpired() &&
    m_calib->GetPAHistoryStatus() != CalibStatus::REQUEST &&
    m_calib->GetPAHistoryStatus() != CalibStatus::WAITING) {
    m_calib->SyncCalibVersion();
    GUI::wxGetApp().CallAfter([this] {
        PACalibExtruderInfo cali_info;
        cali_info.nozzle_diameter        = GetExtderSystem()->GetNozzleDiameter(0);
        cali_info.use_extruder_id        = false;
        cali_info.use_nozzle_volume_type = false;
        m_calib->RequestPAHistory(cali_info);
    });
}

Design notes:

• Version-driven trigger. Reuses the existing IsVersionExpired() mechanism: the request
  fires on the first reported version and re-fires only when the printer announces a new
  calibration version.
• No duplicate requests. SyncCalibVersion() is called synchronously so subsequent push
  messages arriving before the deferred call runs do not enqueue duplicate requests; the
  REQUEST/WAITING status check adds a second guard.
• No is_security_control_ready() gate, matching the working Calibration-tab path — this
  is what fixes the "empty on Device" behavior.
• CallAfter dispatches the command on the GUI thread, consistent with the existing
  command_request_push_all / command_get_version calls in the same parse_json.

Display code (AMSLib::render_generic_text → CalibUtils::get_pa_k_n_value_by_cali_idx over
GetPAHistory()) is unchanged; it already worked once the data was present.

Test plan

• Connect to a printer and open the Device tab directly (without visiting Calibration).
  K-factor values (K x.xxx) are shown for calibrated filament slots.
• Verify the values match those shown on the Calibration tab / history dialog.
• Run a new PA calibration on the printer; confirm the Device tab picks up the updated
  K values (calibration version change triggers a refresh).
• Reconnect / switch between printers and confirm the history is fetched again per device.
• Verify no excessive extrusion_cali_get traffic (request is sent once per version, not
  on every push).

[hemai249]

Hi! @ClusterM We have fixed this issue in the latest version. Please try using the latest version.

[hemai249]

Hi! @ClusterM we were triggering the update check based on AMS data pushes; once the device connected, an AMS data packet would arrive, which we used to initiate the PA data request. The reason it wasn't triggering correctly was due to a bug in is_security_control_ready, which we have already fixed in the latest version.

[ClusterM]

Hi! @ClusterM we were triggering the update check based on AMS data pushes; once the device connected, an AMS data packet would arrive, which we used to initiate the PA data request. The reason it wasn't triggering correctly was due to a bug in is_security_control_ready, which we have already fixed in the latest version.

Yes, seems like it's fixed. Thank you!