The PDS902 answers with error "IAVAIL -e 9999" to any command

[fusionstream]

The PDS 902 3G requires telnet. I don't see any reference to telnet or port 23. Nevertheless, the PDS respons with "instance(pds): Received generic fail error from PDS pds: IAVAIL -e -9999"

As there is no option to send raw commands or custom commands, I can't even work around this.

[dnmeid]

The module works with telnet but not on port 23. It has been tested with a PDS 902 3G without problems. Is the module working for you although it gives the error or doesn't it work at all? What firmware are you using on the PDS, some commands are only available after firmware 3.00 (IAVAIL should also be available prior 3.00)? Please generally be more precise when describing bugs, e.g. describe exactly what you the error is and what you have done to produce the error.

[fusionstream]

I'm afraid I do not recall the firmware version I was working with but it should be 3.00 as I eventually had to use a different app to control it and the programming reference I used was for 3.00.

The module did not work at all. This is why I mentioned the inability to send raw commands.

The pds was running telnet off port 23.

"Describing exactly what you the error is and what you have done to produce the error"

• Creating the instance results in the companion app showing in the log window: "instance(pds): Received generic fail error from PDS pds: IAVAIL -e -9999"
• Hitting a button (that was set to "Select input" with various input numbers) results in the companion app showing in the log window: "instance(pds): Received generic fail error from PDS pds: IAVAIL -e -9999"
• Hitting a button (that was set to "Take") results in the companion app showing in the log window: "instance(pds): Received generic fail error from PDS pds: IAVAIL -e -9999"

Basically, everything I did resulted in: "instance(pds): Received generic fail error from PDS pds: IAVAIL -e -9999"

[dnmeid]

That is quite strange. According to the errors companion is connected successfully to the pds, otherwise you wouldn't get error messages from it. When there is an error the PDS answers with the command leading to the error and an error code. In this case the misbehavin' command seems to be IAVAIL which I use to check if certain inputs are available. This check is only done once after each connection. So it makes no sense that pds replies with error messages to commands it doesn't receive. During my test I once managed to overload the pds command buffer which resulted in a DOS. Maybe you ran into that state. Did you try to reboot the pds? Can you still reproduce the problem or was it a one off?

[fusionstream]

I did reboot the switcher but did not and could not reset due to operational needs. I managed to telnet in via the windows command line and also the other app without error and commands there worked fine so I'm not sure if it's the buffer but I didn't really investigate. This was both before and after reboots and switching between companion and the other methods. To be clear, only one interface was running at a time.

So it makes no sense that pds replies with error messages to commands it doesn't receive.

I've had a look at the module code and at present, with your above statement in mind, I suspect it may have something to do with the carriage return that you use to handle whole lines from the buffer.

It would appear this app expects \r, the other app I used expects a \r\n, but the documentation (which I've just reread) says it replies with \n\x4

Can you still reproduce the problem or was it a one off?

I could reproduce the problem throughout the duration of the show (off and on because I could not use it during the actual show run). I do not have access to one at the moment so I can't test it now but if I do I'll update.

I've noticed there is a debug class. I am unfamiliar with companion development. How would I go about turning it on?

[dnmeid]

Yes you are right about the termination of responses. I'll try with 0x04 as soon as I have a device to test. But this shouldn't cause the problem you had because PDS responds with a \r after each line too. So the difference between \r and \n or 0x04 is only relevant with multiline responses and multiline responses are only used in lists and lists are not used in Companion so far. Second it doesn't explain why the PDS isn't reacting on commands. Even if there is an error in the receiption part of Companion it still is sending the command and PDS should react to it. Only thing I can think of at the moment is that there is an error in the PDS which closes the connection after it throws the -e 9999. So Companion attempts to reopen the connection the next time you use a button and after the connection is established the error and closing starts again before the actual command is sent.

[MarcHagen]

So with a PDS902 when sending a ISEL -i 6 you get 2 lines: ISEL -i 6 < Indicates OK, switched ISEL -e 0 OR 9999. You get a 9999 if there is a invalid input.

Edit: And if i'm correct, this is for 701/901/902 See: 3101725 #2

[dnmeid]

It would be nice if that is the cause of the problem. But the original claim is: "the module did not work at all" and "any command resulted in that error" and "with telnet it worked without the error". That would mean every time companion was used, the sources had been invalid and all the other times they had been valid and instead of 'any command' it is 'only source selecting commands' and instead of 'did not work at all' it is 'worked, but threw an error'. @fusionstream Could this have been the case?

[fusionstream]

Did not work at all for me.

[willosof]

Wow, great attitude.

[JeffreyDavidsz]

Think we can close this