JCM Recycler Autmoatically Returning Ticket From Escrow

[paulp]

But why should disabling a ccTalk coin acceptor cause an ID003 dispenser to become disabled?
I do not see a "ID-003: Disable" as a result of this.
If that was the reason for disabling the dispenser, then why wasn't my ticket returned?

I am now logging all enable/disabling of acceptors and dispensers in my application. I am trying to determine what causes the "ID-003: Disable" to be logged by the Paylink. It seems a call to Payout() can cause this sequence
11:14:10.673 PC: Update Interlock Set. (1800 != 1799 / 1799)
11:14:10.674 PC: Interlock Now Clear. (After 1 tries.)
11:14:10.695 DP: Pay request for 1000, (89140940 - 89139940 (1588629203 - 1499488263))
11:14:10.695 ID-003: Disable
11:14:10.695 DP: ID-003 Status to 4
11:14:10.727 ID-003: Disable acceptance
11:14:11.209 DP: Pay 1000 (1 @ 1000) from 0200-44-09 03AUG18 @ 2
11:14:11.209 ID-003: Pay 1 (0) from 2
11:14:11.209 DP: ID-003 Status to 24
11:14:11.209 ID-003: ACK payout
11:14:14.277 ID-003: Note Waiting
11:14:14.277 DP: 1000 paid so far.


I guess initiating a payout before we have accepted the ticket in escrow could cause it the get disabled and therefore return the ticket? Am currently investigating how this could possibly occur

[davebush]

Hi,

My point was that you disabled an acceptor in both traces.

The 2nd trace shows you (correctly) disabling the Coin Acceptor and not the Note Acceptor, but the 1st trace shows you disabling the Note Acceptor, but not the Coin Acceptor.

I read this as your code accidentally disabled the wrong acceptor.

Dave

[paulp]

The 2nd trace actually shows what happens when I put a breakpoint in my code and the Paylink watchdog kicks in. Both the note and coin acceptors are automatically disabled, as is documented to occur. I included this trace as it was the only way I can reproduce the ticket being automatically returned.

The 1st trace is the actual customer log of the issue which does not show the coin acceptor being disabled, only the ID-003, which could be as a result of my application disabling it (which I have not been able to prove as occuring), or could be due to a Paylink watchdog timeout (no log entry indicates this was the case). Or it could be for a 3rd reason I am yet to identify.

Now that you have pointed out the coin acceptor disabling, looking at my code I do expect this as a result of processing a ticket. However the customer's log does not indicate this. Perhaps I'll check if they have a coin acceptor fitted.

Thanks for your ongoing input into this. I will carry on, but look forward being able to try the firmware variant you offered that would indicate why a dispenser is being disabled.

Moving forward, if I may suggest a change to the standard Paylink library in a future version... Currently I have to manually attempt to correlate the information from 2 different logs (my app and Paylink's). It would be useful if the library allowed my application to inject an entry into the log that Paylink is creating.

[davebush]

This version https://d.pr/f/Mjvp3V should output a log message which will explain why whenever an acceptor is disabled.

[paulp]

Thanks Dave. Even before trying this, I think I may have found the culprit.....

The application method to disable the coin mech
a) Is not checking if we have a coin mech fitted
b) Is passing an acceptor address of 0 expecting it to be the coin acceptor. When a coin acceptor is present it will be. When it isn't, the note acceptor is at address 0 instead.

Therefore if I do not have a coin acceptor fitted (according to my app's config), it disables the the note acceptor instead of the coin acceptor it should be ignoring. Pretty much as you concluded Dave.

Is there anything an AcceptorBlock that would help me identify if an acceptor is coins or notes? I guess I could use the acceptor's Description by comparing against a hard-code description, but this isn't ideal

[davebush]

Great.

In Aesimhei.h

Code: Select all

#define IS_COIN_ACCEPTOR(code) ...

if (IS_COIN_ACCEPTOR(AceptorBlock.Unit))

Regards

Dave

[paulp]

Thanks Dave. We can consider this issue closed now.

paul

[davebush]

Good.

Please start a new thread if you get anything else.