A-b powermonitor 3000 on devicenet

[Eddie Willers 2]

Okay, just to dredge up some traffic, I'll hold forth about one of my recent projects, the Allen-Bradley PowerMonitor 3000 using their DeviceNet interface option. I was initially happy to see that there was a DNet option for this module, as I'm used to A-B drives on DeviceNet and their convenient use of a configurable-size I/O instance (called DataLinks) and the Parameter Object (Class 0x0F) to access data within the drive. I'm not sure I could be more disappointed in what I've found with the PM3000.   They say that it's DNet interface is based on the card they use in the PanelView (which does most of it's configuration from a separate utility, PanelBuilder32).  But it does... almost... nothing. There is no Parameter Object.  You can't send a message to just get the Phase A Real Current, instead you have to send a message to get the whole "All Real Currents" assembly, which is dozens of words long. The DeviceNet object isn't configurable.  You can't change the Node Number or Baud Rate from RSNetworx or any other utility, you have to use the front panel display (Which is itself a big step backwards from the one on the PowerMonitor II.) What it does do is Assemblies (Class 0x04).   It can do one I/O assembly and lots of explicit message assemblies. But the default I/O assembly is "Discrete I/O", just giving you the status of the auxilary inputs and allowing you to force the relay outputs.   That's OK if it was an I/O block, but it's a PowerMonitor, and I want power data ! They've also left some pertinent information out of the user manual, like "what is the data type of the elements in this assembly" and "are these data types all the same in this assembly".    It's been said that this is in the next edition of the manual. RSPower32 is required to serve data up into OPC applications like RSView32, and I like the way that it works as a plugin to RSView32.   But.... it can't use anything but a direct connection to the DeviceNet or a 1747/1771 Passthru driver to acess the DNet.  If you use a ControlLogix-type bridge architecture, no dice.   Also "in the next release".   And while RSLinx can itself attach to the data assemblies, they come up as arrays (hard if not impossible to use in RSView32) and with the words in the Floating Point elements swapped around (making them useless).  RSPower32 takes care of these data niceties for you and provides individual OPC elements. The PowerMonitors are good devices, and I love how compact the 3000 is, and it's Ethernet interface is terrific... but the DeviceNet interface, boys, it STINKS.    

[Eddie Willers 2]

So, you'd think that "hey, I'll select which Data Assembly to make the I/O assembly by choosing it from a list in RSNetworx".   BUUZZZZ !  Thank you for playing !   No such function. Instead, what you have to do is reconfigure the "Configurable I/O Assembly", which is Assembly 1.   To do this, you need to send a very long DeviceNet explicit message that includes the number of the assembly, the length of the assembly (in elements) and the parameter numbers of all of the assembly elements. You could write duplicates of the common assemblies that are available through explicit messaging, or you could make one custom assembly that has all the data you're interested in.   Then you can configure an I/O connection (cyclic connection would be best, as the PowerMonitor needs a time elapsed to analyze power).    Then you get to figure out what size it is and map it into your DeviceNet scanner.

[Eddie Willers 2]

Huh, interesting, I dunno if new posts are supposed to go above old posts or below, maybe it matters which button you push. So, my complaining is done.   I've done the hard work of figuring out the fiddly bits that are not in the manual or in an application guide, and I've worn out the patient ears of Rich Morgan at A-B's power group marketing department. What I'll do now is document what I did to get my data where I wanted it with a minimum of fuss.

[Chris Elston 78]

Great information! I have not done this myself yet, but I know where to come when I do...right here! As far as your question about POSTING order. I have set the board up to POST NEW messages at the top, because I like to see the new posts FIRST not scroll all the way to the bottom. PLUS as replies that are made moves the WHOLE topic to the top of the FORUM. Call me lazy I guess, but boards that post NEW message to the bottom, are too far to scroll. ;) Also another HINT: If you click "NEW POST" at the top, then you don't have to browse through the whole site to look for your new posts that you have not read yet. This will come in handy later, trust me.

[BobB 58]

Been there done that. Programmed a job about 12 months ago. Used 5 Omron CS1 PLCs and Device Net scanner cards (9 of them). Used 7 Powermonitor 3000s and some 80 Omron Device Net I/O blocks. The only way to communicate with the PMs was by explicite messaging. What a pain in the a*** to set up. Once I worked it out it worked great. Yes, you have to pull out the information in lumps and sort it in the PLC. Most Device Net equipment with large amounts of data are set up the same way. Worse than that I had to swap bytes for all words received (thank the lord for Omron's swap byte command) and then swap words to put them in the correct order for 32 bit words. That became tedious as the PLCs did not have a swap word command. Had to use the transfer command on each pair of words individually. If you have a PLC that will not handle IEEE754 word format, forget using these things. Just doing a job now with Pepperl & Fuchs Device Net rotary encoders and, once again, Omron CS1 PLCs. Same set up - data in lumps. Have not found out yet if I have to swap bytes and words to get the correct orientation of data. Oh well, have to earn my pittance somehow.