Okuma OSP100E RS232 Bulletin
Reply with Quote070708-1943 EST USA
Ed:
That is a real mess compared to HAAS as I believe you know.
There is considerable information that is lacking in the application bulletin.
First, there are no discussions of why or the effects of certain actions.
For a long time there have been UARTs that internally in the UART generate and process parity. Most systems use this function at both ends.
It appears that Okuma has choosen to generate parity external to the UART. This might be because they want to carry the RS232 received parity bit into their machine memory. Similarly send a parity bit that came from their program memory.
How do I conclude this:
At the CNC stop bits are set to 2, RS232 parity is off (my conclusion from NON, but confirmed by the PC settings), character length 8 bits.
At the PC the settings are 2 stop bits, 7 data bits, and even parity.
Since the computer is set to even parity and 7 data bits this means the 8th bit sent or received is the even parity bit. The two stop bits follow the 8th bit. Since the 8th bit is a data bit at the CNC it is most probably passed into main memory.
This is not a bad idea because it provides more assurance that the transferred data is correct.
What is needed is a statement of what is being done so that one understands the disparity of the settings at the computer and CNC. Normally the general rule is that the UART settings are the same at both the CNC and computer.
There is no discussion of the communication program and its requirements at the computer. Since the procedure to send a file from the CNC to computer includes the sequence --- 5, 6, 7 --- it appears that 5 (punch) does not actually start the send operation, but rather 7 (OK) is the start function. With this sequence you do 5, then walk to the computer and put it in receive mode, walk back to the CNC and push OK to initiate send. If this is the case, then why not put the computer in receive as step 0, and delete step 6, and reduce walking. What useful function does step 7 serve?
If step 5 was the actual initiator and step 6 was still the start receive function, then other means are needed to prevent sending until the receiver is ready to receive. For example an XON from the computer to tell the CNC to start sending. This means that this protocol has to be in the CNC.
There is no discussion on how to change the baud rate at the CNC or its limitations.
There is no discussion on why 2 stop bits instead of 1. One stop bit would improve thruput by about 10%. And at the very slow rate of 4800 baud this would be helpful.
What is the function and purpose of the parameter READY WAITING TIME?
No definition of DC code and handshake protocol.
No discussion of any timeouts, and if any why.
The various parameters need definitions.
When receiving a file at the CNC is there any reason that requires the entered filename at the CNC to be exactly the same as the filename at the computer? I assume the only reason is to avoid confusion. Why does one have to go to that trouble vs just using an O-nuimber or an embedded name in the file following the %? Note, normally communication programs do not embed the computer filename in the data stream sent.
What are the limitations and structure of the entered filename? Is it limited to the DOS 8.3 format? Or is almost anything allowed?
Do the persons developing these systems ever really work on the machines such that they would experience the difficulties of their design?
.
Boy was he wrong 
