Report By Exception (one more time) *sigh*

[Pippin]

Okay -

I tried the Report By Exception ladder logic in a DL06 with the ecom100 in the 4th (last) slot
and network snooping shows nothing coming out of the PLC at all. The IP and Mac address are correct, so what else needs changing which I'm too dense to have noticed? (Tried various base and slot #'s from 1 to 4 with no effect - nothing else seems to be plc dependent).

Did flip the internal last jumper - as required for email support . . . and it can generate email . . .

The logic "thinks" packets are going out, no obvious error messages generated . . .

Anyway of 'faking' the same effect with a IBOX instruction?

[franji1]

Does your Ethernet packet snooper see the Email stuff?

[Pippin]

Yep - Wireshark has no problem seeing all of that traffic.

[Pippin]

Although I do see it ARPing for itself for some reason . . .

[Pippin]

If I flip the protocol to be 3 (Host Ethernet Raw), then it starts to show up on Wireshark.

BTW - If I flip the IP # via NETEDIT to something different, and load up a ladder using the new IP # and run it, Wireshark still reports the ecom100 still send stuff out as the old IP #. 

At least until the power gets rebooted - so maybe I better retry my tests and cycle the power after each new ladder gets loaded.

[Pippin]

Nope -

IPX is visible, Host Ethernet is visible, UDP/IP is not.

[franji1]

Have you properly configured the IP Address and Subnet Mask in the ECOM100?

[Pippin]

email works - so that is a "yes".

[franji1]

Not necessarily, is everything on the same subnet (ECOM100, SMTP Server, and RBE computer?)

[Greg]

Although I do see it ARPing for itself for some reason . . .

FYI, this normal. This behavior actually helps "teach" wireless routers.

[Pippin]

Yep - same subnet. Which is why the fact that everything else but what I want shows up is so annoying.

BTW, tried this with 2 ecom100's - same responce, so about to pull out an old ecom from other equipment
and see if it works any different.

[MikeS]

the number one thing folks get wrong in this example is not matching up the correct SPxxx bits and the slot number - and it's not any easier because of the SP bits / Slot #'s aren't consistent across the PLC lines.

The example program I have running is for slot 1 (K0190), using SP120 (busy) and SP121 (Error) contacts in the logic. For Slot 4 (K0490), you'd use SP126 (busy) and SP127 (error).

Make doubley (sp?) sure the MAC address and the IP address are correct for the PC that's running the application that displays the packets (Viewer.Exe).

In Viewer.Exe:
    1. make sure you select the ECOM100 that sending the packets (Device -> Select Device)
    2. make sure the port it's listening on (default in the example program is 0x7777) is what's selected (check View-> Setup menu)
    3. make sure you've selected UDP protocol and Display Data as HEX

[Pippin]

An H4-ecom worked fine on the first go at the logic, so just going to call it a moral victory and just use that modules instead of twiddling more with the DL06 Ecom100.

Although the working module is sending out packets even with the *wrong* SP Com Relays specified - which I guess it works just so long as something else isn't sitting in that slot.

Thanks -

[MikeS]

I bet the problem is the disconnect between the slot number and the SP's. The DL05 is the odd PLC in that is uses the SP bit's for slot 0 (SP120, SP121) but the slot is 1 (K0190).

[franji1]

Attached is a handy table I came up with when developing the Network IBoxes