Can an L82 send a msg out of the serial port of an L61?

Can I "Path" my way through an L82 to an L61's serial port, to a radio network that uses DF1 to read/write to Legacy stuff ?

I have an L61 in the same rack and I can write the program within it if need be. But all I really need it for is the DF1 port if I can simply drill through it.

The MSG doesn't complain about the path as I can at least enter it into the MSG dialog without it failing to allow it. Which doesn't mean much I know.
i.e. L81 MSG Path = L61PLCname,2,35 (processor, port, DF1 Destination address)

It will be a while before I can test on live hardware so if it can't be done I'll go a different way. But it seems like it could.... Ken Roach to the lobby please ?

[Scratches head] Maybe ?

I know you can route a CIP message through another processor's serial port. I happen to have a pair of L61's sitting at home and was able to write a test program sending ordinary SLC Type Write messages out of the local serial port or out of an unconfigured empty processor's serial port.

In my test system the originating processor is Slot 0 and the other processor is Slot 4. I just chose DF1 target address 12 abitrarily.

To use the local serial port, the CIP path was "2, 12".
To use the Slot 4 controller's serial port, the CIP path was "1,4,2,12"

I'm not sure what this would do with queues and buffers and connections. But on paper and on the bench, it works.

"the CIP path was "1,4,2,12""
Whats the first "1" denote? Backplane? I browsed to the second processor and it didn't add a 1 to the address.

Yes. I’ve done it from an L75 over Ethernet to a remote rack’s L61 to communicate with DF1 equipment. Don’t have the details handy, but posting to say it worked.

Oooooo A remote rack no less... I hadn't even considered that. That woud let me test... thanks!

I hardwired it to a decoder and I see data coming out that looks like consistently formatted data and it decodes properly... no idea if what I receive will work but it looks promising.

"1" is the backplane port, and in my case "4" is the slot number of the empty processor that is only routing DF1 messages.

It's literally empty; battery and CF card removed, power cycled.

If you have the "remote" controller in your IO tree, then the path to that controller is replaced by the Name of the controller. I didn't put the controller in my I/O tree because I don't need any I/O connections to it.

Need some help here...

I am using an L82 (for the message), through an L61 (for the serial port) through a Moxa serial to Fiber converter - to an MDS radio pair, to an ML1400.

Using DF1 19.2 Half duplex and polling 5 seconds from last success, I get about a 50% message success rate at best.

Using DF1 Radio Modem I get about a 20% success rate.

While I'm open to anything the radio appears to be completely happy talking to each other, the serial traffic does not.

I have netdecoder on the output of the L61 and using the AB DF1 Half Duplex protocol stack, it is filled with truncated fields (master enquiry) containing only 2 bytes (10 05)

When it does get a master command packet through I get a complete slave response so its capable of working but nowhere near reliable .

I am going to move my polling code from the L82 and into the L61 as a test that maybe the L82 can't pass through the L61 as well as I hoped... but any other ideas?


Sample Capture:

Look at this tech note below:

1066637 | Date Created: 10/17/2017 | Last Updated: 02/19/2019

There is a section that talks to the path to controllers serial port.

Or use "The Cheat's Method" which is build the path in your IO config tree, config message, then delete the path out of io config tree.

I have the path, but I'm thinking that perhaps a serial MSG from the L82 through the L61 is a problem.

Then it might be a firmware upgrade of ethernet card or the firmware of the L61? This is all background stuff that's managed by the OS. Might be a feature that is smashed in later firmware?

I wonder if the compatibility matrix on the ab website can shed some light on the problem?

This is only serial - not ethernet. L61 FW is 20.19.
I have an L61 running comms on different radio system so the serial functionality exists.

Could it be the quality of the RS232 cable your using? I use below for noise induced areas

Black Box EDDC
Bulk Extended-Distance/Quiet Cables, Industrial
Send RS-232 data up to 500 feet in noisy environments.
Specifications


This might be handshaking hardware wiring or some other setting. I used to do a lot of serial comms with bar code scanners and scales. Any specialty device like your describing might be below issue with pin outs. Look this up below was my spreadsheet copy sorry!

RS232-C Description Circuit Circuit RJ45 TIA 457
EIA CCITT
1 Shield Ground AA
7 Signal Ground AB 102 4 5
2 Transmitted Data BA 103 6 3
3 Received Data BB 104 5 2
4 Request To Send CA 105 8 7
5 Clear To Send CB 106 7 8
6 DCE Ready CC 107 1 6
20 DTE Ready CD 108.2 3 4
22 Ring Indicator CE 125 1 9
8 Received Line Signal Detector CF 109 2 1
23 Data Signal Rate Select CH/CI 111/112
(DTE/DCE Source>
24 Transmit Signal Element Timing DA 113
(DTE Source)
15 Transmitter Signal Element Timing DB 114
(DCE Source)
17 Receiver Signal Element Timing DD 115
(DCE Source)
18 Local Loopback / Quality Detector LL 141
21 Remote Loopback RL/CG 140/110
14 Secondary Transmitted Data SBA 118
16 Secondary Received Data SBB 119
19 Secondary Request To Send SCA 120
13 Secondary Clear To Send SCB 121
12 Secondary Received Line Signal Detector/ SCF/CI 122/112
Data signal Rate Select (DCE Source)
25 Test Mode TM 142
9 Reserved for Testing
10 Reserved for Testing
11 Unassigned

These days everything is 3 wire so no handshaking. The serial cables are about a foot long with singlemode fiber converters in the middle. The converters are a suspect as well as the radios at this point. I'm putting the code in the L61 to try it directly rather than path through it from the L82.

Does the same thing directly from the L61. Fail Fail Fail, then works twice like lightning.. then fails again. So its not the path....

count the serial sends to your data on that one capture program?

Does it match?

I would look for a loose connection. Reterminate or check the terminations.