Telnet for sending and receiving commands (in 10.6.1)

[Theatre III Sound]

Mike,

I know we've corresponded in the past about a telnet port for SCS and at the time concluded that there was little interest by the user community. Also back when we discussed this, you hadn't implemented RS232 in/out yet.

I mentioned telnet in the DMX out topic recently as I thought it would be a better mechanism than trying to have SCS inject values into a DMX packet. I've also had a discussion with a member of the LightFactory forum (a Yahoo forum) who is an SCS user who would like to drive LightFactory (LF) from SCS and vice versa. LF can already accept commands over a telnet port and the commands are ASCII just like you'd type in at LF's command prompt. LF can send commands via telnet as well, but currently only to another instance of LF.

Given that once established, telnet acts like a virtual serial port, it seems to me that adding that capability to the repertoire of SCS would be relatively easy (that's what they always say, right ). I think you could use the same form as you have now for composing RS232 messages. You'd need a new tab for the permanent options screen to set up the telnet port and I think that's about it. Could you give us an assessment on what it would take to add this capability?

I've asked the developer of LightFactory to comment on generalizing LF's send command so that a port number could be specified which would have to be a number other than the port LF uses (default is 3100). If that can be implemented, then LF will be able to send commands to SCS (or any other telnet capable application).

I think if you add telnet capability to SCS, it and LF will be a dynamite combination, especially for small venues with tight budgets (like my theatre). Also, having telnet will open up possibilities like using a PDA to control SCS, implementing a master cue controller for both lights and sound (and multimedia stuff), etc.

I'm hoping other members of this forum will weigh in on whether they would find this capability useful to them.

[dbn]

I'm the LightFactory (LF) and SCS user who recently started the discussion over on the LF forum. It started out as a request for LF to add support for MIDI Show Control. That's not currently on their product development roadmap, so some alternative solutions were suggested. My rquirement is for LF and SCS to be able to send cue trigger messages to each other. For example, a "lightening" light cue in LF followed by a "thunder" sound cue in SCS, after a suitable delay.

Anyway, it turns out that the existing remote command line features of both SCS and LF are *almost* sufficent to acheive the desired integration. What's misssing on the SCS side is the ability to redirect the incoming and outgoing RS-232 command stream over a Telnet connection. There is the issue of which side will be the Telnet client and which will be the Telnet listener/server, of course. I think all the needed components exist in the Windows network stack. Most of the work will likely be in the GUI (isn't it always?). That addresses cues triggered by SCS over on LF.

To address cues triggered on SCS from LF, similar changes are being requested of the LF developers. Specifically, to allow the IP address and TCP port of the existing "send via Telnet" feature to be user configurable. LF would then allow SCS-compatible cue trigger commands to be sent.

The syntax of the commands in each "direction" would be that of the receiving software.

I still think that MIDI Show Control would be a better long-term solution for LF, assuming it gains sufficent market traction. However, I have an immediate need to make use of this feature, so the commands-over-Telnet path is attractive as the most pragmatic and most feasible solution in the short-term.

I'd like to add my voice in support of the request to extend the RS-232 remote cue triggering interface by allowing redirection over Telnet. I, too, think this would be a powerful, and flexible way to acheive integration of these two dynamite products: SCS and LF. I'm sure that there are other systems that could equally well take advantage of a Telnet interface. Thanks for your consideration.

[Mike Daniell]

It should be fairly straight forward to implement a Telnet interface, but simple changes always turn out to be more complicated than first thought . Are you looking for both Telnet control of SCS, and Telnet output in Control Send cues?

One more thing: terminology. Should this be referred to as "Telnet", "TCP", "TCP/IP" or something else?

[dbn]

It should be fairly straight forward to implement a Telnet interface, but simple changes always turn out to be more complicated than first thought.

Indeed.

Are you looking for both Telnet control of SCS, and Telnet output in Control Send cues?

That would be ideal, yes. Symmetry of use generally leads to ease of use.

One more thing: terminology. Should this be referred to as "Telnet", "TCP", "TCP/IP" or something else?

It's Telnet over TCP/IP (over Ethernet). I think that the term "Telnet" implies the rest, and would be the least confusing terminology.

Telnet does have various session options, but I think all that's needed here is the ability to send 7-bit ASCII characters. No need to worry about Unicode or 8-bit "binary" data. Probably the default Telnet options will suffice.

Thanks!

[Theatre III Sound]

Mike,

I think you could view a telnet port as a virtual serial port, which is why I think you could use the same interface you have now for serial ports and that would mean both ways. To control SCS, a sending application would transmit a packet over the telnet link containing the same characters (scsGO, for example) as an application using a COM port. For outgoing messages, the form you already have for composing multiline serial commands would work just fine.

I think telnet is the proper term to use here. It's one of many protocols that operate over TCP/IP links.

[dbn]

Here's a paraphrased question from the developer of LightFactory:

Is the RS-232 remote cue control input parser in SCS tolerant of extraneous "gibberish"?

That is to say, if properly formatted SCS commands, e.g., scsGo("0"), are embedded in other text, will SCS ignore the unrelated text and properly "trigger" on the recognized character sequence? A hypothetical example follows:
.
LightFactory Telnet Server
>Running Cue : Cue List 1: 1 Cue Number 1
scsGo("0")
Running Cue : Cue List 1: 2 Cue Number 2
scsGo("0")

What is seen here is a mixture of the Telnet CLI interface of LightFactory, which has a command prompt of ">" the cue execution status messages, and the "cue notes" output from the execution of cues 1 and 2 on Cue List 1. The output from cue list execution gives the execution status followed by the content of the "cue note", which is where the SCS command is proposed to reside. I've requested a "silent" mode of operation, wherein only the "cue notes" output is generated, but there is no ETA on that software change in LightFactory.

In the mean time, the LightFactory developer wants to know if SCS will ignore the extraneous information in this character stream?

[Mike Daniell]

In the mean time, the LightFactory developer wants to know if SCS will ignore the extraneous information in this character stream?

Yes, provided any preceding extraneous information is terminated by a CR (carriage return: 0DH). Basically, SCS reads each string terminated by a CR and examines the start of each string. If the start of the string is not a recognized SCS command then SCS just ignores the whole string (up to the CR).

[dbn]

Mike,

Great! That's going to make getting the connection going much easier -- or least it will require fewer software changes.

Another point of clarification coming from Martin Searancke, developer of LightFactory -- only a single Telnet connection between LightFactory and SCS will be required for both RS-232 Control incoming cue trigger commands (LF --> SCS) and Control Send Cue outgoing cue trigger commands (SCS --> LF). If SCS were to implement a Telnet client that can initiae a connection to user-specified IP address and TCP port, that single Telnet session could be bound to both the incoming and outgoing remote cue trigger streams in SCS.

If I can find some sort of COM-port-to-Telnet redirector "hack", I'll give this a test. An internal Telnet solution in SCS would still be appreciated, however.

Thanks!

[Mike Daniell]

I'm planning to work on Telnet control and send for the next release. So if either of you (or anyone else) can assist with testing that will help.

[dbn]

Absolutely. I'd be happy to assist in testing.

One additional issue, which you may already have considered, is that the Telnet link will need to avoid echoing characters that are sent to it back to the sender. This is an option often found on Telnet servers. If you are going to implement the Telnet feature as a client, this won't be an issue. If you additionally choose to implement this feature using a Telnet listener/server, you'll need an option to supress echo. The reason for this is that if both ends of the link support the same syntax for any of their commands, an echoed outgoing command may be indistinguishable from an incoming command. For the current comamnd set, this is unlikely, as each command is prefixed by "scs".

[Mike Daniell]

Telnet feature included in 10.6.1. Thanks, Dave and Bruce, for your input and assistance.

[pcarver]

I need some help with understanding the telnet sending mechanism and possibly a feature request to enhance it.

How does SCS determine when to make a telnet client connection and when to end the connection? Does SCS properly detect when the connection is terminated by the server?

We use a Lanbox (www.lanbox.com) for lighting control and I would like to have SCS send "Go Next" cues to the Lanbox for lighting cues.

The Lanbox has a very rudimentary TCP/IP interface. The way it works is you open a TCP connection to the Lanbox on TCP port 777 and the very first thing you must send is the password. After that you send cryptic ascii sequences. The TCP connection will stay open for a while but the Lanbox will disconnect if it's idle for too long. As long as the connection is open you can continue to send commands, but if the connection times out then you have to reconnect at the TCP level and send the password.

I was able to get SCS to send a Go Next cue to the Lanbox but it's not reliable. I think there may be two problems. First, I can't find any way to control when the TCP connection is made and disconnected so I can't reliably know when to include the password in a cue and when to just send the Go Next command. Second, the Lanbox doesn't actually understand the full Telnet protocol it just understands plain ASCII over TCP/IP. I think SCS may be sending some sort of telnet options or something at the beginning of the connection when the Lanbox expects to see a password. I think there may be a timing issue here impacting whether the Lanbox receives the password correctly.

I think the best option in this case is to use a separate TCP connection for each cue in SCS. It should be possible to open a TCP connection, send the password, send the Go Next command and disconnect without a significant time lag.

[Mike Daniell]

How does SCS determine when to make a telnet client connection and when to end the connection? Does SCS properly detect when the connection is terminated by the server?

SCS makes the connection on start-up and expects the connection to stay live for the whole run. The only exception to this sequence is if you change Telnet options under Permanent Options during the run.

We use a Lanbox (http://www.lanbox.com) for lighting control and I would like to have SCS send "Go Next" cues to the Lanbox for lighting cues.

The Lanbox has a very rudimentary TCP/IP interface. The way it works is you open a TCP connection to the Lanbox on TCP port 777 and the very first thing you must send is the password. After that you send cryptic ascii sequences. The TCP connection will stay open for a while but the Lanbox will disconnect if it's idle for too long. As long as the connection is open you can continue to send commands, but if the connection times out then you have to reconnect at the TCP level and send the password.

Can you provide a link for downloading a Lanbox reference manual that covers this info?

I was able to get SCS to send a Go Next cue to the Lanbox but it's not reliable. I think there may be two problems. First, I can't find any way to control when the TCP connection is made and disconnected so I can't reliably know when to include the password in a cue and when to just send the Go Next command. Second, the Lanbox doesn't actually understand the full Telnet protocol it just understands plain ASCII over TCP/IP. I think SCS may be sending some sort of telnet options or something at the beginning of the connection when the Lanbox expects to see a password. I think there may be a timing issue here impacting whether the Lanbox receives the password correctly.

SCS sends exactly what you see in the 'Message (Hex)' field in the Control Send sub-cue properties. However, it's very likely that the underlying Telnet control software is adding a message header to conform with Telnet standards.

I think the best option in this case is to use a separate TCP connection for each cue in SCS. It should be possible to open a TCP connection, send the password, send the Go Next command and disconnect without a significant time lag.

That's possible (as an option).

How does the Lanbox expect the password? Does it expect it at the start of the message, followed by some separator and then the 'Go Next' command? Or is this a separate message, eg you send the password first, wait for confirmation(?) and then send a message containing the 'Go Next' command?

[pcarver]

I don't think there's really any documentation written the way you'd like to see it, but that's mostly because there's so little to document.

The main documentation page is here: http://www.lanbox.com/support/support.html but it probably doesn't contain anything of interest to you.
The full documentation is also included in the zip file with the software. http://www.lanbox.com/downloads/LCeditPlus_3.4W.zip

The file LCplus Reference v2.0a1.pdf in the Manuals subdirectory of the zip file is the most relevant but it barely touches on the network protocol because there really isn't one.

Basically, telnet is one of a large numbers of protocols that runs over top of TCP/IP. The web, for example, uses HTTP over TCP/IP with no telnet protocol involved at all. FTP, SSH, and a myriad of other protocols are all completely separate from telnet but share the same underlying TCP protocol. The Lanbox just uses raw TCP with nothing else over top of it.

Essentially you connect to the Lanbox on TCP port 777 and it sends you ASCII text "enter password :" (without the quotes) and you must send the password as ASCII text followed by a line feed and/or carriage return (I'm not positive which, but I've written a Perl script and printing "\n" works. I've also used the terminal program Putty with the connection type set to raw and the enter key on my US keyboard works.

After entering the password you send commands to the Lanbox in the format it expects. The specifics are documented in the file mentioned above (LCplus Reference v2.0a1.pdf) but it's basically ASCII representations of hexidecimal numbers. Each message must start with an asterisk and end with a hash (pound/number) symbol followed by a line feed and/or carriage return. In between those two symbols are one or more bytes represented as two digit hexidecimal numbers in ASCII. An example command is:

* CD FF 0001 A0 #

Spaces are optional, the Lanbox ignores them if they are present. That command means the following:
* - Message start indicator, an asterisk
CD - Read DMX values from a layer (also called a buffer or an engine)
FF - The selected layer, in this case FF is the DMX output buffer but other values would refer to one of many possible layers
0001 - The channel number to start at, in this case channel 1
A0 - The number of channels, in this case ten channels represented in ASCII hexadecimal
# - Message end indicator, a hash/pound/number symbol followed by a line feed/carriage return

In response to this message the Lanbox will output a series of hexidecimal values as two ASCII characters for each channel. Other commands will have other output.

There is a publicly accessible Lanbox at demo.lanbox.com with password 777. Just connect on TCP port 777 with Putty or Netcat or any other program that can make a raw TCP connection.

I tried to add an attachment to this post with a Perl script that I have written to control a Lanbox from a web browser but the forum software won't allow it. Let me know if you'd like me to email a copy. I'm not much of a programmer, but the script is functional.

[Mike Daniell]

Thanks for the detailed posting. I've downloaded the zip file from LanBox and had a look at the file LCplus Reference v2.0a1.pdf. Before I go any further down the "raw TCP" path, a quick glance at the manual indicates you could use MIDI instead of TCP/IP (see p7). Is this a viable alternative, which I presume wouldn't be subject to the LanBox closing a connection and re-requesting a password?