No Strings Returning From Certain Projectors

deepforestgreen

I've got about 50 Mitsubishi projectors on campus, and I've begun a project to have the control systems monitor incoming strings, queue the projector for status, etc. (The rooms were, initially, only set up with simple on/off/source commands before I arrived.) But I've run into an odd problem.

I don't get strings from all of the projectors. I will connect to a room and send "'00vP'$0D" ("Is the projector on?") and get a response ('0' or '1') from some projectors, but not others - even through they are the same model. (XD250u, in this case.) All of them work, and I can send commands through 'Control a Device' to control these projectors in any way with no problems, but some of them just don't return strings when I poll them. I feel like I'm missing something.

EDIT: Forgot to mention - it's control over rs-232 from the controller.

jjames

Couple of things:
1) Verify there is a STRING section within the DATA_EVENT for every projector. I'd imagine that with such a large scale deployment that code is roughly the same (if not identical), but it's worth looking at. Reason: Without a STRING event, the processor does not even process it, i.e. no different than sending an RXOFF to it. (In fact, internally it does!)

2) It could be a hardware problem. If the connections were soldered, the RX maybe have been broken over time with things being moved, or possibly just a bad solder. If you're using pre-made connections - I'd advise against that. Only have the wires needed connected because the master can also act as a 485. If it's serial, you (typically) only need 2, 3 and 5. Pre-mades are bad.

[Deleted User]

Although I am not familiar with your particular make and model, you may want to see if there is a menu option that will enable 232 feedback on your display. While working with a Samsung display (non-US model) today, Samsung support informed me that their devices do not respond with feedback when the wildcard device ID is sent in the command. So, these are at least two things that may apply to your specific device.

As Jeremiah suggested, you could have a physical problem with the 232 cable. I often encounter this one-way communications issue when someone uses a pre-molded 9-pin cable or there is a problem with the receive pin. Can you swap a projector that responds with one that does not and see if the problem follows the device or the cable?

My suggestion would be to contact Mits Support about the issue and they may be able to save you some time.

deepforestgreen

It's got nothing to do with the data_event section of the code. I'm watching for strings int he notification window, and I see them from every device as they come in.

The cables are working in that they allow me to send commands. Is it possible that the Tx part of the serial cable is working, but not the Rx? I've never run into that problem, but I suppose it's possible.

I've looked for an option that enables/disables rs-232. No luck.

jjames

You asked for suggestions - which we gave.

Perhaps a call to Mits is in order since we cannot help.

Good luck!

regallion

First thing I usually do in this instance is break out my laptop and plug directly into the projector, just to eliminate cable and controller.

Then plug laptop into other end of 232 cable. Then check controller.

By this stage it's a process of elimination.

Interestingly enough I've just had to revisit a project yesterday that had two projectors (Sanyos) over 232 and both of them began to behave erratically. Were taking commands but I wasn't getting any feedback. Changed serial ports and bam they worked again. Looks like I had 2 serial ports on the controller go faulty on me! (ye olde capacitor issue I guess).

deepforestgreen

jjames - I'm more than delighted for your feedback. I only responded to help us narrow things down. I'm very glad that people on this forum respond to my questions.

regallion - That's interesting. So, it is possible for the transmitting half of the rs-232 connection to work, but not the receiving part. I didn't know if that could happen, but apparently, it can. I'll try a different port (assuming I have one available) and see what happens.

Thanks, all. If it works, I'll update this for the sake of the curious.

regallion

deepforestgreen wrote: »

regallion - That's interesting. So, it is possible for the transmitting half of the rs-232 connection to work, but not the receiving part.

Yeah - seen this happen on two projects now. Pulled my hair out for hours wondering what the hell had happened then just changed serial port and it started working again. Bizarre thing with last project was it happened with two ports - 2 and 3. Moved to 4 and 5 and they just started working again.

Also note that it seemed sporadic. Sometimes a TX would get lost as well and sometimes an RX would make it back. None of it was consistent until I changed ports.

champ

To confirm if the port rx is working short pins 2 and 3 at the processor then send a string and see if you get echoed strings coming back, if not then it is a faulty serial port. To be sure .. Send_command dvProj, RXON
Next short out pins 2 and 3 on the serial cable at the projector end and see if you get an echoed string back, if not then it is a faulty cable.

Also ... Make sure you are using a serial port and not an IR port in data mode.

deepforestgreen

I just tried three different ports and got nothing, so it's probably the cable. Champ, I like your idea - I'll try it when I have time. In that room, it takes a long time to test things, and it's in use most of the day, today. A bad cable would explain a lot. The funny thing is, this cable was installed about seven years ago, and it must have been bad the entire time.

DHawthorne

deepforestgreen wrote: »

I just tried three different ports and got nothing, so it's probably the cable. Champ, I like your idea - I'll try it when I have time. In that room, it takes a long time to test things, and it's in use most of the day, today. A bad cable would explain a lot. The funny thing is, this cable was installed about seven years ago, and it must have been bad the entire time.

I hear that all the time: "but it worked for so long ..." It means nothing. In fact, if there is a shoddy connection, or a fatigued conductor, it's very likely to fail over time rather than right away. Once in a while, I get to actually see how this plays out. I had a customer who's system was just fine for a very long time, then suddenly something failed (heh, and I'm being vague because I don't remember the details, but it's happened to me more than once). So I traced the problem to a bad wire inside the wall, and it just happened to be one I was able to remove. When pulled, it had clearly been grazed by a nail or screw ... yet it worked initially. It just took some time of the home settling, whatever, for it to wear down to the conductors and short out. I've also, many times, seen wires chewed by rodents of various ilk, from mice to squirrels.

I even once took over a job (and I say that to distance myself from what happened, it wasn't *my* bad install), where the customer complained to me that all his house audio was soft and distorted. I immediately suspected his amp when bad. Sure enough, it was, but just to be thorough, I ran an impedance check on the speaker wires. I didn't like what I saw, so I pulled out a volume control. Turns out the original installer used zip cord to run the speaker lines. All the rooms came off a speaker switch, and each had it's own volume control, which (gasp) were potentiometers. Someone had turned the main volume way up, and all the pots way down. Not only were the pots all black and crispy, but the wires running to them were actually fused together 4' up the wall from each.

So when people tell me wires don't go bad, I just chuckle.

John Nagy

In that same spirit, we've seen many installs where "everything has worked fine for [some period] but now [an item] is doing [a thing wrong]", and investigation shows it wasn't connected, component missing, something that means it never ever really worked, but only recently did anyone notice. That is to say, the situation hasn't changed, the notice of the situation has changed.

The projectors in the instant case may have never all worked the same. It may be a projector internal setting, a defect, or they aren't in fact all the same model after all. If the cable tests turn inconclusive, swap a projector that is reporting with one that isn't, and see if the problem follows the hardware or the location...

There is no more sure test than substitution with known working parts. This test is frequently avoided due to it "being too much work", so many hours or days are lost seeking an easier solution.

C.Houliaras

I have a pair (one male, one female) of DB9 connectors which I just connected pins 2 & 3 together to test serial ports and cables. pull the cable from the controller and test - if you get the string back, the port is good. Then, do the same for the cable while connected to the controller.

Hedberg

Two things mentioned above which will allow RS232 send but not receive:

By default, an AMX RS232 port will not receive. I don't know why, but there you are. In order to get the port to receive you must either create a buffer for the device, include a string handler in a data_event, or issue an 'RXON' command. I periodically rediscover this feature; most recently just this Monday. I think the 'RXON' command may be retained through reboots which can fool the unwary with respect to other ports. I'm thinking of having an 'RXON' tattoo put on my forehead.

Beware of pre-built cables, particularly pre-built null modem cables. Also, beware of those little bitty null modem adapters. AMX RS232 ports are not standard in that they are set up for both RS232 and RS422 at the same time. RS422 receive connection pins are 1 and 6. It so happens that many "properly built" null modem cables short pins 1 and 6 and wire that to pins 4 on the other end effectively shorting the receive pins at the AMX DB9. You can get neither RS422 nor RS232 receive when pins 1 and 6 are shorted together. Also, even if you use a straight 9 conductor cable, there is no guarantee that the equipment at the other end won't do something funny. Therefore a good rule: use only three wires -- 2,3, and 5 (typically). If you need a null, don't put it on your AMX port, put it on the controlled equipment.

jjames

Hedberg wrote: »

By default, an AMX RS232 port will not receive. I don't know why, but there you are.

I remember reading somewhere that the reasoning behind this was there was no need for the port listen for stuff if the STRING section in the DATA_EVENT was not even in code. Basically - if you don't care enough to use it in code, the processor shouldn't care either.

Edit:
Device Firmware v1.13.6 says

Fixed serial port issues on startup when data is being received.
Note: with the introduction of this fix serial ports will no longer process received data unless a RXON command is sent. The master will automatically generate this command if a [DATA_EVENT] for the port is present in the NetLinx program. Using NetLinx studio to send data to the port, or using a PC to send data to the port will no longer work unless the port is first enabled as just described.