Strange RS-232 Problem with Da-Lite
rynando
Posts: 68
I had a strange issue pop up with a Da-Lite RS-232 controller today. When the RS-232 connection from the Da-Lite screen controller is attached to my customer's NI-4100 I get no feedback from the controller and commands sent from the Netlinx to the screen controller are ignored. I don't see any lights flashing on the NI-4100 other then the TX light when my commands are sent. I've tried nulling the cable etc. My customer has the RS-232 wall controller from Da-Lite as well and that works great.
The strange thing is that I can take the cable running to the Da-Lite controller from the Netlinx, remove it from the NI-4100 and attach it to my laptop's serial port and control the screen just fine using a terminal program. I get full feedback from the screen as it goes up and down. I can then attach a cable from my laptop to the Netlinx port that the screen controller should be connected to and, without changing any settings on the laptop or the netlinx, communicate bi-directionally between the laptop and the NI-4100. I've also tried this with other ports on the NI-4100 which I know are working fine and have the same port settings.
This leads me to believe that all the ports are working fine. For some reason however the NI-4100 will not accept RS-232 directly from the Da-Lite controller and the Da-Lite will not respond to commands from the NI-4100. Has anyone dealt with this before? I've tried both RS-232 ports on the Da-Lite controller and have had the same results with both. Again, we've got a RS-232 wall control for the unit and it works great . . . in both ports.
Thanks,
R
The strange thing is that I can take the cable running to the Da-Lite controller from the Netlinx, remove it from the NI-4100 and attach it to my laptop's serial port and control the screen just fine using a terminal program. I get full feedback from the screen as it goes up and down. I can then attach a cable from my laptop to the Netlinx port that the screen controller should be connected to and, without changing any settings on the laptop or the netlinx, communicate bi-directionally between the laptop and the NI-4100. I've also tried this with other ports on the NI-4100 which I know are working fine and have the same port settings.
This leads me to believe that all the ports are working fine. For some reason however the NI-4100 will not accept RS-232 directly from the Da-Lite controller and the Da-Lite will not respond to commands from the NI-4100. Has anyone dealt with this before? I've tried both RS-232 ports on the Da-Lite controller and have had the same results with both. Again, we've got a RS-232 wall control for the unit and it works great . . . in both ports.
Thanks,
R
0
Comments
http://amxforums.com/showthread.php?t=4085
Thank you for that link. I will continue reading Jeff's comments.
R
Yes it does. And you are right, the PC does send one by default. I sent the working up and down commands from the PC to the AMX system via a serial connection and watched the incoming data in Netlinx Studio just to be sure I was sending the same thing the PC was.
The lack of any feedback or error messages from the screen is what bothers me the most. When it's going up and down it blasts out status messages. The computer gets them fine . . . the AMX unit doesn't see them.
I really wish that they'd just used relays instead of RS-232 . . . I've never had a problem with that method. I'll call Da-Lite in the morning however I think I already know what their "solution" is going to be.
R
My $0.02, for what it's worth.
Although I checked and the Data_event String: handler will also do this for you.
Sure. Here's the button_event block that fires code off to the screen controller:
[php]
BUTTON_EVENT[vdvTp,nScreenButtons]
{
push:
{
switch(button.input.channel)
{
case 1:
{
send_string dvScreen,"'# 1 SE RE UP',13,10";
}
case 2:
{
send_string dvScreen,"'# 1 SE RE DN',13,10";
}
}
}
}
[/php]
R
No, no buffer is being used. I will try to send the RXON command to the port when it comes on-line. Also the only DATA_EVENT listener I'm using is "ONLINE" so the port's not getting RXON that way. It is able to listen to data sent by the laptop just fine however with the RX LED blinking as data comes in.
R
Sadly no. The ports I've tried are all on the NI-4100 itself.
R
I like to use the devices from http://www.easyadapters.com/index.php
I like that website too.
No, none of the other pins are connected. Our installer used those DB-9 connectors where you crimp the pins on the wires and then shove the pins into the housing. There're only three pins in there. The screen controller on the other end of the cable only has three pheonix connectors for serial communication.
I have noticed that when the DB-9 connector is first inserted into the Netlinx port that the RX LED on the Netlinx will flash once. Does that mean anything to anyone? It seems like I've seen that before on the few occasions where I've actually watched the front of a powered-up Netlinx box while people are plugging things into it's serial ports.
R
Some of the little inline null modem adapters may short out some combination of pins 1, 4, and 6 and this can cause problems. Had a situation the other day with a Polycom codec which wouldn't work properly with the null modem supplied with the Polycom plugged into the AMX DB9 but plugging the adapter into the Polycom and everything communicated properly.
Also, not all serial ports are created equal. There is a pretty wide range of what is considered acceptable for signal voltage. From what I can tell, AMX ports typically have a pretty high voltage (goes from about -9vdc to about 9vdc) from pin 3 to pin 5 so I doubt that a low voltage signal is your problem.
Some terminal programs send characters out to the serial port as they are typed which would result in a string with a lot of time in between serial bytes. You might try sending your string out in one byte parcels to see if the Da Lite likes that any better. I doubt this is the problem, but if there is no other cause found, it might be worth 30 seconds or so to test.
Finally, how long is the cable run?
I'm assuming that the port you are using is properly configured (looks like typical 9600,8,N,1 in the DaLite literature). Have you queried the port with the 'GET BAUD' command to see what it's set at? You mention that you have neither a buffer set up nor a string handler in the data_event. Might as well set it up so you can at least look at the return strings from the DaLite when you get it working. You mention that communications between the PC and the AMX are good, but I don't know how you can tell if you're not looking at the strings that the AMX is receiving from the PC. Under some circumstances, it's possible to get a receive light to flash on your AMX even though the port is not configured correctly.
Looks like the DaLite controller has a terminal block rather than a DB9 connector so you might want to verify the wiring is proper. But, if you unplug the cable from your AMX, where it doesn't work, and plug it into your PC and it does work, that seems to indicate that the cable should be connected properly.
So, this is a mystery as from what you are describing, it should be working.
I've seen stray characters pop up in a receive buffer when a connection is first made. The transmit pin on a serial port typically idles with a negative voltage (from -5 to -15 vdc). The transmit from your Da Lite (pin # 2 on the AMX end) probably has a negative idle voltage and when you plug it into the AMX the AMX sees a voltage change from 0 to -5vdc(or something) and interprets that as a serial string. Of course, it's nonsense. That's something else you can check, by the way. On your cable from the Da Lite you should have a negative voltage from pin 2 to pin 5 and no other voltage. Your AMX provides about -9vdc on it's transmit pin , pin # 3.
I think that the RS232 "standard" is for +/-12vdc but:
I just measured a port on a NI700 as -9.4vdc and on an Axcent 3 as -9.8vdc. My laptop (which is a PCMCIA card) has -5.6vdc and a Cres*ron QMRMC has -5.6 vdc also. Those are all open circuit idle voltages so would be a little less when hooked up. According to the standard, acceptable voltage to the other end is from +/-3vdc to +/-15vdc.
My understanding is that the "idle" voltage measured on pin 3 (DTE) is approximately the "mark" and that the "space" is about equal and opposite.
I think the PC was sending a line-feed at the end which is why I added that. You're right however, the protocol doc does not call for it.
Now THIS is interesting. The installer uses those super thin metal null adapters. There's a small chance that there's one on the port and we didn't notice it. I've had that happen before with those things. They look just like the AMX's serial port when they're installed right and you're stuck looking at them head on. The rack the controller is in is very, very deep and located in a tough place which further complicates spotting something like that. I will have them check to see if one of those things is stuck on the port . . . if that's the case then this problem may be solved.
I was using Hyperterminal and it does send characters out as they're typed.
It's super short . . . less then 25 feet I'd say.
I was watching the data being sent from the PC to the AMX using the "Device Notifications" feature in Netlinx Studio.
Yes, it is a mystery. I'm crossing my fingers and hoping that there's one of those tiny null adapters on that port. It's a long shot but stranger things have happened. Thanks everyone for all your help!
R
If you are using HyperTerminal it will not send out a line feed with every carriage return by default. You have to go into properties and then ASCII setup to tell it to append a line feed to the carriage return. Try turning the line feed on with HyperTerminal and see if Da-Lite chokes on it.
Also, if you can see data between your PC and AMX you should be able to see if a known working command from your PC has the line feed or not.
Which brings up the question of how you are able to monitor data between your PC and AMX? If you are not doing an RXON and you?re not using CREATE_BUFFER and you don?t have a STRING: handler in the DATA_EVENT you shouldn?t see anything with in Notifications. AMX Comm ports are disabled for receive by default.
If it?s not the line feed causing the problem, I?m betting it?s the cable. It?s always the freakin? cable.
I don't care for Hyperterminal. There are a lot of terminal programs available that, for my taste, are easier to control and monitor than Hyperterminal. One that I have used a bunch of times to good effect is a freeware thing called Realterm. It allows a lot of control over port configuration and you can send hex characters. Maybe it's not as intuitive as Hyperterminal, but it's not hard to use.
Yeah, the cable is usually the problem, but I still make the 'RXON' mistake more often than I'd like to admit.
The Da-Lite didn't seem mind it. If an invalid command was sent to the Da-Lite it would respond with an error message.
The working command did have the line feed in it and it was most likely added by Hyperterminal. I don't really care for that application either but it was all my boss had on his laptop and it was able to control the screen controller. He had just used it earlier to setup the stops on the screen via RS-232. I think each time he hit the "enter" key Hyperterminal would spit out a CR and LF.
I don't know. My boss disconnected the serial cable to the screen from the end of his laptop's serial adapter. He then plugged his laptop's serial cable into the AMX and sent the same command he had sent previously to the screen. I was watching the device notifications from the Netlinx port he was connected to using my laptop and saw the command trickle in as he typed it. I was then able to use the "Control a Device" tool to send the same command back to my boss' laptop.
In this case I hope it's an un-noticed null adapter!
R
R
Thanks for reporting back and closing the book on the case.