Status 12 - Paylink Acceptor NV9

[ABates]

Hello,

Is there a way of retrieving the status of a notereader via Paylink after an event has fired?

I have this scenario
- Take payment on the note reader, and it jams
- I get error event back and handle appropriately
- The error is fixed on the note reader, however I never seem to get an OK event back

The acceptor status reads as 12, this occurs if the note reader stays jammed, or if the jam is cleared. The status stays the same in both instances.

Is there a way, if the status is 12 - of finding out what true state is or what the last event was?

Using C# to do this.

Thank You.

[davebush]

Hi,

It's difficult to tell what's wrong without more details. The default installation generates a log file "Paylink.log" in the driver folder. Can you post the contents of that log from before the problem to after you've fixed it and read in another note.

Thanks

Dave

[ABates]

Hello,

This is the paylink log, for this I did the following

- Started Paylink
- Put a note in successfully
- Created a Jam, demo program showed fault
- Closed demo program
- Re-opened demo program
- Demo program showed status OK even though Jam was still present
- Fixed Jam, note was accepted

My query is, if the demo program shows as status OK and no fault on re-load, is there a way I pickup the fault?

If I run this in my code, or the C# Full demo app, I do get the fault back initially, but not afterwards and never seem to get a status 'OK' back either upon fixing the fault.

Driver Thread Started

11:32:48.200 PC: Driver start up
11:32:48.301 USB: Unit 0, ID: 0x0403 0xde50
11:32:48.301 Description: Genoa USB Hub
11:32:48.301 Serial No: AE000001
11:32:48.320 Type: Revision 4 (USB Powered)
11:32:48.320 Latency: 16
11:32:48.385 Config: Start of download
11:32:48.401 Config: Checked, OK
11:32:48.401 Config: Paylink Checked OK against file "Standard.cfg"
11:32:48.416 PC: Memory Reset - new protocol
11:32:48.604 DP: ccNote acceptor 12020209 at ba0 and 3 coins setup
11:32:48.960 DPPC: USB unit reset complete
02 May 2023 Firmware: 4.1.12.9-526 from Aug 20 2018 at 16:35:42 Driver:4.1.12.14
11:32:48.960 : Interface memory set up
11:32:48.960 Exec: DP task took 528 msec
11:32:53.701
11:32:53.701 Ver 004.001.012.009-526 Aug 20 2018 16:35:42
11:32:53.701 DP: Application active
11:32:53.701 Int: 3f 8c 00 03 46 18 bf fa 37 ab 44 a4 40 50 e4 e8 d8 66 54 e6 05 43 5c 6e c3 f5 f0 28 00 3a e7 fd
11:32:53.701 DP: Interface memory recoveryDP: Update Local PayValue 191474=>191474
11:32:53.701
11:32:53.701 DP: Resending Events
11:32:53.701 DP: Application Watchdog recovered
11:32:53.701 DP: Event 0003
11:32:53.701 DP: Turn off barcodes
11:32:54.048 DP: Event 000122 for Acceptor 0
11:32:54.095 DP: Event 000123 for Acceptor 0
11:32:54.204 DP: Event 000103 for Acceptor 0
11:32:54.266 PC: Update Interlock Set. (13 != 12 / 12)
11:32:54.281 PC: Interlock Now Clear. (After 1 tries.)
11:32:54.313 DP: Event ff0120 for Acceptor 0
11:32:54.430 DP: Event 0001
11:32:54.560 DP: Event 0002
11:32:54.665 DP: Event ff0120 for Acceptor 0
11:32:55.440 00:13
11:33:08.650 ccNote: Enable
11:33:08.650 DP: ccNote Status to 0
11:33:08.650 ccNote: Enable acceptance
11:33:08.670 ccNote: inhibits to ff ff
11:33:17.790 ccNote: New event 2, Old 1, note 3 in escrow
11:33:17.790 ccNote: Stack Escrow Note
11:33:21.825 ccNote: New event 3, Old 2, note 3 stacked
11:33:47.150 ccNote: Selftest OK
11:33:47.150 DP: Event fe0120 for Acceptor 0
11:33:47.390 ccNote: Enable acceptance
11:33:47.426 ccNote: inhibits to ff ff
11:33:55.200 00:14
11:34:14.621 ccNote: New event 4, Old 3, event 6=>4
11:34:14.621 DP: ccNote Status to 40
11:34:14.621 DP: Event 060104 for Acceptor 0
11:34:14.621 ccNote: Selftest reports OK following problem
11:34:23.456
11:34:23.456 DP: System closedown received
11:34:23.456 DP: No more updates
11:34:23.456
11:34:23.456 DP: Application has gone away
11:34:23.456 ccNote: Disable
11:34:23.456 DP: ccNote Status to 44
11:34:23.456
11:34:23.456 ccNote: Disable acceptance
11:34:23.503 ccNote: New event 5, Old 4, event 0=>3
11:34:23.503 DP: ccNote Status to 4
11:34:24.546
11:34:24.546 Ver 004.001.012.009-526 Aug 20 2018 16:35:42
11:34:24.546 DP: Application active
11:34:24.546 Int: 3f 8c 00 03 46 18 bf fa 37 ab 44 a4 40 50 e4 e8 d8 66 54 e6 05 43 5c 6e c3 f5 f0 28 00 3a e7 fd
11:34:24.546 DP: Interface memory recoveryDP: Update Local PayValue 191474=>191474
11:34:24.546
11:34:24.546 ccNote: Enable
11:34:24.546 DP: ccNote Status to 0
11:34:24.546 ccNote: Enable acceptance
11:34:24.546 DP: Resending Events
11:34:24.546 DP: Application Watchdog triggered
11:34:24.546 ccNote: Disable
11:34:24.546 DP: ccNote Status to 4
11:34:24.546 DP: Event 0003
11:34:24.546 DP: Turn off barcodes
11:34:24.590 ccNote: Disable acceptance
11:34:24.610 8704 bytes memory free
11:34:24.630 ccNote: New event 6, Old 5, event 0=>3
11:34:24.931 DP: Event 000103 for Acceptor 0
11:34:25.057 DP: Event 0002
11:34:25.182 DP: Event 000103 for Acceptor 0
11:34:25.290 DP: Event 000103 for Acceptor 0
11:34:25.370 DP: Application Watchdog recovered
11:34:25.370 ccNote: Enable
11:34:25.370 DP: ccNote Status to 0
11:34:25.370 ccNote: Enable acceptance
11:34:25.410 ccNote: inhibits to ff ff
11:34:48.065 ccNote: New event 7, Old 6, event 3=>2
11:34:48.065 DP: Event 030102 for Acceptor 0
11:34:54.979 00:15
11:34:56.591 ccNote: New event 8, Old 7, note 2 in escrow
11:34:56.591 ccNote: Stack Escrow Note
11:35:00.620 ccNote: New event 9, Old 8, note 2 stacked
11:35:54.740 00:16

[davebush]

Hi,

So you have asked 2 separate questions.

1/ Can I find out when the acceptor is fixed?

When the note originally jams, as you saw you get the event IMHEI_NOTE_NOTE_MISREAD (Event 060104 for Acceptor 0)

With some acceptors you can then issue a self test command to see if the probelm has cleared. Infortunately the Innovative devices such as the NV9 immediately reply OK (hence the message "Selftest reports OK following problem"). There is no information obtainable from the unit as to whether the jam has been cleared. Normally this isn't actually a problem, because it needs fixing by operator intervention.

2/ Why was the acceptor not marked as faulty on program restart

This is a different mainfestation of the same problem. The acceptor is marked faulty when it reports the jam, but as soon as it reports anything elase this bit is cleared. Unfortunately the act of closing the program inhibits the ascceptor, which the reports the inhibit and clear the fault!

I am afraid that if you want any peristence around a jam then you need to store it and clear yourself.

Regards

Dave