Help: Micro820 to 160 series C VFD via DeviceNet

[EricDC2]

Hey everyone, I'm pretty new here, but have been working lightly with AB PLCs for a while now. I've recently hit a stumbling block that I'm hoping someone can shed some light on.

We have a very old machine that we've been slowly upgrading to make more modern. We have a Micro820 controller on it, and we're looking to add some VFDs to 4x motors. I don't have the inputs & outputs available to control all 4x drives with the standard relays & analog signals that I'm used to doing.

I've started trying to understand how to control them over DeviceNet - which I know is possible, but I haven't been able understand it enough to get where I need to.

I really only need to control standard commands, like forward, reverse, speed reference. From all the reading I've done on the 160 drives, none obviously reference CCW code for the 800 controllers (obviously due to the respective age of the two pieces of hardware).

Here's what I think I know:

Explicit messaging is not what I want to use for drive commands and status updates. This is only used for changing parameters that don't have a time-sensitive component to the read/write.

In the manual they talk about configuring the DeviceNet Scanner to be continuously scanning the drive and the PLC and exchanging these commands into variables in the PLC. This is where I'm stumped, because I can't seem to find this mapping function in the CCW.

Should I be looking at Symbolic messaging? Something I don't know about yet?

I've downloaded some sample code from AB which has some UDFB's for the 520 FVDs, and on my testing bench, I have played around with this, and I can actually get the drive to run and stop using that code, and I can see the Actual Speed of the VFD when it's running - so I know it's possible, I just haven't had that ah-ha moment where I understand what to do.

Any pointers would be greatly appreciated.

 

[Ken Roach]

Welcome to the PLCTalk forum community !

Let's clarify: you're planning to install some old Bulletin 160 drives with 160-DN1 or 160-DN2 interfaces on them to add variable-speed features to a machine controlled by a Micro 820 controller.

It would probably be easier to use PowerFlex 520 or PowerFlex 4 series drives instead, because they are from a similar generation and there's documentation and code for using them with a Micro 800 family controller. They also don't have 20-year-old capacitors and power transistors in them.

I was, back in the day, a DeviceNet expert and knew RSNetworx inside and out, especially the Bulletin 160. But I haven't used the DeviceNet implementation on the Micro 800 series, so I'm approaching your question as a bit of nostalgia.

Other A-B controllers with DeviceNet scanner modules (SLC-500, PLC-5, CompactLogix, ControlLogix) used RSNetworx for DeviceNet software to set up both the scanner and the slave devices. The defaults often worked fine, but there is a lot of flexibility so if you go in blind you can get lost fast. You used the RSLogix software and RSNetworx software largely separately, with an I/O memory block in between them.

The Micro 800 chose a narrower approach, to remove RSNetworx from the picture. Instead they built a 2080-DNET20 module, which can act as a DeviceNet master to just 20 slaves (vs 63 with normal DNet).

The product brochures and user manual tell you at the outset that it's designed to work with a narrow set of products: CompactBlock LDX, PowerFlex drives, E1 Plus overloads, and stacklights.

Notably absent from the advertised feature set: the more sophisticated CompactBlock and ArmorBlock, the E3 overloads, Bulletin 160 drives, FLEX and POINT I/O, and every third party device.

I think you can use the Bulletin 160's with the UFDB_DNET_GENERIC function block.

Let's take a step back and go look at those interface modules on the drives, and figure out if they're 160-DN1 or 160-DN2.

 

[EricDC2]

Thanks for the reply!

I agree with the 520 drives being the better approach... but it was deemed worth $6,000 for me to investigate getting these working as we have ~12 or so drives sitting on the shelf we can use.

I am using the 160-DN2 with these, and I've actually had some good success in the past 8 hours.

I took the RA_PF52x_DNET_STS_CMD UDFB from AB's website, and was able to modify the parameters to make all of the commands line up and work.

So I now have a UDFB that will allow me to start/stop, Fwd/Rev, with speed control. I'm also able to read the drive status with parameters that match. From what I've read in the user manual, I have mapped all of the parameters that are available.

So now... I'm just not confident I know how I got here... the sample UDFB just happened to kind of work, and I've massaged it to now work. I would still love to learn how it works for my own comfort in using it, or for future projects.

What I seem to understand, is that the UDFB is using a few functions that I don't see available in the Ladder Logic "PLUGIN_WRITE_DNET", "PLUGIN_READ_DNET", "DNET_COP". Within these functions, it's referencing SlotID, offset_addr, data_length, dnet_write_data. The first and the last variables I understand, one is the location of the 160-DN2, and the other is the data array I'm sending over.

What I don't understand, is how is this mapped to the commands it's controlling - which are "Assembly Objects"?? I'm assuming this is doen in the offset_addr and data_length variables - but I'm obviously not confident in this.

I've attached a snip of the code if it helps. The drive commands/status it's referencing are on page B-24 of the 160-DN2 user manual.

Eventually I would also like to be able to set the parameters from within the 820 controller - which is why I want to understand how the UDFB is working.

 

[Ken Roach]

"You can't argue with success, Ken"

"I can, and I will !"

This UDFB probably works by coincidence, because it uses the ODVA "AC Drive Profile" instead of a model-specific I/O assembly. The purpose of those generic profiles is/was vendor and model agnosticism.

I would have used the Generic object UDFB and mapped it out to the Bulletin 160.

Unfortunately, I don't have enough experience with the guts of those user defined function blocks to advise you about how to customize or extend it.

If you want to take a step back and use the Generic UDFBs and the Explicit Message UDFBs, I'm willing to follow along and advise on the well-documented public interfaces like the Parameter Object.

 

[EricDC2]

Yes, I would love to take a step back and completely understand what's going on. I get nervous using something I don't fully understand.

This coming week I'll start playing with something new. Is there one that makes more sense to start with? Either the Generic or the Explicit Message UDFB?