Response-time verification for a fluctuating load begins with a defensible question, not a universal number. Define the event being observed, the measurement boundary and the decision that the capture is meant to support before comparing any traces.

Direct answer
For SVG response time verification, retain a dated event window, a stated clock basis, the measurement point and operating context together. That record can support a bounded engineering review; it does not establish a fixed response value, a product fit, or project acceptance.
Part 1. Define the verification question
Start with one decision-oriented question. It might concern whether an event is visible at a named point, whether repeated windows can be compared, or whether more site evidence is needed. A broad request to “prove fast response” does not identify the boundary or the review standard.
| Verification question | Evidence to retain | Not established |
|---|---|---|
| Was a load event captured? | event definition and capture window | a universal response value |
| Can two windows be compared? | same point, clock basis and stated conditions | an acceptance decision |
| Is follow-up required? | exceptions and missing inputs | a product selection |
Part 2. Set the capture boundary
Name the bus, feeder or connection point, the available measurement instrument, the timestamp basis and the signal being compared. A trace without a boundary can be confused with another feeder or another operating period.
The Power Quality System page is a useful upward product-system context, while SVG installation commissioning addresses installation records. Neither page turns an unnamed capture into a response guarantee.
Part 3. Record fluctuating-load context
Attach operating notes to each window: source arrangement, major load state, known switching activity, topology revision and any manual action. This makes it possible to see whether two captures describe comparable conditions.
The Schneider Electrical Installation Guide places power-factor and harmonic conditions in a system context. Record that context beside the capture rather than treating the visible shape of one trace as a complete engineering conclusion.
Important: A measured transition has meaning only within its stated boundary, time basis and operating conditions. It should not be presented as a universal SVG response time or as proof of a site result. Source: IEC Technical Committee 77.
Part 4. Compare windows without inventing a fixed response
Place comparable captures on the same stated clock basis and identify the trigger used to begin each window. Report any uncertainty from sampling, synchronization, threshold choice or incomplete records instead of converting it into a precise-looking millisecond claim.
| Comparison field | Why it matters | Disclosure needed |
|---|---|---|
| event definition | fixes the start of review | how the event was identified |
| measurement location | avoids mixing boundaries | bus, feeder or connection point |
| clock basis | makes timing comparison readable | clock source and known offset |
| operating state | separates unlike windows | load and topology notes |
For a broader evidence pattern, see the APF/SVG comparison method. It remains a method reference, not a substitute for this capture boundary.
Part 5. Keep exceptions in the review package
Preserve missing samples, uncertain clocks, manual interventions, alarm states and topology changes in the same package. Removing them can make a trace look cleaner while making the decision less reliable.
| Exception | Record action | Review value |
|---|---|---|
| unsynchronized sources | state the known limitation | prevents false ordering |
| changed operating state | identify the window | avoids unlike comparisons |
| incomplete event capture | mark the gap | defines next measurement need |
Part 6. Send a bounded SVG review request
The CNBYG SVG product context is relevant only after the review package identifies the project boundary. The public product page does not supply a fixed response target or confirm fit for an unspecified installation.
| Send with quote / RFQ | Why it matters | Avoid |
|---|---|---|
| single-line diagram and measurement point | identifies the electrical boundary | an unlabeled screenshot |
| dated captures and clock note | makes the comparison reviewable | an assumed fixed response value |
| load-event description and operating state | explains the fluctuating condition | a claim of acceptance |
| review objective and constraints | limits the inquiry to evidence | selecting a rating from one trace |
Product recommendation: use the CNBYG SVG product page as a product-context reference only when those inputs are available. Fit boundary: this workflow does not authorize switching, approve protection settings, establish compliance, or prove performance. Send the verification package when the evidence and decision question are ready.
FAQs
What does SVG response time verification mean?
It is a defined review of a named event window, measurement point, time basis and operating context. It is not a universal response promise.
Should every site use one response-time value?
No. The review should state its actual trigger, instruments, measurement boundary and conditions rather than apply an unsupported fixed value.
Which timestamps belong in a capture?
Keep the event definition, capture window, clock source, known offset and the times of relevant operating changes.
Why record load context?
Load state, source arrangement and topology changes explain whether two windows can reasonably be compared.
Does a waveform prove acceptance?
No. A waveform is evidence within a stated method; acceptance and compliance require the applicable project review.
What should an SVG RFQ include?
Provide the single-line diagram, measurement boundary, dated captures, load-event notes, operating conditions and the review objective.
When is engineering review required?
Use qualified project review for live switching, protection matters, unclear boundaries, acceptance decisions or conclusions beyond the available record.
