Eddie Willers

You're still not quite there. The PowerFlex 4 microdrives only communicate using Drive Serial Interface (DSI) protocol, which is basically just a subset of Modbus RTU protocol on RS-485 multidrop wiring. The MicroLogix 1200 and 1500 now have built-in Modbus RTU Master protocol available on their serial ports, but the SLC-5/0x controllers do not. If you want to control this drive serially from an SLC-5/04, you will need a Prosoft Modbus Master card or some other way to convert from an A-B protocol to Modbus RTU Master.

Rockwell Software sells update support; most users pay an annual fee and receive phone support and upgrades to RSLogix 500. If you have not upgraded in the past 5 years (which that version number would indicate) then there is a "reinstatement" fee. The update website is: support.rockwellautomation.com/webupdates But before you can download a new version, you must purchase a support contract from your friendly local Rockwell Automation distributor.

You're going to have to be more clear. Does the drive stop and start when you do not think you are commanding it to do so ? When you say "without fault indication" do you mean that there is no F10 Serial Fault indicated by the 1305 drive, or that the Connection Status bits in the PLC-5C never change ? You mentioned a PLC-5C controller. Is this really a ControlNet Phase 1.25 controller (about seven years old !) or a newer PLC-5C15 Phase 1.5 controller ? I'm not sure how you can say that communications is lost to the drive, if you also say there is no indication of a fault. The drive stopping and starting is more likely an indication of an input to the drive that you do not anticipate, rather than an erroneous command of the drive.

DH-485 is NOT the same as RS-485. That's the fundamental problem here. The MicroLogix 1200 has a multipurpose RS232 port but the protocols supported by your PanelView and PowerFlex 4 are incompatible. The PowerFlex 4 supports only "DSI" protocol on RS485, which is essentially Modbus RTU Slave. The PanelView supports DH-485, which is an A-B proprietary protocol. The MicroLogix 1200 can run six different serial protocols (RTU Master, RTU Slave, DF1 Full Duplex, DF1 Half Duplex, DH485, and ASCII) .... but not two different ones at once. If you had a MicroLogix 1500 LRP with two serial ports, this would be do-able. One port could be set up for DH485 to talk peer-to-peer to the PanelView, and the other could be set up for Modbus RTU Master to command the drive. But with a MicroLogix 1200 and just one serial port..... you're going to have to run the drive with discrete and analog signals, not with a network. I think it's foolish for A-B to offer drives that don't use an A-B protocol like DH485 or DF1, but that's what the super-cheap drive market is like.

You're going to have some trouble finding a "used" controller with a warranty; the warranty is only 1 year and most SLC-500's end up being in use for 7-10 years.

A-B just builds the 1771-AF as spare parts these days... there are better, cheaper, and more compact solutions on the market for RIO and DH+ on fiber. The two Rockwell partner companies I've worked with are Phoenix Digital and Weed Instrument. Phoenix makes chassis-mounted fiber converters, and Weed's are a modular DIN-rail mounted product. www.weedinstrument.com www.phoenixdigitalcorp.com

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.    

Okay, I *think* it is: Class      0x01 hex    (Identity) Instance 0x01 hex    (this one controller) Attribute 0x05 hex    (Status integer) Tuesday I'll be able to check this against a real ControlLogix and figure out if it's correct.

The easy way would be to perform a GSV instruction in the controller itself, and then interpret the results in a simpler format (i.e. a 1,2,3,4) for the MMI screen to display. You can do a GSV instruction to the CONTROLLERDEVICE object class, and retrieve an INT data type that contains the status of the controller. RSLogix 5000 help describes it as follows: Status INT Bits identify status: Bits 3-0 are reserved Bits 7-4 Meaning 0000 reserved 0001 flash update in progress 0010 reserved 0011 reserved 0100 flash is bad 0101 faulted 0110 run 0111 program Bits 11-8 Meaning 0001 recoverable minor fault 0010 unrecoverable minor fault 0100 recoverable major fault 1000 unrecoverable major fault Bits 13-12 Meaning 01 keyswitch in run 10 keyswitch in program 11 keyswitch in remote Bits 15-14 Meaning 01 controller is changing modes 10 debug mode if controller is in Run mode Of course, if the controller is in Program mode the GSV won't execute and you won't be able to tell.  Hmm.   So you have to figure out what the hex codes for CONTROLLERDEVICE and STATUS are.   I wonder if my handy-dandy CIP analyzer is still around here.....

New controller instruction set: http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html I just couldn't resist.....

I found one DHCP server that won't support BOOTP requests from a PLC:   A Linksys BEFSR41 Cable/DSL Router with 4-port Switch. This device is the neatest thing since sliced bread for a DSL connection you want to share;  the 4-port switch works fine for computers you plug in whilst configured to get their configurations via DCHP.   It's an excellent firewall for home use;  I got a couple of probe attacks an hour until I got this, now none. But it ignores BOOTP requests.   Happily, once I set the IP address manually I was able to set the router for Port Forwarding to let RSLinx traffic through the firewall, so for a quick and dirty demo it let me control a SLC over the Internet.   It's not probable that I'd install such a thing in a real production environment.

I've heard this question asked before, always with some incredulity on both sides.   Customer: "How do I connect my A-B system to and HP-IB (or GP-IB, or IEEE-488) instrument ?" Allen-Bradley Guy: "What's that ?" Customer: "What you you mean, what's that.  Everybody uses HP-IB.  It's everywhere." Allen-Bradley Guy: "Um, not in our industries (I think!)" And both are right.  In analytical chemistry and other laboratory sciences, the GP-IB bus is a great way to transfer data across a very fast parallel data bus between programmable instruments like dataloggers and chromatographs and oscillioscopes.   But the 20 meter cable limit, the 24-conductor shielded cable, as well as the (relatively) small field of devices that can be connected don't make it popular in heavy industry, where the 16-point AC input card is still king. The only GP-IB instrument I've ever seen connected to a PLC was a GPS satellite timecode receiver connected via GP-IB to a special PLC-5 card that did sequence-of-events timestamping for electrical distribution.   The maker was called CTI and was located in Colorado but I have never been able to get in touch with them.

Your best bet for inexpensive licensing terms without copy protection is the Software Toolbox products.   You're very unlikely to find this kind of software for a proprietary control system as freeware.

Can you tell I do a lot of DeviceNet? Because you're using seven small PanelViews with one scanner, I suppose it's possible that you'll want to display a lot of the same system data on both.   While the 1771-SDN has a fairly big data area (352 words maximum, I think) it's both efficient and cool to use the Listen Only function on the PanelViews.   You can set up a traditional input/output polling connection to one PanelView, and several other PanelViews can Listen to that output data.   I think they can also have their own unique output connection.  That feature was added later than any of the PanelView terminals I have to play with.  :) Good luck, Eddie Willers

Here's the part that always throws me:  "Which is I, Which is O" ? A-B has done a less than stellar job of enforcing the "Producer/Consumer" nomenclature in DeviceNet products.   RSNetworx itself, when you "Edit I/O Parameters" uses "Tx" and "Rx" for Transmitted and Received.   The PanelBuilder software calls the data connection "Input" and "Output". PanelView Input data   = 1771-SDN "Rx" Input data. PanelView Output data = 1771-SDN "Tx" Output data. The PanelView software is trying to help by referencing tag data as the PLC would see it.  That's fine on Remote I/O when the PLC address is necessarily the PanelView address, but when it's DeviceNet and the PLC data can be mapped anywhere in the scanlist, I personally think it would be better to stick with Producer and Consumer nomenclature everywhere.

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.

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.

Sounds like the memory is getting corrupted while the PV is running.   Although PanelView error codes absolutely stink (hey, at least they're in decimal) at describing the solution to your problem, they've always been pretty close to the mark as far as indicating what it is. So the PV is doing it's Error/Errore/Erreure thing after it's been running for a while... and then at reboot the program checksum fails.  That says runtime corruption of RAM or failing RAM hardware to me.   It's possible for RAM to be intermittent, and not beyond A-B to not catch a thermal problem or something during burn-in.  I dunno if the 550 uses EEPROM or FLASH or something else for retentive memory. You didn't mention which network this PV550 is running on... some are more prone to noise conduction than others.    I am also a big fan of the FAT GREEN WIRE ™ to ground things like this to protect their electronics from spikes.

I'm a regular on three other boards, it seems like this one might be overkill as it doesn't have a running start or an evident sponsor.  But then, maybe it won't be overrun with students in Indian electronics classes or with Linux fanatics. But hey, I'll drop this address with other guys as a place to go as well.  Especially when the phones are as slow as they are today.....