ElectronGuru

I've seen this before but more often with the yellow question marks. If you have a backup of the driver, restore it. Otherwise, note the driver settings, delete and re-create the driver offline and next time you plug in everything should be normal. Then use the RSLinx Classic Backup Restore Utility to create a backup for the next time something like this happens.  Would be nice if someone else could jump in with a magic one-click solution, besides don't plug into the wrong network, lol.

There is a hurdle between RS5000 (V20 and below) and Studio5000 (V21 and above). All L6 controllers hard stopped at V20, but there are a handful of L7s that will go down to V19. Your workaround of "lying" to one controller and telling it that it's consuming a tag from an L6 instead of the actual L7 is pretty clever. I think that most or all data on the backplane is multi-cast, not unicast. I tend to switch everything in the local chassis to multi-cast, as I believe most of the default card settings are unicast.

IT and controls people are the bane of each other's existence, lol.  My experience has been that when the generations of PLC get too far apart, it's better just to use the message instruction. This can be frustrating when all you need is something as simple as line speed to get from one controller to another, but it's reliable.

Whether you in the same chassis is not as important as being on the same network. The Design Considerations manual says; "You cannot bridge produced and consumed tags over different networks. For two controllers to share produced or consumed tags, both controllers must be attached to the same network. You can produce and consume tags over ControlNet or EtherNet/IP networks". It stops short of saying whether you can share data this way across different subnets, which is the situation you're in and is something I've never tried. Like @Joe E., I'd be surprised if it didn't work but if if doesn't, you'll have to use a MESSAGE instruction. 

I think in Rockwell's literature they specifically say do not put an SE server or access on a Windows domain computer, and you're probably experiencing why. I've successfully used @pturmel's suggestion of using VNC several times.  

@Joe E. that's a good point and I agree. The only time I've ever used the DLX editor is when I had a stand-alone drive that needed an external input or two, and I didn't want to pay for a MicroLogix. Like when we had two PF753 that ran at different pre-set speeds based on float switch inputs, but also needed to run in lead/lag with each other. I can't see the point of using DeviceLogix in a drive that is owned by a ControlLogix processor.  

I'm not sure what you mean by, " The drive has only parameters or also programming?". By setting the parameters, you are programming the drive; that is, making it behave the way you want it to.  As for changing the drive and updating your controller there are any number of ways to do this, and I'm sure other people will jump in with their own suggestions. I would upload the existing parameter values to the HIM, install the new drive, then download the from the HIM to the drive. In Studio5000, delete the existing drive and use the discovery tool to add the new drive. Make sure you give the new drive the exact same name as the old, deleted drive so all your tags still work. Interested to hear other methods and suggestions. Best of luck!

@BobLfoot is correct; the .apa file extension is an archive (backup) file and not meant for editing. I don't know of any what to even open a .apa; you can only restore it to a .sed. Speaking of which, what you want to do is use the FactoryTalk Distributed Application Manager to restore the .cli (client) file to a .sed (Site Edition Development) file. 

@BobLfoot has great advice. However, if you're not communicating you can also use the HIM to transfer the program from one drive to another.  If the CompactLogix controller owns the drive then you will need to update the drive's profiled in your I/O tree. In the I/O tree, open the properties dialog box of the drive, in the Overview tab click on the Device Definition button and you'll find the settings you need.  It should be as simple as that but there are SO many drives that sometimes Logix gets really picky about the keying. In my experience it's often easier to transfer the project from the old drive to the new via CCW, delete the old drive from Logix in Studio5000, then upload the new. As long as you give the newly uploaded drive the exact same name as the old one, the Logix tags should fall right into place and everything will be ok.

There are several Control- and CompactLogix L8 processors that will go all the way down to V28, at least according to PCDC. But true, the vast majority of them run only on V32 and up. Anyway, you definitely cleared up my questions for me and today I fooled around with several controllers and versions of Studio to see that in action for myself. Thanks! This helped a lot!

Sorry for such a long post but here goes. I've been messing around this week with a 1756-5583E controller running on version 30.11, and I decided to play with LINTs, ULINTS, and other U-integer data types just for fun. (I now regret this decision, lol). No matter what instruction I attempted to use a LINT or other 64-bit data type in, when I verified the routine it told me I'm using an invalid data type. So I start digging around and found this in the New Features section of Studio5000 version 32 release notes: "Added new predefined data types (USINT, UINT, UDINT, ULINT) and 64-bit data types (LINT and REAL) to improve range, accuracy, and precision of user applications and increase productivity. The new data types are applicable to CompactLogix 5380, CompactLogix 5480, and ControlLogix 5580 controllers only". After a lot of screwing around I discovered that LINT is available in the tag editor in all my Studio versions (21, 28, 30, 31, 32, & 34), but Studio woofs its cookies if you try to use it in code at V31 or below. You can declare a LINT tag but if you can use in code without getting an invalid data type error, I can't figure it out. If I use LINT in V32 or above (as advertised in the release notes), all is well. BUT WAIT: THERE'S MORE! You'd think I'd had enough but I went even further down the rabbit hole and found this on page 130 in the Replacement Guidelines: Logix 5000 Controllers (March 2022) manual (bold italics are mine): "LINT data types are aligned on 64-bit boundaries in Logix 5000® controllers, that use a Logix Designer project, version 27 or later". This appears to directly contradict the release notes that said LINT was new in V32. Then this on page 131: "See Produce and Consume Tags on page 106, if you Produce/Consume tags in UDTs between the following: 5580 and 5570 controllers that use Logix Designer projects, version 26 or earlier. 5380 and 5370 controllers that use Logix Designer projects, version 26 or earlier".  According to Rockwell's Product Compatibility and Download Center (PCDC) there is no L8 controller that can be flashed to below V28. Questions: Does anyone know why 64-bit data types are available in Studio V31 and below if they can't be used in code? If they can be used in code, what the heck am I missing? (I was trying simple things like MOV a decimal value to data type LINT tag). Does anyone know why these three Rockwell reference tools (release notes, Replacement Guidelines, and PCDC) seem to so egregiously contradict one another? Thanks and again, sorry so long. 

@pturmel thanks! If only the V32 release notes had just said, "you can now do math, etc. with a LINT".

FLL always works best when you're clearing an array. I'm a big fan of the CLR instruction when zero-ing a single word of data. 

@Joe E. after I posted I looked it up as well to be sure, and got the same results you did. But I think setting 888 and cycling power sets defaults on any AB product with IP selector switches.  

@BobLfoot just be careful on that 256 - 989 range to not set those switches to 888! I believe that's the value that resets the device back to factory settings.  

Have you checked the input power at the power terminal blocks on the drive? If power is verified with a meter at drive input, you likely have a drive failure. 

@VFD Guy yep! For a 60-second spot check, rotate the motor shaft a 1/4-turn and check again, higher voltage checks are probably OK so long as you're doing that every week. But for a longer test, such as a ten-minute polarization index, I would stick with the motor nameplate values. Either way, I think we're on the same page.

Megger testing at a significantly higher voltages than a motor is rated for could cause motor winding damage. Very few people will ever have a need for "proof testing" a motor, which uses higher voltages. Routine maintenance testing and troubleshooting tests should be done at as close to nameplate voltage rating as possible. @PaulKim1003 definitely let us know how it works out. :) Edited for a bit more clarity.

@PaulKim1003 no, doing a tune isn't first on my list of things for this problem. If you suspect someone has played with the parameter settings, run the compare tool. Sometimes it's a quick and dirty check just to eliminate that as a possibility if you have co-workers who like to tinker. Hardware Overcurrent means the drive is working too hard to power the motor. If it is a parameter issue it's probably because someone changed the motor nameplate data or maybe the carrier frequency. It's far more likely the problem is in the wiring between the drive and motor, or the motor itself, as suggested by @Joe E..  

My question is what happens to the parameters when I do the "static tune" ? Autotuning introduces a drive to a new motor. It sets the best possible values for IR Voltage Drop (P73), Ixo Voltage Drop (P74), Flux Current Ref (P75), and Slip RPM (P621). You only need to autotune when you're installing a new system or replacing a motor on an existing system. If you're replacing a drive and downloading a known good program from the previous drive, the autotune values will still be valid so long as it's the same motor.  The Static Tune energizes the motor but does not rotate it. Rotate Tune turns the motor without load coupled, while Inertia Tune turns the motor with the load coupled. Never autotune with process material present in the system, as this will throw the whole thing off. So if you're tuning a drive/motor where the motor is permanently coupled to a pump and the pump is cooled by the process material (and therefore can't be run empty) Static Tune might be the preferred method. and another question, is there a way to do only "static tune" without going thru all the steps in the startup wizard? You can access the autotune at parameter 70. From the HIM, select the type of tune you want to use, hit enter, then start. Also, if you're in the Wizard in CCW you're allowed to jump back and forth to any step you care to simply by clicking on the desired label in the Wizard Step menu. Since you have CCW available, before you start tuning you should run the Compare tool on the suspect drive against a known good drive. This might get you to the problem quicker.  Hope this helps and let us know how it worked out

In the PowerFLex 700, parameter 174 should be "Auto Rstrt Tries" and when it's set to 0, auto-restart is disabled. Set to anything 1 or above to enable the auto restart feature. Parameter 175 sets the time delay (in seconds) between restart attempts.

And, can you supply a pic or drawing of your wiring?

What specific model of 1400 do you have?

The power supply in a Logix device (whether ControlLogix, CompactLogix, SLC, or MicroLogix controllers) supplies power only to the cards in the chassis backplane, or the I/O modules (if added on expandable units) on a Compact- or MicroLogix bus. Power for the field devices must be wired from a separate, external power supply. Remember that digital outputs in any Logix controller are just optically isolated "relays" to conduct power from an external power supply to a field device. When an physical output is on (true in the logic or force table) you should get an LED indicator on the associated Logix module output status indicator. If you're getting that LED saying you should have an output, that means connectivity is established between the field power supply and the filed device, same as if closing a normally open contact on a relay. So, make sure you have an external field power supply properly wired to your MicroLogix controller and the field device(s). If you have a field device power supply properly wired, it's power is on, and you're getting the LED status indicator on the PLC's output, you need to check your I/O module and field device to make sure they're matched for sinking and sourcing. Not going to get into that here, but check the manual in this attached link, chapter 3: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1766-um001_-en-p.pdf If the field power supply is wired correctly, the LED status indicator on the PLC's output is on, your field device and PLC are matched for sink/source, and you're still not getting the output, the output itself may be bad. In ControlLogix chassis we can disable an I/O card but I'm not sure if that's true in the Micro-1400. Again, check the manual. Hope this helps.

You must use the driver for the communications format for that controller or network, and the driver must be properly configured. All Micro -1000 controllers should have DF-1 (RS232) embedded within them, and many have DH485. These are the only two drivers you'll likely ever need on a Micro-1000.  Whichever one you were using successfully before is what you should try to continue to use.  Serial drivers like RS232 can have several configuration settings, whereas other drivers, such as DH+, may only need to have the correct com port number set. I'm a fan of using the Auto-Configure button when it's available. Once you're back online with the controller, I'd use the "RSLinx Classic Backup Restore" utility to create a backup of the known good driver configuration. This link for the MicroLogix 1000 manual be helpful: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1761-um003_-en-p.pdf Chapter 3 is communications.