speakerman

MrPLC Member
 View profile  See their activity

  • Content count

    88

  • Joined

  • Last visited

Posts posted by speakerman

  1. Posted

    Holy crap lostcontrol! That's breaking it down... You are exactly right, all I want to do is consume the tags the Omron was already set up to produce. It doesn't make sense for me to send any, there were no inputs from the AB to the Omron configured by the OEM. I'll look for the Omron tech note you mention. I suspected there was no practical way to get them to talk, so if we can't actually reconfigure the Omron devices to new IP addresses we'll have to go with your last suggestion - adding a dedicated ENBT card. This occurred to me earlier, but I was hoping we wouldn't have to waste another card and slot just for this system. It's sending a grand total of eight words. The ethernet network switch for the EIP network is already connected to the device, and the cables are in place. We have ten other devices on that network, all with small word counts, so there's plenty of headroom. I was using the generic ethernet device for my quick test. I've asked for the Omron setup specifics from the OEM three times. Unfortunately he has declined to assist. I am not an Omron programmer, have never interfaced with them, and have no software for them. It's one of the few PLC families I've not had a chance to work with yet. Looking through the data sheets on configuring EIP for a CJ2M things seemed well laid out and pretty straightforward. The touch screens look great too. If we weren't dealing with password protection I would recommend the customer buy a copy of CX-1. As for the situation, there was no-one with the technical expertise onsite to assist the OEM in setting this up, so his questions went largely unanswered, and some were answered incorrectly. No-one's fault really, but I think the OEM is ultimately responsible for this quandary for proceeding past the step of configuring the IP addresses without confirmation from the customer's network administrator. Proper IP addresses was just about the only thing the customer could have provided him. I find it weird that now there's someone trying to actually get things working, and with some technical knowledge, if not expertise, he'd appreciate that and try to help his customer. Hatfields and McCoys, I guess. Thanks for taking so much time on this. A new ENBT card it is then. speakerman.

  2. Posted

    Hey lost control; Just tried to connect straight, the AB gives an 'Invalid Path' error with the 192... IP. Although we haven't gotten that far, I also don't know what assemblies to use for the data packages yet, so some more digging is required. Once the IP addresses are right, the path will be corrected and I can work on the data assemblies. It doesn't look like I can configure the AB to only consume tags, it still wants an output assembly too, and that requires a valid path. Perhaps there's a non-obvious way to turn off the output assembly. I'll ask that in the AB forum. Thanks again, speakerman.
    1 person likes this

  3. Posted

    Thanks lostcontrol and Michael, some great answers. I'll find a copy of network configurator and give it a try. If I can't find a download link for that, I'll post again. The IP addresses for the new devices are as follows: 2 CJ2H PLCs, 192.168.0.1 and 192.168.0.10, two touch screens as 192.168.0.2 and 192.168.0.3 The only PLC I need to change for our comm is the main one, but of course I'll have to reconfigure the other devices or they won't work as a system either. The plant has the address structure of 172.20.10.xxx, and if I remember correctly the subnets are 255.255.255.0 for both. Do either of you know if the tag structure is 16 or 32-bit for Omron Ethernet I/P? I assume its 16, so I'll be masking and unpacking the received double words into their individual 32-bit tags. At least that's familiar territory. I've walked into an existing situation here, and the OEM and customer are not agreeing, so being caught in the middle is always fun. Thanks so much for helping. Happy programming, speakerman.
    1 person likes this

  4. Posted

    Hello everyone; This is an excellent thread, a great resource in the link! Answered a bunch of questions for me. I have one outstanding problem and hope someone has some experience with it. We have a CJ2 processor set up to produce tags for an L62 ControLogix, but the Omron was set up with the wrong IP address for the AB. Not the fault of the programmer, he was given bad information, and things have now gone farther and we have no way to edit the Omron, as its code is proprietary and password protected. Obviously it is not feasible to completely reconfigure the AB networks and factory talk suite to match this one device. We don't need to consume any tags with the Omron, just read the ones it produces with our L62. Can we use a managed switch to establish contact from the L62 and at least read the tags already being produced, regardless of the configuration, or are we stuck with having to change the ethernet I/P config in the CJ2? The original vendor has good reasons not to want to help, and although that is frustrating, I may feel the same way if in his situation. Although it would be awesome, we cannot count on help from that front. I personally don't have a lot of networking expertise, but have had success setting up Ethernet I/P to some Yaskawa drives, the details of which are listed in another post. Based on that, I'm hoping we can set up the AB L62 to find this data floating around on the Ether...net. Happy programming, speakerman.

  6. Posted

    Hey dmargineau; CPU is rev 17.4 I don't have the revision handy for the RSLinx Enterprise. It was purchased about three years ago, if that helps. I am not the architect of this system, but am coming in after the fact to try and make it better. The system itself is poorly put together, the logic is enormously overdone, and the network was so slow they had to turn off the historian or there was a huge lag to the HMI. I take it your resolution to the problems you had was to upgrade then? The tags remained hidden until the upgrade was performed? Looks like a stalemate here for now. I will see if this plant has a tech support contract with Rockwell, and contact them. Thanks, speakerman

  8. Posted

    Hey everyone; I've been looking through the manuals and KB and cannot find any solution, or reason, for a problem we're having with Factory Talk View Studio SE 5.00 and the historian server. We have one 1756 processor on the network and all of a sudden tags we are entering into it are not showing up on the server. We've been doing upgrades for some time, and any tags created in the controller are always available when we proceed to the HMI to add them to the displays. Nothing has changed, but the tags stopped updating to the server and we can't find the latest tags made hours ago. We've confirmed they are active, and working properly in the PLC, there are no spelling errors, or data type mismatches - everything is identical to tags we'd used successfully before. We can't find them browsing from a display object, and refreshing the online folder does nothing. We've saved the PLC project a couple of times, and tried shutting down the factory talk editing software in case it needs to update. Shutting down the server is not exactly done, unless there's a tragic reason to do so, as the plant runs pretty much 24/7. Is there a random amount of time between tag creation in the PLC and their arrival at the HMI server? Is there some way we can get the server to grab them from the PLC without shutting it down? I hope someone knows of a way to fix this, it stopped our upgrades cold. Thanks, speakerman.

  10. Posted

    Hello everyone; We have five Siemens BW500 Milltronics scales running totalizing programs, and would like to move their data into an Allen Bradley 1756 controller. The BW500 supports the Modbus RTU protocol, and we were considering that as an option. Is there anyone who has achieved this and can let us know of any barriers, challenges to overcome, or critical configuration parameters to make this work? It seems simple enough, but the 32-bit architecture of the 1756 controllers did create some unexpected complications with the Yaskawa drives we just installed, so I want to make sure we can achieve this before pulling wires and committing resources to the path. The milltronics units have 4-20mA analog outputs as well, so we could send the running rate to the PLC and write a program to totalize based on that. It would be very easy to wire up, and take a bit of programming to calibrate, but in the end it could not be as accurate as a direct reading through Modbus. If anyone can shed some light on this, please let me know. Happy programming, speakerman.

  11. Posted

    Hello everyone; We just installed and commissioned an Ethernet IP network to control 11 small Yaskawa VFD drives with an Allen Bradley 1756 controller. Thought I'd post the results, and offer help to anyone facing this challenge for the first time, as we just did. One short-term burp was not realizing the Yaskawa drives are defaulted to DHCP, which must be changed to 'fixed IP' after the proper addresses are installed. Once we had the proper IPs, the speed set to 100MBPS, and the address mode set to 'fixed', we rebooted the drives and the top green network light on the drive's Ethernet IP cards stopped flashing and the bottom lights started to flash. The top light is network detected, and the bottom is connection established. I proceeded to the Allen Bradley interface and started adding the generic Ethernet modules for each drive. The Yaskawa drives use two 16-bit words each for inputs and outputs in the IP comm, one with the binary interlocks and the other with the speed command in Hertz x 100. The manual I found showed a program example using a generic Ethernet module with a dim of two words for the I/O comm, but of course that had to be changed to 1, as the 1756 uses 32-bit tags. We used the interlock assemblies of 21 for outputs and 71 for inputs, and an RPI of 100ms. Each drive showed up configured immediately. I am very impressed with the ease of this comm setup. We multiply the speed command by 60, as the HMI speed controls were pre-configured in percent, and the drive interprets the command as an integer with two inferred decimal places. (100 percent x 60 = 6000, interpreted as 60.00 Hertz by the drive...). To make this work and put the 32-bit 'Real' speed command in the top two control word bytes, we move it from the real tag to a double integer. Then the double integer is word-swapped to move the speed command to the upper two bytes, and the individual bits of the lower control word are set over the next few rungs. The drives were configured for terminal strip control, and Ethernet IP allows the program to set two control word bits for Ethernet IP network to run the drive instead: bit 5 to take control of run/stop commands, and bit 6 to set the speed reference. I use the control bits to take over the drive when 'remote' is enabled. In local mode we leave the speed reference bit 6 enabled, but the run command comes from the local jog switch. One other burp that arose was the terminal strips for each drive had been wired with a fault that drove an input with the common leg of one of the panel lights. This caused the drives to lock up and not accept the comm speed reference. It was very odd, the drives would run at 33.3 hertz all the time, no matter what the command word was. Once we found the wiring fault and corrected it, the drives started to work perfectly. This was mode more difficult as the small drive's terminal strip is completely obscured by the Ethernet IP option card, and it has to be removed to change anything. Strange that a terminal strip wiring fault would cause the drive to lock up, but I think there is a note in the manual about not begin able to change the reference source during a run command. I think the terminal strip saw a permanent run command, which prevented our reference configuration changes from taking place. Just a theory. If anyone has questions about this, feel free to ask. i know some lead from someone who's gone through the process is always helpful. Happy programming, Speakerman.
    1 person likes this

  12. Posted

    Hey people; Here's an update for anyone who follows this process. Moggie has helped to find everything needed so far, and looking through the manuals it appears all distributed I/O using ET100U modules must have an EPROM in the 308-3UA12 communications card that establishes the I/O configuration. I'll be able to confirm this by examining the card when we are down next month. The remote base controlling ET100U modules each have a dip switch that sets their ID number, and the EPROM located in the remote master 308-E card tells each ET100U how many backplanes it should have, and what the I/O numbers are for each card. I've dug through the drawers and located and old Prommer, a 6ES5695-0AA11, and a spare EPROM module. I've installed the COMET100 software for the Prommer, and it boots just fine. We are currently trying to locate the proper cables for the Prommer and get things talking. The COMET100 software looks simple enough, and I think we have all pertinent manuals now. The next step is to try and get the Prommer to write a new config onto the spare EPROM, and the challenge of that will be to work through the DOS shell for port access and interface. We'll see how it goes. I'll post the results of how this turns out, so if someone ever needs to do this, there's a full story - hopefully with a happy ending. Thanks again to Moggie for offering so much help. speakerman.

  13. Posted

    Hey again, Moggie; Well, I've been looking for any information on the software described, and can't find any copies of the COM ET100 software. Do you know where would we be able to find a copy? Is there a software manual so I can read through the procedures, which will help to understand the process. I also can't see an EPROM module on the comm cards. The model numbers I have are 6ES5, not 5ES5, so does that make a difference? Searching the Siemens website I also cannot find any reference to the part numbers we have or the COM ET100 software. Is there a specific method to search that site more in-depth? Typing in the part number usually goes to all documents and references, so perhaps these parts are just too old, and the data isn't there. I do need to figure out how to do this, as we are paring away this old S5 system and need to make room in the cabinet, so as we delete cards the backplanes eventually need to come off with them. For now we have two empty backplanes plugged in and empty, and things booted up okay, and I think the next phase will be alright as well. After that we're going to have to start removing backplanes as it isn't feasible to completely replace the PLC at this point. Plus this has raised concerns since there are other remote I/O configurations in the rest of the plant, and this shows us we have no real way to assess or repair them should something go wrong. I'd really like to get the process of establishing I/O and modifying it hammered down both for the process we have undertaken, and the security of the rest of the plant. Any help with that would be greatly appreciated. I've attached a couple of pictures of the installation if that helps to visualize what I'm dealing with. thanks, speakerman.

  15. Posted

    Hello everyone; We need to change an I/O configuration on an old S5 PLC with all distributed I/O. I have looked through the manuals we have on site, and am having difficulty finding the proper area describing this procedure. Or I'm looking right at it, and not understanding. We have a Simatic S5 115U 942B CPU, with an IM306 comm card with numbers 6ES5-308-3UA12, and there are six remote I/O stations. We need to alter the last of the six stations, removing some of the last unused I/O cards to make room for something else. The remote rack with the I/O we are deleting is an ET 100U 6ES5-318-8MA12, with 10 input cards 6ES5-431-8MC11, and then 20 relay outputs 6ES5-452-8MR11, on 15 bases 6ES5-700-8MA11. Right now we've deleted four output cards and disconnected the wires from two of the input cards, and left two of the backplanes plugged in, but empty. The system works, but now we need to delete more cards, and will have to unplug the unused backplanes, perhaps even moving some output cards down the backplanes by eliminating some of the input cards too. I'm sure we'll be delving into a HEX based I/O config file, and have looked for that without success. We have limited time to try changes between production runs. So if someone knows of a downloadable manual will show me where to find the configuration file, and how to modify it, it would be much appreciated. Thanks in advance, speakerman.

  17. Posted

    Hey b_carlton; This is interesting to me, I use first scan a lot to set initial values, always with the load and out instructions, and have never noticed a problem. Is this to do with counters and the nature of the first scan? Is there a link to the answer somewhere? I did search the site, but my keywords must not be working. Thanks, speakerman.

  18. Posted

    Hello All; Here's the latest update on the PID MV modulating with, but not following, the set point: There was a calculated bias used in the PID registers, scaled to follow the setpoint, but off by a scaled amount. This offset number was set differently for three pumps - based on the density of the material, it would appear. There was no offset in one of the PID loops. By tuning the offset, I was able to bring the flow in line with the setpoint. We did check the system for a loose wire, missing shield, or anything of that kind, and found nothing wrong. I also put traps in to see if the value was oscillating, and found nothing. With the offset retuned, the performance is accurate at all speeds, and the global backchecks for weight of product transfered do match the totalized flow. Unless something new arises, it would appear that the offset performance changed with this new pump. Must be a reason for the offset register to be there, after all. Any thoughts on this development? Has anyone used these offset registers in the PID before? Happy with the results, anyway. Cheers, Speakerman.

  19. Posted

    Hello Gary; I have had good luck just printing to file as a postscript document, which comes out as plain text, but usually the wrong font. I then copy and paste all into a word document and change the font to Andale Mono line draw. From there you can do anything you want with it. I use both Allen Bradley and Proworx NXT all the time, and they each have their quirks. You'll find a way to make this work. Cheers, Speakerman.

  20. Posted

    Thanks for the leads. I would bet there's some noise in the system, and the reason the PID looks like it's not tracking the number is that it is oscillating with the noise and creating the offset. The 4-20 mA source is a micromotion flow meter, and there was no work done to the drives or motors, just the physical pump itself. We'll look into the micromotion connections at the pump and I'll post the results when we sort this out. I did check for register overwrites, and there is none. I also verified the analog input value, and that checks out. The rest of the card is also fine. The flow on the micromotion display also matches the analog value in the PLC, so if it is noise, it's right at the source. Should make it easier to find. Good to be back. I'll try to do a little quid pro quo and help someone before disappearing again. Cheers, Speakerman.

  21. Posted

    Hello again Forum! Been a while since I stopped by. Busy as all heck. Ran into an interesting problem with an old Quantum PLC, using ProWORX NXT. I am relatively new to PID tuning, and am not sure where to begin to correct this. We have a PID2 to run a pump command for a metered pump that targets a setpoint generated by a fixed recipe value. The setpoint is then modulated to mach the flow of raw material through the process, and the PID2 would respond to the setpoint changes by modulating the pump command, as expected. There were four different PID loops for four pumps, and all were tuned beautifully, all trends showing the PV line almost invisible beneath the setpoint, with the MV following the production changes well. Over the past two years I've been here, there have been several pump changes and this has never caused a ripple in this performance, however, suddenly one loop changed. It tracks the setpoint, but is off by about 7 percent, reading high but not changing the pump command to bring the PV down to SP. This seems very strange, as the error shows the difference, the pump flow is verified correct, and the loop will modulate the pump and flow to exactly track the changes in SP, just always off by 7 percent high. I can understand how the new pump would perhaps have a different flow characteristic, and would guess that all the changed pumps did vary a bit, but I cannot understand how the PID would leave the flow offset by such an obvious margin. Does anyone know how a lop could allow the PV to sit apart from the SP, and yet follow the curve so precisely? Any light shed in this direction is much appreciated. Cheers, Speakerman.

  22. Posted

    Hey Gamble; Sorry for the late reply, haven't been here in a while. I hope this is both helpful and in time to be of use. If there is something you think needs to be added I'd appreciate the input. The standard I've arrived at is from my own experience, as I don't know of any particular 'standard' for planning this. Our OSHA regs just require an e-stop to be within a certain distance to each operating location of a machine, and every so often around it. I think most installers go overboard around here, to err on the side of caution. I also find that so-called e-stops are habitually used as sustained stop commands, not for emergencies, so that figures into my strategy. Operators look upon them as a general tool that is on their panel to be used. I have worked on a system where we had a separate global e-stop that shut down every piece of equipment in the room, which was never hit, and separate individual e-stops for each zone of equipment, which constantly were. The way we do it is that an e-stop button will affect any output or machine with controls in the same panel, and be, or cause, a physical electrical disconnect. If a control panel is large and has buttons for more than one zone of equipment, then I have an individual e-stop located above the controls for each zone. This is coupled with a strategy whereby no control button can affect a piece of equipment unless there is a clear line of sight from that panel. Depending on how interconnected the equipment is and how product flows from zone to zone, satellite e-stops will either be in series with the one on the panel, or be specific to the machine they are on. I let the overall process flow determine that - if the machinery is a station with internal processes then individual buttons are better. If it is all interconnected and mostly product transfer, then one button could shut off several zones. It depends on the complexity of the individual station, and whether or not you want, say, a press system to be interrupted when a nearby conveyor has a problem. For HMI systems, operators are always controlling equipment they can't see, and that is different. My e-stop plan for that is case by case, but physical e-stop locations around the machinery are easier - line of sight. I have upgraded wiring and e-stop plans where buttons would operate something in another room entirely - a weird and very unsafe situation. Following this rather simple concept simplifies my choices when planning the manual interface. Seems simple, even obvious I guess, but hopefully this will be of use. Happy programming! speakerman.

  24. Posted

    Hi All; Well, my first experience with an AD PLC has hit a snag. Something simple, I'm sure, but perusing the manuals has not led to a result. Needless to say this is not my area of expertise. I have a customer who has just purchased a machine outfitted with a 205 plc, DL260 cpu, several i/o modules, and an H2ECOM100. There is also a C-More touch panel that was configured to talk to the PLC through an ethernet hub. I was called because the machine is not working up to spec, the company who installed it is a long ways away, and they are trying to network with it remotely to monitor the code and alarm logs. Prior to my arrival, the OEM had supplied the customer with a copy of DS5, and the C-More programming software, and they had reconfigured the C-More to talk through the RS422 port to get it off of the ethernet network with the assumption that it was interfering with the ability to connect to the PLC remotely. The machine was working correctly system-wise - just not operationally. The touch panel was talking properly to the plc through the hub, and you could interface with the plc directly with the proper cable. We were attempting to establish a communication link with the plc through the ethernet hub using IPX protocol, thus ensuring that the remote attempt would have a chance of succeeding. We were able to see the H2ECOM100, and it did identify the type of plc and cpu number. When attempting to create a link, we got a different error message each time, even if we simply retried the same configuration. We tried using the four different options, station identity, name, IP, and ethernet address. None worked, all gave the same error codes, which I can't find anywhere. These error codes were: 256, 512, 6144, 18432, and 20480. It is not lost on me that all of these codes are multiples of 256. Is that a coincidence? Seems pretty odd. Anyone hear of this stuff? We appear to have done the steps identified in the manual, so when that doesn't work, I guess my next step is you guys... We have a new copy of NETEdit3 to try, but after that it's stumbling in the dark time. Any comments or help will be appreciated! Thanks, Speakerman.

  25. Posted

    Hey Matt; You've got a great plan structure. I would like to put forth a couple of thoughts regarding interface, if you haven't considered them already. I approach something at the scale you describe considering the nature of each 'zone' of control, looking at the level of automatic action desired, and the amount of operator interaction with the normal process flow. You mention this concept within the listing 'interaction boundaries', and the implications are something I consider vital. The more automated an area, the more self-reliant the code structure must be, and the clearer its fault detection and appropriate automatic response. You may find the code design and structure might change from zone to zone, to avoid overcomplicating the simple areas, while properly enabling the complex ones. An example of this is a system that has a visual line of sight to the control station as opposed to one that is sensor based - whereby most of the decisions made are assumptions based on gathered data. With visual systems you can put a lot of power into the hands of the operator to override possibly failed sensors, as they can confirm everything is correct before proceeding. In this case I generally allow all but the most contradictory actions to occur in the manual interface, trusting the operator to see what needs to be done. When designing from the ground up I orient operational controls within the sight line of their machines, and break down the panel locations and size based on that reality. I never want a local control activating something that the operator cannot see. HMI structure can be quite different, as it tends to be more central and less directly informed. If a remote HMI is part of a system, my local control automatic/manual selector switches are always the master control with the highest authority, so that when a local panel is turned to manual, no other control method will activate that part of the system. This protects the people interacting directly with the equipment from a mistaken remote start. Sounds simple, but I often see it otherwise. Dual-zone control interface and the inherent complexity for operator safety is one of my pet peeves. The second aspect I consider that weights the code structure and how it faults is the level of personal interaction people will have with the equipment/product. This adds weight to the above point, or takes it away, depending on the physical reality. If all parts are internal, like inside a washer drum or tank system, then protecting the equipment from plugging and damage is likely the concern. If it is a conveyance system with people and machinery working around and handling large product, then the interface needs to be solid and have redundant backchecks. A perfect example I run into frequently is the wiring of end limit switches on lines that carries 3500 pound stacks of pulp bales. Failures when wiring them N/O have let the stacks run right off the end, or successively butt up against the stop blocks until they toppled over, broke the chain, or kicked out the motor. Most line switches are wired N/O to prevent switch failures from initiating a machine cycle, but the conveyor end limits all need to be N/C so that they fail full. Everywhere that people interact with the line, either to work on it or walk by it, the sensors need to be N/C so that if they fail they will not let the next stack run onto the conveyor in auto until the sensor is repaired. I hope that gives you a couple of helpful ideas, Matt. Good luck with the project! Take care, Speakerman.