Sending a Data String output to external equipment.

[Vollmers]

Hi 

 

I'm trying to do something, which I'm not sure will be possible. We have a graphic platform from Vizrt, which can be controlled in a lot of ways. 

I want to create a String Cue, with this syntax "SendSingleCmd localhost, "RENDERER*MAIN_LAYER*STAGE CONTINUE", 0" 

You normally communicate with the Vizrt program on port 6100, and as TCP. I'v tried a lot of different ways of writng the syntax, but keep getting the same reply:

"Warning: Failed delivering data". I'm sure there's a simple and logical explanation to this. Any ideas??     

 

Cheers Christian

 

[Mike Fahl]

That generally means there's no one listening to that TCP port on that IP address. Try connecting to it using TELNET instead to make sure you can connect to it and send commands as expected.

 

Mike

[Vollmers]

Well, actually there is, because I can control the external machine, from the same machine I have the Production installed on, It is, though, from another application. I can monitor every single incoming command on the external machine. 

When I send the same command from Watchout, that works for the other application, I can't see anything. So my first guess was, that I was doing something wrong in Watchout. One of the things I'm uncertain about, is the last part of the syntax, regarding Watchout. I did add the "$0D" digits, according to your description. But to be honest, I'm not really sure what this syntax does, and if I  need to change it to something else. 

 

/Chris

[Mike Fahl]

If you have one program that CAN talk to the device successfully, and you don't have accurate docs as to what youre supposed to send, you can always snoop the wire to see what the successful program sends, and then mimic that. But of course having proper docs that shows exactly what data to send is preferable (including "framing" such as a CR at the end of the line, or whatever is expected).

 

Mike

[Vollmers]

Well, I do have the documentation for the other application, and the syntax I send is correct. What I'm note sure of, is if the way I do it from Watchout is correct?? I create a new String output, define it with the corresponding IP adress and port number for the recieving machine. Normally it is done by TCP. I drag the string output, to where I want it to start on the timeline, open it, and write the syntax I know works, and end it with "$0D", as refferred to in the Watchout manual. So as far as I know, the procedure is correct. But obviously it's not, since it doesn't work. The question is maybe more of a general nature: Is it possible to control any other system, if you know it can recieve an external command? 

 

Cheers Christian

[jfk]

Well, I do have the documentation for the other application, and the syntax I send is correct. What I'm note sure of, is if the way I do it from Watchout is correct?? I create a new String output, define it with the corresponding IP adress and port number for the recieving machine. Normally it is done by TCP. I drag the string output, to where I want it to start on the timeline, open it, and write the syntax I know works, and end it with "$0D", as refferred to in the Watchout manual. So as far as I know, the procedure is correct. But obviously it's not, since it doesn't work.

The question is maybe more of a general nature: Is it possible to control any other system, if you know it can recieve an external command? 

 

Cheers Christian

 

Of course it is possible to control any system that accepts a TCP/IP or UDP command.

 

You still have not done what was initially suggested.

 

"Well, actually there is, because I can control the external machine, from the same machine I have the Production installed on, It is, though, from another application."

 

That does not reveal anything different, as you can not be certain

exactly what that app is sending or how it is connecting.

 

If you do the same with TelNet, then you clearly know the connection parameters

and the strings sent. I believe that is why  Mike suggested snooping the packets from that app.

Bet TelNet will fail same as WATCHOUT when you run that test.

And when it does, work with the vendor using TelNet (not WATCHOUT) to identify what is astray.

[Vollmers]

Thanks for the valuable inputs    It works know, and then again, it doesn't. I discovered that it seems like Watchout buffers the syntax line, but don't send it. When I open the element in "Output" and press OK, then it sends the command, and everything works. Is there some sort of port or timeout setting for the data connection, that needs to be altered?? Or maybe something else I forgot??   

 

Cheers Chris

[Mike Fahl]

No. Data is sent right away. You should be able to confirm this by using any app that can receive and act on data arriving on a TCP port.

 

For instance, you could set up one WATCHOUT prod to talk to another by enabling TCP control on the 2nd), and then send prod PC protocol commands to it. It should respond instantly.

 

My guess is that your framing is incorrect. What should the command line be terminated with? Perhaps there are more framing characters needed before/after the command string. You mention CR above ($0D). Do you know this for a fact?

 

If the framing is indeed something else, that would explain why it doesn't work when you just append a CR to the command string. Again, please try sending the command from a TELNET client to the device, to see if that works as desired. If it does, WATCHOUT should work the same way. If it doesn't, contact the manufacturer of the controlled device and ask them why. Using TELNET as a client would make it easy for them to repeat your test, and is totally independent of WATCHOUT.

 

 

Mike