Jump to content

ip control from watchout


Tyskern

Recommended Posts

Hi all.

 

I've been trying to control my Barco RLM-W12's via IP from Watchout.

Creating an output, using port 43680, I can make triggers to power on, open/close shutter etc.

At first glance this seems to work fine. Projectors respond fine and does what its told.

However, it stops working, and I get error messages stating that command was not sent.

 

I've been trying to find a.. regularity of it, and so far I can say that if I wait for about 1 minute without sending a string to projector, then it will stop responding.

I will then also loose connection with the W12 from Barco's Projector Toolkit.

If I then delete the projector from Toolkit, add it via scan, I will regain control. Then I can also switch back to Watchout and IP strings will work again..

 

If I would send a string every, say 45 seconds, I can keep going forever (it seems..), but thats not going to be done in reality.

This is plugged directly from laptop to projector, no switches in between.

 

I don't know if this is a barco issue or a watchout issue, or a bit of both maybe. Do I need to setup the network in some special way ? 

 

Does anyone have experience with this? or share a similar problem? and hopefully a solution?

 

Kind regards

Torbjørn Ljunggren

Link to comment
Share on other sites

According to Watchout 5 manual, page 206 -

"When using the TCP protocol, WATCHOUT will open the connection (if not already open), send the data packet, and close the connection after about a minute of inactivity".

 

Seems like you need to continuously poll the connection to keep it open. Someone more knowledgeable may be able to chip in to suggest ways of keeping the connection open...eg. UDP?, a router or switcher in between?

Link to comment
Share on other sites

I just did a very basic test sending 'run' command from one WO pc to another WO pc after a 1 minute lapse. Works everytime. Though the WO manual says WO closes the tcp port after about 1 minute if there is inactivity, the next command sent after a minute works.

 

I'd say check with Barco that the projector continues to listen to the port rather than closes the port.

Link to comment
Share on other sites

  • Dataton Partner

Again; in my experience this is not a WO issue. I use ip control of projectors all the time. (Power and shutter mainly). Works flawless each and every time on i.e panasonic 21k, 110, 6710 and Barco hdx, hdf, flm series. And of course encore / screenpro / several matrices. I do have encountered issues with for instance rlm series. Solved it by correcting economy network settings.

Link to comment
Share on other sites

Hi all. Thanks for the input. 

I'm aware of the Economy mode, which is set to OFF, or it won't use the network port at all.

And this.. 'timeout-issue' occurs even when Toolkit is not running. So that should mean only one connection?

Still scratching my beard going hmmm.

 

Interesting this about closing the network connection Thomas, I'll check with Barco. Timing looks to close for a coincidence...
I'll go back and triple check everything, + trying to send the string from i.e. light desk. Just to try to narrow it down.
Link to comment
Share on other sites

Could also be a gremlin from a source you would never guess to be the cause, as happened here with Adobe products caused by a plugin extension to the Chrome browser -

https://forums.creativecow.net/readpost/2/1063516

 

So you'd have to put on your thinking cap, and/or perhaps uninstall/disable anything you do not need for the connection in your WO PC. Got to be one by one in order to identify the gremlin.

Link to comment
Share on other sites

Hi Torbjørn, as Jonas mentioned Barco RLM-series projectors have a limit of two simultaneous, open TCP connections.


This is a LAN chipset limitation.


 


When more than two TCP connections are opened to the projector, the third attempted connection will be refused by the RLM.


In Watchout, this results in the connection error message you see.


 


 

If you are using a secondary control application, such as the Barco Projector Toolset simultaneously, this may eventually cause your recurring and seemingly random issue.  Here is why this occurs with the combination of RLM-projector and Watchout: 


 


By using the Wireshark analysis tool and some previous knowledge gained here on the excellent Dataton Forum, I have observed that Watchout will close the open TCP port at exactly 60-seconds after the last command is transmitted from Watchout to the RLM.  The next time a command is sent, Watchout re-establishes the connection successfully, if there are less than two connections to the projector.


 


Mostly I think this 60-second port hold is a good idea and I would guess is used for housekeeping purposes due to the random-access nature of a timeline based tool such as Watchout.  IE Watchout cannot predict when and where a timeline might jump to and is always trying to ensure every command gets sent instantly and does not want to keep a port open forever, so it is closed after 60-seconds of idle time.


 


The RLM will maintain a TCP connection until power-cycled, it will not itself close the TCP port unless powered-down, as best I can tell.


This behaviour of the RLM projector is correct, in my opinion, because the projector operates as a client/server model, so the RLM expects the controlling device (Watchout) to have good behaviour and manage the port state as it sees fit.


 


A note for Mike Fahl, I do notice when a TCP port is closed by Watchout, Wireshark shows it as a port ‘RST' (reset). I am not fully knowledgeable on this, but an RST appears to be a somewhat non-standard way to close the port. Terminal applications I have available to me  (I tried MS Hyperterminal, PuTTy, Crestron Viewport and the Apple command-line Telnet client) will all maintain the TCP connection under normal circumstances until closed. When the socket is closed by the terminal Wireshark will show a disconnect as a "FIN,ACK" exchange and seems happy. It is only with Watchout the RST occurs. I am not certain, or if this is bad behaviour.


 


In any case, there cannot be more than two simultaneous TCP connections to the RLM.


 


In my testing, I have sent lots commands simultaneously by making numerous calls by creating several looping Aux Timelines, and although I could get the projector to buffer commands into oblivion, I could not get the error message unless I opened the 43680 port from another application or device such as Toolset.


 


The best solution I can suggest is to avoid running Toolset or accessing the projectors at the same time as Watchout.

Link to comment
Share on other sites

  • 5 months later...

Hi all and thanks for the insight.

I've been away from the RLM's for a while, but back now.. 

 

I hear you on the 'don't use two connections at the same time'. And I don't do that, but the response stills stops after 1 minute.

So the timeout issue occurs even on only one connection. 

To me it seems a bit inconsistent as well. sometimes it can work also after 1m 20sec. I'm starting to lean on the idea that ip control and RLMs are not a good match. Better solved on the hdx-series I suppose..

Anyone know of another little app where I could send ip-strings from, just to se if the problem occurs also on other software?

 

I've set up a system now that seems to work, a dmx value translated into a RS232 string. via a device from resonse-box.

Not as convenient.. but more reliable.

Link to comment
Share on other sites

 

A note for Mike Fahl, I do notice when a TCP port is closed by Watchout, Wireshark shows it as a port ‘RST' (reset). I am not fully knowledgeable on this, but an RST appears to be a somewhat non-standard way to close the port. Terminal applications I have available to me  (I tried MS Hyperterminal, PuTTy, Crestron Viewport and the Apple command-line Telnet client) will all maintain the TCP connection under normal circumstances until closed. When the socket is closed by the terminal Wireshark will show a disconnect as a "FIN,ACK" exchange and seems happy. It is only with Watchout the RST occurs. I am not certain, or if this is bad behaviour.

 

 

Many thanks for your valuable insights, Bill, as always! There's a difference in how WATCHOUT closes the TCP connection compared to most standard tools (such as telnet). A TCP socket can be closed in two ways; gracefully and forced. When closed gracefully, the closing app first closes its sending end, and then awaits the other end to recognize this and close its end. Then the connection is terminated. In between these to close operations, the app that first closes its connection may still receive data from the other end, until the other end also closes its end and acknowledges that. This procedure is to guarantee no loss of data on the "return" channel from the initial closing end's point of view. But since WATCHOUT doesn't care about data being sent from the other end, there's no need to wait for it. Hence the slightly less "graceful" forced close behavior.

 

Mike

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...