C-more’s trend cursor can display a value that differs from the live gauge or digital object because the trend’s visual resolution is limited; first check how you are reading the trend before changing the Modbus data or reinstalling the panel.
Compare the cursor reading with the logged value
When a trend value comes from the cursor bar, treat it as a visual estimate, not as a precise readout of the logged sample. The trend’s visual resolution is 1% of its full-scale range. On a trend with a 200-unit full-scale range, that means the smallest change the display can show is 2 units. A cursor can therefore show the same displayed value for nearby samples or appear one or more counts away from a digital object.
This distinction fits symptoms such as live objects showing 480 while the trend cursor reports 479, or two nearby values appearing identical on the trend. It does not establish that every reported discrepancy has this cause: the deciding check is whether the displayed value came from the cursor or from the logged data.
- Record the gauge or digital-object value and the trend cursor value at the same time.
- Read the corresponding logged data rather than relying on the cursor’s plotted position.
Check: If the logged sample matches the live value while the cursor differs, proceed as a trend-display resolution issue. If the logged sample itself is wrong, continue with the tag and scaling checks below.
Check the trend’s full-scale range
Inspect the configured trend range before changing project data. A trend’s visual resolution is relative to that range, so a wider range reduces the detail the cursor can represent. Use the trend’s configured minimum and maximum to determine its full-scale span, then compare 1% of that span with the size of the observed discrepancy.
For a 200-unit span, the minimum visible change is 2 units. This does not mean the data logger rounds every sample to 2 units; the limitation applies to the visual trend resolution. If the full-scale range is different, calculate 1% from that actual range rather than assuming the same step size.
Check: Confirm whether the cursor’s apparent step matches 1% of the configured span. If it does not, inspect the logged sample and data configuration instead of forcing a range change to hide the mismatch.
Separate display resolution from data scaling
A gauge, digital display, trend plot, and trend cursor may not present the same representation of a value. Check whether each object references the same tag and whether each uses the same data type and scaling configuration. In the described setup, the source was standard Modbus (Modicon) addressing with signed 16-bit integers; verify the actual tag setup in the project rather than assuming all objects handle it identically.
Scaling can introduce rounding when the project converts values in both directions. An integer with an implied decimal place can lose precision during such conversions. Floating-point values can also display apparent precision that does not represent exact arithmetic; floating-point calculations can differ between systems. These are reasons to inspect the conversion path, not proof that a particular conversion caused a given trend error.
| Observation | Likely area to check | Next test |
|---|---|---|
| Cursor differs, logged value matches live object | Trend visual resolution | Compare discrepancy with 1% of trend full-scale range |
| Logged value and live object differ | Tag, data type, or scaling path | Compare raw and displayed values at each conversion |
| Nearby values display identically on trend | Cursor resolution or plotted visual step | Check logged samples and full-scale span |
| Mismatch persists in a minimal project | Project configuration or panel behavior | Preserve the project and escalate if local checks do not isolate it |
Check: Confirm that the live object and trend use the intended tag, data type, and scaling. Compare the underlying logged value with the converted display value before adjusting either one.
Trace each conversion without changing the source value
Do not compensate for a cursor-only discrepancy by offsetting the Modbus value. An artificial offset can make one display look right while making the logged data or other objects wrong. First identify where the value changes: the register/tag value, any scaling or implied-decimal conversion, the live object, the logged sample, or only the trend cursor.
- Write down the tag, address, data type, and scaling used by the trend and the live display.
- Compare the Modbus value with the displayed value at one stable operating point.
- Check whether an integer value is scaled in both directions or represents an implied decimal place.
- Compare the logged sample with the live value, then compare both with the trend cursor.
- Repeat at a second stable value to see whether the difference is consistent or changes with the value.
The case described reported close readings at several points: 480 versus 479, 500 versus 500, and 300 versus 299. It also reported nearby values appearing the same or between the expected values. Those observations justify checking the complete path; they do not justify applying a fixed one-count correction.
Check: You can identify the first point in the path where the displayed value diverges. If the values only diverge at the cursor, leave the source tag unchanged and address how the trend is interpreted.
Use logged data as the accuracy check
The trend’s plotted appearance and cursor position are not a substitute for its logged data. Use the log to judge whether samples are correct. The log data does not have the trend’s stated 1% visual-resolution limitation, so a cursor discrepancy alone is not evidence that the stored value is inaccurate.
Compare the time-aligned logged sample against the live value. If they agree, the control or measurement value and stored sample are aligned at that point; the remaining difference is in the visual trend representation. If they disagree, return to the tag, data type, and scaling path, and make the same comparison at another stable value.
Check: Record a logged sample and its corresponding live reading. Use that pair—not the cursor alone—to decide whether the trend data itself requires correction.
Rebuild only after isolating the failure
Repeated firmware reloads, panel resets, software reinstalls, and project transfers do not diagnose a display-resolution or scaling problem. The reported case tried reinstalling C-more, updating to version 2.53, starting over with a new project, removing the battery, reloading firmware, and loading by LAN and USB; the mismatch remained, including in a minimal project. Repeating those actions before comparing the logged values risks spending time without identifying the point of divergence.
Keep a copy of the current project and a minimal test project. In the test project, compare one live object, one trend, and one tag, then inspect the logged value and cursor separately. Change the trend range only to test its effect on visual resolution; do not alter the register value to force agreement. If the mismatch is present in the logged data, preserve the test project and the exact tag, data type, scaling, and observed values for technical support.
Check: A minimal project should reveal whether the disagreement is limited to the cursor or also appears in stored samples. If both projects show the same logged-data fault after tag and scaling checks, stop repeating reloads and escalate with the project.
Verify the complete trend path before returning it to service
Test the intended configuration from source value to displayed result. Use stable values and confirm that the live object, logged sample, and cursor are being compared as separate outputs. A cursor that differs by a small amount does not fail this check when the logged sample matches and the cursor’s step is explained by 1% of the trend range.
- Confirm the tag, Modbus address, signed 16-bit data type, and scaling used by the tested objects.
- Confirm the trend’s full-scale range and calculate 1% of that span.
- At a stable value, compare the live object with the logged sample.
- Compare the cursor separately, and determine whether its displayed step is consistent with the trend resolution.
- Repeat at another stable value and retain the readings with the project configuration.
Check: Return the trend to service only after the logged samples agree with the source/display values at the tested points and any remaining cursor difference is understood as visual resolution. Stop and contact official C-more technical support if logged values remain wrong after the tag, data type, and scaling path are checked, or if a minimal project reproduces the fault; provide the project and the paired readings.
Frequently asked questions
Why does my C-more trend show 479 when the gauge shows 480?
If 479 comes from the trend cursor, compare it with the logged sample and calculate 1% of the trend’s full-scale range. The cursor has 1% visual resolution; the logged data does not share that limitation.
What happens if two nearby values look identical on the trend?
The trend may not visually resolve their difference at the configured range. Check the logged samples and the full-scale span before changing either source value.
What happens if I use signed integers with scaling?
Scaling in both directions with an integer that uses an implied decimal place can introduce rounding. Compare the raw tag value, converted display value, and logged sample to locate the conversion where they diverge.
What happens if the logged value is also wrong?
Check that the trend references the intended tag, then inspect its data type and scaling path. If the mismatch persists in a minimal project, stop repeating firmware reloads and send the project and paired readings to official C-more technical support.
Stop and escalate to official C-more technical support when the logged sample remains incorrect after checking the tag, data type, and scaling, or when a minimal project reproduces the fault. Provide the project and readings that compare the source/live value, logged sample, and cursor.