When I do set bank state, command=[170, 4, 254, 140, bank_state, bank_number, checksum], sometime it get a bad response(response should be [170, 2, bank_number, bank_state, checksum]) where the last 2 bytes switch position and I get [170, 2, bank_number, checksum, bank_state].
Even that I get the bad response I see on the board leds that the bank state changed according to the state that I sent.
As you can see here in the bad example the command sent is [170, 4, 254, 140, 29, 2, 87], the response is [0xaa, 0x02, 0x02, 0xcb, 0x1d](in translation to decimal its [170, 2, 2, 203, 29]) and the last 2 bytes are 203 and 29, the new state is 29 and the checksum is 203 and the should be in each other position in response
Here is a case where the response has no valid data in it, even if I switch with the last 2 bytes it those not make any sense. [0xaa, 0x02, 0x01, 0xae, 0x00] (decimal is [170, 2, 1, 174, 0])
I’m unfamiliar with this particular syntax in Python. Can you clarify what the data: b’ section of the code is doing after the socket.recv on line 106?
Can you please clarify to what part of the code do you mean, I did not fully understand(line 106 is not here).
This code is in break-point while debugging, the orange part after the line is the current value of the variables.
You can see in the last image for example in line 186 that the data received is [0xaa, 0x02, 0x01, 0xae, 0x00] (decimal is [170, 2, 1, 174, 0]) which has no readable data.
Got it, I was referring to line 186, I just misread the 8 as a 6.
It appears to be a data mismatch. The checksum is being converted into a string. In the last instance a 58 which equates to the ascii character :
Fusion appears to be accepting this sometimes and sometimes not. Either way, when that happens it looks like its throwing a response with a bad checksum.
I did not fully understand the data mismatch you described.
This is not good for us, we are working with the board to control movement so we cannot have bad responses every random time.
This is add up to the timeout exception we are getting.
This occurs in any set bank command(I mean for every bank state being send).
The ascii is just representation of the list of bytes that are being send.
I am pretty sure that the send method is ok because it’s working 90+ percent of the time.
I am not sure about statistics of how many times it happens, it can happen on bank 1 or 2 I did not see a difference.
Its possible, can you try controlling it with Base Station and monitoring what comes out is a similar response?
Are you controlling bank 0 (all banks) ever?
I’m running a test python software that just rams this command into a fusion board I have here. I’ll leave it running over night to see if I can duplicate what you’re seeing.
I can try with Base Station, it does not happen a lot so I am nut sure that I can reproduce it by the Base Station, when I use it with python its in higher rate of commands then I can do with mouse click.
I am controlling bank 0 but it was not the case for the cases that I uploaded here.
By communication failures you mean the timeout exception?
What should be the max rate of commands sent to the board?
I will have to check about the RMA because we are in intensive development and we need the board for testing.
Yes, the board didn’t respond and it triggered a timeout after ~700 millisecond timeout.
Ideally you should be able to write commands to it as soon as you can read out the response from the last command, but I can’t say for sure why it is timing out.
