TI-565T Communication Port capture

I have a TI565t which send a report out communication port 1 using the PRINT statement.

In the past we have had a serial to parrallel convertor and a printer hooked to this port.

I would like to be able to connect a laptop to the port and capture the report as it is sent.

The dip switches on the PLC are set to 300 baud and Xon/Xoff disabled.

What are the remaining communication protocol settings for this port (parity, stop bits, ect). I can not seem to get anything on the plc.

1. I am using a Null modem

2 the "Black Box" serial to parrallel converter is set to 300 7 E.

Does any one have a refference for the communications ports on this PLC?

Hi

The standard TI used for virtually all serial comms ports throughout the range of equipment they had was 7 data bits, 1 stop bit, odd parity.

I remember doing exactly this with Hyperterm linked up to a 565 many many (too many) years ago. Your standard null modem cable should be fine.

Regards

Ken.

The comm ports on the 565 (special function CPU) are for printing ASCII only, not communication.
So I believe you will need a serial cable instead of a null modem cable.

If you need to change any of the dip switch settings, you must stop and restart the processor, the dip switches are only read at startup.

Thanks for the information.

All I want to do is capture the ASCII to a file.

Since the original setup was working. (straight serial cable to black box serial to parallel converter to printer) I am going to try the same setup straight serial cable to laptop. ( I had been using a null modem)

The dipp settings on the black box were for 300 7 E. I'll set the pc serial port the same 7E1 no flow control.

Once I get the data going to the computer I plan on using a couple of Lantronix serial to ethernet converters to pipe the information from our drive room to my office, where I can capture it using something like the old Procomm where I can write a script to automatically open and close the file at the appropriate times.

The pain of it is the reports are only sent once at the end of each 8 hour shift. So after making any changes I have to wait 8 hours for the next report dump to see if it works.

If I were you , I would create another Special Function Program, that prints some type of test report, similar to what your trying to get now. You could then trigger the test print with a "dummy" C, and work out the bugs.

Does your system use the 500 or 505 series bases? If you have the 505 series, you can buy an ethernet card that mounts right into one of your bases. That may give you more options.
Just a thought.

Ken