Aardvark Embedded Solutions Ltd Support Forum

For other interested readers, Dave kindly implemented his fix in 4.1.12.15 and provided a pre-release of this Paylink firmware, which did resolve the problem for me

Hi Dave, That's good to know that you have identified the causs and that the fix would be easy. Unfortunately now we have added reporting of realtime information based on data we are receiving via the GBG MDC protocol, this is causing an excessive amount of false information. Do you have any ideas o...

I can't see a way to attach files to posts, so I have emailed you a log file

FYI, we are polling using ReadDispenserDetails() to determine the dispenser status which I am seeing toggling

I have come back to this today and the same fault (iPro stacker removed) and now I find it is toggling between "Non-Functional" and "Dispenser Count Updated" (pay status 111)

I am using Paylink 4.1.12.14 with a JCM iPro-RC. This device has a stacker and 2 x recycling channels RC1 and RC2. When I pull out the stacker, I get reports that both RC1 and RC2 are non-functional. But then the next poll via ReadDispenserDetails() tells us they are both empty. Each poll seems to c...

Hmmm, probably not now

It has been reported to me that our application made a poor choice of payout denominations.... when only £10 notes and £1 coins had stock available, a £50 payout paid in 1 x £10 and 40 x £1 In fact, I have determined that it is the Paylink that decides the denominations rather than our application s...

Thanks Dave. We can consider this issue closed now.

paul

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. Wh...

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...

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 ...

No signs of a disable when it doesn't return the ticket 10:44:28.539 ID-003: Note in entrance 10:44:28.539 DP: ID-003 Status to 20 10:44:30.703 ID-003: barcode 012242608925463914 in escrow 10:44:31.244 ccCoin: Disable 10:44:31.244 DP: ccCoin Status to 4 10:44:31.244 ccCoin: Inhibit all coins 10:44:3...

Hi Dave, Thanks for the special version with that extra watchdog info. Since using it I have not been able to capture an instance of the watchdog timing out. I wonder if it not a watchdog issue after all. This is backed up by the being no mention of a watchdog timeout in the original Paylink.log I p...

I've looked into this and it seems we call this on a 500ms timer and use a timeout of 1000ms. There does not appear to be anything to disable this timer, nor inhibit it from executing. I have proven that even when I insert a long delay within our TITO validation, the CheckOperation() method is still...

That's good to find out, now it gives me something to go on. Exactly the type of call I was looking for.
Thanks Dave