PJLink protocol

[Shawn Sagady]

Seems like a thread about this comes up at least once a month, and believe me I have read through almost all of them with no solutions.  

 

Attempting to control Panasonic PT-DX100Us with watchout via TCP String Output.  

 

All projectors have admin and user passwords cleared

PJLink is turned on

 

IP/Subnet are all good.

 

Current behavior on all projectors is if you try to connect to the projector on port 4352 it immediately rejects the connection.  

 

Sending commands via the control port (1024) (ex 00OSH 1$0D) works.... kind of.  First time you send the command nothing happens, 2nd time you send the command it returns an undeliverable error, 3rd time it works.  This is repeatable and consistent.    Sending commands via telnet or other utilities results in expected behavior (instant reaction to first command no errors) its only exhibiting that behavior in watchout.  

 

So ver much up a creek without a paddle at the moment if PJLink refuses to even accept connections and the other control method is being silly with watchout.   

 

Any suggestions are welcome, happy to test and provide any addition information requested.

 

P.S. Currently running watchout V5.5.1

[jfk]

Seems like a thread about this comes up at least once a month, and believe me I have read through almost all of them with no solutions.  

 

Attempting to control Panasonic PT-DX100Us with watchout via TCP String Output.  

 

All projectors have admin and user passwords cleared

PJLink is turned on

 

IP/Subnet are all good.

 

Current behavior on all projectors is if you try to connect to the projector on port 4352 it immediately rejects the connection.  

 

Sending commands via the control port (1024) (ex 00OSH 1$0D) works.... kind of.  First time you send the command nothing happens, 2nd time you send the command it returns an undeliverable error, 3rd time it works.  This is repeatable and consistent.    Sending commands via telnet or other utilities results in expected behavior (instant reaction to first command no errors) its only exhibiting that behavior in watchout.  

 

So ver much up a creek without a paddle at the moment if PJLink refuses to even accept connections and the other control method is being silly with watchout.   

 

Any suggestions are welcome, happy to test and provide any addition information requested.

 

P.S. Currently running watchout V5.5.1

 

 

Has anyone contacted the projector manufacturer's support group for assistance?

External control is an area that 'separates the men from the boys' in professional projectors.

Seems everyone does fine with their own utility interacting with their own projectors.

But companies like Digital Projection have always strived to provide versatile, reliable external control

Caveat Emptor

 

I had my share of fun with a Panasonic (documented above),

but I could get that specific model to work.

It did seem to have trouble with rapid command sequences,

so you have to manually time them out. time consuming pita

 

but telnet sessions mask command timing issues

(there are ways to overcome that, pasting in multiple commands

in MaOS terminal telnet somewhat simulates rapid commands, for example.)

[Shawn Sagady]

I have successfully used watchout with MANY panasonic projectors before, this is a real anomaly for me.  I have not reached out to Panasonic yet since that is often a road of misery.   Wanted to see if anyone with similar experiences here had a solution before I tempt the beast.

[Shawn Sagady]

Sorry combine this with may last post if needed, but just to add in response to JFKs post.

 

The Panasonic functions perfectly (not PJLink but with the Panny command controls) when sending them via telnet in terminal or any other packet sending application.  its is ONLY watchout that has the really weird issue with having to send the command 3 times.

[Mike Fahl]

Best way to troubleshoot this is probably to snoop the Ethernet wire data and compare what WATCHOUT sends with what some other controller sends, to see if there's any difference that can explain the discrepancy. I use Wireshark, which is a free utility.

 

Mike

[bgillette]

There are several reports of something like this happening with Panasonic projectors, the usual way to resolve is switch over to the PJLink protocol.

 

Ive been thinking about what has been reported here over the years, and then looked at some of the forums at other media server and control system manufacturers for similar issues and have some thoughts about why this occurs:

• Watchout doesn't monitor what is happening on the port other than manage the connection, because Watchout is NOT a control system. Mostly this is a good thing, let Watchout be good at what it does. Use other tools when required.
  
• Watchout is built for efficiency and speed...It gets the connection established and sends the command as fast as possible. (Otherwise, we'd be complaining about latency)
  
• Watchout doesn't show the response from the controlled device, however it does provide feedback in the Messages Window if the connection is not successful. 
  
• Watchout simply manages the port connection, and when that is successful, it sends the string in the cue.
  

 

With these points in mind, I believe the problem here lies with the way the Panasonic protocol functions:

 

When TCP port 1024 is established, the Panasonic opens the port and responds with some text:

"NTControl  0/x0d"

Presumably this is because Panasonic defines two methods of connection, 'protect' and 'non-protect' and the Panasonic is letting the controller know which mode it currently is working in because the protocol is different for each mode. 

 

Although this response is documented by Panasonic in the protocol, it does break the typical 'challenge/response' nature of most control protocols. That is, the controlled device should only 'speak after spoken to'.

 

The moment the port is opened, instead of waiting for a command to be sent in, the Panasonic is busy figuring out the status of the projector, and outputting text to the port. This is a response not requested by the controller (Watchout). Watchout ignores this anyway, but it does mean the projector is likely not ready to receive commands when the port is opened.

 

So, given the round-robin nature of the failure mode, documented here and around the web, this is what I think is happening:

 

Watchout attempts to connect to port 1024. Connection is opened successfully.

Panasonic projector responds with "NTCONTROL 0\x0D"...

...Watchout simultaneously sends out the command for the first time which is only partially received by projector because it is 'busy'

No action occurs because command is received by projector as a partial string so it sits in the projector buffer waiting for a proper terminator in order to begin processing...

 

...Connection remains Open

Watchout sends complete command second time.

The projector interprets this as received with bad characters because part of previous command is already partially in buffer.

Command fails with Undeliverable Error, waits for another command...

The projector buffer is now empty because a complete challenge/response cycle has completed...

 

...Connection remains Open

Watchout Sends complete command third time.

Command Completes without an error.

 

My guess is that if you use Wireshark or some other ethernet sniffing tool, you will see an "ERR3" and "ERR5" returned from the Panasonic when the command is sent three times.

 

Things to try:

1) Prepend and/or append your command with a padding of a few $OD 's to flush the projector command buffer and give the Panasonic some time to prepare for receiving commands.

 

2) Use TWO cues, separated by .5 seconds (try varying this)

First Cue, Open port send one or more $0D strings 

Second Cue, send actual shutter command

 

Bill Gillette

[Mike Fahl]

That would be a particularly crummy implementation of TCP which just throws away data when not "ready". But I wouldn't be surprised if Bill is right (he typically knows what he's talking about ;-). Bill's suggestions of sending two cues, the first with jusy a $OD anf the second with the real command, spaced apart by a second or so, should tell. The first command will open the connection and send  a (hopefully) innocent Carriage Return character. The delay will let the projector "wake up" and come to its senses. The second should then execute the desired command.

 

After opening a TCP connection, WATCHOUT will keep it open for a while (about a minute if memory serves me), in case new commands come along to the same connection. After a timeout with no further data being sent, WATCHOUT will close the connection.

 

Mike

[RobBergenstock]

Yep, according to the DZ-110XE manual pages 119-120, you have been using RS232 rather than PJ-Link since you mention 00pon for power on, and 00osh:1 for shutter execute. As I said earlier, most times it is syntax error on the user part. For example, I don't know what the 00 is before pon, and also before osh:1 (Note it is the letter o, not numeral 0, in the command osh). According to the Basic Format given on page 119, it should be - 02ZZ;PON03$0D (read as: zero 3ZZ semi-colon;capital PON with letter O, not number 0 followed by zero 3 then Watchout's requirement for the carriage return $0D as in zero D) but since the start and end bytes are hex codes and output from Watchout requires that hex be preceded with a $ sign, I think it should actually be - $02ZZ;PON$03$0D Some serials are case sensitive, so I've used capitals where so given in the manual. The only doubt I have in the above is the Projector ID syntax. I have used the string ZZ to identify ALL projectors. I could be wrong (and without a projector to test, I'm only guessing). For shutter control, try - 02ZZ;OSH:103$0D (where value 1 is for shutter execute, and value 0 is for shutter end (I presume on and off, respectively.) or $02ZZ;OSH:1$03$0D Note: No command can be sent or received for 60 secs when the projector lamps have just started. As an after-thought, perhaps the PJLink protocol is easier to use as the PJLink Specification 100.pdf document gives clear examples of the syntax to use for every command.

 

Hello,

 

Why can no commands be sent or received within 60 seconds of the lamp starting? I am attempting to use a series of shutter cues, and the command will not send/receive within 60 seconds of the previous command being executed (whether it is going from closed to open, or open to closed, the result is the same). When I interface with PJLink I am able to open and close the shutter as frequently as I like. In the past, when I've run serial commands out of Watchout, I have also been able to open and close the shutter as frequently as I like. Is this 60-second wait time just something Watchout won't allow over TCP? Is there anyway around it while still using TCP? Any help is appreciated!

 

Thanks,

Rob

[Thomas Leong]

If I recall correctly, the "Note: No command can be sent or received for 60 secs when the projector lamps have just started." is from the Panasonic manual, therefore a projector manufacturer limitation, not a Watchout limitation.

 

Re unable to "send/receive within 60 seconds of the previous command being executed", I would not have a clue as I don't have Panny. Perhaps someone else who has one can enlighten here.

 

Thomas Leong

[Walter]

Hi Rob,

 

I have had no issues in the recent past with repetitive shutter commands to panasonic projectors. Can open and close as many times and as fast as I like from watchout. So issue must be caused by something else?