Fusion bad response


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.

good example:

bad example:

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?

It’s an array of bytes, you then can access every byte of the response with [index]

I meant what does it do putting that after a variable declaration?

It looks like a fallback for a failed variable value assignment, but I haven’t seen it before.

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.

So if you look at what is printed out on line 183 it is a bunch of hex values. Except for the last character which is a colon character :

That seems to me like a data mismatch where most data is one type and the checksum is being sent as another.

Does it always trigger on the same relay control command?

If so, can you statically type out the command to see if the error triggers?

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.

I will have to get some free time to run a test, but I haven’t seen any reports of this happening before.

Could it be a the board itself? Maybe it is broken?

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.

Well I ran the test program over night, while I did get some failures to communicate I did not trigger a bad response like you’re seeing.

We can do an RMA and I can run the same software on your board to see if I can trigger it if you’d like.

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.

We want to do the RMA but we need a board here to do testing, can you send us another board and when it will get here we will send back the old one?

Unfortunately its against company policy to offer advanced replacements especially on Solid State relay controllers as they are special order items.