SLC 5/05 1747-L551C ethernet communications to ABB VFD

[Robb B]

I did review the different communication modes, but considering I only want to get speed, power, and flow for now, I think just doing the 3 EEM should be okay. I'll probably only run the EEM routine every few seconds, too.

 

[Robb B]

Okay, communications is working, but not getting the data that I think it should be. I think it should be a value of 0 (vfd is not currently running) in data table N17:0

Any suggestions? I've used different commands and service codes than the scant examples give, but reading through the documentation I think it should support a single value read.

 

[mylespetro]

Do you need to adjust your Instance and Attribute to read the appropriate parameter? Looks like you're trying to read parameter 1.01 the way it's set there.

EDIT: Looks like parameter 01.01 is indeed "Motor speed used". Does the value change at all if the VFD is running (if you are indeed able to start the VFD that is)?

 

[Robb B]

Do you need to adjust your Instance and Attribute to read the appropriate parameter? Looks like you're trying to read parameter 1.01 the way it's set there.

EDIT: Looks like parameter 01.01 is indeed "Motor speed used". Does the value change at all if the VFD is running (if you are indeed able to start the VFD that is).

With the drive running, the data table reads as the attached picture. The other two EEM should be reading AMPS and FLOW, (starting at N17:60 and N17:120 respectively).

Maybe I need to scale the response data?

 

[mylespetro]

I don't know if I'm misunderstanding how to use the EEM instruction, but is the data table address inside the instruction supposed to be the same as the control block address of the instruction?

 

[Ken Roach]

You put your finger on it: no, they're not !

Choose another data table or offset to hold the actual EEM message result, designated as the "Data Table Address (Receive Data)" in the EEM configuration window. You could stick it at N17:58 if you wanted to be really efficient on memory.

You're sending the data payload to N17:0 and N17:1, which are part of the EEM Control Block, so it's writing over the configuration every time the message completes.

 

[Ken Roach]

And I'm not sure if this data is encoded as REAL (IEEE 754 single precision floating point) or as 32-bit DINTs. You might have some byte swapping and data table COPY instructions to do.

Handy byte-by-byte IEEE 754 converter:

https://www.h-schmidt.net/FloatConverter/IEEE754.html

 

[Robb B]

You put your finger on it: no, they're not !

Choose another data table or offset to hold the actual EEM message result, designated as the "Data Table Address (Receive Data)" in the EEM configuration window. You could stick it at N17:58 if you wanted to be really efficient on memory.

You're sending the data payload to N17:0 and N17:1, which are part of the EEM Control Block, so it's writing over the configuration every time the message completes.

I'll try testing this right now. The data in the receive table of the EEM instruction doesn't make sense either: it shows 52 and 59 in columns 0 and 1

edit: removed the other two EEM for now, using n17:60 as the receive data location, values still don't make sense, but I'm pretty sure it's scaling that's needed. Something to work on tomorrow.

 

[Robb B]

Control words and data tables are organized and separate, communications works and data is coming in. I'm having issues with the EN and DN bits. I have a b3 XIC in front of each EEM instruction so I can work on one at a time, but the EN and DN bits stay true even if the bit is toggled high/low. The instruction also seems to keep running if the XIC is false when I enable the Continuous Run (CO bit) which I guess makes sense, but goes contrary to expected behaviour. Right now I need help figuring out how to reset the DN bit. The DN bit does not go true if the CO bit is true, as it just keeps repeating, but I'd like to eventually have these EEM instructions on a timer, to keep network data down.