ElectronGuru

Can you compare these values to the one that does work with local/manual control?

I read your last response about the parameters 62, 63 , etc and completely missed your previous post about your display indications and wiring. This actually changes some things, so sorry, here goes another (belated and out-of-sequence) post.  The fact that you're not getting a RUN indication on the display means that the command module is essentially ignoring the keypad start input. This means you may have an active stop or safety.  Terminal 4 is the digital input common for sourcing (as opposed to sinking) inputs, and has no programmable function. If you have no other digital inputs, I'm wondering why there's a wire landed there.  Digital input 1 is always the hardwired stop. Whether it's sink or source, you remove the 24 volts from there and the drive stops. This is why when there is no hardwired stop/stop controls there's a jumper between 1 & 11, keeping DI-1 hot. Just for kicks, put a volt meter on DI-1 and see that you have voltage whenever you're trying to start the drive. I believe this is tied internally to the safety 24 volts, as well. Are you using the safety circuits? If so, this is likely what's keeping you from starting manually.  The programmable digital inputs are on terminals 2 & 3, and 5 through 8, and they are programmed at parameters 62 & 63, and 65 through 68, respectively. The defaults are usually benign and wouldn't cause a start inhibit if nothing is wired to the terminal, but I'd set them all the 0/Not Used just to be sure. As for viewing the parameters on the laptop, Connected Components Workbench (CCW) is free and it will change your life. Download it and you can get on any PowerFlex drive without Studio5000.  If absolutely none of these suggestions work or even lead you to the solution, it's unlikely but not impossible that you may have a bad button on the command module. if you run out of ideas and have the down time, try swapping it with a known good one. 

My experience is that when you close and re-open a display that has a trend object, you're starting from scratch with all new trend data regardless of which PanelView model it's running on. In fact, I've seen the trended data disappear just by stopping and re-starting the trend without having closed the display. I believe the default path for PanelView trend data is Windows CE > C:\Logs, and while the data should always be available there (or wherever the configured Data Log path takes it), I don't believe the trend object itself will hold previously trended data.

62 and 63 are digital input functions for terminals 2 and 3 respectively. There are over 50 possible settings for each of these and yes, they can keep your from starting the drive.  64 is used to determine how the start source is triggered when using 62 or 63 are being used as a 2-wire control start source. 

Are those the values of the drive status parameters after you push the start button on the keypad? If not, see what those values are while holding the start button down.  Do you have a FWD/REV indication in the upper-left of the display? Do you ever get the RUN indicator directly above the FWD/REV? Do you have any hard-wired digital inputs for external start/stop/speed commands, jog speeds, etc. Besides the safeties, any hardwired inputs at all and what are they programed for? Something (obviously) is inhibiting a manual local start on this. Just gotta figure out what it is. If you have a different 525 drive that is working in manual, best thing would be using CCW to run the Compare Tool on them. Do you have CCW? It's free download if you don't.

@BobLfoot I believe 391 is Step Logic, not Stop Logic. This displays the current step of the Step Logic profile, assuming step logic is being used.  There is also a Drive Status 2 at parameter 393 (previously suggested) that could be helpful, but the drive status parameters need to be viewed while trying to run, and I don't think he's done that, yet.

To be clear, do you have a jog input button hardwired to the drive? Starting the drive from the keypad is not "jogging" it. The green button on the keypad is giving a "run" signal. To truly jog the drive you would need to wire a jog button to the input terminal block and program that input to be the jog command.  So if it's running and at speed, the drive thinks it's running at the commanded speed reference. This means the network speed reference source is giving a speed signal of zero hertz/rpm. What are the values of drive status one and two when you're trying to start in manual, with keypad and local pot in control?  Also, check the factory jumper between terminals 1 & 11 (I think). A lot of people remove this jumper and without a hard-wired stop button, it disables the drive. Look in the I/O wiring section of chapter one of the user manual to be sure of the terminal numbers. Since you're getting a run indication with network settings active this is probably not the problem, but it's too easy to not take a glance at. 

Do the drives run from their normal start/source(s) on the network? Check parameters 6 and 393, Drive Status 1 & 2. Use these to try to see what the drive is seeing. Can you attach a copy of the CCW file so we can look at the whole drive?

You might try using an Enhanced Select (ESEL). You can have up to six inputs and the SelectorMode parameter allows the instruction to decide which input is selected. You can choose from manual, high, low, median, or average. 

You can add and remove forces individually at any time for both analog and digital tags. But when you enable forces, you're enabling (and disabling) all installed forces all at once. If you add a force while forces are enabled, that new force value will take effect immediately.

Yes, that's the setting I was referring to and you already have it as low as it will go.  It's bizarre that you only lose updates on two things, a fill animation and system clock, and only on web-page. Especially considering they're simultaneously working on the Clients.  Are there other animations on this display that do work? If not, publish some displays that have other animations and see if they have the same issue to try narrow down if it's all animations, or just the fill. Not sure what to think about the system clock hanging up as well. How is that being displayed; via text box?, screen default?, other?  

So the problem only happens on the web-page, and happens regardless of where your viewing from. And never happens on the Clients, regardless of where viewing from. I assume you mean the system clock on the web-page is also stopping; not the actual system clock in the controller.  If all of that is true, I have to assume that it's not just the system clock and fill animation, but likely the whole web-page display that's freezing. This could be a network problem, even though it's happening on the development computer. Did you check the synch settings in the VP Admin?

Your shared files are password protected. 

You didn't include very much information, so please forgive me if my answer is a bit long and focused on the fundamentals. If you could include more details, like what specifically you want to have happen as the result of the button being pushed, it would be quite helpful. First off, the button should actuate immediately when pushed. There is no OSF or other instruction in the HMI pushbuttons.  In the momentary push button's properties dialog box, under the General tab, you can choose whether the button is normally open or normally closed. If the logic is set the reverse of what is required for your process, you might think it's not acting until released. There is also a "Hold time" which holds the pushbutton's changed state signal to the controller for the selected amount of time, regardless of how long the operator actually pushed the button for. The states tab is where you set how the button appears when it is not pushed, vs pushed. A momentary pushbutton only has two states and by default, they are exactly the same when the button is initially drawn on the display. If the states are not edited, this could lead someone to think that nothing has happened until the button is pushed or released. For any of this to work, there must be a tag assigned in the connections tab. Without an assigned tag, a momentary pushbutton is an object without any function and when you push it, nothing will happen. Hope this helps.

To expand on @BobLfoot's answer: In SE, the controller tag data goes to an HMI server, and from there it is displayed on either an SE client or web page. When you say it doesn't always update, are you saying this is an intermittent problem? If so, and assuming this is not happening on the development computer, I'd want take a glance at the network and see if anything else (like an SE client) is having update issues. If you have SE clients (in addition to the web page), check to see whether they're updating in a timely manner. If you don't have any clients, create and launch one and see how it does. In FT ViewPoint Admin, under the Server Settings tab, check the tag update rate and display synchronization settings. Also, don't forget to check the obvious stuff, like making sure that in the HMI display itself, the tag update rate isn't set to something silly, like 60 seconds.

Firmware is the bane of all controllers/software. PCDC can only do a controller-by-controller compare and it's super-inconvenient that Rockwell doesn't have a master list somewhere. So over the last few years, while sitting on airplanes with nothing else to do, I made my own, attached here. You're welcome. One caveat; I went controller-by-controller by myself and have not had anyone verify this for mistakes. If this was a map, there'd be a "not intended for navigation" disclaimer, but it has been a great cheat-sheet for me since I created it. Hope it helps. CLX FW Chart.xlsx

OOPS! Just noticed I re-posted something that was done a few minutes before I posted, and then addressed it to the wrong person. Sorry! KD_PDF.pdf

You posted this question in a different thread. Here's the answer I gave there: "Test Display is a feature of the FactoryView Studio (programming tool) where you test a single display's functions when writing the code. You're testing whether a numeric display or text box accurately shows the value of an analog tag in the controller, of if a momentary pushbutton does, in fact, actuate a controller's XIC instruction. Test Display tests only one display at a time, and cannot interact with other displays or project-scope features. As such, certain objects on your display, like display navigation buttons, login/logout buttons, shutdown/goto-config buttons, etc, will not work in Test Display. To test those types of objects you would have use use the "running man" icon to Test Application, which would create a temporary .MER application and launch it on your laptop, and this would would give you full functionality. Test Display and Test Application are project development tools only. They are intended to be used during project development to test your programming before you create and download a .MER file to the PanelView. They should not be used as the primary operator interface with your process".

Test Display is a feature of the FactoryView Studio (programming tool) where you test a single display's functions when writing the code. You're testing whether a numeric display or text box accurately shows the value of an analog tag in the controller, of if a momentary pushbutton does, in fact, actuate a controller's XIC instruction. Test Display tests only one display at a time, and cannot interact with other displays or project-scope features. As such, certain objects on your display, like display navigation buttons, login/logout buttons, shutdown/goto-config buttons, etc, will not work in Test Display. To test those types of objects you would have use use the "running man" icon to Test Application, which would create a temporary .MER application and launch it on your laptop, and this would would give you full functionality. Test Display and Test Application are project development tools only. They are intended to be used during project development to test your programming before you create and download a .MER file to the PanelView. They should not be used as the primary operator interface with your process. Has your company got a dedicated laptop at each machine and using it as the HMI? Or perhaps a client at each machine fed from a server that has FTME? How and why are you controlling your processes form Test Display?

I think all the PanelViews use FactoryTalk View Studio Machine Edition, known more commonly as FactoryTalk ME. 

I always thought is had to be fourth or closer, and I think closer is probably better. But if you have a system working well with four modules between the controller and power supply, then clearly the controller can be the fifth module. Wish they would've show a pic for us over-thinkers, lol. 

I believe the controller card must be in the fourth slot or closer to the power supply. If it's in the fifth slot (four cards between the controller and power supply) it's too far.

As @pturmel said above, more details would be helpful. But since you said you're trying to ping the controller, I assume you're using ethernet to connect. If the laptop can't see the controller (not responding to pings) then RSLinx, which lives on the laptop, will not be able to see it, either. You'll have to get response from the ping before Linx will be able to see any given node. After checking that the ethernet card on your laptop is installed and working properly, check the TCP/IP4 settings. The laptop's IP address is usually set to "obtain automatically" out of the box. If you're not using BOOTP or DHCP, you'll need to change to the laptop's address to match the controller's subnet and subnet mask. Hope I'm not preaching to the choir, but I've attached a quick reference doc that I give to beginners who are learning how to connect via ethernet for the first time.   Ethernet Settings In Laptop.pdf

You're showing three ladder files: File 2, File 28, and Pumps. Are you sure that all three of those are being scanned? Are there JMP/LBL or MCR sets being used in File 2 or Pumps? You're sure you've saved any recent edits and the Cross Reference Report is up to date; no sneak bits lingering further downstream writing a zero back to the output after this rung has been scanned? Just for grins, create a temporary branch rung around the existing XIO N30:6.8. On the new branch, grab an unused B3, put it on an XIC, and manually toggle it. Probably won't make a difference but that will point more directly back at code scans being the likely problem.  It's been a minute but I believe the Logix500 has "Test single scan" and "test step" modes where you can run the code one full scan at a time, or step through code the code one rung at a time. If it's not something obvious that we can't see from your pics, you might try that to see where you're getting hung up.  Hope this helps. 

@alan_505 thanks for sharing the dates. I'd heard they were going to discontinue the SLCs earlier than planned due to supply chain issues that came up during Covid.  I just looked up RS 500 on PCDC and found that V12 is the only one available, and it's currently showing grey in its life cycle status (the next step being red/discontinued). I'd say that means they're going to stop selling & supporting RS 500 about the same time they end the SLC hardware support, Sep '24..