PDA

View Full Version : Okuma OSP100E RS232 Bulletin



Edster
07-08-2007, 11:30 AM
I was having trouble with the RS232 Communications on my Okuma MCV-4020. This Bulletin helped a lot. There are differences between the settings we normally use and the JIS (Japanese Industrial Standard). I thought I'd post it here if anyone else needs it.

http://www.ewwenterpriseinc.com/files/E100.pdf

gar
07-08-2007, 10:07 PM
070708-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?

.

Jarwalcot
07-08-2007, 10:36 PM
See if this helps... See attached.

gar
07-09-2007, 07:39 AM
070709-0632 EST USA

Jarwalcot:

Really it does not answers my questions.

It is the same old --- do this, do that, and so on --- no definition of functions, effects, or limits.

Why is Okuma hung up on the slow 4800 baud? Etc.

.

Edster
07-09-2007, 09:14 AM
Communications are working great on the Okuma. Gar's Isolator is allowing 19,200Kbps speeds, the max speed of the machine.

It's funny when I was having problems the first thing the tech from Okuma said was the speed is too fast. I explained that I was using an optically isolated cable. He changed the speed to 4800 and said I bet this fixes it. (nuts) Boy was he wrong :)

I don't know why they want a different file name. I'd rather it went off the O word to eliminate confusion. It might have something to do with the eithernet/data server option. Which I ended up getting installed on the machine. Okuma doesn't provide DNC operation in the standard machine configuration. It's a $4k option, the eithernet with data server was $6k. It's a no brainer considering the ultra slow 19,200kbps maximum speed, and the data server bumps up the machines small 512k memory with a hard drive that you can run the program off of. I haven't had a chance to figure it out yet though. The tech that installed it has no idea how it works, so I'm waiting for the application engineer to stop by and test out the tech's work :confused:

I can set the machine up to receive and then go to the office and send the file. I don't have to walk back and forth a bunch of times. If the file name is the same as a file in the control's memory when I get back to the machine it asks if the file should be overwritten, then continues with receiving the file.

I does seem like they are making a simple thing WAAAY more complicated than it shoud be. And a lot slower too :) The bulliten was a little different than my machine was, but it got me closer than anything before.