ECOM100 data that alternates between a valid value and zero needs to be isolated at the source before anyone changes the host trend or PLC logic. Compare the value in DirectSoft with the host reading, then inspect packet-loss diagnostics in NetEdit; this separates a changing PLC value from an unreliable communications path.
Compare DirectSoft and host values before changing anything
A host trend that alternates between, for example, 6.00 and 0.00 can make a communications gap look like a real process change. First determine whether the zero exists in the controller data or appears only after the host requests it. Changing scaling, filtering, or the plotted range before making this comparison can hide the symptom without correcting its source.
- Choose one affected setpoint or analog value and record its controller address and expected engineering units.
- Observe that value in DirectSoft while the host is showing the alternating readings. Compare the values at the same time, as closely as the tools allow.
- Repeat the comparison for another affected point if needed. Note whether the controller value itself reaches zero or remains steady while the host reports zero.
Check: If DirectSoft also shows the value changing to zero, investigate the logic, source signal, and controller-side data path. If DirectSoft remains steady while the host alternates, continue with the ECOM100 communications checks.
Check ECOM100 lost-packet diagnostics in NetEdit
When the controller value is steady but the host value drops to zero, lost or delayed data delivery is a plausible cause. A host may display a default, stale, or invalid value when a read does not complete as expected; the exact behavior depends on the host driver and its configuration. Do not treat a displayed zero as proof that the PLC register contains zero.
- Open the ECOM100 in the NetEdit utility.
- Read the lost-packet count and record it with the time of observation.
- Observe the count while reproducing the host trend problem. Compare whether the count increases as the zero readings occur.
A nonzero count by itself does not prove that packet loss caused this particular symptom. Correlate the count with the affected time period and repeat the DirectSoft-versus-host comparison. If packet counts remain unchanged, do not make an unsupported network change; investigate the host polling and data handling path next.
Check: Confirm whether lost packets increase during the fault and whether the controller value remains stable at those times.
Separate network congestion from host polling behavior
Network traffic is one possible explanation when DirectSoft is steady and the host is not, but the symptom alone does not identify a specific network fault. Host request rate, concurrent traffic, and driver behavior can all affect what the host receives or displays. Do not infer a traffic limit or change a polling interval to a specific value without measuring the installation and checking the host and device configuration.
- Record when the host requests the affected values and when it displays zero. Check whether several points fail together or only one does.
- Compare host readings with DirectSoft observations over the same interval.
- Review NetEdit lost-packet counts during that interval. If counts rise, examine network loading and the communications path; if not, focus on host polling, driver status, and value handling.
A zero isolated to one point suggests a different investigation path from simultaneous zeros across many points. Use the host's diagnostics to determine whether it received a valid response, timed out, or substituted a value; do not assume which behavior applies.
Check: Identify whether the fault is shared across points and whether host diagnostics or packet counts coincide with each bad sample.
Reduce the confirmed cause without masking the data
Use a temporary restore only after the checks point to the communications path. If network loading is confirmed, reduce avoidable traffic or separate competing traffic using the site's approved network procedure. Change one condition at a time and keep a record so the night shift can reverse a change that has no measured effect.
- Capture the current host trend, DirectSoft value, and NetEdit lost-packet count.
- Apply one approved network or host-polling adjustment tied to the observed cause. Do not alter PLC scaling or force values to suppress zeros.
- Repeat the same observation and compare the count and readings against the baseline.
Do not average, hold, or replace zero readings in the host as a permanent repair. Those techniques can conceal a missed read and make trend data appear normal while communications remain unreliable. Treat any temporary display-side handling as temporary only, document it, and remove it after the underlying fault is corrected.
Check: The change must reduce the measured fault indication and stop the correlated host dropouts without changing the actual controller value.
Verify a stable end-to-end trend before returning the system
After the corrective change, observe the same controller point in DirectSoft and the host over a representative production interval. Check every affected setpoint and analog value rather than assuming one recovered point proves the whole data path. Include the host trend and NetEdit packet-loss diagnostic in the verification record.
- Confirm the DirectSoft value remains consistent with the expected controller value.
- Confirm the host no longer alternates between that value and zero.
- Confirm whether NetEdit lost-packet counts continue to increase; investigate further if they do.
- Record any temporary workaround and assign its removal to the permanent repair.
Check: Return the data path to normal service only after controller readings, host values, and communications diagnostics agree through the observed interval.
FAQ: Resolve ECOM100 zero readings
What happens if DirectSoft shows a steady value but the host shows zero?
Investigate the ECOM100 communications path and host read handling. Check the lost-packet count in NetEdit while reproducing the host dropout.
What happens if DirectSoft also shows the value dropping to zero?
The zero is present at the controller observation point, so check the logic, input source, and controller-side data path before adjusting the network.
What happens if NetEdit reports lost packets?
Record the count and see whether it increases when the host trend drops to zero. A count alone is not proof; correlate it with the fault interval and controller reading.
What happens if only one host value alternates?
Compare that point's controller address and host diagnostics with other affected values. A single-point issue calls for checking that point's mapping and read handling, not assuming a shared network outage.
What happens if zeros continue after reducing network traffic?
Restore the documented baseline if the change did not help, then inspect host polling and driver diagnostics. Stop changing production communications settings and contact AutomationDirect official support when the ECOM100 diagnostics or host response cannot be interpreted safely.