Anyone controlling a Blu from AMX (NetLinx) over Ethernet?

kirchh

...And if so, might some sample code be available? I had no luck finding anything at AMX.

Thanks.
--Daniel

Scott E.

Are you saying that you couldn't find BSS Soundweb London code on AMX's website, or you couldn't find the IP example?

The code is here (you must have a login) after you type 'bss' into the manufacturer field:
http://amx.com/inconcert/trednet.asp?page=device

The protocol is identical whether you are pointed to an IP socket or an RS232 port. By default, the code shows an RS232 port mapping. If you want to change the mapping to an IP socket then follow this example of setting up an IP connection via AMX and you will be ready to go.

http://www.amx.com/techsupport/techNote.asp?id=621

kirchh

Hi Scott -

Many thanks for the links. I wasn't able to find IP examples, just serial. I'll dig into the info you provided.

While I have you, perhaps you can clear up a confusion I have based only on my first look at the BSS documentation for the DI kit. The documentation states, \"Note: The ACK/NAK mechanism is not used for Ethernet messages as TCP provides it automatically.\" Does this mean that there is no mechanism for the controller to be notified that it has sent a malformed message when communicating via Ethernet? If so, I take it that the ACK/NAK mechinism is intended solely to detect transmission errors (valid message gets damaged during transmission) rather than message construction errors (invalid message constructed and sent).

Thanks for the help!

--Daniel

Scott E.

The ACK/NAK should always be turned OFF, for both IP and RS232, when using the AMX or Crestron modules. If it is turned on this code will not function.

The ACK/NAK is acutally used to tell the Soundweb London that the message it has sent to the 3rd party controller has made it successfully. If this is turned on , the 3rd party controller MUST ACK messages received from the London.

For the AMX/Crestron modules, the London will answer back with an ACK (0x06) saying the received message was properly formatted and then a full message specifying that the certain action has been completed successfully. If you don't get that full message back then the London will respond with a NAK (0x15) for a improperly formatted message. Or if an ACK comes back, but not the full message, that means the message was formatted correctly but the desired action didn't take place (so the message could have specified an SV or ObjectID that doesn't exist in the current design).

REMEMBER: The above paragraph is how the AMX/Crestron modules are designed. If the programmer decides to write their own base code they are in charge. Which means if they don't program the code this way then all they'll get back, by default, is an ACK or NAK from the London saying the message was properly formatted.

Both the AMX and Crestron code has been heavily tested and used in many designs for a couple of years. If you are using either of these two controllers you can rest assured they work, and the work reliably. It will save the programmer many hours of time if they use this pre-written code.

Scott

kirchh

Scott -

Thanks for the response. I'm not sure I made my question clear enough.

The London DI Kit documentation, on page 7, has a section entitled \"Protocol details\", which describes the ACK/NAK mechanism. This is a discussion of the basic command system used with the Blus, and does not involve any particular 3rd-party control modules. In that section, the following statement appears:

\"Note: The ACK/NAK mechanism is not used for Ethernet messages as TCP provides it automatically.\"

If this is correct, and there is no ACK/NAK mechanism when communicating via Ethernet, does this mean that there is no mechanism for the controller to be notified that it has sent a malformed message?

Does it also follow that if one wants to convert code from using RS232 to Ethernet, modifications would have to be made to remove ACK/NAK processing?

--Daniel

Scott E.

Okay - I thought you were refering to the 'ACK' property on the London box itself (which, again, should always be set to NO when using the AMX/Crestron modules).

The ACK/NAK mechanism is a transport layer function. Which means its sole purpose is to send an ACK/NAK to the 3rd party controller when it receives a properly framed message (not formatted message as I incorrectly stated above). This does NOT check the validity of the message itself. Since TCP/IP has its own transport layer functionality built in, the ACK/NAK is redundant and so we don't do it.

So, no, you will not receive an ACK/NAK using TCP/IP for a malformed message because the TCP/IP frame will automatically re-transmit the message if it has been told the message was malformed (this happens automatically on a layer that we don't have access to when sending messages over TCP/IP). All the transport layer does is make sure the receiving end gets the message as the user originally sent it.

To answer your question on whether you need to convert code when using switching from RS232 to IP...well, that depends on how you program the code is the first place! I wrote the Crestron and AMX modules for use over RS232 or IP in a manner where the user does not have to do any modifications to switch between the two methods. Simply point to an RS232 port or an IP socket. And this code provides true feedback as well.

With that said, if you choose to write your own code you will need to decide on your own architecture and that is what will determine whether you need to convert code. Personally, I do not rely on the transport layer in my code so I don't have to make any modifications (as I choose to do on the AMX/Crestron code).

kirchh

Scott --

Thanks for taking the time to reply. I've made progress on the control interface coding and the bahavior is precisely as you've described. I've now got a question about the SUBSCRIBE behavior that I've posted separately.

Thanks again --
--Daniel