The event log writes the first 11 entries, then misses the 12th because the counter’s current value is BCD while the pointer operation expects binary; converting the counter value with BIN corrected this installation.
Check the counter value before changing the pointer
The program uses a counter to select the event-log position. The counter’s current value is identified as V1000, and the code loads an address with LDA o1000 into V1505 before using P1505 with the indexed writes. The important distinction is that the counter’s displayed or stored count can be BCD while pointer arithmetic expects a binary offset. A value that looks like decimal 12 in BCD is not the same bit pattern as binary 12.
Do not begin by changing the base address or adding a compensating offset. First inspect the raw current-value word at the point where the log entry is written, and determine whether the counter value is BCD or binary. Check the actual words used by the pointer path as well: V1000, the intermediate value after conversion, and V1505. Preserve the existing program before editing so the original address setup and data formatting remain recoverable.
Check: Identify whether the value supplied as the index is BCD or binary and verify that the pointer still uses the intended base address.
Separate BCD indexing from an address-range problem
| Observed behavior | Likely issue to test | Diagnostic |
|---|---|---|
| Entries appear in expected locations, then later entries shift or land unexpectedly. | A BCD count is being interpreted as a binary pointer offset. | Compare the raw counter word with the value after BIN; test the resulting offset before allowing a write. |
Entries appear to fail at counts 8 or 9 when the program constructs addresses such as V2008 or V2009. |
The assumed address form may not identify valid memory locations in the controller’s address scheme. | Inspect the actual computed destination and confirm the documented address range and indexing syntax for the installed controller. |
| Values are stored, but the date, time, or error-code words are wrong. | The fault may be in source-word formatting rather than the pointer offset. | Verify the three data words before the indexed writes: V1600, V1601, and V1602. |
The address-range concern raised for V2008/V2009 is a separate diagnostic path. It matters if the program is actually constructing or addressing those locations directly. It does not explain a BCD-versus-binary mismatch in a pointer offset, and the successful correction here was converting the counter value with BIN. Confirm the controller’s address convention rather than assuming that a decimal-looking suffix is a valid address.
Check: Decide whether the failure is caused by a malformed index, an invalid destination address, or bad source data; do not treat those as the same fault.
Convert the counter value before using it as an offset
For the existing counter-based design, preserve the counter and convert its current-value word to binary before that value feeds the pointer operation. The legacy correction was to move the counter value to an intermediate location and apply BIN, then use the converted value for indexing. Keep the raw BCD value separate from the converted offset so the conversion does not overwrite a value the counter or display logic still needs.
- Identify the counter’s current-value word, reported here as
V1000. - Copy that value to a spare intermediate word appropriate for the installed program.
- Apply
BINto the copied value, following the controller’s instruction syntax and operand rules. - Route the converted result to the value used by the pointer/indexing logic; retain the existing base address and data-write instructions unless testing shows a separate addressing fault.
- Check the converted value at representative count changes, including the count that previously failed, before enabling production writes.
Do not infer the required intermediate address from the example. Select an unused location in the project and confirm its address and data type in the controller documentation or project cross-reference. If the conversion instruction errors, produces an unexpected value, or the controller’s instruction semantics are unclear, stop before permitting writes into the log area.
Check: At each test count, the intermediate value must represent the intended numeric offset in binary, and the base address must remain unchanged.
Retain the three-word record and validate it before writing
The code prepares three words for each record and writes them to separate indexed areas: V1600 is written with base V2000, V1601 with V3000, and V1602 with V4000. The earlier logic combines and shifts source values to format date, time, and error-code information. A bad index can send otherwise correct data to the wrong location; a bad formatting rung can put incorrect data into the right location. Test these paths independently.
Before an event write, inspect the three prepared words and compare them with the intended source values from the date/time and error-code inputs. Then inspect the destination words at the selected index. Avoid using an assumed display interpretation as proof: check the raw word values and the controller’s representation rules. Keep the event trigger logic and the pointer correction distinct during troubleshooting so one-shot or count changes do not obscure whether the conversion fixed the destination.
Check: Confirm the three source words are correct before the write and that all three destination areas receive the record at the same intended index.
Choose between a converted counter and a binary increment
There are two approaches in the legacy correction: convert the counter’s current value with BIN, or replace the counter scheme with a one-shot event trigger and INCB. The conversion approach is the smallest change when the existing counter and associated logic are needed. The one-shot plus binary increment approach can simplify the index representation, but it changes how the event count is generated and must be integrated with the event trigger and record-write sequence.
Use a one-shot so a sustained event condition creates one log action rather than incrementing the index repeatedly on every PLC scan. Verify that the one-shot is rearmed only as intended for the next event. With the incrementing approach, confirm the index increments exactly once per captured event and that the data words are written using the same updated index. If the existing counter is also used elsewhere, replacing it may affect more than the table and requires a project-wide reference check.
Check: Select one indexing method, document whether the index is BCD or binary at every handoff, and verify one event produces one index change and one complete record.
Prove the repaired log through the former failure point
Test with writes directed to a controlled or cleared log area, not live records that must be retained. Exercise successive event captures through the index that previously failed and inspect both the index value and the destination words. Include counts around the observed boundary and any values where the BCD and binary representations differ; do not rely only on the first few successful entries.
- Record the raw counter value, converted offset, and pointer-selected destinations for each test event.
- Confirm the offset advances as intended and each event writes exactly one record.
- Verify the record’s three words in their respective destination areas and confirm no write lands outside the reserved event-log range.
- Repeat with the actual event trigger sequence and confirm the index does not advance when no event is captured.
Before returning the log to service, check the project’s intended table capacity and what should happen when the log fills. The source does not specify a wraparound, stop, or overwrite policy, so determine that behavior from the program requirements and controller implementation rather than assuming the pointer can safely continue indefinitely.
Check: The repaired program must capture the formerly missing entry at the intended location, preserve all three data words, and stay within the configured table range.
Stop before writes can corrupt the log
If the converted value does not track the intended count, if the computed destination is outside the reserved table, or if BIN operand behavior is uncertain for the controller, inhibit event-log writes and review the controller documentation and project cross-references. Do not compensate with an arbitrary offset: that can conceal a representation error and move later records into unrelated memory.
Check: Keep production logging disabled until the index value, destination range, and complete three-word record have passed the controlled test.
Frequently asked questions
What happens if a BCD counter value feeds a binary pointer offset?
The pointer interprets the BCD bit pattern as a binary number, so the selected location can diverge from the intended count. Convert a copy of the counter value with BIN before using it as the offset.
What happens if the log fails at count 8 or 9?
Check whether the program is directly addressing locations such as V2008 or V2009; those address forms may not be valid in the installed memory scheme. Also check the pointer value separately, because an invalid direct address and a BCD index are different faults.
What happens if I change the counter to a one-shot and INCB?
The index can be maintained as a binary increment instead of converting a BCD counter value. Verify that the one-shot captures exactly one event, the increment occurs once, and the write uses the intended updated index.
What happens if the index is correct but the logged date or error code is wrong?
Inspect the prepared words V1600, V1601, and V1602 before the indexed writes. If those values are already wrong, troubleshoot the formatting and source values rather than changing the pointer.
When should I stop and contact official support?
Stop writes if the pointer selects an out-of-range destination, conversion results are unclear, or testing risks overwriting retained records. Contact the controller manufacturer’s official support channel with the exact controller model, instruction documentation, raw counter value, converted value, and observed destination addresses.