New Life Games LLC
Homebrew Player Tracking and EFT Systems => NLG Homebrew Player Tracking and EFT Systems => Topic started by: tcv on August 14, 2020, 04:17:12 AM
-
Hi all
I have some doubts with the 9bits communication
I am experimenting with a SAS HOST application that I am developing in Python language from windows10
The application starts with a thread that sends every 200ms 0x81 and 0x80
0x81 = (0x80 + EGM address) with MARK parity
0x80 with EVEN parity
To send a command, the application pauses the thread
and first sends the 0x80 command, does a 200ms sleep and then sends the 0x11 command, after receiving a response
I resume thread 0x81 / 0x80.
This works perfectly, even with other 0x12, 0x18, 0x0F commands. However other commands do not return data, for example 0x1C, 0x1F.
I have been able to verify with the IGT SAStest application that all these commands respond correctly, therefore it is clear that I must be doing something wrong in my application
This happens on some machines, on others if they return response from those commands.As I have been able to read some post, some machines do not verify parity, so it is possible that if they respond to those commands
I do not know if it will be a matter of General Polls times(200ms) or the combination of parity change Mark to Even.
I appreciate any input or help on this topic because so far I have not gotten those commands to work
Thank you very much for your help
-
Hi TCW welcome to NLG
For arduino microcontroller my code for a general poll is as follows.
As far as i can recall if there has to be a small delay between 0x80 and 0x81 hence th 20ms delay.
Your 0x80 should be space parity not even (Ie 9th bit always zero)
If you are testing on a IGT its useful to go into diagnostics and do comms test to see if your SAS comms is coming through as expected.
void GeneralPoll()//
{
SASEvent[0]= 0x00;
UCSR1B = 0b10011101;
Serial1.write(0x80);
delay(20);
Serial1.write(0x81);
UCSR1B = 0b10011100;
Serial1.readBytes(SASEvent,sizeof(SASEvent));
}
-
Hi iwalker
With arduino I have tried with this method that you use and it works correctly, but I would like to achieve it for the Python application that I am developing.
I have also tried with IGT SAS Test software, it Works perfectly.
The surprising thing is that this machine responds to commands, for example 0x1C or 0x1F from the SAS TEST but does not respond from my Python application.
However with other commands such as 0x11, 0x12, 0x0F it responds without major problem from my application.
I understand that it is a timing issue, but I also use 20ms to the 80/81 cycle and 5ms inter-byte for Long Polls.
I'm not really sure, but maybe the Mark / Even change causes unwanted delays.
In my case it only works if the cycle 80/81 I configure it with Mark parity, and Even to send the bytes of the command that I request.
As I have been able to find out, there are DLL, not free, that are used for this type of communication.
If my application were for commercial purposes I would have no problem paying, but this is a job by learning and entertaining.
Regards
-
Hello TCV
Have a look at PySerial
https://pyserial.readthedocs.io/en/latest/pyserial_api.html (https://pyserial.readthedocs.io/en/latest/pyserial_api.html)
Regards
-
Hello iwalker
Thanks a lot for your help, but I've already been looking at the pyserial documentation.
That's where I found a way to change the Mark / Even parity on the program flow without needing to close / open the com port
See the extract with sync 80/81 with a time (self.gp = 20ms.)
self.connection.parity = serial.PARITY_MARK
self.connection.write([0x80])
time.sleep(self.gp)
self.connection.write([0x81])
time.sleep(self.gp)
self.connection.parity = serial.PARITY_EVEN
#-------------------
Regards
-
Hello TVC
self.connection.parity = serial.PARITY_EVEN should be self.connection.parity = serial.PARITY_SPACE
I think whats happening is this - Your commands that are working have an even parity so for those bit 9 is zero.
Commands that are not working have odd parity so bit 9 is 1 and so mahine thinks it is being addressed.
-
Hi iwalker
What do you suggest, that I send those commands that don't work setting to odd parity?
I can prove it
As soon as I do the test I will report the result
Thank you
-
The suggestion is to use space parity - sorry this got lost on previous post due to font size - fixed
-
Could you not tri-send commands Odd, Even, Space … counting on one to execute. You could kill the attempt sequence once you get back a success response.