New Life Games Tech Forums

Homebrew Player Tracking and EFT Systems. => NLG Homebrew Player Tracking and EFT Systems. => Topic started by: AndyP on March 10, 2011, 12:11:26 AM



Title: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 12:11:26 AM
I have uploaded a debug version of the DLL here: http://users.tpg.com.au/adslcmdn/SASEGMTest/debugddl/SASEGM.dll

To use it, rename the existing DLL to something like SASEGM.dll.old and copy the new one into the same directory. The only reason you need to keep the correct version dll is because the windows installer tracks the version or hashcode and will not uninstall the test app fully if it finds different file versions.


OK, there is a few minor changes I have made that will help those having the "01 :" Problem somewhat. I am aware of a few issues still and I will get to them soon.

What was going wrong? Well for a start SAS is by far the worst protocol I have ever used. Its not really suited to multidrop applications, and making it work is a hack. The reason the IGT program works is it takes everything that is read into the serial port and puts it up on the viewing pane, so it cant really multidrop. What I do is poll and VGM and then wait for a response. I read the serial port asynchronously (otherwise the app would hang all the time) then put the responses in a buffer. When the app starts, depending on computer and serial bus speeds I would sometimes get a chirp from and EGM that would be added to the buffer. When I send a poll for meters or whatever, the oldest response is removed from the buffer. OF course I would always be processing the previous response. :279-

So the difference is now, I check for parity error and throw away chirps. I will eventually feed this back to the test app rather than throwing it away. The problem is that there is no way in windows to detect if each byte has a parity error, another reason SAS is not suited to polling via the serial port.

I am still queuing up responses, but I will remove this feature (bug) soon.

I have also adjusted the serial port read timeouts a bit.

The bonus with the debug version of the dll is that you can all use a program called DBMON (might already be installed on your pc) to view the traces of the dll workings. For those who continue to have issues I can look at the trace to try and figure out what is going wrong.

Let me know how you go!



Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 12:22:17 AM
To use it, rename the existing DLL to something like SASEGM.dll.old and copy the new one into the same directory. Let me know how you go!



Did that and got this (screenshot below).

Or are you just supposed to click continue?
Clicking details says this:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.DllNotFoundException: Unable to load DLL 'SASEGM.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at SASEGMTest.SASEGMWrapper.SAS_Initialise(String commPort)
   at SASEGMTest.Form1.buttonInit_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3615 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
SASEGMTest
    Assembly Version: 1.0.0.1
    Win32 Version: 1.0.0.1
    CodeBase: file:///C:/Program%20Files/AP/SASEGMTest/SASEGMTest.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3614 (GDR.050727-3600)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
    CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.




Title: Re: Debug SAS DLL for testing
Post by: Tilt on March 10, 2011, 12:38:07 AM
I'm getting the same error as Poppo too.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 12:45:33 AM
And to add, clicking continue does not work. It doesn't do anything at all now. Previously it worked fine for me with either built in serial or USB serial.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 12:53:14 AM
I'm getting the same error as Poppo too.

Same music I'm afraid.... :8-  :179-
Click to enlarge screenshot>>>


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 01:18:18 AM
Must have buggered the upload. Let me work on it.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 01:20:08 AM
Must have buggered the upload. Let me work on it.


NO
rush! Take your time....


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 01:32:28 AM
Nope, seems to be ok here. The dll you download needs to be in the same directory as SASEGMTest.exe


Stayouttadabunker, i take it yours started up ok? Can you download DBMON.exe (should find it on google somewhere) and save some of the trace for me? dbmon is just a command line program, so you need to run it from a command prompt (make you screen buffer 9999 so we can get some decent data). If you cant find dbmon I will upload a copy soon.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 01:36:51 AM
Nope, seems to be ok here. The dll you download needs to be in the same directory as SASEGMTest.exe


It is


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 01:44:50 AM
Bizzare. Not sure about that one. I just downloaded it to my dev pc, then put it in the directory where my install was and it works fine. Maybe the debug version needs some other library to make it work. If boredom prevails dependency walker will show this.

I'll see what stayouttadabunker comes back with and take a look at the trace before I put another upload.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 01:46:25 AM
DBMon here if required: http://users.tpg.com.au/adslcmdn/SASEGMTest/debugdll/Dbmon.Exe


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 01:49:46 AM
If boredom prevails dependency walker will show this.


Didn't have these errors before.

<edit> And I don't have those missing files.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 01:56:39 AM
Yup, thought that may be the case. Not sure how many installed the VC10 runtime, but looks like that is the issue. There is obviously a few more libraries needed for debug builds. Previous version was release build. If your dll was previously working I would leave as is.

The main aim of the debug build was to track down issues.

VC++ 2010 redistributable is here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:01:03 AM
andy,
I downloaded the database monitor but the bloody thing completely blackens out
my entire screen with an old square mouse cursor that I can move around but I see nothing.
Is there a way to reduce the screen size of the dbmon.dll?

I cannot copy & paste the screen shot because I'm forced to use Cntrl,Alt & Del to shut it off.
When I do that, I lose the "print screen" save and cannot show you a screen shot.

I petty much get 928 CPL and a bunch of different commands ranging from "Init" to "Stop" ...lol


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 02:05:40 AM
andy,
I downloaded the database monitor but the bloody thing completely blackens out
my entire screen with an old square mouse cursor that I can move around but I see nothing.
Is there a way to reduce the screen size of the dbmon.dll?

lol. did you donwload the one I put up? I think IBM has a program called dbmon too, which is for as400 databased! We need the microsoft version, which is actually stands for debug monitor! To get it out of full screen mode hit alt + enter

Also, just start a command prompt (start->run->cmd) and then rund dbmon from that. You wont see any action until you start the test app and hit initialise. To increase the screen buffer click on the c:\ icon top left of the window and choose properties.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:07:15 AM
lol  thanks pardon my computer ineptness...lol


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 02:11:36 AM
Yup, thought that may be the case. Not sure how many installed the VC10 runtime, but looks like that is the issue.

VC++ 2010 redistributable is here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84

I already had the VC++ 2010 redistributable and still a no go, and don't have those missing files. Even did a repair and same results.



Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:18:44 AM
dbmon is black and blank.
It's like it's not running even though the Test App is "Initialized"...
Click to enlarge if needed.
I gotta go to bed soon...
see the little clock on the bottom right?
My E.S.T. time here...yawn  :294-
Foster's the late night bird...lol>>>


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 02:22:33 AM
wow, its so much easier when visual studio is installed!!! I'll do some reading and see what I can figure out regarding debug tracing. Its definatly time for me to create a virtual machine with no visual studio.


Title: Re: Debug SAS DLL for testing
Post by: Tilt on March 10, 2011, 02:24:19 AM
Same as poppo again here too.  I already had 2010 installed as well.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:25:17 AM
andy,
What do you mean by visual studio...?
A different program?


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 02:27:00 AM
Not sure if this is the issue, but a quick google turned up this about the missing wer.dll

 'trying to run the debug version of the executable (the VC redist doesn't include the debug version of the VC++ runtime)'


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:33:54 AM
I think the "executable" is being the Test App "start" button..or the "Initialize" button.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 02:38:03 AM
andy,
What do you mean by visual studio...?
A different program?

Yup. All the source code is written and compiled using a program called visual studio 2010. When you install it, it installs all the libraries and debug libraries.
Obviously none of the debug libraries are included in the vc redistributable, which now leads me to think you may not be running the latest dll!


I think I can force the installer to include debug libraries, I will have a go.


BTW. Normally when distributing a program, we have a bunch of testers that will install and test it for you, so all the problems get picked up before a release. This is not the case here, I am running solo!


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 02:42:25 AM
BTW. Normally when distributing a program, we have a bunch of testers that will install
and test it for you, so all the problems get picked up before a release.
This is not the case here, I am running solo!


That's where you're wrong dude!
We're with ya every step of the way!! lol  :138- :301- :273- :288- :303- :114-


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 02:46:28 AM
...., which now leads me to think you may not be running the latest dll!

Not sure if any paths are hard coded, but Bunker's screenshot shows it's not intalled in the default install folder. Notice the dll is in 'test app' folder.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 03:07:46 AM
Well according to microsoft you are not allowed to redistribute debug libraries... so I will put the dlls up on my site here http://users.tpg.com.au/adslcmdn/SASEGMTest/debugdll/msvcr100d.dll just in case I need to use them to debug some stuff on a customer site.

I am pretty sure that you can just put it in the same directory as the dll, if not is c:\windows\system32


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 03:13:42 AM
I am pretty sure that you can just put it in the same directory as the dll,

That works. Program now runs and talks to the machine (but old version already did for me). Could Bunker's issue be related to the dll folder noted above?


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 03:22:39 AM
I am pretty sure that you can just put it in the same directory as the dll,

That works. Program now runs and talks to the machine (but old version already did for me). Could Bunker's issue be related to the dll folder noted above?

most likely. New dll's need to go in the same folder as SASEGMTest.exe


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 03:26:24 AM
dbmon working too. Here is a small capture. What's up with line 4032 - 'Chirp from Poll Address: 0'.  Address 0?  Normal? I get those groups of chirps frequently, but only that one (for the short time I let it run) had address 0. All the other groups were all address 1.


4032:   Enter: CSerialPrinterPort::WriteCommBlock
4032:     Leave: ReadCommBlock
4032:     Bytes Read 0
4032:     Empty buffer!
4032:   Leave: CSerialPrinterPort::WriteCommBlock
4032:     Waiting on comm/shutdown events
4032:   Write General Poll
4032:   Enter: CSerialPrinterPort::WriteCommBlock
4032:   Leave: CSerialPrinterPort::WriteCommBlock
4032:     Comm signalled
4032:     Enter: ReadCommBlock
4032:       Parity Error
4032:       IO Pending
4032:     Leave: ReadCommBlock
4032:     Bytes Read 25
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 1
4032:     Chirp from Poll Address: 0
4032:     Waiting on comm/shutdown events
4032:     Comm signalled
4032:     Enter: ReadCommBlock
4032:       IO Pending
4032:   Retreive General Response
4032:   Enter: RetrieveResponse
4032:   Leave: RetrieveResponse
4032:   Write Sequence Poll
4032:   Enter: CSerialPrinterPort::WriteCommBlock
4032:   Leave: CSerialPrinterPort::WriteCommBlock
4032:   Write General Poll
4032:   Enter: CSerialPrinterPort::WriteCommBlock
4032:   Leave: CSerialPrinterPort::WriteCommBlock
4032:     Leave: ReadCommBlock
4032:     Bytes Read 1


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 03:36:48 AM
No, thats one of the problems with SAS and PC's, its not actually a chirp, its a no activity response from a general poll. The problem is, you can see that 25 bytes were in the buffer, and when you read them out there is no way to tell if the parity error is for one or all. If you could, all the chirps wouls show parity error (because the wakeup bit is set) and the response would show no parity error.

I will get the timing stuff sorted soon, and that should fix most of those little issues.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 03:42:39 AM
I am pretty sure that you can just put it in the same directory as the dll,

That works. Program now runs and talks to the machine (but old version already did for me). Could Bunker's issue be related to the dll folder noted above?

most likely. New dll's need to go in the same folder as SASEGMTest.exe

Okay,
I just stuck everything into the SASEGMTest.exe folder...
I'll go try it again.


ADD>>> No go Houston...Here's a screenshot...
Everything's in the same folder...>>>



Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:03:43 AM
ADD>>> No go Houston...Here's a screenshot...
Everything's in the same folder...>>>

Ok, are you sure that is the new dll? If it is you should have been getting the errors we were getting without the msvcr100d.dll. And I don't see that in there. If you go to details view of the folder, the dll file size should be about 279k vice 56k of the old one.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:08:50 AM
I think so...it was larger in size if I recall...279kb


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:11:37 AM
I think so...it was larger in size if I recall...279kb

Never mind, I see it's highlighted and the size is shown. But are you running the SASEGMTest.exe from that directory too? Or using a shortcut pointing to a different one?

Maybe the solution is  :276-

 :96-


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:14:05 AM
yup...same size as yours...lol
Below that is the "Properties" folder>>>


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:21:58 AM
I think so...it was larger in size if I recall...279kb

Never mind, I see it's highlighted and the size is shown. But are you running the SASEGMTest.exe from that directory too? Or using a shortcut pointing to a different one?

Maybe the solution is  :276-

 :96-

Nope, I run it from the "Start" button on the left>>>


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:26:24 AM
I don't know if you should have another copy in the properties directory???  And I put the msvcr100d.dll in the SAGEGMTest folder.

Try double clicking the SASEGMtest.exe right from within the folder.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:30:04 AM
Yeah...I did but this pops up instead>>



Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:32:03 AM
Yeah...I did but this pops up instead>>



That's good since that is what we were getting. Now move the msvcr100d.dll into the SAGEGMTest folder and try again (double clicking from within the folder).


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:39:14 AM
okay,
I re-arranged my folders to look exactly like yours.>>>


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:43:27 AM
okay,
I re-arranged my folders to look exactly like yours.>>>

Ok, now double click the program from within the folder and.....<drum roll>....


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:45:29 AM
<Smash!> drums busts...lol


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 04:46:08 AM
good night Poppo...
you tried...
I gotta  :294-
I just verified that the serial cable is good because the Sim still works fine...

 :172-


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 04:54:23 AM
Did you double click the SASEGMtest.exe or the msvcr100d.dll?  :103- Should be clicking the SASEGMtest.exe

Oh well, tomorrow is another day. Wait...it is tomorrow.  :88-


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 11:01:21 AM
Ok, after getting a good night's sleep :47- , the only other thing I noticed is that it looks like you are using all of the files from the original program and not the first updated one. AndyP will have to answer this, but maybe this dll will not work right with those other files. I am going by the file sizes and time/dates that your screenshot shows vs the ones on mine.

Once that is sorted out and if nothing else, the dbmon program should now work. The output of dbmon is pretty fast, so after you verify it is outputting something, you may want to close it and then run it like this for about 10 seconds:
dbmon >c:\dbmon.log
That will direct the output to the dbmon.log file which you can then attach for AndyP to look at. Note: you won't see any output on the screen when run tihis way, it's all going to the log file.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 11:50:05 AM
Ok, after getting a good night's sleep :47- , the only other thing I noticed is that it looks like you are using all of the files from the original program and not the first updated one. AndyP will have to answer this, but maybe this dll will not work right with those other files. I am going by the file sizes and time/dates that your screenshot shows vs the ones on mine.

Once that is sorted out and if nothing else, the dbmon program should now work. The output of dbmon is pretty fast, so after you verify it is outputting something, you may want to close it and then run it like this for about 10 seconds:
dbmon >c:\dbmon.log
That will direct the output to the dbmon.log file which you can then attach for AndyP to look at. Note: you won't see any output on the screen when run tihis way, it's all going to the log file.

Best way to work out version is by the build date and size. I am well overdue for sleep (midnight here) so will take a look in the morning.

Directing the dbmon output to file is the best way. All I need is the first couple off polls and maybe a request meters 10-15 then quit the app. The poll rate is pretty quick, so wont take long to make a huge file.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 01:18:52 PM
lol...Good day...
I've tried double clicking all kinds of ways to start the App.
I've even run it straight from the "run" commands and
still cannot get past the [01:] displayed.
After a fresh night's sleep, I'm ready to attack this again but
from a different computer....however with an S+ this time.
Last night it was my S2000.

I just sent an email to AndyP showing him screenshots of the working Sim from last nite.
There seems to be some problem with they way it's
downloading the TestApp during installation perhaps.
I'm going to try it again with this computer and run the DBMON and the other one.
I'm also going to re-arrange the file folders of the APP on this computer similar to yours.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 01:27:08 PM
I'm also going to re-arrange the file folders of the APP on this computer similar to yours.


The main problem I see after your last screen-shot is the wrong versions of the support files. Not sure if that matters or not, but since the second version was not just a DLL change like this update, I would assume it does.

Sometimes having multiple copies of different versions will cause problems if the wrong files are being loaded. That is sort of why you were not getting the error message like you 'should' have after updating the dll.

I agree that you should try it on a S+. The meters button won't work for some SP chips (it calls for meters that don't exist on older SPs), but you should get door open/close messages.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 10, 2011, 01:56:45 PM
I agree totally with you.
I'm making up another harness like the first one
I made for the S+ Interface board  (J2 to the serial PC port)
as I still have a not-burned-out working S+ interface board one here...lol


Title: Re: Debug SAS DLL for testing
Post by: Tilt on March 10, 2011, 02:00:55 PM
I have the new .dll installed and running on both of my laptops.  One with a USB -> serial cable, the other with a real serial port.  I'm still seeing the same type of timing problems on both of them with this version too.  Get some  :294- AndyP, and thanks for your continued efforts with this!


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 02:15:19 PM
..as I still have a not-burned-out working S+ interface board one here...lol

Hopefully the mailman will rectify that today.  :204-


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 06:38:14 PM
As I posted in the USB serial port adapter thread, this Edgeport 4 port unit works with the IGT SIM but not with this app. Here is a sample of the dmnon log.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 07:55:48 PM
As I posted in the USB serial port adapter thread, this Edgeport 4 port unit works with the IGT SIM but not with this app. Here is a sample of the dmnon log.

Thats interesting. Its writing out data, but getting a large delay befre any responses are received.. Seems the uart in the card is not sending an interrupt fast enough. Of course it wont affect the SAS app because it processes the data asyncrounously. I might have a try at using a USB to Serial adaptor and see if I can replicate it here.



Title: Re: Debug SAS DLL for testing
Post by: jay on March 10, 2011, 08:04:25 PM
I am wondering at this point if the varied results are related to the varying specs of our PCs
I still believe that there is a timing issue with the code, possibly buffering - real time device management is a royal pain so no disprect to Andy.
I am just suggesting this as perhaps being a diagnostic aid in knowing what needs to be tweaked.

I am wondering if we could report in on your processor speed / Ram and how well the app is working.
Perhaps older PCs are working better than newer ..... and and more / longer polling is required for the newer systems
Or if its perhaps the otherway around and newer PCs are working better.

Jay


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:22:08 PM
OK, for you smart guys out there. Here is the problem:

If I only want to poll a single machine, thats easy, because I know every repsonse I get is from that one machine. If I poll 2 machines, how do I know which machine the reponse is from?

What I do now, is poll the first machine, wait for a response, poll the second machine and wait for a response. Now the problem I am beginning to see is that sometimes the UART does not tell me its received any data for a while, so I give up waiting and go on and poll the next machine. Then all of a sudden I get all the responses in a block.. What is supposed to happen is that you set a timeout in the UART, so that if it has not received any data in a certain amount of time, it sets the interrupt so that the receive buffer can be read. It looks like the USB adaptors ignore this setting.



SAS has no way of detecting the start of a response packet, and no way of detecting the end of a response packet, so I cant sort through a buffer of data and look for messages. Furthermore, exception responses do not have the poll address in them, so I cant map them back to a particular machine in software.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:25:14 PM
I am wondering at this point if the varied results are related to the varying specs of our PCs
I still believe that there is a timing issue with the code, possibly buffering - real time device management is a royal pain so no disprect to Andy.
I am just suggesting this as perhaps being a diagnostic aid in knowing what needs to be tweaked.

I am wondering if we could report in on your processor speed / Ram and how well the app is working.
Perhaps older PCs are working better than newer ..... and and more / longer polling is required for the newer systems
Or if its perhaps the otherway around and newer PCs are working better.

Jay

You are correct, doing real time stuff in windows is hard. The faster the PC the better in this situation.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:36:43 PM
Well I just plugged in a belkin USB to serial adaptor and failed out of the box. The problems here are slighty different to others I have seen so far, but along the same lines.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 08:42:57 PM
As I posted in the USB serial port adapter thread, this Edgeport 4 port unit works with the IGT SIM but not with this app. Here is a sample of the dmnon log.

Thats interesting. Its writing out data, but getting a large delay befre any responses are received.. Seems the uart in the card is not sending an interrupt fast enough.

The Edgeport has a configuration utility with these options. Anything you think I should try? Also attached is the pdf explaining those settings about half way through.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:45:29 PM
Mabe check the low latency, and fast reads/writes and see what happens.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:49:45 PM
What is even more interesting now, is that my USB to Serial adaptor is sending data to the machine, and the machine has stopped chirping, but its not responding. Exactly like the gameking comms analyser showed. :103- :103-

Time to look at it on an oscilloscope I think. Maybe the parity bit is not getting set..


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 08:52:10 PM
Just tried the belkin adaptor with IGT's sas test and it does not work either.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 10, 2011, 08:56:45 PM
Mabe check the low latency, and fast reads/writes and see what happens.

Ok, I checked those and now I am getting responces (door open, door closed). Here is a new dbmon log with those settings. Maybe it will help.


Title: Re: Debug SAS DLL for testing
Post by: jay on March 10, 2011, 09:08:02 PM
Just throwing this out there..... are the SAS responses a fixed size ? ie consistant byte count.
Alternatively can you ask the machine to report its SAS number followed by another poll ?



Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 10, 2011, 09:11:52 PM
Just throwing this out there..... are the SAS responses a fixed size ? ie consistant byte count.
Alternatively can you ask the machine to report its SAS number followed by another poll ?



No, the responses are all different sizes. The problems stems from the fact the general response is a single byte response, so there is no way of determining which machine it has come from.


Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on March 10, 2011, 11:26:04 PM
IBM X41 -  worked with the old dll and new one

no problems or differences  seen between versions


so far two machines hooked up to a 4 port usb hub -   One I-Game 3904 and one Bluebird

I have to wire up two more machines   an 044 and reel touch.



Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on March 10, 2011, 11:26:40 PM
oh an Acer C110

didn't work at all - both - old and new


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 11, 2011, 02:02:49 AM
IBM X41 -  worked with the old dll and new one
no problems or differences  seen between versions
so far two machines hooked up to a 4 port usb hub -   
One I-Game 3904 and one Bluebird
I have to wire up two more machines   an 044 and reel touch.

Munch...the "hub"...what make and brand?
It's working on 2 machines to one PC at the moment?
Details please my friend!!!  :89- :71- :91-


Title: Re: Debug SAS DLL for testing
Post by: Foster on March 11, 2011, 02:19:18 AM
He is using a USB hub to allow him to connect more USB to Serial RS232 adapters cables.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 11, 2011, 02:22:16 AM
Like this?  :103- >>>


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 11, 2011, 03:37:56 AM
This is the 4 port USB unit I mentioned in the other thread. Only $29 shipped and it's all in one.

Bought some of these 25ft cables too.
http://cgi.ebay.com/25FT-RS232-Serial-Cable-DB9M-DB9F-M-F-male-female-/130468687074 (http://cgi.ebay.com/25FT-RS232-Serial-Cable-DB9M-DB9F-M-F-male-female-/130468687074)


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 11, 2011, 03:46:00 AM
I bought one for just about $30.
The others were like over $200.00....nuts


Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on March 11, 2011, 11:03:09 AM
I tried a $5 non powered USB hub and it didn't work with the serial adapters -  no communication at all.

I had this old Belkin F5u021 which is powered -  and it works!   

Three machines hooked up and working!!!!


Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on March 11, 2011, 11:04:05 AM
Like this?  :103- >>>

You come up with the best pictures


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 11, 2011, 12:50:10 PM
Like this?  :103- >>>

You come up with the best pictures


That photo was actually a snapshot of my brain reading this stuff...  :72-
Now I know why Einstein's hair was so screwed up!  :96-



Title: Re: Debug SAS DLL for testing
Post by: pshoey on March 11, 2011, 06:40:55 PM
Andy,

The Windows serial driver can be send an IOCTL that places a copy of the uart line status register when a parity error occurs. This allows you to place the serial port into SPACE parity mode and you will receive the LSR byte with every data byte and can check if a parity error occured and hence data with the wakeup bit set.

The IOCTL is: IOCTL_SERIAL_LSRMST_INSERT

Check MSDN docs for the details.

HTH

pshoey


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 11, 2011, 11:53:44 PM
Andy,

The Windows serial driver can be send an IOCTL that places a copy of the uart line status register when a parity error occurs. This allows you to place the serial port into SPACE parity mode and you will receive the LSR byte with every data byte and can check if a parity error occured and hence data with the wakeup bit set.

The IOCTL is: IOCTL_SERIAL_LSRMST_INSERT

Check MSDN docs for the details.

HTH

pshoey


Dude that is an awesome find. I had been starring at various IOCTL's over the last few days and was even considering writing my own serial port driver. I have a few things to do next week but I will have a play with that one toward the end of the week.

Its a shame the SAS protocol does not set the wakeup bit for responses.


Title: Re: Debug SAS DLL for testing
Post by: Forrhouse on March 16, 2011, 01:11:42 AM
That is an awesome find. I must get one!   Here is a re-post from the closed thread of a cheap USB to fiber interface.

I still would like to see fiber implemented. I think I have found a very low cost fiber solution. It is a USB to fiber board.
They give customizable drivers with it and it seems that you can build it yourself if you like rather than purchase one complete which is $85
If this will work for us and enough people are interested, maybe we could get a group buy going.
E~

Here is the link to the board:

http://www.controlanything.com/Relay/Device/USBFOI (http://www.controlanything.com/Relay/Device/USBFOI)




Title: Re: Debug SAS DLL for testing
Post by: poppo on March 16, 2011, 09:52:49 AM
There still would need to be some sort of fiber board in each machine (capable of daisy chaining). And unless someone finds a secret stash of factory boards, this will not really help much. I don't think converting to fiber at the PC end has ever really been the issue, but more of what to do at the slot machines.

I am also curious as to how many slots most people actually have. I know there are a few folks here with a lot, but if 95% of the people have 8 or less, I still think it would be simpler and cheaper to just have individual RS232 lines to each machine. Since we really only need 3 wires, it could be done with thin wire like telephone cable or even CAT5 (to multiple machines) . In the RS232 adapter thread, I posted a 4 port USB to RS232 box for $29. So 8 machines could be connected for about $75 total, even if adapters need to be made for machines without RS232 ports like the S+.

And as I also mentioned I think the software would actually be easier to write. Instead of polling machines on a single line and dealing with timing issues, etc., if each one is on a separate comm port at the PC end, you always know what data is coming from which machine. Each machine could actually be set up with the same SAS address (i.e. 1) which further simplifies the software end. Just poll the comm ports instead of the SAS addresses.

Just my $.02


Title: Re: Debug SAS DLL for testing
Post by: jay on March 16, 2011, 08:45:05 PM
I have two of the fiber boards.
I am sure the board does not differ much from the Rs232 version.
So I am sure a mod to either an existing Rs232 or one of the other interfaces would not be that difficult.

When we get to that stage I am certainly willing to donate one of my boards for discection.

For the sake of expidency having SAS1 connected to COM1,
                                              SAS2, connected to COM2 and so on

Does make a lot of sense - we can forget the timing issues for multiple polling etc.

Can we go beyond 8 or is that a Windows Limitation...... (I only have 4 slots but inquiring minds want to know).




Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 16, 2011, 09:10:29 PM
I have two of the fiber boards.
I am sure the board does not differ much from the Rs232 version.
So I am sure a mod to either an existing Rs232 or one of the other interfaces would not be that difficult.

When we get to that stage I am certainly willing to donate one of my boards for discection.

For the sake of expidency having SAS1 connected to COM1,
                                              SAS2, connected to COM2 and so on

Does make a lot of sense - we can forget the timing issues for multiple polling etc.

Can we go beyond 8 or is that a Windows Limitation...... (I only have 4 slots but inquiring minds want to know).




You can go beyond 8 ports.

However before you all get to excited, I will still be supporting multidrop in my software. The way I have it set up is so that it can compile it to either use serial port, or dedicated hardware. I am not yet convinced that it is impossible to do with a serial port, its just that my time of late has been consumed with real work. I was lucky there a few weeks back because I had about 2 weeks free with no paid work. FWIW, that SAS DLL has about 6000 lines of code so far!! Thats what you get for 2 weeks of my work!

Now I have a bunch of rs232 to fibre optic converters here that came from old IGT machines, and I have posted a schematic for a rs232 to fibre board. If someone wants to make these I am happy to provide schematics and PCB files. The Fibre optic interfaces that most people are posting up are not the type used for game comms. The type you need uses this fibre : http://www.i-fiberoptics.com/patchcords.php?id=1

Also, if by chance its not possible to get the serial port working the way I want, it would not be hard for me to get a really cheap micro controller to do the job, or alternatively I may even consider writing a serial driver for windows.



Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 16, 2011, 09:11:33 PM
Oh, and further more, I am still not convinced that the USB adaptors are the way to go. There is too much latency and a lot dont support parity. The better option would be to consider a PCI comms card.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 16, 2011, 09:15:11 PM
Can we go beyond 8 or is that a Windows Limitation...... (I only have 4 slots but inquiring minds want to know).

I've used 16 port units before, but they start getting more expensive. Digi makes the best ones and it's best to use a PCI card based one when going with that many ports.

I'm not sure how many of the 4 port USB ones like I got can be connected before you start having USB bandwidth issues. Not that there is that much traffic going across the lines. I'm sure 2 (for 8 ports) would be no problem.

And if using com separate com ports, each slot can still be set to SAS 1 to further simplify the software, since each machine would be identified by it's com port number and not the SAS address.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 16, 2011, 09:18:40 PM
Oh, and further more, I am still not convinced that the USB adaptors are the way to go. There is too much latency and a lot dont support parity. The better option would be to consider a PCI comms card.

Agreed on the PCI card. But the sim program is working fine with every USB adapter as far as I know. Again, the idea is that you only need to deal with one machine at any given time. Whatever is on that com port is coming from one machine.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 16, 2011, 09:40:52 PM
Oh, and further more, I am still not convinced that the USB adaptors are the way to go. There is too much latency and a lot dont support parity. The better option would be to consider a PCI comms card.

Agreed on the PCI card. But the sim program is working fine with every USB adapter as far as I know. Again, the idea is that you only need to deal with one machine at any given time. Whatever is on that com port is coming from one machine.

That last trace you sent me whilst significantly better than the first, was still showing latency issues. I guess not a problem for the home user, but you will get comms errors from time to time.


Title: Re: Debug SAS DLL for testing
Post by: Foster on March 16, 2011, 09:50:10 PM
The Sim can poll multiple addresses.
I just have to move the serial extension cable between the 2 machines.
IT only grabs the events for the SAS address that is active at the time.
S2000 is SAS address 1
S+ is SAS address 2
I have turned off game events for the S2000, I do not need to see each game start and end.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 16, 2011, 10:34:54 PM
The Sim can poll multiple addresses.
I just have to move the serial extension cable between the 2 machines.
IT only grabs the events for the SAS address that is active at the time.
S2000 is SAS address 1
S+ is SAS address 2

True. But if you are moving the cable back and forth, both machines 'could' be set to SAS 1 and the sim program (or any program) would not care. That is why I said it could simplify the program by only needing to poll one SAS address, but 'poll' the com ports instead. So for example, S+ on com 1, S2000 on com 2, etc. Then the program just looks at SAS 1 on each com port and does whatever it needs to with the data since it would know what machine is on each com port. Same end result as polling SAS addresses, only easier/cheaper to implement (IMO) unless the number of machines is really large.

Note that I'm not advocating changing the direction of this app, only that there may be an alternative way to accomplish the goal of networking machines.


Title: Re: Debug SAS DLL for testing
Post by: Foster on March 16, 2011, 10:59:11 PM
RS485 is just as cheap to do as well. and all you need is one port and one cable that is the data bus for all machines.

I need to see the various DCS or comm boards for the S+ to see if they used RS485 as well on it.


Title: Re: Debug SAS DLL for testing
Post by: poppo on March 16, 2011, 11:23:41 PM
RS485 is just as cheap to do as well. and all you need is one port and one cable that is the data bus for all machines.

It may well be. I really don't know much about RS485. I just figured RS232 would be simpler since it costs <$5 to make an  adapter if needed. There are multi conductor cables (like from a 25 pin RS232 cable) that could connect up to 12 machines (using a common ground), so it's not like one would need to run a ton of cabling. 


Title: Re: Debug SAS DLL for testing
Post by: Foster on March 16, 2011, 11:35:32 PM
The Max491 are about the same costs, if you do not worry about fault tolerant operation or the like (just the terminating resistor at each end.


Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 17, 2011, 02:29:08 AM
Foster,
Do you mean like these things?
What are the advantages of using the RS485 as opposed to what we're using now? >>>



Title: Re: Debug SAS DLL for testing
Post by: Foster on March 17, 2011, 02:46:31 AM
That one is for the computer.

The computer uses one RS485 (either USB to RS485 or PCI based RS485 port)
In fact I think those multiport adapters that you poppo are playing with support RS485 or some versions do.


Basically you wire it in a bus configuration. (parallel) and not in a star config.
The only critical part is that you put a 120 ohm resistor at each end.

it would look like this

PC        GM1       GM2 ... GMn
|_______|________|_____|

The PC and the last game machine would have a 120 ohm resistor installed.

IF Andy could have it print GMx as it send data to or from a machine (using the SAS Address for x) then we would know which machine was polled.
or even allow us to give a name to each SAS Address we use (SAS 1 could be called S2000 or Double Diamond or such)
I believe that is the 2 wire version which would work. also if the machine has only a RS232 (a RS232 to RS485 could be built easily enough)




Title: Re: Debug SAS DLL for testing
Post by: stayouttadabunker on March 17, 2011, 03:01:38 AM
I see...
I would also like the ability to change address names or alongside in the TestApp - instead of "SAS address 001, 002, etc"
Just like they way I change the names of the addresses of the machines in the CDS ProLink.
It was pretty cool to have 5  S+'s all talking to my PC at once!
The harness was pretty simple but was only able to convert the coin in & out and jackpot signals through the serial lines.

Much in the same way your your name and phone number is listed in the phone book -
the ProLink allowed me to type in machine names with poll addresses...


Title: Re: Debug SAS DLL for testing
Post by: AndyP on March 17, 2011, 07:51:59 AM
I see...
I would also like the ability to change address names or alongside in the TestApp - instead of "SAS address 001, 002, etc"
Just like they way I change the names of the addresses of the machines in the CDS ProLink.
It was pretty cool to have 5  S+'s all talking to my PC at once!
The harness was pretty simple but was only able to convert the coin in & out and jackpot signals through the serial lines.

Much in the same way your your name and phone number is listed in the phone book -
the ProLink allowed me to type in machine names with poll addresses...

The test app was never intended to be a functional program. The idea was to do a dll to abstract away the IGT propiatory stuff that could then be used in a real program. The test app was just to test the DLL, nothing more.


Title: Re: Debug SAS DLL for testing
Post by: Forrhouse on April 27, 2011, 06:50:05 PM
Just wondering what the status of this program is. Have anymore features been added as far as standard SAS stuff, new features and testing?
What about for Tito using rs485v and the ability to use fiber?   I'm hoping that this project has been dropped or given up on.

Andy, I know that your really busy.  Any news on your end.

Thanks,
Eric


Title: Re: Debug SAS DLL for testing
Post by: AndyP on April 27, 2011, 09:26:50 PM
On the backburner at the moment. Happy to work with someone else on it (c++) but dont have the time to chase it up right now.


Title: Re: Debug SAS DLL for testing
Post by: Forrhouse on April 28, 2011, 06:19:28 AM
I completely understand. I wish I new how to work with code, C+, C++, etc.
It's Nice to know that it's still a go down the road.
Thanks,
Eric


Title: Re: Debug SAS DLL for testing
Post by: InChile on October 29, 2011, 11:19:59 PM
Hi All

I'm new to the site but have read all the great stuff you have been doing with the SAS app. I managed to connect one of my machines to the app and receive some messages without any hassles. I have been looking for help with SAS for ages and your site is a great help.

Many thanks to you for sharing your knowledge! I attached a picture of the app with a comm logger in the background.  :244- :3- :131- :259-

Regards


Title: Re: Debug SAS DLL for testing
Post by: SLOTMAN on October 30, 2011, 02:55:40 PM
I hope my post isnt going to be misconstrued as hijacking but I really want to get in on the EFT and player tracking.  Andy, it seems like you have spear headed this project and after reading all the posts you have a commercial interest.

I would love to help in your pursuit and I feel i have some to offer.  If you look at my pic you will see a wide array of machines.  I would love to demo any software.  I have access to every type of communication peripheral like usb-rs232, rs232-rs485, fiber to 10/100, etc. etc. So you will not be receiving any questions from me like "what is bit parity" if you know what I mean.

Almost every one of my machines have some type of player tracking still installed including the card readers so I think I may be a big help to you and all I ask is that I get to use the software for my personal use and nothing else. 

At the minimum I would at least like to attempt to communicate with some machines for other users benefits.


Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on October 30, 2011, 03:22:48 PM
I think Andy is gone


Title: Re: Debug SAS DLL for testing
Post by: AndyP on October 30, 2011, 08:42:22 PM
Not gone, just dont have a SAS machine anymore and I am pretty busy at the moment.


Title: Re: Debug SAS DLL for testing
Post by: jdkmunch on October 30, 2011, 08:43:37 PM
Hey !   It's great hear from you ! 


Title: Re: Debug SAS DLL for testing
Post by: FORDSBS on October 30, 2011, 10:06:00 PM
Not gone, just dont have a SAS machine anymore and I am pretty busy at the moment.

Andy, thanks for all the help you gave us.
Ford


Title: Re: Debug SAS DLL for testing
Post by: AndyP on October 30, 2011, 10:14:55 PM
No worries. We are working on getting 3 casino's onto a new monitoring/jackpot system at the moment so everything I was working on has to be shelved for now. I have personally got about 4 projects running at the moment and one of our staff leave in 6 weeks leaving me with another half dozen projects until I can find a train someone else!


Title: Re: Debug SAS DLL for testing
Post by: TZtech on October 30, 2011, 10:55:11 PM
Hello Andy

Nice to hear from You again. Is there nothing available that emulates SAS comms coming from machine side? I have seen mention of a SAS toolkit. Unfortunately only available to GSA members. Any idea what this is?

Ian


Title: Re: Debug SAS DLL for testing
Post by: AndyP on October 30, 2011, 11:01:27 PM
Hello Andy

Nice to hear from You again. Is there nothing available that emulates SAS comms coming from machine side? I have seen mention of a SAS toolkit. Unfortunately only available to GSA members. Any idea what this is?

Ian

Only emulation from the server side. No game simulators. I got the toolkit, but its pretty much useless. I think its posted up here somewhere from memory, search for SASTest.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on November 23, 2011, 11:30:30 PM
Andy,

The Windows serial driver can be send an IOCTL that places a copy of the uart line status register when a parity error occurs. This allows you to place the serial port into SPACE parity mode and you will receive the LSR byte with every data byte and can check if a parity error occured and hence data with the wakeup bit set.

The IOCTL is: IOCTL_SERIAL_LSRMST_INSERT

Check MSDN docs for the details.

HTH

pshoey


Trying to get this working now, without much success :(


Title: Re: Debug SAS DLL for testing
Post by: Foster on November 24, 2011, 03:59:14 AM
Where are the C# programmers?
I need your help.


Title: Re: Debug SAS DLL for testing
Post by: Foster on November 27, 2011, 06:42:45 PM
I have figured out something
I do not know who is the blame, Microsoft, motherboard or device makers.
I can not get Andys DLL or my own code to work with motherboard serial ports, but both work with USB to Serial adapters
Why is that?


Title: Re: Debug SAS DLL for testing
Post by: clone on January 09, 2012, 05:15:21 AM
Hey all, sorry for waking up an old thread, but I'm just entering the world of SAS.

I've read a lot of this forum, and will probably read all the rest, but this test thingie got my attention. I also get "Unable to load DLL 'SASEGM.dll': The specified module could not be found." error when trying to run the program, and when I load the solution in VS 2008 and try to add reference to SASEGM.dll I get: "A reference to 'C:\Program Files\AP\SASEGMTest\SASEGM.dll' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."

Any idea why the dll doesn't work?


Title: Re: Debug SAS DLL for testing
Post by: Foster on January 09, 2012, 10:26:05 AM
You have to look at his code and see how he references it.

I would match how he has it referenced.
You might have to translate it to the language you are developing your program in. (C#, C++, VB)

Try his TestApp with your system and machine
You cant do much with his test app but if it does the basics he has coded then you know his DLL will work with your Com/Serial Ports

Also you must understand how to configure SAS on your Machine and how to connect to your computer..

I can tell you that the State of Montana has a SAS document on their web site
I am using it to help me code my own program




Title: Re: Debug SAS DLL for testing
Post by: AndyP on February 07, 2012, 08:46:36 PM
Back onto it now.

You lads are going to hate me, cause I have to do this commercially, so I need to use the IOCTL_SERIAL_LSRMST_INSERT command that was suggested to me elsewhere, this means it will only work with hardware serial ports from what I am aware.

Stay tuned.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on February 07, 2012, 11:11:09 PM
Did a quick change to the serial port driver using IOCTL_SERIAL_LSRMST_INSERT to detect the parity errors, sooooo much more reliable now!!! Only tested it against a SAS Simulator, so now I will go and find a real SAS machine to do some tests.



Title: Re: Debug SAS DLL for testing
Post by: Foster on February 07, 2012, 11:17:46 PM
Andy look up DCB (Device Control Block, if you change one bit fParity = false that will tell the UART or drivers to ignore any parity errors.
I just have not figured out how do so in Managed C#, I know it involves using the Win API calls instead of the .Net serial port class.


Title: Re: Debug SAS DLL for testing
Post by: AndyP on February 07, 2012, 11:44:04 PM
Andy look up DCB (Device Control Block, if you change one bit fParity = false that will tell the UART or drivers to ignore any parity errors.
I just have not figured out how do so in Managed C#, I know it involves using the Win API calls instead of the .Net serial port class.

I need to know when there is a parity error. The parity bit is used in place of a wakeup bit, and the wakeup bit is set with the machine poll address to denote a 'chirp' from the VGM. I need to detect the chirp to differentiate between a chirp and an exception code.



Title: Re: Debug SAS DLL for testing
Post by: Foster on February 08, 2012, 12:08:16 AM
The EGM's only assert wake up bit when they do not see polling from the host after 5 seconds.

There can only be a few reasons for this
Problem in the physical hardware of the host or EGM, cable cut or disconnected.
Host power failure, Something on the host crashes.
The Host software not polling often enough.  That is not likely to happen with the computer hardware available today.

if you can tell me how to disable parity checking in C# please do.


 



Title: Re: Debug SAS DLL for testing
Post by: AndyP on February 08, 2012, 01:00:45 AM
The EGM's only assert wake up bit when they do not see polling from the host after 5 seconds.

There can only be a few reasons for this
Problem in the physical hardware of the host or EGM, cable cut or disconnected.
Host power failure, Something on the host crashes.
The Host software not polling often enough.  That is not likely to happen with the computer hardware available today.

if you can tell me how to disable parity checking in C# please do.


Remember, I am doing this for commercial reasons, so I need my code to be very reliable, and I have to cater for all circumstances, including what you describe. I could get a chirp and decode it as a door open for example, and report it to the survellance team who then send security to investigate. Has to be rock solid.

Not sure how to disable parity checks in .net, but maybe you can try set parityreplace with a null?? http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.parityreplace.aspx

 If not, the only way would be to write a wrapper around the native API, which would require a fair amount of work. Given the early version of the .net framework had no serial port class, I would be surprised if some code did not already exist that wraps up the win api. There should be some examples of how to interface to the native API here http://zachsaw.blogspot.com.au/2010/07/net-serialport-woes.html which contains some code to work around a known bug in the .net serial port class.


Title: Re: Debug SAS DLL for testing
Post by: zarobhr on February 08, 2012, 11:01:01 AM
i wrote my own serial interface, i can detect the parity error on my general polls i just dont do anything with it yet since i am not polling multiple machines on a single port (YET), just multiple machines on different ports.

i do not use vb.net serial port class as it was too much issue and didnt want to report parity error without do a replace on it. and i could control timing on it to well

i do calls to winapi32 using writefile and readfile






Title: Re: Debug SAS DLL for testing
Post by: all3bar on August 09, 2012, 12:04:34 AM

        No_activity = 0x00,
        Slot_door_was_opened = 0x11,
        Slot_door_was_closed = 0x12,
        Drop_door_was_opened = 0x13,
        Drop_door_was_closed = 0x14,
        Card_cage_was_opened = 0x15,
        Card_cage_was_closed = 0x16,
        AC_power_was_applied_to_gaming_machine = 0x17,
        AC_power_was_lost_from_gaming_machine = 0x18,
        Cashbox_door_was_opened = 0x19,
        Cashbox_door_was_closed = 0x1A,
        Cashbox_was_removed = 0x1B,
        Cashbox_was_installed = 0x1C,
        Belly_door_was_opened = 0x1D,
        Belly_door_was_closed = 0x1E,
        No_activity_and_waiting_for_player_input = 0x1F,
        General_tilt = 0x20,
        Coin_in_tilt = 0x21,
        Coin_out_tilt = 0x22,
        Hopper_empty_detected = 0x23,
        Extra_coin_paid = 0x24,
        Diverter_malfunction = 0x25,
        Cashbox_full_detected = 0x27,
        Bill_jam = 0x28,
        Bill_acceptor_hardware_failure = 0x29,
        Reverse_bill_detected = 0x2A,
        Bill_rejected = 0x2B,
        Counterfeit_bill_detected = 0x2C,
        Reverse_coin_in_detected = 0x2D,
        Cashbox_near_full_detected = 0x2E,
        CMOS_RAM_error_data_recovered_from_EEPROM = 0x31,
        CMOS_RAM_error_no_data_recovered_from_EEPROM = 0x32,
        CMOS_RAM_error_bad_device = 0x33,
        EEPROM_error_data_error = 0x34,
        EEPROM_error_bad_device = 0x35,
        EPROM_error_different_checksum_version_changed = 0x36,
        EPROM_error_bad_checksum_compare = 0x37,
        Partitioned_EPROM_error_csum_version_changed = 0x38,
        Partitioned_EPROM_error_bad_checksum_compare = 0x39,
        Memory_error_reset = 0x3A,
        Low_backup_battery_detected = 0x3B,
        Operator_changed_options = 0x3C,
        A_cash_out_ticket_has_been_printed = 0x3D,
        A_handpay_has_been_validated = 0x3E,
        Validation_ID_not_configured = 0x3F,
        Reel_Tilt = 0x40,
        Reel_1_tilt = 0x41,
        Reel_2_tilt = 0x42,
        Reel_3_tilt = 0x43,
        Reel_4_tilt = 0x44,
        Reel_5_tilt = 0x45,
        Reel_mechanism_disconnected = 0x46,
        One_dollar_bill_accepted = 0x47,
        Five_dollar_bill_accepted = 0x48,
        Ten_dollar_bill_accepted = 0x49,
        Twenty_bill_accepted = 0x4A,
        Fifty_dollar_bill_accepted = 0x4B,
        Hundred_dollar_bill_accepted = 0x4C,
        Two_dollar_bill_accepted = 0x4D,
        Five_hundred_dollar_bill_accepted = 0x4E,
        Bill_accepted = 0x4F,
        Two_hundred_dollar_bill_accepted = 0x50,
        Handpay_is_pending = 0x51,
        Handpay_was_reset = 0x52,
        No_progressive_info_received_for_5_seconds = 0x53,
        Progressive_win = 0x54,
        Player_has_cancelled_the_handpay_request = 0x55,
        SAS_progressive_level_hit = 0x56,
        System_validation_request = 0x57,
        Printer_communication_error = 0x60,
        Printer_paper_out_error = 0x61,
        Cash_out_button_pressed = 0x66,
        Ticket_has_been_inserted = 0x67,
        Ticket_transfer_complete = 0x68,
        AFT_transfer_complete = 0x69,
        AFT_request_for_host_cashout = 0x6A,
        AFT_request_for_host_to_cash_out_win = 0x6B,
        AFT_request_to_register = 0x6C,
        AFT_registration_acknowledged = 0x6D,
        AFT_registration_cancelled = 0x6E,
        Game_locked = 0x6F,
        Exception_buffer_overflow = 0x70,
        Change_lamp_on = 0x71,
        Change_lamp_off = 0x72,
        Printer_paper_low = 0x74,
        Printer_power_off = 0x75,
        Printer_power_on = 0x76,
        Replace_printer_ribbon = 0x77,
        Printer_carriage_jammed = 0x78,
        Coin_in_lockout_malfunction = 0x79,
        Gaming_machine_soft_meters_reset_to_zero = 0x7A,
        Bill_validator_totals_reset_by_an_attendant = 0x7B,
        A_legacy_bonus_pay_and_or_multiplied_jackpot = 0x7C,
        Game_has_started = 0x7E,
        Game_has_ended = 0x7F,
        Hopper_full_detected = 0x80,
        Hopper_level_low_detected = 0x81,
        Display_meters_or_attendant_menu_entered = 0x82,
        Display_meters_or_attendant_menu_exited = 0x83,
        Self_test_or_operator_menu_has_been_entered = 0x84,
        Self_test_or_operator_menu_has_been_exited = 0x85,
        Gaming_machine_is_out_of_service = 0x86,
        Player_has_requested_draw_cards = 0x87,
        Reel_N_has_stopped = 0x88,
        Coin_credit_wagered = 0x89,
        Game_recall_entry_has_been_displayed = 0x8A,
        Card_held_not_held = 0x8B,
        Game_selected = 0x8C,
        Component_list_changed = 0x8E,
        Authentication_complete = 0x8F,
        Power_off_card_cage_access = 0x98,
        Power_off_slot_door_access = 0x99,
        Power_off_cashbox_door_access = 0x9A,
        Power_off_drop_door_access = 0x9B,