MLC 1400 to Servo ASCII Comms

[[email protected]]

I am trying to communicate from a ML1400 to a Yaskawa Servo having an indexer control module using channel 2 and an isolated RS232 to RS 485 Full Duplex converter. The converter is the FA-ISOCON from Facts Engineering (AutomationDirect)which is set up 9600 baud which everything else is also. The sending of commands to the servo works everytime but the response is not seen.I have tried putting first a 10 and then 20 msec delay between the AWA and the ARL though I am now guessing that from Ken Roach's barcode reader example I don't need the delay. I would think that the response would be in the buffer until it is read anyway though. How do the buffers work. I have been using the DN bit of the AWA to trigger the delay which then triggers the ARL. The ARL locks up with EN setand EU but not RN. On the converter I see first the transmit and then rec leds flash and the servo comms monitor shows the receipt of the command and the sending of the response, so?????
Thanks for being here.
Mark

 

[Ken Roach]

Can you tell us more about the serial protocol used by this Yaskawa drive ?

The ASCII Read Line (ARL) instruction expects to see terminating characters on the end of the incoming string. Typically these are Carriage Return and Line Feed. These characters can be changed, and are defined in the port configuration.

If the terminating characters don't match what is configured for the port, the ARL instruction will wait indefinitely for the matching characters, appearing to "hang".

You can use the ASCII Read (ARD) instruction to read the buffer just based on time, without waiting for the terminating characters.

 

[[email protected]]

Characteristics of the Yaskawa Communications are:

1. Full Duplex RS422 or RS485
2. Start-stop synchronization (ASYNCH)
3. 9600 Baud (selected)
4. 1 start bit
5. 7 data
6. 1 bit even parity
7. 1 stop bit
8. NO X-ON/ X-OFF
9. NO DTR/DSR
10. NO RTS/CTS
11. NO Echo (selected)

The response string from the servo is in the format of:

STRING[CR][LF]

Claimed echo response time is 150 microsec. max.

Normal response to non data request commands, ie. SVON (Servo On), is:

OK[SP][SP][SP][SP][SP][SP][SP][SP][SP][CR][LF]

The setup on the PLC is:

1. ASCII
2. 9600 Baud
3. EVEN Parity
4. 1 stop bit
5. 7 Data
6. Termination Character 1 is \d ([CR])
2 is \a ([LF])
7. No Handshaking
8. Delete mode Ignore
9. Echo is unchecked
10. XON/XOFF is unchecked

I had switched to the ARD requesting 15 characters but that is locking up as well. I want to implement your advice from your apnote about a barcode reader. I haven't tried sending and receiving from my laptop through the isolated rs485 adapter yet.

 

[[email protected]]

OK!!!! Thank you Ken Roach
This is what I did to get it working.
I did just what you said in the bar code reader example.
The instructions only want to be told to act, so only request them with one shots, no holding contacts based on DN. Then, for the instruction to tell the program it is done use a one shot falling based on the EN bit of it's control word. (Thanks Ken).
The response, which the servo said it sent as:
1OK[sp][sp][sp][sp][sp][sp][sp][sp][sp]0D0A
when it came back resulted in:
1OK[sp][sp][sp][sp][sp][sp][sp][sp][sp]^M^J

The above was obtained using the ARL (Ascii Read Line) instruction with no delay betwen sending the command to the servo, only using the falling EN of the AWA command seding instruction, as the trigger for the ARL. Ken, your explanation that the ascii stuff is running off on it's own, and suggestion to use the falling EN as the signal of completion of the instruction were the two big helps. As others have said I am sure I am Glad you are here.
Mark