Clearing ID-003 Fraud Error

[jq]

Hi All,
I've had a kiosk running for a month or so now with no problems, until the other day a note got jammed in the reader and it ceased working. When i had a look at the status being reported back the flags, ACCEPTOR_FRAUD, ACCEPTOR_DISABLED & ACCEPTOR_FAULT were all set. The Note reader was powered up and down and the software attempted to enable/disable it. The only way we could get the note reader back into service was to use the MilanDiag.exe tool and press the reset card button. My questions are:
1) Does anyone know a good way to reproduce a fraud attempt with on the ID-003 Ardac 5 note reader?
and
2)What API call(s) are made when you press the Reset card button on in the MilanDiag.exe tool, as i couldn't see a reset board function or anything similar.

[davebush]

Hi,

1) I'm not sure what when wrong here. Having checked the code, the ACCEPTOR_FRAUD bit was for "future expansion" and is needier used by the existing system.

2)There is no standard way of resetting a Paylink as it is not supposed to ever need to be reset!

For future use, these problems are much easier with a log. You can either cut & paste the log from the AESWDriver window, or supply the path to a log file as a parameter to AESWDriver, or run MilanDiag (which has a report log button).

[jq]

OK thanks for that. I guess i could have been wrong and got a 0 or 1 in the wrong place.

Similar to what I described though, the note acceptor sometimes gets into a state where it always returns a busy status, despite resetting the power (but not actually sending the reset board cmd from the MilanDiag.exe) to the whole machine. I'm not 100% sure how it comes to be in this state, but i'm going to try and work out how this happens. Here is the driver output from start-up:

Code: Select all

08:57:30.62 Driver restart (after crash)
08:57:30.64 Opening Genoa USB unit... 
08:57:30.65 Device Open failed 1
08:57:30.65 Waiting for USB Port
08:57:30.65 USB:PC has updated basic area @ 0!!!
08:57:30.65 Device Closed
08:57:30.65 Driver Exit as Restarted
08:57:31.15 Opening Genoa USB unit... 
08:57:31.47 OK,       ID: 0x0403 0xde50
08:57:31.47  Description: Genoa USB Hub
08:57:31.47 Manufacturer: Aardvark (AE)
08:57:31.97 Memory Reset
08:57:32.16 : SCH2 Hopper S/N 200418, Address 6, Value 20 at 1034 setup
08:57:32.16 DP: SCH2 Hopper S/N 199823, Address 8, Value 5 at 1064 setup
08:57:32.16 DP: Interface memory set up
08:57:32.16 Exec: DP App. task took 176 msec
08:57:32.16 7960 bytes memory free
08:57:32.16 USB:PC has updated basic area @ 100!!!
08:57:32.17 Memory Resynchronise
08:57:32.36  Update @100, 24=>0
08:57:32.36  Update @104, 24=>0
08:57:32.36 USB unit re-synch complete
08:57:32.36  Value 5 at 1064 setup
08:57:32.36 DP: Interface memory set up
08:57:32.36 Exec: DP App. task took 184 msec
08:57:33.03       0 < 00
08:57:33.03       3 > 03
08:57:33.03      15 < 00
08:57:33.03      63 > 06
08:57:33.04 ccTalk: Timeout (90) for cc hopper @ 6
08:57:37.64 7720 bytes memory free

Here is a sample of what happens when I toggle the disable check box within the demo application. The status box changes between 2C and "Busy" when check and un check the disable box.

Code: Select all

09:04:11.59 Acc: ID-003 Note Enable
09:04:11.59 DP: ID-003 Note Status to 20
09:04:22.60 Acc: ID-003 Note Disable
09:04:22.60 DP: ID-003 Note Status to 24
09:04:23.69 Acc: ID-003 Note Enable
09:04:23.69 DP: ID-003 Note Status to 20
09:04:26.64 Acc: ID-003 Note Disable
09:04:26.64 DP: ID-003 Note Status to 24
09:04:27.53       0 < 00
09:04:27.53      63 > 03
09:04:27.53      12 < 00
09:04:27.53       3 > 03
09:04:27.54 ccTalk: Timeout (90) for cc hopper @ 3
09:04:28.11 Acc: ID-003 Note Enable
09:04:28.11 DP: ID-003 Note Status to 20

I'm looking for a way to get the acceptor out of this busy state.

[davebush]

Hi,

The ID-003 Acceptor gets the ACCEPTOR_BUSY set when the Acceptor reports an INITIALIZING, STACKING or ACCEPTING status, and cleared when the acceptor reports IDLING.

Have you checked the note cassette?

More generally, the messages you are seeing are from the control level firmware, the module that supports the acceptor output messages with a prefix ID-003:, I'm surprised that there are no such messages in your output.

Depending upon your exact set-up, it can help to get a clear record by disconnecting the acceptor comms, then reset the Paylink, wait for the diagnostics to go idle, and then re-connect the acceptor.

[jq]

The ID-003 stopped accepting notes what so ever yesterday, so it has been RMA'd (for the second time).

For future reference what command or API call is sent when I press the "Reset Card" (Reset the firmware on the Milan Interface) button on the MilanDiag.exe?

When I get the new note acceptor, i'll see if i can get it to display the same behaviour again and let you know.

I seem to be having pretty bad luck with these note acceptors at the moment.

Thanks

[davebush]

Hi,

The interaction between the Paylink and the PC is not designed to continue smoothly if the Paylink is reset, so there is no published interface to reset the Paylink.

The MilanDiag reset button utilises a diagnostics "side channel" to send a reset for use by programmers who will not be concerned about transient problems with the API interface.

[hvaldivia]

hi DaveBush,

I've been looking for documentation on the Reset Card in the Milan Diag application. Do you know if it is possible to run the Milan Diag app in hidden mode and send the Reset Card command using command line parameters? or do you know if there is an alternate method to reset the paylink board and all connected peripherals? or even better, do you know where I can find documentation about this "side channel" API?


Thank you.

[davebush]

Hi,

Resetting the Paylink unit is bad idea. The DLL data and the Paylink will become unsynchronized and require recovery, which is done automatically but is not guaranteed to be problem free.

The technique is as below:

Code: Select all

  // Send a "k" command as a "internal" null-terminated string
  // Use at your own risk.

static struct
    {
    long Code ;
    long Length ;
    char Data[128] ;
    } Block ;

  Block.Code =  0 ;
  Block.Data[0] = 'k'  ;
  Block.Data[1] = '\0' ;
  Block.Length  = 2    ;
  WriteInterfaceBlock (-1, (char*)&Block,  8 + Block.Length) ;

P.S. Sorry about the delay, we were on vacation.

[ideaztech]

2 of my coin hoppers started giving this Fraud Allert error that prevents the hopper from working. This is after 2 years of working properly. Do you know what causes this and how to fix?

I need this fixed fast. Please get back to me right away, even if you just have a quick response for now.

Thanks

[davebush]

Hi,

The Paylink log will show you which fraud bit has actually been returned, they are one of:
Opto fraud attempt, path blocked during idle = 0x0008,
Opto fraud attempt, short-circuit during idle = 0x0010,
Opto fraud attempt, short-circuit during payout = 0x0100,

I have absolutely no idea what these mean in terms of making hoppers work - I only process the values return by the hopper firmware.

I have no memory of anyone else reporting this as a Paylink problem, you'll have to talk to the hopper distributor / manufacturer.