ElectronGuru

MrPLC Member
  • Content count

    366
  • Joined

  • Last visited

Posts posted by ElectronGuru


  1. Sounds like you found it. Each family of I/O cards have their own options, all with similarities and differences. The 1756 analog output diagnostic cards have a feature that lets you ramp to the user defined value in fault mode. The 1768 input cards have output files that aren't even described in the manuals. Sometimes we just have to muscle though it with trial and error to what works. 

    1 person likes this

  2. Counting from 0 - 1000 in 500ms is pretty quick when related back to changing the state of an output. Any compare instruction (EQU, LIM, etc) will only remain true for the period of time the .ACC is either equal to, or within the limit of the instruction, which is this case is likely just a few milliseconds. 

    When I've come across similar challenges I've had pretty good luck using an OTL as the output instruction. Even if the EQU is true for only 1ms during the scan, that's enough to latch the output regardless of whether it's in a continuous, periodic, or event task. The drawback is, of course, you will now also need an OTU to unlatch the output at some later point.

    As mentioned above, more info about your controller, version of Studio, and process would be helpful.

    1 person likes this

  3. Logix controllers do not have regularly scheduled input and output scans in the same manner that an older SLC500 did. Logix looks at tags as needed when the code being scanned is utilizing said tags.

    As for how much time a controller spends actually scanning tags/code, that is a matter of how many rungs of code, how well the code is written, etc. The only way I know to decrease the scan time is to write and organize the code to scan as efficiently as possible. I don't know of any "gas pedal" we can push to make it scan faster.

    I assume you're looking at the scan times in the task monitor(s), yes? You're not looking at the watchdog timer setting? There is a limit to how long the code is allowed to be scanned, which is set by the watchdog timer.  In Logix, each task will have its own watchdog timer with a default setting of 500ms (same as your stated scan time), which can be changed from 0.1 to 2B ms. Whatever value the watchdog timer is set to is the longest amount of time the task is allowed to be scanned before the watchdog timer for that task throws a controller fault. I'm only mentioning this because your stated scan time is (perhaps coincidentally) the same as the watchdog default setting, and I just wanted to make sure we're on the same page.

    Hope this helps. 

    1 person likes this

  4. If the TON instruction is repeatedly restarting in the run mode you may have a free-running timer, which is a timer that is deliberately resetting itself through its own .DN bit. The Timer.DN tag is placed on an XIO instruction in series with the TON, and it runs over and over and over, without ever stopping. This is only one of a hundred possibilities. Two things you can do:

    1. Right click on the timer tag and run a cross reference report to find out everywhere it's being used and figure it out.
    2. Follow @Michael Lloyd's suggestion and post the code here so we can try to help you narrow it down.
    1 person likes this

  5. Electricity is extremely predictable except in three scenarios: ground faults, arc faults, and lightning. In those cases, typically all bets are off. It is interesting that you had false indications on only one of several I/O cards on a backplane. When something like this happens, I usually ask myself, "what's different". Some random thoughts, in no particular order:

    • With no minor faults in the fault log, I'd be inclined to think that no faults occurred and this is truly an electrical field device/wiring anomaly, rather than a card problem.
    • Are the limit switches physically located where they might be more susceptible to stray currents during bad weather than other related I/O?
    • Is the shielding or grounding different on this card or its I/O points/field devices compared to others on the backplane? 
    • Did you get this error on inputs 0-3 and 4-7?
    • Is the 24V field power supply shared with any other I/O?
    • Have you checked the RTBs for dust or loose connections? Find anything that looks suspicious?

  6. Auto-tuning is the process of introducing a new motor to a drive. It typically only needs to be done on new installations, or when a motor is damaged and needs to be replaced. Most rotating auto-tune functions will energize the motor for a few seconds without rotating it, accelerate the motor to something below its nameplate rated speed, decelerate to energized but not moving again (ramp to hold), and then announce, if it's a good tune, that auto-tuning is complete. 

    The reason for this is that every motor has its own "finger print", and auto-tuning allows the drive to become more familiar with that particular motor. Once auto-tuning is completed, the drive and motor will run more efficiently together, and presumably last longer. You don't need to monitor or change any parameters during this process; just let it run. Personally, I prefer to run the auto-tuned without the motor being coupled to the load. Some drives will offer coupled (inertial) tunes, while other may require uncoupled (rotational) tunes. But you should never have process material in the system if you do a coupled auto-tune.


  7. There are only two jumpers that I know of on the MCB for the PowerFlex 755 drive; Safety and Enable for frames 1...7, and Enable for frames 8...10. So if this is possible, I don't think that jumpers would be involved.

    It might be possible to find the two or three tabs on the plug part of the MCB that are for power, hook power to them, then program while communicating via the Ethernet or serial ports. But without an adapter made for that purpose, I would be really warry of trying that. Again, if anyone else knows of a safe and effective method of doing this, please jump into the thread. 

    @VFD Guy, you ever hear of this?

    Question for @MTPControl; Why do you need to configure the MCB outside of the drive?


  8. Not that I'm aware of. The main control board (MCB) is plugged into and powered through the backplane. I don't know of any safe means of attempting to power the MCB inside or outside of the drive without line power applied to the drive. If anyone else has a method for this, I'd like to hear it.

    If you have drive tools software, such as Drive Executive of Connected Components Workbench, you can configure your drive offline and then download the project to the drive once you're ready for power. If you're using ControlLogix, you can configure the drive in Studio5000 and once all the power and networks are up and running, the controller will take over the drive for you.  


  9. This means that you have an L7 or L8 controller with the digital, scrolling display, and that display is currently saying "No Project".

    If so, you are correct that the controller literally has no project. This happens only under a few conditions:

    • You have purchased a new controller that has never had a project downloaded to it.
    • For a few moments when performing a download. (One of the first download steps is deleting the current project),
    • When the controller has a major non-recoverable fault.

    Is there also a red fault light activated on the front of the controller? If so, this means the controller experienced a major non-recoverable fault, and has cleared its own project. This is generally considered a hardware failure and as often as not means the controller will need to be replaced.

    You can try downloading a project to the controller and see if it starts running normally. If it doesn't, you may try to flash the firmware on the controller and then download. And if that doesn't work, replace the controller. 


  10. I'm not an expert on this drive but I do know that most PowerFlex drives do not allow you to adjust the bus voltage thresholds. You can only program (on some drives) what happens when a bus over- or under-voltage condition occurs.

    As you likely already know, the bus voltage will typically go low for one of two reasons:

    1. The incoming power is low
    2. There's a problem with the axis motor or wiring that's pulling the voltage down.

    I've attached a link to the PF527 user manual, and Technical Specifications on bus voltage voltages can be found in Appendix A on page 137.

    I would check the specs against your specific drive, check the actual bus voltage with a meter at the DC+ and DC- terminals on the power terminal, and work from there.

     https://lvmcc-pubs.rockwellautomation.com/pubs/520-UM002C-EN-E.PDF

     

    1 person likes this

  11. Sorry, @VFD Guy, I miss-spoke (-typed) myself. The firmware is fine; it's the EDS that's a pain.

    As most of us know, the EDS is just a text file that shows information about the device, does a couple of minor background things, and mostly just shows a pretty pic of the device in RSLinx. Typically, when you have a new profile your laptop hasn't seen before and you get that yellow question mark in RSLinx, you can just upload the EDS for that new profile from that device via RSLinx and be done with it. You can still right-click and upload the PowerFlex 520-series drives' EDS from RSLinx, but it's a few hundred files across several folders, and you have to use the EDS Hardware Installation Tool to install and get the EDS running.

    For anyone who's not used to the EDS installation tool, I've attached a short doc specific to the PF525 EDS download and installation. If anyone has a better, quicker way, please share!

    EDS.pdf


  12. Not sure. Even though the release note says it was first noticed in V4.x, I know for a fact I had six PF525 drives with V3.x that the USB ("MainsFree Programming") feature wouldn't work on. That's the first time I complained about it, around three-ish years ago. This last January I had another batch of 525s come through and thought I'd re-check since the customer wanted to use that feature and sure enough, they'd finally fixed it.

    BTW, flashing the firmware is as easy as it can be. Getting it downloaded and installed on your laptop, not so much.


  13. @RobinEriksen it should transfer the values for all the changed parameters for the drive. In your OP you said the drives aren't networked, so you shouldn't have to worry about duplicating node addresses on multiple drives. Once the transfer is complete, aside from auto-tuning (if needed) you should be able to "plug-and-play".

     

    @VFD Guy From the release notes for PF525 latest firmware revision, V7, released Dec 2020:

    "USB connection is unresponsive on Windows 8 and 10 (PCBANOM-1471)

    Corrected Anomaly with Firmware Revision 7.001

    Known Anomaly first identified as of Firmware Revision 4.001

    Catalog Number: 25B

    PowerFlex® 525 with firmware revision 7.001 and later supports the USB application with Windows® 8 and 10."

     

    Full release notes here:

    https://compatibility.rockwellautomation.com/GeneratedReleaseNote.aspx?v1=59671&v2=59671&o=&pdf=0

    1 person likes this

  14. With the power off, remove the control module from the front of the drive and look in upper left-hand corner to find a USB port. Plug that into a laptop and a new device icon should pop up on the laptop. Click on it and follow the prompts to upload the parameters to the laptop, then reverse the process to download to the other drive. 

    One thing to be aware of is this procedure doesn't work well with Windows 10 unless both drives have firmware revision 7. If they have a lower version, just use a Windows 7 laptop or VM. No other software will be needed.

    You can also download Connected Components Workbench (CCW) free from the Rockwell website, here:

     https://compatibility.rockwellautomation.com/Pages/MultiProductSelector.aspx?crumb=111


  15. Your Logix controller is looking at five different things to make sure I/O can is compatible for use: vendor, product type, product code, major firmware, and minor firmware. There is what's stored in the Logix profile, and there's what's actually on the I/O card. Electronic keying is making the comparison to see if the physical I/O card "fits" into the stored profile. 

    There are three possible configurations for electronic keying:

    1. Exact Match - All five categories must match exactly.
    2. Compatible Match - First three categories match but whatever firmware is in the physical I/O card must be the same or higher as the firmware stored in the ControlLogix profile.
    3. Disabled - doesn't matter what type of card it is or what firmware, Logix will try to use it. (Never do this).

    So if it's telling you that your problem is firmware revision, you're either set to exact match and they don't, or you're set for compatible match and the physical card has a lower firmware than the Logix profile. If you're set for exact and the process (including safety and company policies) allow for it, change it to compatible. Otherwise you may have to flash the card to the desired, matching firmware revision. 


  16. @Joe E. I didn't intend to misrepresent your remarks. I, too, would've used the word gibberish to describe data that I can't use because the formatting is incorrect, and I believe that's what you were saying.

    When teaching I often describe COP colloquially as "a more powerful MOV". I had responded above to @VFD Guy that since COP is used to move arrays of data around, I don't understand how it's used to convert Float or REAL to DINT and have meaningful results.

    My question to @VFD Guy and @panic mode remains; how do you use COP to successfully convert a REAL to a DINT and have the result be useful, since the resulting data looks nothing like what we'd want it to? I've also run into the decimal point thing with PowerFlex drives and have always just used the MUL to get rid of the decimal point so the drive will respond as desired.

     

    On 4/15/2021 at 8:45 PM, VFD Guy said:

    Get the reference I want as a real, copy to a DINT, send the DINT to the drive, the drive (750 in this case) would convert back to a real. You can look on knowledgebase.

    Are you using the COP in lieu of MUL? If so, is that the only application for this method, or is it something can be used anywhere you're converting REAL to DINT? Or is the drive truly taking a controller's REAL value of 45.5Hz COP'd to the DINT value 1110835200 and converting it back to REAL?

    I hate to sound like I'm slitting hairs or beating a dead horse, but I feel like there's something fundamental I might be missing here.  


  17. Getting back to the OP's question:

    Sending a DINT to a REAL (or vice versa) via a MOV instruction is ok if you're not worried about losing the fractional value (anything to the right of the decimal point) of the data. REAL to DINT, the DINT truncates the decimal data and rounds. DINT to REAL adds the decimal point, but the fractional value is 0.

    @panic mode 

    On 4/15/2021 at 8:18 AM, panic mode said:

    viewing 5.0 as integer will show up as 1084227584 because data format is ignored. this is not gibberish... it is interpreted as wrong format and hence displayed incorrectly.

    If that's the case, in a practical sense, how is the COP data then useful in controller code? If it is the correct value that is merely displayed incorrectly due to formatting, will a controller or drive still respond correctly to that value in that format? 

    Let's say I COP a REAL value of 45.5Hz from controller to drive via Ethernet. The COP instruction is going to send 1110835200, yes? I don't have a drive available to test this, but I'd be blown away if it actually went to 45.5Hz.

    Have I been missing the bigger picture this whole time? If so, please show us the magic worm hole that would allow skipping the additional code I'm currently having to write to re-scale and drop decimal points whenever I'm forced to mix and match data types. 


  18. There are only about a million things that could cause this. The PF755 gets it's speed command via a parameter called "Speed Reference A" or "-B". When troubleshooting speed problems the first two things I ask myself are:

    1. What is the speed reference?
    2. What is its value?

    So is the speed reference coming from the HIM? From ControlLogix? From an analog input? Once you've identified that, figure out what the value is and determine whether the drive is responding correctly. You said the commanded speed ref is 60 but it's only producing 40. Are you sure there's not a preset speed that's been activated? Has an input been programmed and activated to make the drive switch to Speed Ref B? That's the most obvious stuff to start with, and I imagine you've already checked. 

    Use Connected Components Workbench (CCW) or the older Drive Executive to go online with the drive while it's running and view parameters 935 and 936, Drive Status 1 and 2. This will tell you at a glance what the drive thinks it's doing. So if @BobLfoot is correct and you've hit a current limit, it should jump off the page at you in P935.

    In no particular order, here are some other ideas;

    • Are these drives new, or have been installed for a while and just started doing this? If new, it's likely in the drive configuration. If this is a new problem on an existing system that was previously working, starting looking into what changed. Did someone screw with the parameters? Was someone digging around in a control cabinet and knock a wire loose? Etc
    • Don't forget to check for obvious things outside of the drive like mechanical binding, bad motor bearings, etc.
    • Do all four drives do the same thing? If so, use Drive Executive or Connected CCW to run a compare tool against a working drive to see what's different.
    • CCW has a feature that allows you to view only the parameters that have been changes from their default values. The is a really helpful tool is you suspect programming.
    • Continuing in that same line of thought, particularly on new installations, mis-programmed parameters are the likely cause of drives not responding correctly. If the motor name plate says max speed is 1200RPM but you don't want your process to run more than 900, then set the motor name plate parameter value to 900, that will give you a lot of scaling / speed control issues. (Proper to set name plate parameter to 1200, and the separate "Max FWD Speed" parameter to 900). Are you sending a signal that you think calls for 60Hz but the drive is programmed for RPM?
    • The same thing applies to encoder programming, if you're using one. Leaving the encoder resolution at the default value of 1024PPR when you actually have a 3K will cause issues. 
    1 person likes this

  19. @VFD Guy according to Rockwell literature and my personal experience, mixing and matching data-types always carries the possibility of rounding or truncating errors. So while moving a a DINT value of 60 into a REAL will produce a REAL value of 60.0, moving a REAL value of 60.5 into a DINT will produce 60. When a rounding error occurs, ControlLogix tends to round to the nearest even number, just like the manuals say it will. If you're always dealing in whole numbers and never going outside of data type value boundaries, you can get away with a lot. Unfortunately, my life has not been quite so sheltered, lol.

    I'm not sure how COP applies to this situation, since in ControlLogix the COP instruction is used to move a contiguous array of data, not a single value. Can you COP a single value with a length of 1 and get a conversion? If so, please explain how. I've just now tried it and got some crazy results. 


  20. There are several different operands in a MAM instruction and depending on the controller, the data types for the various operands can be DINT, REAL, UINT, AXIS_CIP, AXIS_VIRTUAL, etc. Within the code, if you right click on the instruction and click on Instruction Help, it'll lay out exactly which data type goes with which operand within the instruction. 

    If somewhere in your code the original programmer is moving DINT values into a REAL data type, or vice versa, you might have some rounding or truncating going on, but it could still be workable. Mixing and matching data types is never ideal but if a programmer has no choice, they can often account for those decimal point issues by offsets, buffering, or other tricks of the code writing trade. I've had to play with this myself when I realized the REAL 60.0Hz my controller was sending was being read by the drive as 60, since the drive only had INT available and apparently didn't recognize decimal points.