RS232 DNC input not working

[dingo0722]

I have set all the parameters on the computer and the cnc to the same values 1200 Baud, Even Parity 8 bit data, 1 stop, software flow control. The machine is listening and the computer transmits but nothing is recieved.

I hit the MDI DNC button twice and the machine says waiting. I then send the file using Predator CNC editor but nothing has been recieved.

I use the same rs232 cable for my other machines

Any ideas would be great

[johnohara]

Does the problem travel with the computer and/or cable?

In other words, if you connect the computer and cable to a different machine does it work?

[dingo0722]

So I made another cable based on the Haas pin outs. The one my other machines use has the TX RX crossed. I can now recieve programs from the Hass but cannot transmit to it. Or atleast it does not recieve my signal. I am going to check the cable now and verify the pin

[johnohara]

A null modem cable has more than just the TX/RX pairs crossed. Since there is no modem involved the configuration is considered DTE (data terminal equipment) to DTE. Other pins besides 2 and 3 are used to "handshake" the communication between the devices. Here are some links to help you:

RS232 serial null modem cable wiring and tutorial

Serial Port and Modem Cables

Google: "serial null modem"

What kind of port is it? 9-pin or 25-pin?

~John

[dingo0722]

Im going from a 9computer side to a 25 cnc side. I was able to transmit to the cnc successfully. I am now getting format errors on the CNC which makes me think that the post I am using is not creating the G code in the right format

[dingo0722]

I get error on the CNC side:

251 Program Data Struct error
212 Program integrity error

[dingo0722]

OK I got it running now. Maybe some one can explain this to me, when I load a program via the rs232 I cannot go through the list Prog button, select all and hit recv232. I get a error message. But when I load via a double press of the MDI/DNC it loads and runs the program

[dingo0722]

now I am back to it not working at all. Neither tx or rx

[Ashish B]

Please refer the attachments & check whether the settings match.

Surely, you should get the work done.

Thanks

[Ydna]

Program integrity error (along with RS-232 abort) are the errors I get when I don't have the RS-232 cable hooked up. So that might be a sign of a bad connection somewhere.
Do you have a multimeter lying around? You can try testing the pins from one end to the other on your cable to ensure they are still conducting between them. I have found that different serial cables can vary WILDLY from one another, even if they don't have any markings indicating they were made for a special machine.

I'd suggest making a very brief sample program in order to test the connection (if you haven't been doing it already). Just a few random lines that don't actually do anything will suffice, and it'll load real fast too. You can hammer out the post issues later if there are any.

We only have one Haas machine and one simulator connected via RS-232, but for those machines we use a very simple bridge to complete the connection.
(haas 25 pin) (PC 9 pin)
2--------------2
3--------------3
7--------------5

I cannot tell you if this connection would work in both directions though. I never tried it!
But the alternate jumpered connection won't hurt anything. We have two-way communication between PCs and Fanuc robots using a connection like this...
http://tinyurl.com/23m9scv

When I was originally making the RS-232 adapters for our machines, I tried a few different incarnations and they all worked when downloading from PC to the machine (from the manual, from here on cnczone, and other pinouts too). So I went with the simplest one. I can test out uploading from Haas to PC over the weekend if you haven't figured it out by then. A while back I made a solderless breadboard for testing RS232 adapters, so I can test literally any connection in only a few minutes. But I won't be at the shop until saturday.

[johnohara]

Sorry for the delay, I was working on some other things.

I believe your problem lies in one of two places, the cable (90%) or the port settings (10%).

1. Going from 9-pin to 25-pin can be tricky. Plus it has to be null modem. TX/RX is straightforward, and maybe ground, but the others can be a PITA. If you can find a manufactured cable you are confident in from another machine that would help a lot. 9-25 pin null modem adapters used to be available but are hard to find today. Using a known "good" cable will help you resolve the port settings.

2. I'm surprised it's using "even" parity. I assume we are trying to send a text g-code file to the machine. Using even parity is a way of error checking the bit stream. In the old days, it was common for terminals to use "NO" parity and use some form of handshaking to throttle the flow to prevent buffer overruns. Haven't seen even parity in a while and I could be wrong.

Is there a manual available online for this machine? This is an interesting problem and I'd like to help you with it.

~John

[johnohara]

The image posted by Ydna reads like this:

Do not cross Transmit and Receive. Use pin-to-pin connections. (simple enough)

Jumper pin 4 to pin 5 on the DB25 side, and pin 7 to pin 8 on the DB9 side. Pin 4 and pin 7 are for Request to Send signals. When they go high they immediately tell "themselves" it's Clear to Send. Both the computer and the machine see this as coming from the other side of the cable when in fact it's their own signal. That's what's known as "faking it."

Pin 20 on the DB25 side and pin 4 on the DB9 side are both Data Terminal Ready. Both sides fake it the same way. When pin 20 and pin 4 go high (both devices raise their "ready to go" flags by sending voltage to the pin), this sends voltage to pin 8 (pin 1) that used to indicate a carrier signal from the modem on the other side. It also raises pin 6 (pin 6) which used to mean the modem on the other side is ready to receive.

All this talk of modems is a moot point, but the computer AND the machine still use the protocol because it works.

Pin 7 to pin 5 is signal ground to signal ground.

~John