Hi,
We are getting a high number of fraud's being reported from our MCL Serial Compact Hoppers and they are being shut down by the paylink board. We are confident that there is no genuine fraud being attempted, so would like to know if we can stop the paylink from shutting down the dispenser and how we do a software reset on the dispenser, as according to the ccTalk protocol for the dispenser a software reset will clear the fraud error (or does the paylink board do this and then disable the dispenser itself?).
Thanks,
Dispenser Fraud
Moderators: aardvark, davebush, Admin
Just a bit more information we've managed to gather about this problem.
It appears to only be effecting the £0.10 hopper.
The kind of fraud it is reporting is "Idle fraud blocked" (Raw event code: 03).
There was a coin in the stuck in the rear exit slot (the one which fires upwards @ 45 degrees) on the hopper.
So has anyone else experienced this before and if so how did you resolve it (i.e. any hardware changes or implementation changes)? We're pretty confident now that it is a mechanical problem to do with firing 10p coins against gravity, and i don't think there is anything else that can be done from a software point of view.
It appears to only be effecting the £0.10 hopper.
The kind of fraud it is reporting is "Idle fraud blocked" (Raw event code: 03).
There was a coin in the stuck in the rear exit slot (the one which fires upwards @ 45 degrees) on the hopper.
So has anyone else experienced this before and if so how did you resolve it (i.e. any hardware changes or implementation changes)? We're pretty confident now that it is a mechanical problem to do with firing 10p coins against gravity, and i don't think there is anything else that can be done from a software point of view.
An update on this:
It appears the cause of this is the dispenser is dispensing coins too fast. So fast that the coin before the current one has not quite cleared out of the way, so that the coins collide and the following coin then doesn't have enough energy to leave the exit chute and thus drops back down to rest there, creating a fraud error.
We have tried this with a modification on the bowl exit chute to try and clear the coins out of the way before the next one fires out, this did help reduce the occurrence rate but not eliminate the problem.
Is there a way through software to slow down the speed at which the dispenser fires coins out?
It appears the cause of this is the dispenser is dispensing coins too fast. So fast that the coin before the current one has not quite cleared out of the way, so that the coins collide and the following coin then doesn't have enough energy to leave the exit chute and thus drops back down to rest there, creating a fraud error.
We have tried this with a modification on the bowl exit chute to try and clear the coins out of the way before the next one fires out, this did help reduce the occurrence rate but not eliminate the problem.
Is there a way through software to slow down the speed at which the dispenser fires coins out?
There's no simple way to configure Paylink to slow down the rate - the rate is determined by the speed that the dispenser disc rotates.
You *could* just do Payouts or single coins, but this may end up being to slow.
You *could* just do Payouts or single coins, but this may end up being to slow.
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
We've tried the multiple request to payout a single coin and it is painfully slow.
One thing I've looked at is using a ccTalk command to set the Coin Payout Mode to single coin (1-2 coins per sec). I assume by default it must be on the multiple coin payout mode, which is considerably faster(8-10 coins per sec).
We don't really want to use all the encryption features offered by putting the dispenser into single coin payout mode, but this would slow the rate down.
Is it possible through the WriteInterfaceBlock and ReadInterfaceBlock functions to talk ccTalk to the the dispensers?
Is there another/better way to get low level access to the dispensers?
Finally if we can use the WriteInterfaceBlock function, what is the definition of the long interface (first parameter) of this function, i.e. how do I work that out or specify the ccTalk bus there?
Any examples of the usage of these functions would be great.
One thing I've looked at is using a ccTalk command to set the Coin Payout Mode to single coin (1-2 coins per sec). I assume by default it must be on the multiple coin payout mode, which is considerably faster(8-10 coins per sec).
We don't really want to use all the encryption features offered by putting the dispenser into single coin payout mode, but this would slow the rate down.
Is it possible through the WriteInterfaceBlock and ReadInterfaceBlock functions to talk ccTalk to the the dispensers?
Is there another/better way to get low level access to the dispensers?
Finally if we can use the WriteInterfaceBlock function, what is the definition of the long interface (first parameter) of this function, i.e. how do I work that out or specify the ccTalk bus there?
Any examples of the usage of these functions would be great.
The cctalk command "set single coin mode" means that the hopper will then reject any request to pay more than one coin. At that point you still need to issue a payout request for a single coin at a time!
The parameter to WriteInterfaceBlock is:
GET_INTERFACE(DP_CCTALK_INTERFACE)
Values in AESIMHEI.H (You can be forgiven for not finidng that !!!)
The parameter to WriteInterfaceBlock is:
GET_INTERFACE(DP_CCTALK_INTERFACE)
Values in AESIMHEI.H (You can be forgiven for not finidng that !!!)
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.