kaiser_will
MrPLC Member-
Content count
918 -
Joined
-
Last visited
Posts posted by kaiser_will
-
-
Allright guys, doughead me figured out that I was trying to change the COIL to differentiate up. Homer says "DOH". I made the change (thank you all very much) and it is working as expected. -
When I open the Edit features of the counter event trigger, 234.00, the Differentiate features are greyed out and Omron tech support is unaware of how to unlock these features. -
The PLC model is a CS1G-CPU43H. Counters C49, C50, C51 are the problem children. We are an equipment OEM, typically integrating Allen-Bradley controls. This customer, however, requested Omron controls utilizing their "base" PLC and HMI programs. Thus, we have limited Omron programming history and have been hand-tied to use someone else's PLC program. I have found numerous errors in their base program, so I would not be surprised if that is the root of this issue. J5422_2008_10_20.cxp -
I am near completion of our first Allen-Bradley to Omron PLC program conversion and have one issue that is not working itself out yet. When a sequence of the machine runs, I have 4 different counters setup to increment once to keep track of number of cycles run. The issue is that all of the counters will sometimes count once per cycle, as they should, then other times make huge jumps. Omron tech support tells me that I should be able to change the trigger coil to Differentiate Up, but this feature is greyed out on all symbols. Omron is not aware of how to turn turn off the greyed out feature. How to unlock the greyed out features for coil edits? What elementary mistake am I making with my counters? -
Has this behavior been going on a long time or recent? What is the Ethernet/IP structure for this communication network (possibly something changed on the network side, such as packet latency time)? I would suggest you run an Ethernet/IP packet sniffer to find some clues. I like to use WireShark, which has a free download. If you can limit your network to just the problem PLC and your computer, running a packet sniffer, then let the sniffer run until you find the comms dropout. Go back and review the table of data. Compare to a reliable PLC comms as reference. Intermittent comms dropouts require dilligence to get to the root cause. http://www.wireshark.org/ -
The PLUS PanelViews require the newer FactoryTalkStudio HMI development software. Keep in mind that if you want to just upload the program from the HMI, what you are going to get is the compiled program (.MER) and not the full application (.APA). There is a thread out here for converting the uploaded MER file into an APA application folder. -
Thank you to everyone for their support on this issue. We tried Bob's nifty Excel solution, and that works wonders for his RSLogix file. However, I have not done VB programming to be able to go in and edit Bob's Excel solution. If it is of little trouble to modify his source for my program, have at it. I am still fumbling around to figure out his solution with what tools I have available. The tag I am interested in with my program is MessageList and MessageListB (same thing). Thank you. J5128_093108.ACD -
Has anyone used the new CS1W-EIP21 Ethernet/IP interface card? We are using the card to communicate, via Ethernet/IP, with all of the I/O devices. As of now, there is no communicating going on. I have used an Ethernet packet analyzer to capture communication events comparing how the Omron communicates compared to an Allen-Bradley CompactLogix PLC (our typical solution). It appears that the A-B PLC talks broadcast, and the Omron PLC has very little traffic (probably limited broadcast traffic). I have been working with Omron's tech support on a daily basis and they appear to be snowed on the issue. We are an integrator, our customer required Omron controls, and our hardware supplier said "Omron can talk Ethernet/IP to the I/O devices you have identified". -
That would work for getting the value of the string at the time, but what I am trying to do is port out all of the 300+ string content messages of a message string array, preferably into an Excel worksheet, so that I can cut-and-paste into the machine documentation. There is PLC logic to energize bits of the message array to send the "system condition" message string to the HMI, which will display the text string instruction at the top of every screen via the screen template. Such as, if MessageBit(1) is energized, "Msg 1: Control Power must be ON" is displayed on the HMI, letting the operator know that they need to press the control power on button to advance to the next startup task. With this setup, all of the message contents are kept in the PLC and not the HMI, leading to an easy way to keep house. As a new machine is developed and implemented for a customer, many custom messages are added to inform machine opeartors. The goal we shoot for is if an operator presses any button, the machine performs that function or informs the operator as to what conditions are lacking. -
We have a project with many messages passed to the PanelViewPlus via an array of string messages. My dilmena is that the list within the PLC is very long (300+) and I want to pump it out to an Excel file (or similar) to add to documentation. However, exporting the tag list in Logix5000 just moves the string array name and not the contents of the array (all of the darned messages). Any ideas? -
When planning a PLC as your system controller, you should figure out what I/O (input and output) points you will have. Will they be discrete (on/off) or analog (0-10VDC, 4-20mA, etc.)? Are the discrete I/O sink or source (this detail can stick it to you hard if overlooked). Simply taking a used PLC and turning it into a robot controller could prove to be difficult. You may run out of I/O, not have all the I/O you need, not be able to interface to motion controllers, etc. If you want to turn an old PLC into something useful, first make a table of the PLC's capabilities. If you have a vanilla-flavor SLC-100 rack, then you are probably limited in how many I/O and the type (discrete, sink, 24VDC). For turning a PLC rack into something useful, take a look around your workplace or home for an area where automation would be a great benefit. For instance, I turned the smallest Siemens DC-powered PLC into a hyrdraulic ram controller for a friend who does concrete work. He was tired of having to pulse the trigger to turn the hydraulic ram (use to bust of old concrete slabs) on for a brief period (10-30 secs), off, then pulse back on. I installed a lighted toggle switch in the cockpit for enabling the circuit, replaced the on/off trigger switch with a pushbutton, and a few rungs of code for the PLC relay output to energize the hydraulic ram. -
Very good information. We used to run Ethernet to panel M12 sockets, then had panel-connected M12 cables from the panel to field devices. Changes were made to go straight RJ45 from the panel through a cable gland to the field devices. Now design is looking at possibly going back that direction if hardware manufacturers are going to go the way of RJ45 to M12. We have been using Turck molded RJ45 cordsets, but the prices are high and lead times are horribly long. If someone mistakes on system orders (which often happens) then a project ship date can slip due to a blasted RJ45 cable taking 2-4 weeks. We are experimenting with a new Siemens field-terminating RJ45 plug that shows great promise for ruggedness. -
Does anyone know if Allen-Bradley is looking at adding M12 Ethernet/IP ports to their Control or CompactLogix PLC platforms? My A-B distributor knows of nothing in the works from their channels, but there seems to be a lot of momentum in this direction from the European hardware manufacturers. I have never been a big fan of the RJ-45 connector for communication connections in a dirty, electrically-noisy, vibration-filled industrial manufacturing environment. We have been seeing more European-based hardware, such as Hirschmann Octopus Ethernet Switches and Festo Pneumatic Valve Manifolds, with M12 screw fittings for Ethernet communications. Just wondering if Allen-Bradley is on the band wagon with this innovation or not. -
A new customer prefers SMC pneumatic valve manifolds for a project we are working up that will have an Omron CS1G CPU. We have had a lot of luck recently with Festo CPX fieldbus manifolds talking Ethernet/IP to Allen-Bradley CompactLogix CPUs and would like to put together a similar package with SMC valving and I/O working with an Omron PLC. The Festo CPX system works out well because a mix of I/O and pneumatic valves can be built in a single manifold with just control power and an Ethernet line running to the manifold. Has anyone had experience with a similar setup with SMC? I am working with my local SMC distributor but want to hear of any issues or recommendations with such a setup. -
So, RSLinx can find the PLC processor, but RSLogix times out? My understanding is that RSLogix uses RSLinx for its communication, with RSLinx being the communication layer and RSLogix being the logic development layer. Thusly, the problem is probably with RSLogix not doing exactly what you want it to. Try, instead of RSWho-ing in RSLogix to drill down through the communication options to go directly to the processor. One thing that happens is that RSLogix remembers the last communication path the last time you went online. I have run into a similar problem. When you are DONE with RSLogix, go into RSWho and Clear Project Path. RSLogix remembers the last path when you went online last time, and if your processors are on vastly different networks or connections, when you try to RSWho the software wants to use the last pathway to connect. -
Thank you for the input. I have been working with Allen-Bradley and the device Ethernet/IP interface board manufacturer to get to the bottom of what is the current condition. Since this was the first time I tried to get two Allen-Bradley PLCs to communicate with the same Ethernet/IP-enabled device, I needed to get the groundwork in to come to the facts. The Ethernet/IP interface board manufacturer has a serious flaw in their board firmware that does not allow two or more PLCs to communicate with the board at the same time. Ironically, once we got down to the facts that this should be possible was I informed by the board manufacturer that they are aware of this flaw and are working on a resolve. We could have taken the easy route and used messaging instructions for PLC #2 to pull data from the device, but the customer was explicit that this is not allowed per their specification. -
Good information! 1. However, the customer is explicit that information cannot be messaged from PLC#1 to PLC#2 or vice-versa. Part of their iron-clad, no-exceptions specification. The customer wants PLC#1 to control the process and PLC#2 to grab data from the process (Ethernet-enabled device) with no messaging between PLCs other than for triggers. 2. One can configure the I/O comms to the Ethernet-enabled device (generic Ethernet device) for either PLC #1 or PLC#2, but not in both CPUs. Trying to do so generates a "Device is configured by another controller" fault (in the second CPU to get configured) which will not open up the session for tags to be mapped to that device. I am working with CompactLogix L32E processors, but am pretty sure the same thing goes for ControlLogix CPUs. It appears to either be an Ethernet/IP rule or an Allen-Bradley rule that 2 or more CPUs cannot map the same I/O device. If I add an Ethernet card to the second CPU rack, there might be a way to set up the tags for listen only. If this is the case (that a separate Ethernet card can be setup to listen only to that Ethernet-enabled device), then the rule is being set by A-B and not the Ethernet/IP standard. Thusly, a custom A-B driver might be in the works to make this be accomplished (i.e., for a CompactLogix CPU to configure an I/O device for listen-only). -
I have a customer that requests that PLC #1 do the control and PLC #2 pull the data, both talking to the same Ethernet-enabled device. However, Allen-Bradley does not support two PLCs owning the same device. Ideas? -
If your encoder count register in the PLC is increasing with the machine stopped, then the high-speed counter card is counting pulses from somewhere. Most likely electrical noise from improper grounding. Inspect the encoder wiring into the counter card and make sure the ground lead is floating at the encoder and landed at the counter card (Float In Field). A lot of electricians want to land every wire in a cable, but that pesky ground loop will cause you lots of havoc (like higher count rates and counting while machine stopped). -
All of the excellent strategies put forth so far involve a PC with the Allen-Bradley programming and communication software running at a remote site (and plugged into that site's PLC network) with user remotely connecting into the network through a hosting software package. What if the remote site has its PLC network hanging off of their network and I want to remotely connect up to a PLC and monitor it's program? I have such a scenario and have found I cannot successfully ping the Allen-Bradley CompactLogix 1769-L32E CPU or the PanelView 1000 Plus (but I can ping some of the other Ethernet-enabled devices). I am tending to think this is possible if I setup the Gateway IP address in the PLC (I/O Configuration, Port Configuration tab). -
I am working on developing a data collection/machine reporting system for our customer base. An idea that came up was to capture I/O values at the time of an abort alarm condition. With most of our I/O being discrete, this should not be too difficult to do, but will involve a lot of fields (for all of the I/O tags). Possibly, a graphical status screen with all of the I/O (like the rack addresses and such) and their value (ON = green, OFF = red). I developed some screens like this many projects ago to display real-time I/O values (with the ability to force I/O), so having that same screen display the I/O values at the time should not be the end of the world. This would be very helpful in identifying the conditions at the time of an event. -
This sounds like similar to a "state machine". An input changing state, such as a pushbutton, with a one shot bit, moves a constant into an integer (such as Step1=1). Next rung has a test for Step1=1, then execute a change (like turn an output on). The next rungs, with the output on and Step1=1 then increments Step1=2, and so on. At the end of the sequence, reset Step1=0 to be ready to loop again. Here is a quick and dirty example. What is your goal in such a scheme? I use state machine logic, such as this, for a system that has many sequential steps and to make it easier for the customer to follow the logic/troubleshoot. StateMachine.ACD -
All Ethernet/TCP-IP with a PC running RSView and a ControlLogix CPU is gravy. I would get the CPU powered up, program loaded in, and IP address set. Then move onto the PC, setting up RSLinx to connect to the new PLC. Once you have the comms ready to roll, load in the RSView application and start talking to the PLC. Cycle PC power and life should be good. -
I suggest you build up a spare PLC rack with some I/O and some physical inputs. Pop the spare CPU into the rack, power up, load in a test program (something simple coming from the inputs), put the rack into run mode and verify proper operation online. Nuff said. I use our test rack for training techs and new controls engineers. Fresh meat. On a related note, beware of the plastic bands (or clips) in the PLC-5 rack CPU slot inserts. I did have one occasion in which one of the bands got stuck (on the CPU I was pulling out) so the new CPU that I slid in pushed the orphan band into the card edge fingers and everything went to crap on power up. It is possible that the plastic bands was a PLC-2 thing that eventually went away.
PLC-5 SETUP
in Allen Bradley / Rockwell Automation
Posted