[kmc5266]

I have an Okuma MC-6VA CNC with a OSP5000M-G Control. I am trying to load and download to the CNC Control thru the RS-232 Serial Port. The programs going to the control from my laptop are losing characters along the way. The programs going to the laptop from the CNC control never lose any characters. I think this means the cable is ok. The slower the baud rate, the fewer characters are dropped but, I still lose 1 or 2 characters at the slowest speed. I need this to be perfect before I can turn to this over to the guys in the shop. My local distributor hasn't been much help.

[gar]

080407-2152 EST USA

What baud rates are you trying?
What is handshake mode?
Is this a drip mode operation?
How long is the RS232 cable?
How is the CNC machine grounded? And the computer?
Are you using a real RS232 port on the computer vs a USB port adapter?
Are FIFOs turned off at the computer?

.

[kmc5266]

I have tried every baud rate from 4800 to 150, the slower the rate the fewer characters are dropped. I have tried hardware,software and no handshake modes. This is not a drip feed op. My cable is 15 ft. long. The machine is grounded to earth with a copper grounding rod. The computer is not grounded. It is a laptop running on battery. I am using the real serial port on the computer. I have the FIFOS turned off.

[lshingleton]

What software are you using for comunication's--easytalk -simco---puncher reader----procom plus?
How old is the labtop your using?

[kmc5266]

I am using a program called DNC4U. It works well with a variety of machines that we have. The laptop is an older Dell Inspiron 3800 with 700 Mhz Pentium III using Windows XP Pro O/S.

[gar]

080408-2010 EST USA

kmc5266:

Here is my suggestion.

Download a trial version of Cimco Edit 5. This relatively easy to set up and extremely reliable. www.cimcosoftware.com .

Setup for 4800 baud to start. I believe you set Okuma for 8 data bits, no parity, and 1 stop bit. If this is the case, then Okuma expects the 8th bit to be even parity and they do the parity check some other place than in the UART. Set your computer UART for 7 data bits, even parity and 1 stop bit.

Have FIFOs disabled.A battery operated laptop run on batteries should not have a grouind path noise problem.

Is there anything you can describe about the lost characters? Is it always lost characters, or sometimes do you gain characters, or is it just that some characters are modified?

.

[kmc5266]

It is always dropped characters. Usually 3 to 5 characters. I have a test program that is the same line repeated 100 times or so. There seems to be a regular pattern to this. 5 or 6 lines of good data, then a few characters dropped then 5 or 6 lines of good data etc. If I slow the baud rate down 150, I can download a 6K program with only 1 or 2 errors. It takes 15 to 20 minutes to do so. then I have send it back to the laptop to compare the 2 files to find the errors. I have never found an error sending to the laptop from the CNC, however.

[lshingleton]

On the software you are using can you put a milli sec pause after the end of block?
keep the baudrate high and install a delay ---easytalk and cimco can do this so i would say somewhere under setting you should be able to do this-50ms should be enough

[gar]

080408-1142 EST USA

kmc5266:

A loss of whole characters and no parity errors, assuming parity is enabled, means a failure to send or receive the character, and is not a communication noise problem. This also means it is not likely the problem is in either the sending or receiving UARTs or the communication cable.

Most likely it is related to handshake and buffer problems. Try sending from one computer to another.

.

[kmc5266]

I tried a delay between blocks with no improvement. I sent a test program between my laptop and another computer. The program went back and forth with no problems. I used the same settings and the same cable, that I used on the Okuma CNC. Do you have any suggestions for the pin configuration on the cable? I am wondering if this could be hampering the handshake process. I agree with you that it is most likely a handshake or buffer issue.

[lshingleton]

At this stage-the last thing i would try is simco editor 4 and if that dont work call maintenance or service and replace the communications board

[Additek]

I had the same problem when sending from PC to Okuma OSP5000 control using NCnet on the PC. Tried everyting. Finally got it fixed by using ms-dos based v24.exe program. No more error since then.
in a DOS box.

[theokumaguy]

Most of these issues relate to the PC side settings for the RS232 port. If you:
Right click on my Computer
Select Properties
Select Hardware Tab
Select Device Manager
Expand Ports (COM & LPT)
Right Click the Com port in question
Select Properties
Select Port Settings Tab
Select Advanced
Turn down your receive buffer

This has fixed the problem on several communication issues I've had with older controls. The receive buffer on the PC fills up and sends the software handshaking stop message, and the "lost" characters are the characters that are transmitted by the machine before the machine has received and processed the "buffer full" message. The dos based communication programs do a similar thing, because the RS232 port acceleration is not used via dos (from my understanding).

[gar]

080715-0542 EST USA

theokumaguy:

For many communication programs the communication parameters are set from within the communication program, except for the UART FIFOs.

My understanding is that kmc5266's problem is lost characters at the Okuma when sending programs to the Okuma.

kmc5266 has proven that the problem does not exist when sending data to another computer.

The problem would seem to be one of the following:

(1) Even though the UART FIFOs are turned off the PC receiving program does not properly handle the handshake signal.

If Cimco software is the receiving program, then from my experience it does not have a handshake problem, and we would eliminate the PC end as the problem, at least relative to software handshake.

(2) Okuma does not send a handshake soon enough, or fails to send the handshake signal. It might be worth while to try the opposite kind of handshake signal (hardware vs software).

(3) Okuma has some sort of internal problem processing data.

A difficult but possible way to sort out this problem is to:

Use a second computer (a DOS computer or some other operating system that does not get in the way of doing the tests) with two serial ports.

Connection of one port to the data to Okuma, and the second port to data from Okuma.

A special program that monitors both ports.

Data from the PC is collected in sequence, and stored in a file for later reference. The received handshake signal is inserted into the file. For the start of a hardware handshake a special code would be inserted. A message of the off time is inserted followed by the start handshake signal. Continue with storing the sent data. This contuinues until the end of the data being sent and then the file is closed.

By analyzing this file in correlation with a file of the data in the Okuma it should be possible to identify the origin of the problem.

.