Hi, I am not totally new to this forum, but have been away for awhile. The RC forums were instrumental a couple of years back in my being able to successfully complete a project with PEP1, TSU9600 and two RFX9600.
As you shall be able to read further on, for the last few days a have been baffled with what essentially boils down to: What is occurring when a ASKII command controlled equipment reacts as expected through Windows Hyper Terminal and has no reaction at all when access through the PEP2/TSU9800 panel and a RFX9600 serial port?
I am using ProntoEditPro2 and have currently updated all the Pronto components to: PEP2.4, TUS9800 panel firmware 7.3.3 and RFX9600 extender firmware 1.4.7.
Problem: While RS232 ASKII commands are sent through Windows HyperTerminal and equipment has been verified to respond correctly , when the same exact command and syntax is inserted into the PEP2 ASCII function command section and downloaded to the panel, the command does blink the correct the RFX9600 extender RS232 serial port led, but the equipment fails to react. As to discard any straight to cross wiring issues between pins 2 & 3, additional iterations of tests are performed with a null modem connector inserted and removed, but to no avail. Subsequent changes and test are made to the ASKII command syntax in the PEP2, by adding \r, \n, etc., and we still get no reaction from the equipment we intend to control. Leaving everything "as is", except for removing the RS232 cable from the extender serial port and connecting it to the PC serial port, the exact same ASKII command is typed and sent through Windows HyperTerminal, with or without \r and the equipment is confirmed to react correctly. We also made conversions of the commands from ASKII to HEX and inserted the commands into PEP2, downloaded them to the panel, but with the same failed results. Thus we have covered and verified to have the correct software and firmware updates, the RS232 cable wiring, baud rate and other serial port parameters, but cannot get the equipment to react when connected to Pronto TSU9800 / RFX9600 combo, but it will invariably react correctly when connected to a PC with the exact same cables, connectors and commands, via Windows HyperTerminal.
In addition we have made tests, tying together pins 4-6 and pins 1-7-8, but still to no avail. The manufacturer's literature (Polycom HDX8000) states that only pins 2,3,and 5 are required. We also connected the RS232 serial port of the RFX9600 to the PC and on Windows Hyper Terminal observed that the command's ASKII characters read exactly the same as was input to PEP2 program, except when we would addition to the command, control characters like \r, which seem to have no effect and to do not reproduce as characters on the Hyper Terminal window. Some test that were performed with commands that had been converted to HEX, when transmitted to the PC and observed through Hyper Terminal, would be shown as the original ASKII characters, but if the HEX converted command contain control characters, then the command would show with the correct ASKII and a few gibberish characters.
I am required to finish this project in the next two or three days, so I am in a dire predicament and have run out options on what to try next, any and all help will be greatly appreciated.

can you give an example of some of the protocol for the polycom?

They are simple non cryptic commands. When I type the following commands in Windows Hyperterminal, the Polycom HDX8000 reacts accordingly and acknowledges by literally echoing back a response on HyperTerminal, except when the command is an inquiry like "get", where the inquired info will be the response. Here are a few examples among its many API commands:

colorbar on (response: colorbar on) and so on;
colobar off, camera near 1, camera far 1, camera near move left, camera near move right, camera near move up, camera near move down, etc.

I am baffled by what is going on, but I have come to think that someone might have the knowledge to make a step by step sequential analysis of what actually happens when I send the ASKII commands through Windows Hyperterminal versus when the TSU9800/RFX9600 components send them, which under the present predicament, apart from confirming that the wiring, electrical signals and communications settings are correct, there must be something that is being omitted, subtracted or added, that is causing the failure. (Apart from equipment malfuntion)

I really appreciate your time and interest in helping me.

Thank You

Can you email a copy of the protocol,

What kind of Flow Control is in use on your COM port when using Hyperterminal? XON/XOFF?

None

Thanks for replying

Yes, but where or how do I attach a file, through the RC mail application. I was able to extract the pages and reduce the file to be attached from 7megs down to 1.5megs, but I am stuck on where to attach it and what is the maximum file size. Thanks

As of today, you cannot attach file to RC mail. Have a quick look @ gopronto's profile and use the email addy there. Do you perhaps have a link where you downloaded the protocol document?

Finally got down to the bottom of what was happening, and will paste the content of my last email with Mark of gopronto:

Eureka! It's finally working! Mark, I am really, really grateful for your time and effort in helping me. There was some irony to what was acctually occuring, as I will explain in a moment, and apparently since I was half asleep when I did many of the test, I was not fully aware that I was omitting a very simple, not necessarly obvious, but crucial step in not always updating the edited command to the data base. If I recall correctly, in PEP1 when I would type a command in the ASKII or the HEX box, that would be it, that was what was going to downloaded. In PEP2, the input box reflects and retains what I typed and even after closing and reopening the program it is still there, but it has to be updated through the conflct resolution window, as to able to substitute the previous command. I am very sorry to have committed this blunder and of having taken your time, when you might have been helping others. Everything eventually turned out as follows:



1. The Polycom API commands can be written literally as plain alphabetical characters as they are published in the manual.

2. The backslash carriage return (\r), has to end the command in the Philips Pronto setup, but is not requied in HyperTerminal.

3. The backslash line feed (\n), is not necessary, but does not effect the command if included.

4. The RS232 connections only require pins 2,3,and 5, in null modem configuration.

5. The Polycom HDX8000 does not require nor provide RS232 flow control.

6. The Polycom manual and thier tech support, recommeded that while connected and sending RS232 commands through the serial port, that a concurrent telnet IP connection be made through defualt port 23, as to be able to monitor on the telnet console what the RFX9600 extender was acctually sending and what the Polycom was responding. I cannot over emphasize how useful this is in confirming if what is not happenig, is do to communications or to not being able to recognize the command. In my case, at times it was both.

But with all this said, it was not untill your last email, that I went diligently back to perform your instructions, and "boom" eveything started working. This lead me to backtrack and reveal my errors. BTW, the syntax that you provided was acknowleged by the Polycom. I don't know if I will be able to return your favor, but I will definitely try to help others as you have help me.

Thanks again!

Rolan,

Glad you are up and running.

A few additional notes (hope you don't mind) as 232 communication is one of the most problematic and error-prone areas of ProntoScript...

1. '\r' is sent automatically by hyperterminal. When you press [Enter], you are sending ASCII 13 (CR - Carriage Return) or '\r'. ASCII 10 (LF - Linefeed) or '\n' may also be sent depending on what Terminal Options you specify. (IIRC, Append Line Feeds to Carriage Returns).

2. Another reason for opening connection to polycom on port 23 could be to overcome any issues you might see from RFX9600. Specifically, when you send() or match() on a serial port in ProntoScript, the receive buffer is cleared if the first parameter of the function call resolves to anything other than null or an empty string (''). By using TCP, you can overcome potential issue of data loss in that you are not receiving data via 232, but rather via TCP/IP. And, of course as you mention, this is a great debugging tool.

I have discussed 232 data corruption issue several times in various threads in this forum over the past 2 years. Unless you are trying to receive unsolicited data from equipment, you may never notice this issue, but it is there.

A search for UART and Lyndel will find relevant info.

Here are 2 links from said search that might be helpful to others as well. They discuss key issues one should be aware of when trying to do 2-way message communication using RS232 and RFX9600 for both synchronous and asynchronous operating modes.

[Link: remotecentral.com]

[Link: remotecentral.com]

Lyndel,
  Why would I mind! I am really grateful of the time and help one is given in these forums. 
   BTW, please correct me if am wrong, but I could not find any person to person (p2p) "professional" tech support through Philips, I tried everything, including calling the Netherlands at different hours of the day, but to no avail. When I finally got through to tech support in the USA, they did not seem to be up to par on the Philips professional products, especially when involving RS232. In my first encounter the support technician told me that I was doing it all wrong! That I had to first capture the commands! So I told him, "OK lead me trough it", which he actually attempted to do and came to the realization of how mistaken he was, and no doubt that anything beyond I/R was foreign to him. As far as the Philips Pronto Professional web site, of which I am a registered member, I could not find much help there either, apart from document downloading, a FAQ section and email support, which I am still awaiting for them to reply. So the bottom line is if it were not for the RC Forums there would be huge void in tech support for the Philips professional products. I am currently seeing adds of Philips Pro products that allude to the input they get from professionals, which they then sustain to incorporate into their products, but I am currently at a lost of where is, and how does one contact Philips Pronto tech support. The irony is, that besides your help, I got more help from New Zealand, then from the USA or the Netherlands. If Philips plans to give support to professionals, maybe they should look and see how AMX, Crestron, Extron and others are doing it, and from there devise a successful strategy. Any guidance and advice will be greatly appreciated.

Thanks again!

Distributors are trained and then they train the installers. Philips does have a training team here in the US. They are based out of Atlanta and do go around to places like AVAD and do training sessions.

If you want pro assistance/help/examples, you are best suited to sign up for Level I/II certification by clicking the ProntoScript icon on top-right of the site:
http://www.pronto.philips.com

Create a user account, do level I/II certification then you can download many more examples as well as tidbits of information such as how Philips builds libraries and the script compression tools/ANT scripts they use to do this.

Thanks Lyndel, I will give this a try and see how it turns out.

I should have mentioned that my criticism was not necessarily directed at the Philips knowledge base, the training, the website or the FAQ, but more so, to the how and whom does one contact for "live person" tech support on specific issues, be it through a phone call, though web chat, or through delayed responses as in these forums. Is the Philips professional tech support phone numbers insider information? The only "live person" support and responses that I was able to get on my recent issues was through my post on these forums. BTW, I do have access to the professional section of the Philips web site, but the email and phone number they have posted, got me no where. I must insist, that it was basically the RC forum responses that got me to solve my issues, of which I am very grateful, thanks to all!