Report By Exception

[cncwapner]

I'm starting to understand more on how the RBE works but still have a few questions.

1. What is V2001 1 = COMM_FUN_SEND and what does this do?
2. Here is an example data section of my packet. What is the structure of this?
48 41 50 FE 15 8C 14 14 00 33 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 00 00

Eric

[MikeS]

Eric,

that's the function code that tells the ecom (or ecom100) to do a 'send packet' operation.

in the world of rbe, there's really only one legitimate operation and that's 'send a packet', that's why there's only the one function code listed in the documentation.

--MikeS

[Greg]

1. This tells the ECOM to do the send (COMMand FUNction SEND).
2. The 1st 13 bytes of this are our own protocol and cannot be removed from the telegram.

48 41 50 = "HAP" (Host Application Protocol)
FE 15 = Application Value
8C 14 = CRC (or zero)
14 00 = Length (20 bytes to follow)
33 = (Function Command requires no ACK) (32 = Function Command requires ACK)
00 00 00 = 3 bytes are always zero

DATA:
00 01 00 00 00 00 00 00 00 00 00 00 00 03 00 00

[Greg]

Actually, "HAP" = "Host Automation Products"... oops. 

[cncwapner]

OK, thats simple. But now If I wanted to ACK the packet how would I do that?
Also say I wanted to write data back, is it always two bytes per V address?
So say I wanted to write DEC 192 to V3020 would it be 00 C0 or just C0?

Eric

[cncwapner]

Also what is the Application Value?


Eric

[MikeS]

eric,

if you're asking how to get the pc to ack the packet sent by the ecom, you set the appropriate value in the 'flags' (location v+4). by default, a value of 0 says the packet sent by the ecom will require an ack from the pc.

there are always 2 bytes per plc v address.

the byte ordering is dependant on the pc application that's receiving the data, so it's not possible for us to say for sure what byte oredering you need. i can say that normally, to send 192, you'd send in '0x00c0'.

the application value is generated by the sending device and it is unique to each packet sent. when the destination device responds, it uses that application value in the response packet. this is then used to match up the source packet with the response packet. this value is not something you generate, it's done automatically by the ecom.

[cncwapner]

Very simple, I see now.
Last question? When I use the RX Block in my ladder, does it wait for data to be read or does it just read?
If it just reads, how would I know when it acctually reads a packet? Is the a SP that says data has been read?

Eric

[cncwapner]

I think this is right. I receive this from the PLC:
 48 41 50 85 21 00 00 14 00 33 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 03 00 00
Then I want to write 00C0 to V3020 so I send back:
 48 41 50 85 21 00 00 14 00 33 00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 03 00 00

But my V3020 never changes on the PLC.

Eric

[MikeS]

i think all you're doing wrong is not changing the function code(s) from 'send' to 'respond'. try this:

48 41 50 85 21 00 00 14 00 22 31 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 03 00 00

this is a code snippet from our viewer application that ships with the rbe sample code that shows the response function codes:

// See if an ACK was requested by the module.
if (Buffer[9] == FUN_COMM_REQ_ACK)
{
        // Send ACK.
        static DWORD ReplyCount=0;
        char buf[100];
        char pTestStr[50];

        // Return a char buffer back to the ECOM module.
        wsprintf(pTestStr, "Reply: %ld", ReplyCount++);

        WORD *pWord;
        WORD *pAppVal = (WORD *) &Buffer[3];

        buf[0] = 'H';
        buf[1] = 'A';
        buf[2] = 'P';

        pWord = (WORD *) &buf[3];
        *pWord++ = *pAppVal;
        *pWord++ = 0;
        *pWord++ = 2+strlen(pTestStr);

        buf[9] = FUN_RESPONSE;
        buf[10] = FUN_COMM_RESPONSE;

        strcpy(&buf[11], pTestStr);

        sendto(sock, buf, 11+strlen(pTestStr)+1, 0, &Addr, AddrLen);
}

[cncwapner]

OK, I'm sending this back now but V3020 still doesn't change. For some reason V3000 mirrors V2000. Is this normal?

[MikeS]

that's not normal

it may be that you have the same plc address specified in the wx and rx instructions  you should have an "lda o2000" in the rung for the wx, and a "lda o3000" in the rung for the rx.

can i make the assumption that you've tried the sample program that ships with the rbe 'care package' the sample that talks to our viewer.exe example? if so, can i also assume that when you monitor v3020 (as text - 16 bytes) you see the 'replies: xxxx' and the incrementing number?

if the sample program is working it points to your application as the problem, if the sample doesn't get the replies, it points more toward the ladder program.

[cncwapner]

It's been some time since I worked on and completed this project. I have sucessfully writen a ladder and PC application that sends a broadcast packet out upon power up, and the PC application responds to this packet. The response is received by the DL05 ECOM and sets the IP address of the PC we are talking with in the ECOM. Its kind of like PLC-DHCP. From this point, my PC application receives changes to inputs on the DL05. Works great and now I dont need to change the ECOM host PC IP information when the PC's IP changes.
If anyone is interested, drop me an email.