Joe E.

I'm generally a big fan of AB stuff, especially PLCs and drives. Their old PanelView Standard HMIs were solid...but I've never liked the PV+ line. The Micro 800 series PLCs and PV Component HMIs are also on the "avoid" list.

Here are my standard steps for weirdnesses in FT View Studio, especially with the communications shortcut. It's worth a shot here too. Delete-recreate the object, then make a new MER. If that doesn't work, close VIew Studio and re-open it, then make a new MER. If that doesn't work, reboot the PC, then make a new MER. Is that the only object that uses that font? With the PV+ being a Windows device, that may be doing weird things. I'd try another font as a test. If it works with the new font, try changing it back.

To maybe help isolate it, do you have an external monitor you can plug in? Try it both mirrored and extended.

We have a mess here. Before I started last February, they didn't have anyone really specifying stuff. On our older AB machines with SLC500s, we have PanelView Standard HMIs. The newer machines with Logix 5000 PLCs have PanelView+, PanelView+6 (compact and standard), PanelView+7 (standard and performance), Red Lion Kadet, Maple Systems, and Schneider HMIs. Those are the ones I've found so far; there may be more. The ones with the higher end PV+6/7 HMIs don't need them at all but they're using them anyway.

panic mode's description is a more elegant version of what I had stewing in my head. It just wouldn't come out as coherently for some reason...

Like Bob, I haven't used it except to open a test project to see if I could figure out how awful it was (sorry, FT View Studio and CCW may have me a bit biased against AB's newer HMI software...). I don't have that same issue in my test program. I'm using View Designer v6.01 in a virtual machine running 64-bit Windows 7 Professional, SP1. My first thought, honestly, is video drivers. I've had weird things happen video-wise that had nothing directly to do with the software in question.

My rough draft that I mentioned above did something similar except all of the PLCs were in machines on the line. IOW, one machine served as the data concentrator and gathered all of the information from the other PLCs on the line. The first word of data that was transferred was binary flags and the first flag was a heartbeat that the data generator flashed. The recipient then monitored its status to see if it stopped blinking. If your data collection PLC is always on and your network is reliable enough (ours wasn't down there), you can use the heartbeat to track when the machine is powered off. Of course, you're going to need an "extra" PLC which was another expense we didn't have the budget for. When I did it, all I could use was hardware we already had.

Wow, that thing has 41 programs in the continuous task...that seems like a lot. It's also a SoftLogix processor (running on a PC instead of a dedicated PLC). So, the UDT "In" tag is controller-scoped, which makes sense since it's holding Input data. As an entire tag, it's used destructively (written to) about 20 times by external routines. These are only available in SoftLogix and I have no idea what they're doing since they're not part of the ACD file. All of the other destructive instructions refer to individual bits except one place in one program where an array of all 0s is written to UDT member In.D when INPUTS_BYPASS is active. Short answer...you're past my experience now. I've only ever worked with SoftLogix once, in my first automation-type job when I was a multi-craft maintenance and all we could do was go online to look at the ladder code for troubleshooting (not change anything). And that was about 15 years ago. The online help refers to DLLs and to the SoftLogix5800 System User Manual (1789-UM002) for more information. As an example, the first JXR is in the program FirstRoutine, subroutine CallScheduledJxrs and calls the routine ValveGFileStatus. That shows up in the controller organizer as a routine under the FirstRoutine program. Double-clicking on it gives you the configuration dialog which shows the path and filename of the DLL file. A quick look in the user manual shows that the DLLs are standard Windows DLLs that are developed using any standard software development software like Visual Studio. I don't know how much access you'll have to the actual DLL from within RSLogix without having a source code version of it. I'm afraid I'm going to have to hand you off to someone else at this point.  

I sent you a PM with my email address if you want to send it that way.

It looks like they're using some user-defined-types (UDTs) to buffer the physical inputs. "Input Table for cyclical data" implies to me that they have a subroutine somewhere that maps the physical inputs to byte registers inside the tag called "In". Inside the tag "In", there's an array of registers called "D" that the inputs are copied into. Can you share the ACD file?

The value of PLUG_INDEX is indeed the array index and will determine which sensor you're looking at. Find that tag in the tag database and cross-reference it. Either select it and hit CTRL-E or right-click on it and select cross reference. That will give you a list of where it's used. Look in the "Destructive" column for entries marked "Y". Those instructions change the value of the tag. If there aren't any...it's a little more complicated and may be changed by the HMI. Hopefully it only changes on machine setup/startup... Note: there are at least 2 tag databases in the controller: controller-scoped tags and program-scoped tags. Each program will have its own tag database and you can have multiple programs per task and multiple tasks per controller. Look first for the tag in the tag database for the program you're looking at, then look at the controller tag database.

Hmmm....that's interesting.... I've written code in the past to track downtime but it was a rough draft that didn't get to the point of handling power off conditions. One thing I did was use a GSV instruction to get the current wall clock time. You can make sure that your first scan or power up routine has a GSV for wall clock time that executes before whatever code you're using to track time-of-day. You would then build in code that would be able to "fill in" shifts that elapsed since the last time-of-day was updated. Code could get interesting with loops if more than a shift has elapsed, but should be do-able with loops. IOW, on power-up, grab your last "time-of-day", which should be one scan before it was powered off, and store it. Then see if you're still within the same shift. If so, elapsed time since last "time-of-day" to "now" will be added to your maintenance downtime register and then you just continue on. If you've spanned a shift, it gets more complicated. I looked quickly through the major and minor faults and didn't see anything right away that would trigger when power is lost, but there may be something. If so, you may be able to use the fault handler to record the current time and set a "Maintenance" flag of come kind, but I'm not sure how useful that would be...hmmmm.... I'm out of time now, but I'll be thinking about it over night (whether I want to or not...;) )

Do you have FactoryTalk View Studio for Machine Edition? If so, it comes with a program called "ME Transfer Utility". You can connect to the HMI and use the utility to upload and download the runtime file. However... It's possible to have multiple runtime files on the HMI at the same time and you can't tell which one is the active one without getting to the system's configuration mode. If the transfer utility shows that there's only one runtime file, well and good. But if there are more than one it probably won't be obvious which one is the correct one. To figure out which runtime file is active, or if you don't have View Studio, you'll need to access the configuration mode of the HMI. Here are some links that may be helpful: https://theautomationblog.com/how-do-i-access-the-panelview-plus-configuration-menu/ https://www.youtube.com/watch?v=k3E7bjhBDVA https://theautomationblog.com/panelview-plus-white-square-missing-or-f1-not-opening-configuration-mode/ If the unit boots up and otherwise works but doesn't respond to touch, you can plug in a USB keyboard/mouse. I have a wireless combo that uses one transceiver for both the keyboard and mouse that works like a champ for this.  

Sorry, man, you're now beyond my experience with these things. The only place I've ever seen them used is to interact with a dataliner display for the operator to enter a few parameters. Does it look like the code you see in the PLC is complete? Can you tell if the -DB is doing some machine code?

chelton: That's good to know! I know one of the biggest problems I've had with USB converters was communicating with PLC-2s, so it's good to know that the -DB works. Did you use the 1784-CP10 that OP mentioned? Or just a 3-wire null modem? The -CP10 has jumpers on some of the pins. spark man: is this a machine that's running? If so, is there any way you could power down the chassis and pull out the BASIC module? I'd be curious if it's actually doing anything in the process. Is anything connected to the comm ports during normal operation? Some of the machines I've seen that had BASIC modules weren't using them any more.

chelton: That's good to know! I know one of the biggest problems I've had with USB converters was communicating with PLC-2s, so it's good to know that the -DB works. Did you use the 1784-CP10 that OP mentioned? Or just a 3-wire null modem? The -CP10 has jumpers on some of the pins. spark man: is this a machine that's running? If so, is there any way you could power down the chassis and pull out the BASIC module? I'd be curious if it's actually doing anything in the process. Is anything connected to the comm ports during normal operation? Some of the machines I've seen that had BASIC modules weren't using them any more.

Have you used a USB converter with the 1771-DB? There are some devices out there, especially older ones, that won't work with USB adapters but need a native port.

I've been around machines that had Basic Modules installed, but never interacted with them. Do you have the manual? I looked quickly and I too would expect a different result from the LIST command. The returned value doesn't seem valid. Do you have another PC with a serial port? Maybe an older one running XP with a native port instead of a virtual one? I believe XP came with HyperTerminal. I also know weird things happen when using virtual COM ports and newer operating systems aren't always good about handling HyperTerminal.

You can use a MSG instruction to read the fault history. I think it has the last 3 faults saved inside the drive. Here's the MSG configuration:   And the tag values: The "...ParNos" array is the "Source Element" tag in the MSG configuration while the "...Results" array is the "Destination Element".

I wonder if they've changed something this year to not let that work any more. If you double-click on the v19 ACD file, it should prompt you to upgrade it as it's opening. You can then select whatever version you want (from among those you have installed). If you can, I would go to at least v24 since I think that's the first version that lets you download all of the documentation to the PLC.

We do have Tech Connect. Their activation system is one thing I really don't like about them. I do remember having to get in touch with them to get it activated properly, but don't remember exactly how it worked out. I found this KB article (access level: Everyone) that seems to say that you need toolkit to activate older versions, but that's not the case for us. We don't have toolkit licenses, but I'm able to support older versions. Weird...

We're using standard licenses (9324-RLD300ENE). In my Activation Manager, all of the licenses have "n/a"  in the "Product Version" column.

That is correct. If you need the value of a single INT tag to end up in a single DINT tag, use MOV.

Page 77 of the user manual (2198-UM001I) shows a single-phase grounded (WYE) supply connected so L1 is the neutral and L2 is line. They do not show a method for ungrounded single-phase supply. This does not apply to all Kinetix 5500 drives; just the ones that support single-phase input power. According to ProposalWorks, that's the 2.5A, 6.3A, and 12.5A peak output models.

If it's used in the PLC program somewhere, you can just inhibit the HMS module in the PLC that doesn't need it. That way you can restore it later easily if you do need it.