Hi and thank you for your answers you gave me today Dave.
I would have some other questions, if you can help me.
First of all, the Fujitsu F56 dispenser connected to the paylink is trying to give the money too fast.On a PayOut() command there are many rejects, each 2 or 3 note is rejected, no matter what denomination i have, so the process of getting to the desired sum is slow.(and sometimes it misses one or two notes, after the STATUS_PAYED issued).
Should i mention that with the dispenser`s DEMO program, connected via RS232 on a pc, if i issue 20 bills, the command is sent at once without any problem,i also noticed that the pace is slower than when i give the command from paylink, at least from what i heard.
Thank you.Best regards, Filip.
F56 counting too fast/too many rejects.
Moderators: aardvark, davebush, Admin
Re: F56 counting too fast/too many rejects.
I do not recognize the problem you are discussing with the F56. Paylink issues a "Pay <n> bills" command, and the unit should do it.
For any problem with Paylink, you should always get a log and attach that. In that way I can analyze how the Paylink is trying to drive the unit. Please set up the configuration file to generate a log of the problem and attach that in a reply.
For any problem with Paylink, you should always get a log and attach that. In that way I can analyze how the Paylink is trying to drive the unit. Please set up the configuration file to generate a log of the problem and attach that in a reply.
Re: F56 counting too fast/too many rejects.
About the F56 problem,it seems that it has an issue with our notes (plastic notes). I ran the program with test bills (paper) and i didnt had problems. So i guess i have to contact the F56 manufacturer.
Thank you.
Thank you.
Re: F56 counting too fast/too many rejects.
Hi again. It seems that the F56 i had was not suitable for my country currency. So, after we sent that back, i receied an F53 instead, and i continued my project. Now here is where my biggest trouble is.
The dispenser ,after a payout it may OR not dispense the correct amount of cash.Here is a part of the log:
Notice please that line - DP: Cycle End - no retry as unit failed in payout - 0 coins @ 50 status: -3.
Another issue that i have, no matter how many notes do i have to dispense, if, let`s say i issue a payment with MORE than nine bills, the dispenser ALWAYS gives me 9 bills, then it pauses for 3-5 seconds, then continues.Sometimes it just stops, without giving me the full requested amount.But even if the PayOut goes well, its just the same...nine bills..then pause..then nine bills..and so on.
The F53 it seems to support a total of 20 bills payment at once, and, if i ran their test app and issued a 20 bills command, it never paused at nine bills, instead it continued untill it reached 20 bills.
I use -- Firmware: 1.1.12.7 from Feb 14 2014 at 14:17:06 Driver:4.1.12.6--
Thank you.
The dispenser ,after a payout it may OR not dispense the correct amount of cash.Here is a part of the log:
Code: Select all
09:29:45.503 DP: Payvalue increased by 120, (5075 - 4955 (-1403294078 - -1403299153))
09:29:45.503 DP: Pay request for 120, (5075 - 4955 (-1403294078 - -1403299153))
09:29:45.503 ccNote: Disable
09:29:45.503 DP: ccNote Status to 4
09:29:45.503 Exec: DP App. task took 11 msec
09:29:45.503 ccNote: Disable acceptance
09:29:46.010 DP: 080911AA0600~F53 @ 2 is off line
09:29:46.010 DP: Pay 120 (9 @ 10) from 080911AA0600~F53 @ 1
09:29:46.010 DP: 30 left unqueued
09:29:46.473 F56: Issue Pay, Cass 1 pay 9, sent
09:29:55.045 F56: Counted, Cass 1 paid 9 of 9, Done
09:29:55.071 DP: 90 paid so far.
09:29:55.071 DP: Cycle End - no retry as unit failed in payout - 0 coins @ 50 status: -3
09:29:55.089 9 coins @ 10 status: 1
09:29:55.115 DP: Overall status: -3
09:29:55.115 ccNote: Enable
09:29:55.115 DP: ccNote Status to 0
09:29:55.115 Exec: DP App. task took 46 msec
09:29:55.115 ccNote: Enable acceptance
09:29:55.147 ccNote: inhibits to ff ff ff ff ff ff ff ff
09:29:55.194 DP: *** DLL has "noticed" pay result!!
09:29:58.018 F56: 0 < e0
09:29:58.018 F56: 123 > 12
09:29:58.018 F56: 797 < e0
09:29:58.018 F56: 7 > 01
09:29:58.018 F56: Tx Failure (2054)
09:30:00.049 F56: 0 < e0
09:30:00.049 F56: 123 > 12
09:30:00.068 F56: 797 < e0
09:30:00.068 F56: 7 > 01
09:30:00.068 F56: Tx Failure (2054)
09:30:00.522 F56: Cass 1, [0a] F56: Cassette 1 level normalAnother issue that i have, no matter how many notes do i have to dispense, if, let`s say i issue a payment with MORE than nine bills, the dispenser ALWAYS gives me 9 bills, then it pauses for 3-5 seconds, then continues.Sometimes it just stops, without giving me the full requested amount.But even if the PayOut goes well, its just the same...nine bills..then pause..then nine bills..and so on.
The F53 it seems to support a total of 20 bills payment at once, and, if i ran their test app and issued a 20 bills command, it never paused at nine bills, instead it continued untill it reached 20 bills.
I use -- Firmware: 1.1.12.7 from Feb 14 2014 at 14:17:06 Driver:4.1.12.6--
Thank you.
Re: F56 counting too fast/too many rejects.
Firstly, the payout in groups of 9 notes is a deliberate measure whereby Paylink is able to report the progress of large payouts as each batch completes.
Unfortunately in this case it reveals a rather esoteric bug in Paylink, which needs fixing.
The problem is that Paylink has two dispensers that it can use for the payout of 120, one with 50 notes, one with 10 notes. It considers the 50, but that is broken, so it resorts to the 10 and considers paying 12 notes. As described above, at this point it decides to pay 9 notes.
When this completes, it should return to pay another 3, but as the 50 value dispenser is faulty, it erroneously decides that payout cannot be completed.
Unfortunately in this case it reveals a rather esoteric bug in Paylink, which needs fixing.
The problem is that Paylink has two dispensers that it can use for the payout of 120, one with 50 notes, one with 10 notes. It considers the 50, but that is broken, so it resorts to the 10 and considers paying 12 notes. As described above, at this point it decides to pay 9 notes.
When this completes, it should return to pay another 3, but as the 50 value dispenser is faulty, it erroneously decides that payout cannot be completed.
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
Re: F56 counting too fast/too many rejects.
We could produce a version of Paylink that paid out larger batches, but this would only halve the number batches as the F53 imposes a 20 bill limit. - one problem is that Fujitsu have never provided a test unit, so we cannot test the update.
The firmware problem is Paylink, a new Paylink firmware release would fix that.
The firmware problem is Paylink, a new Paylink firmware release would fix that.
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
Re: F56 counting too fast/too many rejects.
A version with larger batches would be great, i dont know if that can be done without a testing unit. all i can do is test it against my F53, and see if that works. Even the 20 bill limit is good, that means that the speed of the payout would be more than double.
I want to ask, when tpaylink is issueing a PayOut, it has something to do with the sensors of the dispenser, like, it asks to perform an operation with certain speed, or certain sensors involved? I still dont understand why Paylink is not working properly with our banknotes. I just tested the F53 unit giving direct commands via Rs232, and it is working flawlessly with our bills.
I want to ask, when tpaylink is issueing a PayOut, it has something to do with the sensors of the dispenser, like, it asks to perform an operation with certain speed, or certain sensors involved? I still dont understand why Paylink is not working properly with our banknotes. I just tested the F53 unit giving direct commands via Rs232, and it is working flawlessly with our bills.
Re: F56 counting too fast/too many rejects.
I am very concerned and puzzled about the fact that Paylink does not work "reliably". Paylink just uses the standard "Count" (Pay out) command, and I can see no reason why it should behave differently from the DEMO program.
Paylink specifies to stop the payout after any rejects - is the DEMO program rejecting notes, but continuing or not rejecting any either?
Have you specified Bill sizes to Paylink? - Paylink should default to the most tolerant settings.
Paylink specifies to stop the payout after any rejects - is the DEMO program rejecting notes, but continuing or not rejecting any either?
Have you specified Bill sizes to Paylink? - Paylink should default to the most tolerant settings.
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
Re: F56 counting too fast/too many rejects.
Not really, it is rarely that when i issue a bill deliver command, a reject occurs, but even if it did, it continues until it`s finished.Paylink specifies to stop the payout after any rejects - is the DEMO program rejecting notes, but continuing or not rejecting any either?
As i said, i also made a little test program and i`m sending commands via serial port.Basically its just "Give me 10 bills from 2-nd cassette", and it is working like the demo program, without problems.
I dont know, i tried setting in "Standard.cfg like this also- "Cassette 9 Value 50 Max 151 Min 131 Thickness 11 ", it is the same setting that i gave in their program, but it doesnt seem to change anythingHave you specified Bill sizes to Paylink? - Paylink should default to the most tolerant settings.
And about rejects, rarely a reject occurs via Paylink, just because the first bill that comes out usually gets stuck as soon as it leaves the cassette, doesnt even goes to reject tray, and after that, the whole dispenser system gets jammed.
This is a major issue, because, in order to make the system work i have to manually reset the unit. So you can imagine that in this condition the F53 with paylink its pretty much useless.
I would say maybe it has something to do with the dispenser, but this is already the second unit that i tried.
If you think that i can make some kind of adjustment regarding country Code maybe in the standard cfg, as in their program i have to specify the country for my bills at "01" which is for mexican pesos and australian bills (this is the only country code that works with my currency). Pretty much if i "MECHA RESET" the unit with any other country code like 00, or 11, the bill payment is just as bad as it is with paylink (blocking the note), so maybe is something to consider.
Thank you for your help.
Re: F56 counting too fast/too many rejects.
The problem mentioned in the previous posts on this subject is specifically related to countries using the Polymer (plastic) banknotes. At this time, this includes: Australia, Bermuda, Brunei, Canada, New Zealand, Papua New Guinea, Romania and Vietnam.
The Fujitsu F53 and F56 have a bit that must be set to 1 to indicate that Polymer banknotes are being used. You might call this the country code. The Fujitsu documentation calls this the setting for Australia and New Zealand, but the Fujitsu support department told me to use that setting for any country that is using Polymer banknotes.
In my case, I am trying to use Canadian banknotes. Our configuration works perfectly with the old banknotes, but as soon as it tries to pick up the new Polymer banknotes, the F53 stops and Paylink reports the error: "Hopper Jammed". We have tried all the different settings for width, length, and thickness, but that is not the issue and it doesn't make any difference. Fujitsu support told me the Australia bit setting changes how the sensors work so that it will work with Polymer banknotes.
They gave me this information for the programmers reference:
Notice that it is part of the same command that tells the F53/F56 whether to use the front or rear shutter. The first two bits (b0 and b1) are for the front and rear shutter action. In that same command, b6 needs to be set to 1 for "Australia and New Zealand dollar Specification". According to Fujitsu support, Australia was the first country they set up for Polymer bills, but any other country using Polymer should also use this setting.
I am using Paylink firmware version 4.1.12.6 which is the last version available on the aardvark downloads site at this time. In this version there is a configuration setting for "Delivery at Rear" or "Delivery at Front" which appear to relate to those first two bits. But there is no configuration for country or polymer banknotes that I can find. Maybe it is undocumented.
Please respond to this as soon as you can. Many Canadian and Australian customers are using this system and we need to be able to pass that setting to the F53/F56 to indicate the Polymer banknotes.
The Fujitsu F53 and F56 have a bit that must be set to 1 to indicate that Polymer banknotes are being used. You might call this the country code. The Fujitsu documentation calls this the setting for Australia and New Zealand, but the Fujitsu support department told me to use that setting for any country that is using Polymer banknotes.
In my case, I am trying to use Canadian banknotes. Our configuration works perfectly with the old banknotes, but as soon as it tries to pick up the new Polymer banknotes, the F53 stops and Paylink reports the error: "Hopper Jammed". We have tried all the different settings for width, length, and thickness, but that is not the issue and it doesn't make any difference. Fujitsu support told me the Australia bit setting changes how the sensors work so that it will work with Polymer banknotes.
They gave me this information for the programmers reference:
Notice that it is part of the same command that tells the F53/F56 whether to use the front or rear shutter. The first two bits (b0 and b1) are for the front and rear shutter action. In that same command, b6 needs to be set to 1 for "Australia and New Zealand dollar Specification". According to Fujitsu support, Australia was the first country they set up for Polymer bills, but any other country using Polymer should also use this setting.
I am using Paylink firmware version 4.1.12.6 which is the last version available on the aardvark downloads site at this time. In this version there is a configuration setting for "Delivery at Rear" or "Delivery at Front" which appear to relate to those first two bits. But there is no configuration for country or polymer banknotes that I can find. Maybe it is undocumented.
Please respond to this as soon as you can. Many Canadian and Australian customers are using this system and we need to be able to pass that setting to the F53/F56 to indicate the Polymer banknotes.
Re: F56 counting too fast/too many rejects.
Thank you for that information.
The next release of Paylink will include a configuration option that allows this to be specified to the standard Paylink build.
in the mean time, this: http://aesoffice.eu.com/HTTPSpace/Payli ... olymer.zip special version of Paylink will always set the polymer note bit during initialization.
Dave
The next release of Paylink will include a configuration option that allows this to be specified to the standard Paylink build.
in the mean time, this: http://aesoffice.eu.com/HTTPSpace/Payli ... olymer.zip special version of Paylink will always set the polymer note bit during initialization.
Dave
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
Re: F56 counting too fast/too many rejects.
Thanks Dave,
This last update worked excellent. The Fujitsu F53 and F56 work perfect now with the Canadian Polymer bills. In fact, we still have many old non-polymer bills mixed in and it works great with both types of bills. I think this configuration is best for all countries with all types of bills. Even if a country doesn't use polymer bills at this time, the machine will be ready for the future.
Kevin
This last update worked excellent. The Fujitsu F53 and F56 work perfect now with the Canadian Polymer bills. In fact, we still have many old non-polymer bills mixed in and it works great with both types of bills. I think this configuration is best for all countries with all types of bills. Even if a country doesn't use polymer bills at this time, the machine will be ready for the future.
Kevin