Problem with meter

robsch · Post by **robsch** » Tue Nov 10, 2009 3:14 pm

Hi Dave,

I'm using the SEC meter in conjunction with the PayLink with a Linux system. I have detected two problems:

1. If I call CounterIncrement with a value > 32767 the driver stops working. Any further calls do not work correctly, since the SEC meter does not get incremented any more. If I call CounterRead I get the incremented value, but this is not the value that at the SEC counter. I have to stop and then start again AESWDriver to the cached value of PayLink to the one of the meter.

2. Because of this I thought I could imcrement partially. A value of 32770 would then result in a double call of CounterIncrement. First value would be 32767, next would be 3. However, and this is the second problem, the call is a non-blocking one. If I make those calls without any waiting the counter hangs again.

I can live with the first problem. But only, if the second one is solved somehow. How could I find out that the incrementation is completed? Or could I make CounterIncrement blocking anyhow (return when the function has done its job)?

Another question: The only device that is connected to PayLink is the SEC meter. Which essential calls should be done to start and stop the system properly? EnableInterface? USBDriverExit? And are there any further recommendations when dealing with the meter (e.g. timing issue or so)?

The output of the driver:

Code: Select all

15:08:00.810 PC: Driver start up         
15:08:11.832 Unit 0 OK, ID: 0x0403 0xde50
15:08:11.832          Type: Revision 4 (USB Powered)
15:08:11.832   Description: Genoa USB Hub           
15:08:11.832  Manufacturer: Aardvark (AE)           
15:08:11.832     Serial No: AE000001                
15:08:11.832       Latency: 16                      
15:08:11.873 PC: Memory Reset - new protocol        
15:08:11.892 USB: PC Link Up                        
15:08:12.148 DP: Interface memory set up            
15:08:12.148                                        
15:08:12.148 PC: *** USB unit major memory reset ***
15:08:12.148                                        
10 November 2009     Firmware: 4.1.10.12 from May 14 2009 at 12:27:14     Driver:1.1.2.5                          
15:08:12.148 Exec: DP App. task took 258 msec

Regards,
Robert

davebush · Post by **davebush** » Tue Nov 10, 2009 4:26 pm

You're correct - there was a 16 bit increment variable in the meter driver.

That's now been corrected to a long - you can download a pre-release of the next firmware from here:
ftp://aesoffice.eu.com/FTPSpace/GenoaID ... -10-13.zip

robsch · Post by **robsch** » Tue Nov 10, 2009 5:03 pm

Thank you for the reply.

Do you know if the call is still not blocked? How can I increment a value of 100.000?

Could you please also reply to 'another question'?

Thank you Dave.

Regards
Robert

robsch · Post by **robsch** » Wed Nov 11, 2009 8:26 am

Is it possible to determine if the IncrementCounter call is completed?

And is there another way to access the meter? On a lower level maybe?

Regards,
Robert

davebush · Post by **davebush** » Wed Nov 11, 2009 11:34 am

You can now issue an increment up to 4,000,000,000 - although it will take a while to complete and the meter will reach it's maximum value!

There's no way to check the call - basically as soon as you issue the increment Paylink will continue to try to complete the increment to meter until it is powered off.

If the system is power cycled before the increment is complete, the value actually reached will be read by Paylink.

If what you want is a USB interface to an SEC meter, then drop me an e-mail (daveb@aardvark.eu.com) and we can discuss special purpose software.

robsch · Post by **robsch** » Thu Nov 12, 2009 9:07 am

Thank you for the information and the link to the firmware update. With the firmware update it works much better.

However, I'de like to know the following things:

- Is it safe to call CounterIncrement for a single counter repeatedly, although the counter has not reached the target value?

- What happens if I increment different counters in quick succession? Could this be a problem or is this also safe?

- What happens if the counter incrementation happens and I call CounterDisplay repeatedly? I've got the impression that those calls are queued somehow, so that after incrementation the commands are processed not till then. Is this true? If so I could imagine that this could make troubles if those calls would overflow the queue. So can I do or should I avoid any calls during incrementation (though I cannot determine when the incrementation is completed)?

- Generally: is the counter reliable whatever I do? Or should I keep any things in mind when working with counter?

- Is the driver and PayLink thread-safe? Or is it only allowed to have a single application with synchronized calls?

- Still the question: What should I call to cleanly initialize and stop the driver and the PayLink module? Could you provide an example? Should I query the state of the counter, the PayLink or the driver from time to time or can I expect that there will be no problems as long as no power cycle has taken place (consider that we assume that this won't happen)?

Thanks in advance.

Regards,
Robert

davebush · Post by **davebush** » Thu Nov 12, 2009 10:17 am

- Is it safe to call CounterIncrement for a single counter repeatedly, although the counter has not reached the target value?

Yes. The increment calls set a target value (in the Paylink unit itself) and the Paylink continues to issue incrments to the meter until the mter reaches the target.

- What happens if I increment different counters in quick succession? Could this be a problem or is this also safe?

Similarly safe. It makes no difference how a target value is reached - whether with many calls or only a few.

- What happens if the counter incrementation happens and I call CounterDisplay repeatedly? I've got the impression that those calls are queued somehow, so that after incrementation the commands are processed not till then. Is this true? If so I could imagine that this could make troubles if those calls would overflow the queue. So can I do or should I avoid any calls during incrementation (though I cannot determine when the incrementation is completed)?

There is no queuing anywhere in the Paylink system design.

- Generally: is the counter reliable whatever I do? Or should I keep any things in mind when working with counter?

Generally, you can issue any command whenever you wish.

- Is the driver and PayLink thread-safe? Or is it only allowed to have a single application with synchronized calls?

The only part of the Paylink system that is not thread safe is the CounterIncrement call. This contains a line of the form Target = Target + Increment and so could potentially lose an update if called by two threads simultaneously.

- Still the question: What should I call to cleanly initialize and stop the driver and the PayLink module? Could you provide an example? Should I query the state of the counter, the PayLink or the driver from time to time or can I expect that there will be no problems as long as no power cycle has taken place (consider that we assume that this won't happen)?

It the OpenIMHEI call succeeds, then you have a working Paylink system at that point. Calls to USBDriverStatus will confirm that the system is still working (e.g. the USB cable hasn't fallen out etc.)

robsch · Post by **robsch** » Wed Nov 25, 2009 7:56 am

Hi Dave,

I have two further issues:

1)

ftp://aesoffice.eu.com/FTPSpace/GenoaID ... -10-13.zip

Is this also as a Linux version available? If so how is started? Is it also an executable or is a special tool required?

2)

And when will be there a final, stable version? How will I come to know about a new version?

Thanks,
Robert

davebush · Post by **davebush** » Wed Nov 25, 2009 11:26 am

The executable is a firmware loader packaged with an issue of the firmware. Running the program updates any attached Paylink - which can then be connected to a Linux system.

At some point in the (near) future, we'll release 1-10-13 as a full release - at that point a Linux firmware loader will be packaged with the new firmware.

When this happens, the download page on the main website at http://www.aardvark.eu.com/products/milan/support.htm will update.