RS232 Problems

[Parky]

Dear All

I am experiencing problems using a RS232 source to trigger sound cues. I am using girder on another machine to send RS232 script, according to the instructions, to the machine with SCS intalled. Even when I bring up the RS232 monitoring interface, there is nothing. On examing the null modem ports I can see data leaving the PC with girder and data arriving on the PC running SCS. After becoming very frustrated I further tested the ports using Hyper Terminal, this revealed that the 2 machines were communicating with each other and therefore it is nothing to do with the serial ports on either machine. Which leads me to believe that it is a software problem. If anyone can help me solve this problem I would be eternally greatful. The system is as follows... PIR sensors which are fed of a VOIM interface which are handled by Girder, on activation Girder sends a RS232 script to SCS and SCS and plays the relevant Sound Cue according to the relative PIR. I am nearly there and would love to sort this out as the show is only a week away. Many Thanks

[Mike Daniell]

Following up on this, there will be a few mods to RS232 control in 9.4.7. Parky has a pre-release of 9.4.7 and has confirmed RS232 control is now working OK.

[Theatre III Sound]

I thought I'd give this capability of SCS a try, but I'm seeing the same problem that was originally reported.

I'm running V9.5.0 of SCS and tried using a virtual terminal service called com0com along with com2tcp, both of which I found on SourceForge. Like Parky, I was able to get communication between two hyperterms, each on a separate PC working. But if I then run SCS on the server side with the same terminal characteristics set (19200 baud, 8-bit, 1 stop bit, no parity), nothing happens and nothing shows up in the RS232 monitor window of SCS.

At home, I no longer have a physical terminal, but at the theater I'm involved with there is a VT240 kicking around, so I could try to use it connected to the COM1 port of the PC to see if that works which might help point to whether the problem lies with SCS or com0com. In the meantime, if anyone has an idea I could try, please post a reply.

I have no immediate need for this to work, but I am exploring the idea of having a master control program that fires off cues in SCS as well as LightFactory. Both programs can be controlled via command lines, so the control program could use the same basic mechanism to communicate with them.

[Mike Daniell]

Have you checked other RS232 parameters, such as HandShaking? If you could email me (or post on this forum) the RS232 specification of the device you are trying to connect to SCS then I'll see if I can work out why SCS is not recognizing the device.

[Theatre III Sound]

In an effort to determine where the problem lies, I eliminated the use of the virtual comm port software (com0com & com2tcp) and tried using physical comm ports instead. Here's my configuration:

I have connected the physical comm ports of 2 PCs (COM1 in both cases) with a null modem cable. I can set up a Hyper Terminal on each PC and get them to talk to each other. The Hyper Terminal port characteristics are as follows:

Connect using: COM1
Bits per second: 19200
Data bits: 8
Parity: None
Stop bits: 1
Flow control: Xon/Xoff

With the two Hyper Terminals connected, I can enter characters on one and see them appear on the other and vice versa.

Now, on the PC running SCS, I disconnect the Hyper Terminal and start up SCS. On the RS232 Control tab of the Options screen, I have set the following:

Enable RS232 control of cues
Comm Port: Com 1
Data Bits: 8
Stop bits: 1
Parity: None
Baud Rate: 19200
Handshaking: XON/XOFF
Enable RTS: No
Enable DTR: No

I have a production loaded in SCS and can proceed through its cues by clicking on the GO button. I then connect the Hyper Terminal on the other PC and try to enter 'scsGo("0")<CR>' (minus the single quotes). The Hyper Terminal screen remains blank as well as the RS232 Test screen of SCS on its PC.

I have also tried using hardware handshaking with and without enabling RTS & DTR, but the outcome is the same.

A couple of questions:

Should I see characters echoed back to the remote Hyper Terminal from SCS as I type them?

Should I see each character appear on the RS232 Test screen as I type it on the remote PC or does the test screen only display completed commands (i.e. after receipt of the terminating <CR>)?

[Mike Daniell]

Should I see characters echoed back to the remote Hyper Terminal from SCS as I type them?

No - SCS does not echo back the characters.

Should I see each character appear on the RS232 Test screen as I type it on the remote PC or does the test screen only display completed commands (i.e. after receipt of the terminating <CR>)?

SCS waits for the <CR>, ie hex 0D, before displaying or processing the message.

I can't see anything obviously incorrect in your setup, but I'll email you with a request for more info.

[Mike Daniell]

Issue solved. RS232 input, like MIDI input, is expected to be sent to SCS from a device or software which has the appropriate SCS messages ready to send when required. The key difference between that assumption and using HyperTerminal or something like that is the time taken to send the entire message. If you are typing in the RS232 command then the time taken depends on how fast you type.

Because SCS expects RS232 messages to be sent from an automated system, SCS discards an RS232 message if the <CR> (hex 0D) is not received within 1 second of the start of the message. This timeout helps remove any rubbish that gets on the line, but if you are typing the RS232 commands in real-time then the message is very likely to be discarded before you have finished. This was the case in Theatre III Sound's test. Still using HyperTerminal, but sending a file containing the command instead of typing it in in real-time, SCS recognized and acted on the RS232 command.