Joe E.

MrPLC Member
  • Content count

    877
  • Joined

  • Last visited

Community Reputation

89 Excellent

2 Followers

About Joe E.

Contact Methods

  • Website URL http://

Profile Information

  • Gender Male
  • Location Blacksburg, VA
  • Country United States

Recent Profile Visitors

5445 profile views
  1. Overlapping memory areas in TIA Portal

    Hmmm.... I searched the project and it turned up where the words are used. It would be really nice if the search results had a column showing whether it was used as a read or as a write. As it is, you have to open each result and look at it.
  2. I have a fair amount of experience with Simatic Manager, but I'm new to TIA Portal. This one has me stymied after a couple hours of hunting (this time). This is an issue we've encountered before with various machines programmed in Portal, but didn't have a chance to chase it down. Here's a simple and clear example. This machine is from France and was programmed with Portal v14. The alarm bits are all contained in a global data block DB2. The alarm bits are individually SET in FC2 when conditions are right for each alarm. Each bit has its own -(S)- coil, which (as far as we can tell) is the only place it's written...EXCEPT...the first network in FC2 uses MOVE instructions to write "0" to DB2.DBD0 and DB2.DBD4 any time a "reset" pushbutton is pushed (there are 2). The problem we have is that all of the ways we've tried accessing the cross-reference for the program only show the individual bits (DBX), not the double words (DBD). If the MOVE instructions had been placed in another FB/FC/OB somewhere, we would have had a major devil of a time finding them. They just happened to be at the top of the alarm FC. Here's a screenshot of the MOVE instructions with the x-ref information shown for DB2: In the Simatic Manager world, the Cross Reference will show where the different registers are used, whether as DBX, DBB, DBW, or DBD, but it seems to me that the Cross Reference in Portal only shows actual symbols, not addresses. Since there is no symbol defined for the DBD addresses (and I don't there CAN be, since they're defined as DBX bit addresses), they don't show in the x-ref. I opened the Cross-Reference window (which is different from the bottom-half cross-reference information tab above) and clicked on "Show overlapping access" on its toolbar, which opened another sub-window...which is blank and doesn't show the overlapping access to the DBD word (maybe because the MOVE instructions used absolute addresses instead of non-existent symbols?): I came across a blog post about issues in TIA portal v13. One of the entries mentions a global address overview, which is tantalizingly close to the "show usage" tab of the old Simatic Manager x-ref but I can't find any way to get to it. This probably wouldn't help us track down a DBx.DBDy overlap, but would be useful for finding unused "M" memory: Another "interesting" piece of information is how the HMI alarms are configured. They use trigger tags that are word-level, not double-level. In other words, alarm #1's trigger address is DB2.DBX1.0, which is part of Trigger tag Alarme_mot_0, which points to DB2.DBW0. The tag databases and x-refs for the PLC and HMI appear to be distinct and separate entities, contrary to the marketing presentation we attended for Portal which said that everything was in one place and easy to find. That's definitely not our experience so far. I found an article on Siemens' website about prepending "AT" to the beginning of a tag name to have overlapping tags but that only applies to the declaration areas of FBs and FCs. This is a global DB. And I'm not sure it would even work anyway, though I suspect it would IF the MOVE instructions used the tag names instead of the addresses. Can anyone help me figure out a way to x-ref the DBD usage and to find the global address overview?    
  3. Counter Malfunction

    Is the counter tag used in another place?
  4. Ultra 3000 Drive Follower not indexing

    I don't suppose you have a backup parameter file from before Maintenance Bob got to it? Or another identical machine to compare?
  5. You're welcome. I learned those tips the hard way. One of my first tasks here (over 8 years ago) was converting an old PanelView 1400 (a CRT HMI that was a predecessor to the Panelview Standard) to a PanelView Plus. It connected to a PLC-5 over DH+. It took me a while to figure it all out using just the manual we had for RSView 32 version 4 (which became FT View Studio at version 5, I think). Unfortunately, the glitches and gotchas I had to work around back then are still there at v8.2.
  6. Here's another tip. If you copy/paste a bunch of objects from one HMI project to another, and if the device shortcuts are named differently, you will have trouble. Also, if you change the name of the device shortcut in the communications setup, it will NOT change the name in your display objects! To remedy that, you can select all of the objects on a display screen by pushing ^A, then open the tag substitution dialog by pushing ^R. You can search for any text and replace it with any text: In this dialog, I can enter Ink_Detect in the "Search for:" field and enter Ink_Detect_D in the "Replace with:" field if I change my device shortcut name to Ink_Detect_D. This is also a handy dialog to use to see the tags and expressions that are used on that display. You can just scroll through the list looking for misspellings etc. There are other gotchas I learned the hard way. You can be doing everything perfectly correctly and it still won't work, until you reboot your PC. Then it "magically" starts working. If everything looks right, like, "...it should work, darn it!!!", try rebooting the PC. Especially, especially, especially if you're making changes to the device shortcut or communications settings. I've had countless annoyances working with these HMIs when I made a change to the communications and had to jump through otherwise pointless hoops to get it working again. I've even seen where I could run the project in test mode and it's fine but when I compile & download the runtime to the HMI, it doesn't work. Until I reboot the PC and re-compile the runtime file. Then it works, without changing anything else. As an example, I decided to test what I just outlined above by changing the device shortcut name to verify that it didn't change it in the object properties. Then I changed it right back and nothing would communicate in test mode. I shut down/restarted View Studio, same result: no comms to the PLC. Then I rebooted the virtual machine, opened View Studio, and tested it and it worked perfectly. If in doubt, and you think you have it right, first close and re-open View Studio. If that doesn't fix it, reboot your PC.
  7. Here are some screenshots of what I'm working on now: First, here's the Communications Setup dialog box: The device shortcut here is "Ink_Detect" and it points to the MicroLogix 1400 at 192.168.0.16 Next is the Connections tab of the properties of a multistate indicator that's tied to the address N7:70: Note the syntax with the colons and square/curly braces. Your device shortcut name is embedded in there. If you click the "..." button under "Tag", you'll get the tag browser: The project name is Ink_Detect_D, which is the top level of the browser window. Ink_Detect is the name of the device shortcut. This is not final and I'll end up changing the names once it's closer to being done and I know exactly which line it'll end up on. If your shortcut is configured correctly, and the PLC is ping-able at the IP address in the design (Local) tab of the shortcut, clicking "Refresh All Folders" will populate these folders. The address I need for the multistate indicator is inside the N7 file, expanded above. If you use the "..." button to open the tag browser, you can just double-click on the address you want and it will automatically add the punctuation and syntax it needs.
  8. Awesome, that's good to hear. We're all at v8.2 (2 laptops for the maintenance folks and 4 for engineers). Our firmware versions range from 5.x to 9.
  9. Cool. We have so much on our plates, we haven't been able to investigate that at all. Right now, we're avoiding anything that would make it more complicated to keep the machines running and make the upgrades we're being asked to make.
  10. My VM is Windows 7 32 bit. One of the reasons View Studio is isolated on its own is that there's an involved process to convert the database files to work on 64-bit Windows that we haven't been willing to tackle yet since we have several dozen projects and the last thing we need right now is to have some on 32-bit and others on 64-bit. There's something going on with either our group policies (rigidly controlled by IT) or our network switches (also rigidly controlled by IT) that we can't "autobrowse" and find anything. The Ethernet/IP driver in RSLinx Classic very rarely works; we have to use Ethernet Devices. Logix 5000 devices use Ethernet/IP while the older SLC and PLC5s use a different protocol that may not work with autobrowsing. There are several members on here with much more networking experience than I have who can clarify that difference. The shortcut name can be anything (as far as I know) but it has to be in each display object's configuration exactly right with the right numbers and placements of square and curly braces, periods, and colons. It's a royal pain if you try to do it manually but is pretty straightforward if your local device shortcut is right and you can browse the PLC...which brings us back to your original question. If you open an object on a display, go to its "Connections" tab, and click the "..." button under the "Tag" column to open the Tag Browser. Click "Refresh All Folders". Your shortcut name should show up as a folder with an "Online" folder under it. The "Online" folder should contain a bunch of stuff. In a 5000 processor, it would be the tag names. In a 5/500 processor, it will be a folder for each data file. If that doesn't populate, there's something wrong with your device shortcut.
  11. You shouldn't need RSLinx Classic at all to get the HMI to talk to the PLC, assuming the PLC already exists and is programmed (I assume that's the case, since you can see it in RSLinx Classic). I have FT View Studio installed by itself on its own virtual machine with RSLinx Enterprise and NOT RSLinx Classic. If the PC you're using to develop the HMI project can ping the PLC, you should be able to browse the tags in the PLC from within View Studio once the device shortcut is set up correctly. We don't have any 5/05s in service, and only one on hand that's not in a rack and I can't put my  hands on it immediately, but I do have a MicroLogix 1400 on my desk with  PV+7 talking to it that works similarly enough I may be able to help you some... Can you share your View Studio project archive (it will be a *.apa file after you use the application manager to make an archive).
  12. When I use RSLinx Enterprise inside View Studio for ME, I have to manually add each device to the Ethernet driver, both HMI and PLC. It doesn't browse and find them automatically. That may be a quirk of our network, though.
  13. 1769-L32E Need t2 ethernet ports

    All that I described above is done with an unmanaged switch. Each device will need its own IP address.
  14. 1769-L32E Need t2 ethernet ports

    Based on what you've described, I would think they would be able to do both through one network connection. How often would the log's mass be updated from the PC to the PLC? And how much downtime data is being collected (and how often)? I'm not familiar with the L32E, but we have a machine using an L33ERM to do CIP motion over Ethernet/IP of a servo (old Anorad linear motor on a Kinetix 6500 drive) while also communicating with a ControlLogix L71 over the same Ethernet port. The L33ERM and L71 are exchanging 50 integers in each direction every 100ms with no issues whatsoever. Over that same network port, the L33ERM is also talking to 2 PowerFlex 525 drives, an SMC on-machine I/O system (valves and discrete I/O) and an HMI. I set up a quick project with an L32E. It's from the older series with a built-in serial port and a built-in Ethernet port. It doesn't support adding a second Ethernet port. This is the biggest limitation we found when using even the newer family of CompactLogix: you can't have a second network port for remote access to monitor/gather data independent of the local machine I/O network. For now, when we want to do that, we have another machine on the line that has a ControlLogix PLC that has 2 -ENBT modules: one on the machine network and the other on the office network. The ControlLogix polls the other machines and gets the data together in one place to be accessed (some time in the future...) via the office network.
  15. 1762-IT4 help

    I've never used that particular combination before, but I just created a program in RSLogix 500 and added a ML1400 with an -IT4. After you add the -IT4 to the I/O Configuration, double-click on it to open the module properties. Then click on the tab for the channel you're using and set the options. Enable the channel. For what you're doing, I would set the data format to "Engineering Units" and the rest appropriately. The "Open Circuit" setting tells it what to do when it detects a broken wire. For a heating circuit, going "Upscale" is the preferred option since that will cause the heater outputs to turn off. You get to choose which option works best in your application. Once it's set up, you will have 6 words in your input table associated with the module. The first 4 words are the values from the 4 channels. Words 4 and 5 are status words. Here is the installation manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/in/1762-in013_-en-p.pdf Here is the user manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1762-um002_-en-p.pdf The memory map starts at pdf page 31. Is this an existing system or are you building it from scratch? To just turn on a warning light, you would wire the warning light to an output and just use a GRT instruction. Source A is the TC signal, source B is the setpoint for the warning. If you want to make the setpoint easy to change while it's running, you can use an integer register for Source B. You can also just use the actual setpoint there. The TC module has some diagnostic bits that you might want to experiment with to do error checking and to maybe flash the light if there's something wrong. FORUM_TC.RSS