SAS Host controller DLL. What do you want to see?

[AndyP]

Close, but you need the .net framework 2. I chose version 2 because most people will already have it installed. I thought the installer asked you to install the correct framework if not already installed, but I could be wrong.

The initialise button opens the comm port and starts polling the gaming machine. It wont do anything if you dont hit initalise.

The installer asks for framework 4...so the number# 2 .net framework version doesn't get used because of this?
What would happen to my laptop if I delete and remove all the Net Framework versions from my computer installed after .Net #2?
You'd think .Net Framework 4 would be "backwards" compatible with this .DLL App?

The application definatly needs framework version 2. All versions can be installed and will work together side by side (thats the advantage of the .net framework), the application only uses the version it needs.

As for the installer asking for version 4, thats just a mistake on my part. It should be checking for version 2. I will fix that when I do a build next week.

Ok it looks like Andy will come through with our dll today and then stop work on it.  What is missing that we would still need to implement.

I'm on The Explorer of the Seas about to set sale for a 9 night cruise an can look at some of this stuff. It's food to get away for awhile.

Its Saturday here, so 2 days off work! I will finish up what I have done next week and build a new installer. Probably Monday, maybe Wednesday. I have to do some software upgrades in a few casino's this week, so that might screw me around a bit.

The DLL should have most of what you need by then, and if we find another message needs to be added I will put it in. The bulk of the work is now done, and adding more functionality is pretty simple and wont take a lot of effort.

It would be good if we could a partial copy of a bit of your programming notes Andy,
so we can compare it these help tutorials for those that want to do a crash course on C# language?

It was interesting to me how you implemented and
utilized the SAS sheet into the Test App .DLL as a template of sorts.

All c# code I wrote is included in the installer. If you look at c:\program files\AP\SASEGMTest

There is one file, that has a wrapper for the dll. IT is called something like SASDllWrapper.cs (not in front of my dev pc at the moment) You will see all the DLL functions in that. Plus the delegates for the callbacks.

The way the DLL works is pretty straight forward. If the dll recieves a message, it calls a function in your c# app (callback). You have to tell the DLL what function it has to call by using the RegisterXxxxxCallback functions.

It all looks really complicated, but its not that hard once you get your head into it. Happy to assist if needed.

HEre is where you get a free copy of visual studio for c# http://www.microsoft.com/express/Downloads/#2010-Visual-CS

[knagl]

Pardon my ignorance, but with what has been created so far, can multiple machines be addressed if they're all networked together, or does this current setup require being physically attached (via communication wires) to the machine it wants to talk to?  In other words, could I tell the software to add 10 credits to machine A and then tell it to add 50 credits to machine B?

Thank you again, Andy, for your continued work on this.  It's a great project that a lot of us are interested in.

[Foster]

I am going to key chip mine and see what I get when I try to insert tickets (I know it wont accept them) right now it just says bill rejected when insert a ticket.

VFD reads "Voucher in Progress"
App prints "67 Ticket has been inserted"

I know the app can not validate the ticket yet.
And I am not sure sure if it should be set to SAS EFT or SAS AFT anyways.

[AndyP]

Pardon my ignorance, but with what has been created so far, can multiple machines be addressed if they're all networked together, or does this current setup require being physically attached (via communication wires) to the machine it wants to talk to?  In other words, could I tell the software to add 10 credits to machine A and then tell it to add 50 credits to machine B?

Thank you again, Andy, for your continued work on this.  It's a great project that a lot of us are interested in.

The DLL supports multiple machines, the test app doesn't. I might add the ability to poll 2 machines in the next version of the test app. I cant test it though, because I only have one SAS machine.

I have nearly implemented all the Montana spec. Half a day should have it dusted off.

I am going to key chip mine and see what I get when I try to insert tickets (I know it wont accept them) right now it just says bill rejected when insert a ticket.

VFD reads "Voucher in Progress"
App prints "67 Ticket has been inserted"

I know the app can not validate the ticket yet.
And I am not sure sure if it should be set to SAS EFT or SAS AFT anyways.

Thanks for that bit of info. I will look up exception 67 on Monday when I get back to the office and see what is says. Might be as easy as sending back a few simple messages to make it work.

[stayouttadabunker]

By Monday, you'll have ALL THE BUGS from your "Testers"....

Surely you can write a fix while lazying around on your yacht all weekend while I'm shoveling snow!??  

[Forrhouse]

Here are some more pics of fiber converters that I have. they are still not the ones I was looking for, but they have the same function.
E~

[Forrhouse]

Here is another IGT model.
E~

[Forrhouse]

Bally S6000 fiber converter. Front and side views.
E~

[Foster]

From my understanding how the tickets are printed
The machine creates a number and prints the value,  ticket number with a barcode it then prints the ticket and sends the information to ticket validation server
This may vary if every ticket payout ticket is validated with the server before it is printed

When a ticket is inserted the number is read by the BV and transmitted to the machine,
which then sends it to the ticket validation server,
The Validation looks up the ticket data in a database which at the minimum has the ticket value, a date and time stamp, machine or asset information which might even contain the exact location of the machine on the casino floor.
If the ticket is valid the server transmits value, maybe a validation code or other data to let the machine know it is a good ticket.

[StatFreak]

From my understanding how the tickets are printed
The machine creates a number and prints the value,  ticket number with a barcode it then prints the ticket and sends the information to ticket validation server
This may vary if every ticket payout ticket is validated with the server before it is printed

When a ticket is inserted the number is read by the BV and transmitted to the machine,
which then sends it to the ticket validation server,
The Validation looks up the ticket data in a database which at the minimum has the ticket value, a date and time stamp, machine or asset information which might even contain the exact location of the machine on the casino floor.
If the ticket is valid the server transmits value, maybe a validation code or other data to let the machine know it is a good ticket.

I don't know how they implimented it, but if I were to do it, I'd have the machine request a ticket ID and transmit all of its information, including the dollar amount to be cashed out, machine ID, etc.. The database would create a new record, store all of the data, and send the unique record ID back to the machine (though the server, of course) to be used as the ticket number (and bar code), and probably the date/time stamp info as well. The machine wouldn't print the ticket or clear the credits until it received confirmation from the server that the data record had been stored. There would be a fail timeout interval if the server did not respond, blah blah...

You wouldn't want the machines creating ticket numbers since you would want to ensure that they were unique.

When a ticket were inserted into a machine, all it would need to do would be to transmit the ticket number (bar code value) to the server, which would look up the record in the database. If the record were valid, the database would return the value to be added to the machine and void the record in the ticket table so that the ticket could not be used again. Casinos most likely record the redeeming device's ID info so that the tickets can be traced to the specific cash boxes when they count the cash and for accounting purposes. Failure code for invalid ticket number, voided ticket, etc. etc...

Put another way, the ticket wouldn't have any information on it (in the barcode) besides the record ID. The text indicating value, date, issuing machine ID, etc. would be an affectation for human use only. The value of the ticket, the date time stamp, and all other information would be stored in the database and sent to the redeeming machine upon request.

[Foster]

So far my machine has not created duplicate ticket number yet.
They are not sequential.
It looks like they are using a RNG to generate them
It could be hash of value, date/time, asset number, etc as well.
 
The first 10 digits are all 0 then the next 8 are machine generated ticket number for number with 18 digits
I do know that SG363 says if you have mixed validation, IGT SAS and Bally Miser tickets that start with 0 are SAS validated and those start with 1 are Bally Miser validated.

[StatFreak]

So far my machine has not created duplicate ticket number yet.
They are not sequential.
It looks like they are using a RNG to generate them
It could be hash of value, date/time, asset number, etc as well.
 
The first 10 digits are all 0 then the next 8 are machine generated ticket number for number with 18 digits
I do know that SG363 says if you have mixed validation, IGT SAS and Bally Miser tickets that start with 0 are SAS validated and those start with 1 are Bally Miser validated.

I'm not talking about one machine, Foster. Would you implement a casino with 10,000 machines or more and take a chance that no duplicate records would ever be created? Even though the odds may be very much against it, best practice would be to have a single source create unique ticket numbers and assign them. In addition, it would be problematic if the machines printed the tickets and cleared the credits without getting verification from the server that the record was properly created, so it wouldn't increase printing speed efficiency much either, because the machine would still have to wait for a response from the server.

I'm not saying that this is how it's done -- because I don't know, but it's the way I would do it.

P.S. Bunker, what are you doing up at this hour?

[AndyP]

Does not matter if the machine makes duplicate transactions, because the uniqueness comes from several things, time, machine serial and ticket number. In the database those fields would become a clustered primary key.

In my experience the more simple the method, the less prone it is to failure. Myself and my business partner designed a cashless system a few years back, and we went the simple route. Assume success and log everything so it can be tracked if there is a problem. This was based on our experience of designing more complex design we used for player tracking system

[TZtech]

Hello Andy

Is this system still available. Is there a website where I can check it out. Looking for a basic cashless system for the street market and small casino clients in Africa.

Ian

[AndyP]

Hello Andy

Is this system still available. Is there a website where I can check it out. Looking for a basic cashless system for the street market and small casino clients in Africa.

Ian

We did it for a client, so we dont actually own it. IT was integrated into their system. If you are interested though, I am always happy to talk! We have had some loose discussions late last year about doing a new system for the european market.

[AndyP]

Here are some more pics of fiber converters that I have. they are still not the ones I was looking for, but they have the same function.
E~

This second one in youl ist there is the one we use in Queensland Aus, New Zealand and Northern Territory Aus. The one numbered 75421603 is it. Its just an RS232 to FO converter.

[Neonkiss]

Myself and my business partner designed a cashless system a few years back, and we went the simple route. Assume success and log everything so it can be tracked if there is a problem. This was based on our experience of designing more complex design we used for player tracking system

One question,
If you use SAS to pull the info for the back-end system, did you have to have approval from IGT to market the system?
This is where we are stuck with a system now. We hate to ask for permission for fear of receiving a  Cease and Desist order from the big boys. Also looking into this thru the GSA

If you want please PM me how one might obtain approval of using a backend system thru SAS

[StatFreak]

Does not matter if the machine makes duplicate transactions, because the uniqueness comes from several things, time, machine serial and ticket number. In the database those fields would become a clustered primary key.
...

That makes sense.

...
In my experience the more simple the method, the less prone it is to failure. Myself and my business partner designed a cashless system a few years back, and we went the simple route. Assume success and log everything so it can be tracked if there is a problem. This was based on our experience of designing more complex design we used for player tracking system

With regards to assuming success, are you saying that the machines do not wait for an acknowledgement from the server before dumping the credits? That would seem to me to be irresponsible, and would also seem to go against the gaming manufacturers' history of taking extra backup and security measures whenever cash is involved. I have no gaming programming experience, but I do have both banking and online transaction programming experience.

Of course, we could dispense with most security measures for home use.

[stayouttadabunker]

...Of course, we could dispense with most security measures for home use.

I agree, I still like Munch's suggestion of just setting up the Test App
to allow the machine to "see" a ticket  at least -
(Foster has already tested that far) and to shoot off say...a 100 credits to the machine for now.
Work out the bar code, time, machine serial and ticket number bugs later.
Simplicity is best for home use, the tweaking of the Test App
to bring it up casino-level security measures - could be added later on?

There's a lot of things to learn when taking up the game of golf for instance.
One day, after I sliced several balls into the woods - and old man yelled "KISS!"
I turned around and looked at him and asked him what he was talking about?
He said: "Keep It Simple, Stupid!"    

I became a much better golfer and to this day still apply KISS to my golf swing mechanics.  

[TZtech]

Ok that will work but requires a ticket printer. It would be even easier to detect a status change on the change button (The app has these events already coded) and then do a promo credit download       

Change_lamp_on = 0x71,
Change_lamp_off = 0x72,

dont have acess to machines over weekends so maybe someone can confirm that these events are sent through when the change button is pressed.

[AndyP]

Myself and my business partner designed a cashless system a few years back, and we went the simple route. Assume success and log everything so it can be tracked if there is a problem. This was based on our experience of designing more complex design we used for player tracking system

One question,
If you use SAS to pull the info for the back-end system, did you have to have approval from IGT to market the system?
This is where we are stuck with a system now. We hate to ask for permission for fear of receiving a  Cease and Desist order from the big boys. Also looking into this thru the GSA

If you want please PM me how one might obtain approval of using a backend system thru SAS

IGT has nothing to do with it. The only thing you need from IGT is the protocol, and this requires you to sign a non-disclosure agreement.  Any other approvals are usually only from government regulators.

...
In my experience the more simple the method, the less prone it is to failure. Myself and my business partner designed a cashless system a few years back, and we went the simple route. Assume success and log everything so it can be tracked if there is a problem. This was based on our experience of designing more complex design we used for player tracking system

With regards to assuming success, are you saying that the machines do not wait for an acknowledgement from the server before dumping the credits? That would seem to me to be irresponsible, and would also seem to go against the gaming manufacturers' history of taking extra backup and security measures whenever cash is involved. I have no gaming programming experience, but I do have both banking and online transaction programming experience.

Of course, we could dispense with most security measures for home use.

SAS might be a little different, i have not looked at that part in any great detail just yet. The AFT stuff looked a little more transactional.

A lot of protocols however are a simple as that. The machine logs the details of the ticket, then the machine sends off an event to the host monitoring system. All the systems I have ever worked on use reliable messaging, which means the event is never lost. In the off chance of a power failure or something that does end up in a lost transaction, you can always look in the audit menu in the machine. In circumstances like this it does not matter how complex your transactional model is, you can still loose data. The onlyy problem with a complicated system is the transcation tends to become a nighmare to complete in the event of a such failure.

[Forrhouse]

Here are some more pics of fiber converters that I have. they are still not the ones I was looking for, but they have the same function.
E~

This second one in youl ist there is the one we use in Queensland Aus, New Zealand and Northern Territory Aus. The one numbered 75421603 is it. Its just an RS232 to FO converter.

Hi Andy.  Thanks for the info on the converters. How is the converter PN: 75421603  implimented. They are only used with the GameKing/iGame or Multistar I think yours are called and the S2000s right?  I know the AVPs have an rs232 daughter card, a fiber optic daughter card, a progressive daughter card and an optional rs485 card. I may be forgetting about one.

Anybody have schematics for this board, PN: 75421603?
Also, where does the power connect? I see the Molex Mini Fit Sr  white 1x2 connector on the card which is for power, but where does the other end connect to? What kind of connector is on the other end of this power cable?

Thanks,
Eric

[reho33]

This whole concept was discussed a long time ago by me and at time we really had no solution but here is the thread: http://newlifegames.net/nlg/index.php?topic=4255.msg35924#msg35924

[TZtech]

Hi Eric

Those are from the S+/PE+ era. S2000/Igame platform have fibre interfaces on the comms board.

Ian

[TZtech]

Part 2