Into the frying pan with IP control
McNeill
Posts: 14
I am working on a project that is very fluid. I posted a question earlier looking for an IR file because this thing is changing.
I was going to use RS232 control for a Panasonic PT-DW10000 projector. Cust is a school and wants to control a piece of owner furnished gear that needs Sony 9 pin. I assume the Sony 9 pin will be no big deal but I have not looked at the protocol or anything yet. anyway I need another com port.
First issue is no more hardware budget period.
So assuming that can 9 pin be knocked down the Control System is NI-2100. Only way to free a port is to move the projector to IP control... Never have messed with that and I hate having to cut my teeth under a time constraint. Is there a nice module available to handle all of the under the hood stuff?
I need to get up to Dallas and go thru the classes but am swamped with work for the next 8 months. Any help/direction/advice welcome.... Just need to do basic ON/OFFand Input Select at this point. Can add polling etc... as updates..
Thanks,
Robert
I was going to use RS232 control for a Panasonic PT-DW10000 projector. Cust is a school and wants to control a piece of owner furnished gear that needs Sony 9 pin. I assume the Sony 9 pin will be no big deal but I have not looked at the protocol or anything yet. anyway I need another com port.
First issue is no more hardware budget period.
So assuming that can 9 pin be knocked down the Control System is NI-2100. Only way to free a port is to move the projector to IP control... Never have messed with that and I hate having to cut my teeth under a time constraint. Is there a nice module available to handle all of the under the hood stuff?
I need to get up to Dallas and go thru the classes but am swamped with work for the next 8 months. Any help/direction/advice welcome.... Just need to do basic ON/OFFand Input Select at this point. Can add polling etc... as updates..
Thanks,
Robert
0
Comments
I buy them all the time for between $20 and $40. If the client is changing the scope, then they should understand that all bets are off and this is a change order. However, that bitter pill goes down a little easier if the cost is not too high.
Just a thought.
This was a nice convenient way to make another 2-way port available for an important device.
Hey! Projectors have feelings too! ;P
Usually is is along the lines of "I feel too hot".
I looked at my stock pile and I have 4 AXB-REL8 units but no AXB-232++. I have tendered an offer for a couple.... We will see what happens.. Thanks, I do want to revisit the IP thing some time though...
UPDATE--- I found 3 of the AXB-232++ units on EBAY and decided to snag them, So I will use one in this project and squirrel the others away for future....
Some devices are perfectly happy to leave the connection made all the time. Lutron and Escient are examples of this, but provision needs to be made if an outside circumstance breaks the connection (like a reboot of the controlled device). You could conceivably use an RS-232 module for this type of device, and just run your own routine to keep the connection alive outside the module. Just give it 30 or seconds or so to settle between tries (a mistake ReQuest makes in their module ... the dang things go nuts trying to re-establish the connection until they get through, you can see it in the telnet screen spamming like crazy).
Some devices make the connection, exchange data, then drop it, and you re-establish it each time. The MAX media server is like this, and most web servers if you are connecting HTTP. There is no help for these but get into the control module itself and make your connection each time. If the module wasn't meant for IP and you don't have the source, you are out of luck.
A few are happy enough to stay connected while stuff is going on, but get flaky if the connection is left open with no activity. Denon receivers are like that ... leave them open and alone for 24 hours, you have a dead control port. But if you drop the connection after a reasonable inactivity timeout (like 5 minutes), then re-establish it when needed, they are fine. This type could also probably be run with the RS-232 module if you handle connections outside. In this case, however, you might also want to buffer commands to the port so they aren't lost when the connection is down.
You hit at what I am unsure of because the lack of experience with IP comms, I have none. I understand TCP/IP from a support position and am very familiar with subnetting etc.... I just have never had the opportunity to code IP based stuff in AMX. Deciding if to open the socket and leave it open of manage it to the degree of opening and closing it for every request or command....
From memory it was limiting in what it can do (compared to direct rs232) but simple commands to turn it on/off and switch inputs is pretty easy.
I've controlled a few of these projectors using IP its not that hard.
I'm not sure but check AMX to see if they have a generic PJLINK module which may save you some time. Otherwise I'm sure they will have a duet module.
Probably, your projector will respond to the same protocol that RS232 works with. You will probably just consider the projector as a telnet server and connect up to it with an AMX IP client and it will probably be on port 23. There are very good tech notes that tell you how to do this. Of course, you also have to configure your master and the projector network-wise. As mentioned, you'll probably have to goof with it a little till you figure out what makes the projector happy (keep alive etc)
I've switched to doing as much IP communication as I can. It's just where things seem to be heading towards.
The most common mistake I made early on was trying to maintain a hot connection at all times. (similar to RS-232) In the long haul, I've found that it's best to let the connections die and re-establish only when needed. A lot depends upon how the device behaves. But, when I can, I try to make connections only when something needs to and try to manage the 'listening' instead. That's the one thing you do have pretty good control over.
For example, on data streams that are larger by nature, I try to break them into small chunks and send one chunk at a time. I'll disconnect and reconnect for each chunk. It's obviously a little slower but it does cut down on the errors.
Like most things, once you dive in, the water feels warmer after you splash around a bit. I'd suggest making an effort to do one thing via IP and see it through. You'll come out on the other side very happy with yourself and your efforts. When it's all said and done, there's just not that much difference from RS-232.
Attached is a module I use when TCPIP is a last min change. It actually will manage the whole TCPIP communication side. What Happens is you pass in a virtual device, IPAddress, IP Port into the module. You actually send and receive the messages on the virtual device. So those that do not use IP a lot the virtual device will act like a normal serial device. The module handles the rest!!! Of course this will only work if the RS232 protocol is the same as the TCPIP protocol. If not a module, or code should be written correctly to manage the IP communication. The cool thing is this will work with existing modules and code that was coded for the rs232 device. All you would have to do is change the device address from 5001:1:0 or whatever, to a virtual device address and include the module...
I will give this a whirl....