[SRT Mike]

I know there are a lot of threads on this, but I searched them all and can't find the solution.

I have an LC-40 with the OSP-5000 control. I have a RocketPort (just a board with a lot of COM ports) connected to the PC, which runs Windows 98. I am using NCNET lite to transfer the program.

I made up the special serial cable according to instructions I read online. Bit parameter 1 is set to 00011011 and parameter 12 is set to 00100010 (some suggested the left most bit of parameter 12 should be 1, but when I enter a 1 it always changes it back to 0).

The baud rate is set to 4800, even parity, 7 data bits, 2 stop bits.

I am able to send programs from the machine to the PC with no problem - it works every time. I do this by going to the PIP menu, pressing the PUNCH key, then the command I use is "PUNCH ABC, CN0:" and it works.

When I try to send files to the control from my PC, it gives an error about 50% of the time, and when it sends it correctly, the file is either blank after the file name, or it contains some error codes the NCNET program sends, or it will have the complete program, but every 10 or 12 lines there will be several characters or a whole line missing.

I have tried changing all the settings in the NCNET program. If I adjust the # of stop bits, I get parity errors on the control. I have tried changing the flow control from hardware, software, none, both in NCNET but it always seems to do the same thing.

If I try to change the baud rate in the control (and on the PC) from 4800 to 2400 or 9600, I can't even send from the control to the PC - the file is all just garbled... but at 4800 baud it works every time, never a problem.

But I can't seem to send any files from PC to OSP5000.

I type "READ CN0:" and hit enter
If I don't get an error, then it will create a file called A.MIN, but when I look at this file, it will either just be the filename ($FILENAME.MIN%) and then blank after, or it will be the program, but have characters missing in various points or even a whole line or two missing.

Any clues?

Driving me nuts!

Thanks

[Algirdas]

First of all. Please, take in mind it will not be ein zvei and ready. It will take time.You have communication working, fortunately, it makes the task much easier.
I made up the special serial cable according to instructions I read online
post it's diagram here. Take into consideration, please, the fact, that communication works as a complex of wiring, connecting and parameter settings. There are many combinations working. Do not mix something from one to another.
Bit parameter 1 is set to 00011011 and parameter 12 is set to 00100010
Do You think, that it is all the same for every control? OK, lets check, what it means:
NC optional parameter (bit) parameter#1:
bit 0 = 1 tape code. for ISO, must be =1.
bit 1 = 1 recognize tape code automatically. mus be =1 for adjustments at least
bit 2 = 0 TV check. 0 is correct - no TV check.
bit 3 = 1 tape delimiting code set to ISO. correct
bit 4 = 1 verifies tape during reading. Are You verifying? I would suggest 0 for adjustments and to leave without verifying for ever.
bit 5 = 0 rewinds tape. 0 is correct- no rewind.
bit 6 = 0 handles special code as an alarm. =0 this bit, no alarm while special code is correct.
bit 7 = 0 does not store special code. same as above (bit 6) =0 is correct.
and parameter 12 is set to 00100010
Let's see, what it is:
bit 0 = 0
bit 1 = 1
bit 2 = 0 file name output for tape punch out. "0" is for output. Correct
bit 3 = 0 end of record code for tape punch operation in ISO code. I would recommend =1 to have only LF
bit 4 = 0 code used for tape feed for tape punch operation. =0 is correct: null
bit 5 = 1 specifies whether tape feed portion is punched. =0 is better: not punched
bit 6 = 0 communication link is reset by pressingg NC reset button. does have no influence
bit 7 = 0
or a whole line missing
hand shaking problem, most likely. Is Your PC communication program using hardware handshake?
it's good to have two stop bits on OSP side.
If I try to change the baud rate in the control
Cable length?
If baudrate 9600 doesn't works, You need to see the serious problem.

[underthetire]

OK, this can be frustrating for sure. "if" I remember correctly, and it been a while on the 5000, after you change baud rates on that control, you need to press the backup softkey then cycle the control power. Keep in mind it's been a long time for me on that control, so i'm going off a very fuzzy memory.

[OkumaWiz]

Underthetire is on the money, but even Okuma doesn't tell you that when you backup and cycle the power, be sure to turn off the breaker for at least 30 seconds or the RS board doesn't properly reset to the new parameters.

[OkumaWiz]

Based on your description, you are having a handshaking problem. Turn on software handshaking (XON/XOFF) and make sure it is matching on the PC side.

After receiving the file name, the Okuma will "XOFF" to create the file in memory and then "XON" for another 256 characters. Then it will "XOFF" again to save the data, and "XON" for another gulp of info. This repeats until it sees the file delimiter.

Clues: If getting garbage characters, baud rate is not matching.

If getting chunks of good data, but missing sections, Handshaking is not working.

If getting no data out or in, cable is bad.

Always try punching data first. PC's are better at receiving and will get you a good file with good format to send back to the Okuma.

Best regards,

[Superman]

One thing that has not been stated is that the PUNCH and READ settings are independant ( they have seperate settings )

You've got the PUNCH settings down pat, now find your READ settings and adjust them ( they should be very similar ), the PC transfer software may also have a similar config that sending and receiving are also seperate settings.

If you have a program like below

$FILENAME.MIN%
(TEST FILE )
M30
%

When <PIP> <READ> CN0: <WRITE>
the file should be downloaded into the control as FILENAME.MIN
When <PIP> <READ> CN0:, <WRITE>
the file should be downloaded into the control as A.MIN
When <PIP> <READ> CN0:,ABC <WRITE>
the file should be downloaded into the control as ABC.MIN

MIN is a default extention and is not required, the comma after CN0: is a rename operation and if no name is specified after that comma then A is the name given

[MCR-B II]

Hi everyone

We have this ports on lathe machine. We want to communicate with serial
port. It is not RS232C (female). Serial on picture is male.

How to communicate ?. Is it same with RS232C procedure ?.

[rotec]

I know there are a lot of threads on this, but I searched them all and can't find the solution.

I have an LC-40 with the OSP-5000 control. I have a RocketPort (just a board with a lot of COM ports) connected to the PC, which runs Windows 98. I am using NCNET lite to transfer the program.

I made up the special serial cable according to instructions I read online. Bit parameter 1 is set to 00011011 and parameter 12 is set to 00100010 (some suggested the left most bit of parameter 12 should be 1, but when I enter a 1 it always changes it back to 0).

The baud rate is set to 4800, even parity, 7 data bits, 2 stop bits.

I am able to send programs from the machine to the PC with no problem - it works every time. I do this by going to the PIP menu, pressing the PUNCH key, then the command I use is "PUNCH ABC, CN0:" and it works.

When I try to send files to the control from my PC, it gives an error about 50% of the time, and when it sends it correctly, the file is either blank after the file name, or it contains some error codes the NCNET program sends, or it will have the complete program, but every 10 or 12 lines there will be several characters or a whole line missing.

I have tried changing all the settings in the NCNET program. If I adjust the # of stop bits, I get parity errors on the control. I have tried changing the flow control from hardware, software, none, both in NCNET but it always seems to do the same thing.

If I try to change the baud rate in the control (and on the PC) from 4800 to 2400 or 9600, I can't even send from the control to the PC - the file is all just garbled... but at 4800 baud it works every time, never a problem.

But I can't seem to send any files from PC to OSP5000.

I type "READ CN0:" and hit enter
If I don't get an error, then it will create a file called A.MIN, but when I look at this file, it will either just be the filename ($FILENAME.MIN%) and then blank after, or it will be the program, but have characters missing in various points or even a whole line or two missing.

Any clues?

Driving me nuts!

Thanks

Im digging up an old thread here I know, but Im having a similar issue with my very old green screen OSP5000. Did you resolve this if yes what did you find? Do you use a BTR?
My machine has a BTR, that used to work fine, now I cant send.

[Algirdas]

There are many simillar points between regular RS232 and communication with BTR.
"Hercules" is a Windows application very helpfull for communication diagnostic and adjustments.

[rotec]

With the LB15 all fixed, my next task is to tackle the LS30N coms issue. It's an early 5000 green screen and I'm told it can't use the serial port even though it has one. This is why it has a BTR. is this true?
I have your settings from an earlier thread I'll start there.

[Algirdas]

is this true?

Only in case if it's damaged, which also is not likely. Okuma RS232 interface is very resistant.
check if DB-25 is wired.

[rotec]

Only in case if it's damaged, which also is not likely. Okuma RS232 interface is very resistant.
check if DB-25 is wired.

Hmmmm well my 5000 green screen 100% does have a wired DB 25pin port on the machine (same as the LB15) and right next to the DB25 there is also a round plug and behind the round plug the BTR is wired into.
So do you think the reason the BTR was used was because back in the day they did not know how to use the serial port?

I recall someone once telling me that the very early OSP 5000 did not have a functioning serial port, thus the BTR. But this could be wrong.

[rotec]

FYI My OSP 5000 green screen lathe is year 1981

[rotec]

Only in case if it's damaged, which also is not likely. Okuma RS232 interface is very resistant.
check if DB-25 is wired.

Algirdas please take a look at my video below. Saves me typing 1000 words!
The original DB25 is wired but it has never been used. The machine was fitted with a BTR long before we got the machine, and we used the BTR for many years. Now I have no coms and was wondering can I use the DB25 serial connector rather than the BTR?

https://youtu.be/AeraWEQ9Jls

[Algirdas]

1. Why the BTR was used?
I have no idea. Maybe there are some advantages. Drip feed, for instance.
2. Original TR. Usefull only in case if you need to use paper tapes.
3. Serial port. I would check Read CN0:, and, if doesn't work CN1:

[rotec]

1. Why the BTR was used?
I have no idea. Maybe there are some advantages. Drip feed, for instance.
2. Original TR. Usefull only in case if you need to use paper tapes.
3. Serial port. I would check Read CN0:, and, if doesn't work CN1:

We purchased the machine 1999 from the original owner who purchased it new in 1981. I understand it was one of the first Okuma lathes commissioned in Australia and certainly the first LS30-N. I'm also told that the BTR was installed because they believed these earliest versions of OSP5000 machines could not support serial communication another (conflicting) story is that the techs back that did not understand how the coms worked and so installed a BTR to get around the lack of understanding.

The BTR used to work fine and frankly I have no issues going back to using it, but right now I have no coms, I have spare RS232 boards but none fix the problem. Which leads me to suspect that the BTR is bad thus my idea to try and get the serial port working and dump the BTR.

Lastly why is my send command using PUNCH NAME, PP: rather than CN0 or CN1? What does the "PP" mean?

[Algirdas]

PP:, CN0:, CN1: are port names.
In my understanding, serial communication check is quick and easy. Then you can tell for sure if it's not working.
It's easy to understand, why the supplier sold BTR to client for $$ instead of the serial cable.

[rotec]

PP:, CN0:, CN1: are port names.
In my understanding, serial communication check is quick and easy. Then you can tell for sure if it's not working.
It's easy to understand, why the supplier sold BTR to client for $$ instead of the serial cable.

Then I will set up my parameters and cable for the OSP 5000 and see if have any luck. Do you have any recommendation for the cable wiring config? Same as the LB15 (5000-LG) serial cable?
Also which are the preferred parameter settings
and
Which commands should be used for send and recieve?
Thank you.

[Algirdas]

see #2 and #6 comments on this topic.
Main idea is to understand, what are you doing. Parameter numbers can differ from one instance to another.
See two manuals attached, These are from this forum and contains some useful hints.
page 14 contains a good version of diagram ( "Complete_Serial_Communications #1.pdf" ). If you need DB-9 at the PC end, check with 1st illustration of "RS 232 setup and communication.pdf" ( Fagor )
The cable diagram there is also suitable at some conditions.
Check the DB-9 pinout. The idea is:
Gnd to Gnd ( no variations ) could be named as SGnd
TxD goes to RxD ( no variations )
RxD goes to TxD ( no variations )
RTS goes to CTS ( can be bridged at both ends in between ) and there are some more variations
CTS goes to RTS ( can be bridged at both ends in between ) and there are some more variations
DSR goes to DTR ( can be connected to Gnd at both ends ) and there are some more variations
here is really good detailed description

the communication will start if speed at both ends are set the same. All the rest of settings ensure proper decoding of data and flow control.

[IguSystem]

We purchased the machine 1999 from the original owner who purchased it new in 1981. I understand it was one of the first Okuma lathes commissioned in Australia and certainly the first LS30-N. I'm also told that the BTR was installed because they believed these earliest versions of OSP5000 machines could not support serial communication another (conflicting) story is that the techs back that did not understand how the coms worked and so installed a BTR to get around the lack of understanding.

The BTR used to work fine and frankly I have no issues going back to using it, but right now I have no coms, I have spare RS232 boards but none fix the problem. Which leads me to suspect that the BTR is bad thus my idea to try and get the serial port working and dump the BTR.

Lastly why is my send command using PUNCH NAME, PP: rather than CN0 or CN1? What does the "PP" mean?

Hi, if you use pip, give it a try
PUNCH "NAME", TT:
READ TT:, -> the program comes with A.MIN or a good dnc link program "FILENAME.MIN" (pc file name). Maybe it works too READ TT:"Name"

I have installed about 200-500 Okumas file transfers (1999-2020), but less and less and I don't remember exactly the old ones anymore

End of send is good to add [00] and %

Difficult machine sometimes. If you need help, you can also send email adress what you find igusystem.fi