Reading labels is not fully working

[daniep01]

Now i have tested a bit more. After the inital read i did when i installed the newest test-build it seems to be something wrong with the labels of sources 17-32 and all above 256 comes up as "undefined". It only reads 468 sources even though I got 500, so 32 is missing. Hopefully this helps you out.

Destinations reads out just fine. Only got 200 so i cant tell over 256 on theese.

Originally posted by @evenover in https://github.com/bitfocus/companion-module-generic-swp08/issues/3#issuecomment-874171958

I suspect this needs the DLE DLE processing to be done to fix

[chibiconsulting]

BTW, are you checking the ACK/NAK returned by the controller? Not sure if the Ultrix sends those; however, on a NAK, you could log a message with the data sent to check it later and that might narrow down the possible issue.

[evenover]

I did a capture of a namerequest with wireshark.

https://we.tl/t-N5W65GPGEH

[daniep01]

Thanks, is this a capture between Companion and the Ultrix showing the missing 17-32 fault?

[evenover]

Yes, companion actually get the labels of source 273-288 and set them to variable source name 17-32

[evenover]

What value are you using as DIV/MOD?

EDIT: Looked into the code; when checking the readout it looks like the names should be MOD/DIV 256.

[daniep01]

Looked into the code; when checking the readout it looks like the names should be MOD/DIV 256.

That would make some sense except the crosspoint set/get command is MOD/DIV 128

[evenover]

That would make some sense except the crosspoint set/get command is MOD/DIV 128

Just a hint to check it 😉

I think the set/get command is from the swp02 which did not support names and because of that didn't need more than MOD/DIV 128

[daniep01]

The crosspoint command from SWP08 supports upto 1024 sources/destinations by means of DIV/MOD 128. (7x128)+128

[evenover]

                         10 02 6a 01 01 01 90 10 10 45   .s......j......E
0040   58 54 31 30 2d 31 33 45 58 54 31 30 2d 31 34 45   XT10-13EXT10-14E
0050   58 54 31 30 2d 31 35 45 58 54 31 30 2d 31 36 45   XT10-15EXT10-16E
0060   58 54 31 31 2d 31 20 45 58 54 31 31 2d 32 20 45   XT11-1 EXT11-2 E
0070   58 54 31 31 2d 33 20 45 58 54 31 31 2d 34 20 45   XT11-3 EXT11-4 E
0080   58 54 31 31 2d 35 20 45 58 54 31 31 2d 36 20 45   XT11-5 EXT11-6 E
0090   58 54 31 31 2d 37 20 45 58 54 31 31 2d 38 20 45   XT11-7 EXT11-8 E
00a0   58 54 31 31 2d 39 20 45 58 54 31 31 2d 31 30 45   XT11-9 EXT11-10E
00b0   58 54 31 31 2d 31 31 45 58 54 31 31 2d 31 32 86   XT11-11EXT11-12.
00c0   b8 10 03    

If you look at the first name in this "EXT10-13" it is the source number 401 in my ultrix. I would think the "90" value in the first line with the message has something to do with it. 144+256 =400 (MOD 256). 144 wouldnt be a value in MOD 128 if i'm thinking right(?)

[chibiconsulting]

If you look at Router Control Protocols SW-P-88 Issue 4b.pdf, section 8.2.4. CROSSPOINT TALLY DUMP (WORD) Message, there is precedent for some responses sent from the controller using DIV/MOD 256, even though most of the others use DIV/MOD 128..

[daniep01]

Does the spec you received from GV have anything on message type 6a?

[daniep01]

If you look at Router Control Protocols SW-P-88 Issue 4b.pdf, section 8.2.4. CROSSPOINT TALLY DUMP (WORD) Message, there is precedent for some responses sent from the controller using DIV/MOD 256, even though most of the others use DIV/MOD 128..

Very true

[daniep01]

If you look at Router Control Protocols SW-P-88 Issue 4b.pdf, section 8.2.4. CROSSPOINT TALLY DUMP (WORD) Message, there is precedent for some responses sent from the controller using DIV/MOD 256, even though most of the others use DIV/MOD 128..

6a 01 01 01 90 10

I've assumed that it's the 01 immediately before the 90 that is the 256 multiplier and created a new build which implements this change. I'm not sure what the other 01 bytes mean. The DLE DLE is also taken into account now but there is still a problem when 2 messages are received in the same block of data which I need to look at.

var multiplier = data[3]
var label_number = (256 * multiplier) + data[4]
var labels_in_part = data[5]

https://we.tl/t-lrYOqqPteN

[evenover]

Does the spec you received from GV have anything on message type 6a?

Request 100(64) Byte 1 = Matrix/Level Byte 2 = Length of char: 00=4char 01=8char 02=12char

Response 106(6a): Byte 1 = Matrix/Level Byte 2 = Length of char: 00=4char 01=8char 02=12char Byte 3 = 256 multiplier Byte 4 = Source nr MOD 256 Byte 5 = labels in part

same for the destinations CMD 102

[daniep01]

Thanks, in that case we should be good! Let me know. I wonder if requesting longer labels would work, I can add code for that easily enough.

[evenover]

The ultrix only support 8char, but it could probably be practical to have a "choose how many characters you want"-option on the request or in the "edit instance"

[daniep01]

I've added the 4/8/12 char options. Is the get names functionality working ok now?

[evenover]

I'm not going to be at work before Monday, so I'll test it out then.

[evenover]

I actually got to test it today. It reads out everything correctly name wise, but it only get 484 or 468 source names. I've tried refresh many times now. Maybe the source-script stops when the destinations start coming in?

I also have a source that i have changed the name of, but the variable in companion doesnt seem to be updating even though wireshark see the updated name. If i restart companion the first 16 source names comes up as undefinded, but after some refreshes they show up as intended.

[daniep01]

Yes, I need to make the incoming buffer more robust so that data can't get lost and so that multiple messages in one response are dealt with in order.

If a name changes in the ultrix then using the get names action should update it in companion. Not sure why that isn't working. Did that work in the old version of the module do you know?

[evenover]

The old version got the names of source 1-16 and got the updates when names changed in the ultrix.

It seems to not be updating sources 1-16 in the new build, but if i change the name of source 17 in the ultrix, the variable in companion updates.

The destination names works every time.

[daniep01]

I've improved the message processing to hopefully prevent missing updates. Please try this new build. ~https://we.tl/t-tBQ4qjNiCD~

https://we.tl/t-gM9Firsk5K

[evenover]

It seem to be reading out fine, but it still doesnt get the last 16 sources. It reads 484 of 500 sources and 200 of 200 destinations.

[daniep01]

If you view the warning and debug log after reading names is there anything relevant?

[daniep01]

It seem to be reading out fine, but it still doesnt get the last 16 sources. It reads 484 of 500 sources and 200 of 200 destinations.

I believe source 484 is in this block, is that correct?

6a 01 01 01 e0 10 10 45   .s......j......E
0040   58 54 31 35 2d 31 33 45 58 54 31 35 2d 31 34 45   XT15-13EXT15-14E
0050   58 54 31 35 2d 31 35 45 58 54 31 35 2d 31 36 45   XT15-15EXT15-16E
0060   58 54 31 36 2d 31 20 45 58 54 31 36 2d 32 20 45   XT16-1 EXT16-2 E
0070   58 54 31 36 2d 33 20 45 58 54 31 36 2d 34 20 45   XT16-3 EXT16-4 E
0080   58 54 31 36 2d 35 20 45 58 54 31 36 2d 36 20 45   XT16-5 EXT16-6 E
0090   58 54 31 36 2d 37 20 45 58 54 31 36 2d 38 20 45   XT16-7 EXT16-8 E
00a0   58 54 31 36 2d 39 20 45 58 54 31 36 2d 31 30 45   XT16-9 EXT16-10E
00b0   58 54 31 36 2d 31 31 45 58 54 31 36 2d 31 32 86   XT16-11EXT16-12.
00c0   18 10 03                                          ...

And these are the last 4 taking the total to 500?

6a 01 01 01 f0 04 45 58   .s......j.....EX
0040   54 31 36 2d 31 33 45 58 54 31 36 2d 31 34 45 58   T16-13EXT16-14EX
0050   54 31 36 2d 31 35 45 58 54 31 36 2d 31 36 26 cf   T16-15EXT16-16&.
0060   10 03                                             ..

Is it the final 16 from these captures (EXT 16-1 to EXT16-16) that are missing?

[evenover]

Yes, EXT16-1 to EXT16-16 is missing

[daniep01]

Which is odd because they are split across two messages.

[daniep01]

I've made a new build with much more logging for reading names, could you try this and check the debug log after requesting names.

https://we.tl/t-u5UPJFXGQ4

[chibiconsulting]

Just out of interest, if you configure the Matrix size to a different number of sources, either more or less, Does the number of missing sources change or is it always 16?

[evenover]

I have now added 16 more sources to the matrix and now I get the EXT16-1 to EXT16-16, but the newly added 16 sources are not getting into a variable. I can see in the log that the names are coming into companion.

Could this still be a buffer problem? what if the command for destination names were sent first, would it miss 16 destinations?

[daniep01]

Are the names also missing from the dropdown source selection list or only the variables?

[evenover]

Are the names also missing from the dropdown source selection list?

No, they are listed in the sources dropdown list

[daniep01]

Ok, there may be an limitation in sending hundreds of updates to companion variables quickly. The variables are handled by the core application rather than the module. I'll do some tests.

[daniep01]

I've changed the way the variables are set to hopefully fix this

https://we.tl/t-LPUaiScjuZ

[evenover]

With the new version it seems to be reading out right, even after several "refresh labels".

Good job!