MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Paullys50

  • Rank

Profile Information

  • Country United States
  1. Stripped down HMI Software

    I'll say Ignition, you can buy just the Vision module and skip the rest since you have it covered. You could purchase unlimited/5 client/1 client licensing pending your client needs.  A third party module was just released called Chirp to link Ignition to Canary's data historian might be valuable however I'm not clear on the cost (if any) with that module.
  2. Flex I/O

    I don't understand how you can say this when you didn't do the homework to make sure the hardware you selected would do what you wanted it to do? Not to mention the decision to use previous generation hardware and to somehow state that they have limited capabilities because you're trying to cram a square peg into a round hole. Sounds like you just picked something off the shelf assuming it would work. 
  3. I always recommend following/creating/modifying a naming convention like you see in higher level languages, from wikipedia: In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types, functions, and other entities in source code and documentation. Reasons for using a naming convention (as opposed to allowing programmers to choose any character sequence) include the following: to reduce the effort needed to read and understand source code;[1] to enable code reviews to focus on more important issues than arguing over syntax and naming standards. to enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences.
  4. Allen Bradley Vs. Mitsubishi

    It really depends on how much you have going on in your logic and HMI screens. Mitsubishi can do it just like AB, however in my opinion AB programming software is better. My perspective is from a ControlLogix/CompactLogix perspective. I would still say I would prefer RSLogix 500 over Mitsubishi software. The new GOTs do have some nice features to them, I'm not a big fan of the development environment either. But FT ME isn't all that great either. So call that one a wash.
  5. You want to use the 1734-NATR if you are using DLR to map your PLC IP address to a an IP address on your SCADA network. Otherwise you can use the 9300-ENA, which is another NAT device which will do the same thing, but not DLR compatible. If you have a Stratix switch already, it might have NAT, depends on the model.
  6. User Define Tags (UDT) are custom datatypes that you can create. This allows you customize your logic, and make it more legible. UDTs are related to AOIs (add on instructions) as when you create an AOI, by it's definition, it creates a UDT for the specific AOI. AOI - This is like a 'function block' of code, or a custom instruction a user created. Just like the native Timers, Counters and Math instructions, an AOI instruction can be added to your logic like any built-in instruction. The AOI is completely user created, so you can create reusable code. It's an object that you can instantiate over and over again in the logic. So if I have 100 motors in a system, I will need all the control logic for those motors. Start, Stop, speed commands, running feedback, motor disconnect feedback..etc. This is tedious and prone to copy/paste errors. With an AOI, you can write all of this code one time, and turn it into a reusable instruction. So for all of your motors you just call your motor AOI instruction with its pre-built motor control logic and off. It contains all the logic to control your motor. UDT - This is at the tag level. You can create tags already and assign them a built-in datatype (BOOL, DINT, REAL...etc). Well, by creating a custom data type you can create tags with custom datatypes. Say you have a analog input. You know that you will always need the following tags for any analog input in y: Raw_Input : DINT Scaled_Value : REAL Raw_Min : DINT Raw_Max :DINT Scaled_Min :REAL Scaled_Max : REAL If I have 100 analog inputs, it's a chore to define all of these tags for each analog input. By creating a single 'Analog_Input' UDT that contains the tags I require I can create a new tag using my 'Analog_Input' udt as it's datatype. Level_Sensor_1 : Analog_Input. This automatically will create child tags: Level_Sensor_1.Raw_Input Level_Sensor_1.Scaled_Value Level_Sensor_1.Raw_Min Level_Sensor_1.Raw_Max Level_Sensor_1.Scaled_Min Level_Sensor_1.Scaled_Max I can create another tag: Temperature_Transmitter_1 : Analog_Input And it would automatically generate: Temperature_Transmitter_1.Raw_Input Temperature_Transmitter_1.Scaled_Value Temperature_Transmitter_1.Raw_Min Temperature_Transmitter_1.Raw_Max Temperature_Transmitter_1.Scaled_Min Temperature_Transmitter_1.Scaled_Max Read up on AOIs and UDTs in the manuals. They are quite valuable.
  7. Personally, I use alias tags but not directly on IO. For IO I always buffer it to the AOI that controls the device. I have various input mapping routines for my digital inputs, analog inputs, device feedacks...etc. Same for the output side. I also have AOIs for all of my field devices, as that logic adds additional functionality to my system such as delay on/off, simulation logic, alarms..etc. From a basic perspective, my IO mapping logic for a digital input would be a simple XIC (Local:1:I.Data.5) OTE (LS001.Field_Input) where LS001 would be a tag for my digital input AOI representing Limit Switch #1. LS001.Field_Input is where I feed the field digital input into my AOI logic for processing. The LS001 children are used throughout my program. Child tags might be: LS001.Field_Input (This is where the field IO signal is buffered too) LS001.DelayOn_SP (This is a delay time setpoint, perhaps I want to debounce the signal) LS001.DelayOn_Timer (This is the delay timer) LS001.Simulation_On (This is a simulation bit where I might need to use it during testing, it just a software bypass of the Field_Input) LS001.Alarm_Active (Maybe I want some type of alarm for the deivce) LS001.Delay_Input (This is the state of the Field IO signal AFTER a time delay). Doing it like this gives me additional options for my device, plus if my IO changes, I only have to update the IO buffer routine. I can do this manually, or easily with some scripting in Excel or Python. On large projects, using Excel or Python to create the logic and importing it as an .R5X file can be a real time saver.
  8. Mitsubishi - Gettting Started/Advantages/Disadvantages

    Thanksf or the feedback JRoss, I think the biggest challenge will be to replicate our AOI/UDT functionality that we have created in RSLogix5000 into equivalent code. Coming from an AB world, seems I will need to fall back to my SLC/PLC5 experience when it comes to memory allocations and tagging. Then go back to our "pre-AOI" world of calling routines for device control and indexing through it.
  9. Mitsubishi - Gettting Started/Advantages/Disadvantages

    Thanks, I came across that but since that thread is 10+ old years I figured I'd ask again ;)
  10. All - Our company recently got a request for a small automation system, however they spec'd Mitsubishi. Our typical clients request AB (ControlLogix/CompactLogix), as such we pretty much have all of our standard software on AB taking advatages of things like AOIs, UDTs, Import/Export features. How difficult is it to transition to using a Mitsubishi? I'm starting to look into the product line and software, for the people who have used both whats the biggest differences? Advatages/disadvantages? Part of the project process is to evaluate risk, so of course a new platform is a risk, just trying to quantify it. Thanks!
  11. Batch Process Control

    I would disagree with this approach. IF you could bring an SI, you are better off letting them drop in their standards and methods, learn from them. Trying to develop your own standard, then asking a Systems Integrator to implement well that will just cost more money and more headache, and you'll end up with less functionality. Let the pros do what they do, they have years of experience that just raise the bar when it comes to this sort of thing. As others have said, S88 is where you want to be, but to get there the "right" way is an investment. Considering the original design concepts of your system are almost 20 years old, it's time to consider modernizing it Maybe it won't happen right away, but in 5 - 10 years, management can't believe that their 25 year old methods are efficient. So your company really needs to begin to create a rough plan for a migration strategy now so it can be though-out, budgeted as a capitol project in 5 years. It's great that you've converted to CLX, but unfortunate the system wasn't re-written at that point. As you've discovered, converting the software to a CLX is quick, fairly easy and cost-effective but you still have constraints due to the original platform. When it comes to S88 and CLX, you really want to become educated, and start using Phase Manger in the CLX. "Phases" are the key to S88, it maintains modular code, it ensures standard code, and it allows dynamic code. Phase Manager is also Rockwell's solution on the PLC level to adhere to the concepts of S88. If you've been talking to Rockwell at all, you are probably aware of this. Unfortunately S88 software licensing (FactoryTalk Batch, WW InBatch) isn't cheap. Our software standard is completely based on S88, but we use the S88 concepts for everything. Batching, Continuous my opinion I can program just about anything with the S88 philosophy. I've done a few batching projects now, and the biggest reason to use FactoryTalk Batch or WonderWare InBatch is for recipe management. Dedicated batching software, and PLC code which is all S-88 compliant really gives you a lot of creativity as to how your recipes are created and executed. As you've mentioned, you now have mass flow meters and you could do simultaneous additions, well that is pretty easy to change the recipe to handle that with dedicated batching software.
  12. Point I/O compared to Flex I/O

    I'm a fan of FlexIO, if PointIO CIP connections can be managed all into a single connection for one rack regardless of specialty modules that would help convert me. The bigger problem for me is wiring them. With Flex you have plenty of terminals to land your filed wires, and in general a 36"x60" panel will accommodate 2 full FlexIO racks and all the power/field wiring/conduit entries PointIO, it all depends on how compact you are trying to make your IO. Sure on PointIO you can cram 8 digital inputs into a terminal, but you have voltage/common terminations that have to move somewhere else, where as on the 2 and 4 PointIO input modules all the wiring can be landed on the PointIO terminal (to an extent). That same 36" x 60" panel could fit more IO using PointIO, but that means more wires, more conduit entries and you have to change your wire ways accordingly and now that 36" x 60" panel seems awfully congested. Gets more complicated when you get into analog IO. 2 point analog cards are great for landing your field wires, but eat up your CIP connections. I think PointIO is good for machine/skid systems, but I don't think I am ready to use it an a large distributed system yet unless I was trying to use a large quantity of control panels of a smaller footprint say 30" x 36".
  13. RSLogix 5000 Question

    I suppose it depends on how "machine" is defined/interpreted....I think of a "machine" as something that can be broken down, re-located, "self-contained" (skid), minimal cost to do so, "turn-key", HMI & PLC & electrical can be moved with the machine without disconnecting. "System" equipment (my definition) is equipment that is pseudo permanently installed. Sure you can move it, but you would be de-commissioning and re-commissioning, high costs involved in both mechanical and electrical work, and it takes weeks-months to commission. With that said, I would love to see your system regardless of how you define it, especially if you still consider it a "machine" by my thought process. If you can give tours I'd love to see it. Either case, you compliment my point that a functionality comparison between RS500/RS5000 is moot considering how complex the machine/process/system will end up being. The code itself will be drastically advanced (especially when using flagship controllers) then what you would see in RS500.

    I have come to appreciate the cost. And I and see why others do not. If you plant maintenance, and you don't change much of the PLC code in the plant, then don't pay the support yearly agreement. Pay the $400/hr for the phone call when you need it. If you are an integrator, it really depends on the variety of RA products you use. I have yet to find a vendor that can provide a single phone number, where I can get assistance on any product. PLC/SCACA/Drives/Switches....etc like RA can and I KNOW someone will pick up (anytime of day), and I know the Knowledge base is there as a backup. I have yet to find a knowledge base as useful as theirs. GE, Siemens, Wonderware...none can provide the information that the RA knowledgebase can. I was on a startup in the spring, and the system consisted of a RA PLC, Danfoss VFDs, InTouch Scada, and I had every problem imaginable. VFD "emergency" tech support consisted of a single guy with a cell phone who was walking through a parking lot..., Wonderware, you are forced to use your distributor support first, and their "WDN" "answers" to tech problems are not detailed enough to help at times. RA gets me the info I needed when I needed it. Had I used PowerFlex Drives and Factory Talk SE, I would have had one phone number, when I needed them, where I needed them. I wasted a few days tracking down support from multiple vendors. It all depends on what you use, how often you use it and how complex your systems are. I am happy when I go to sight and I have a single phone number to call and a good knowledge base to reference in case things don't go "smoothly".
  15. RSLogix 5000 Question

    No you won't have issues. However, you may need to upgrade RSLinx pending firmware version the ControlLogix will be. I'm very surprised that a "Machine" is coming in with a ControlLogix L7 series processor. That is the flagship processor now, really for entire plant control, not necessarily machine control. I would have expected a compact logix (granted, complex motion-control...etc may require it). With that being said, one can only speculate as to what the program is going to look like, I would imagine that this the code itself may dwarf whatever you have seen in a SLC/Micro PLC before. This will be more of a shocker than the 500/5000 comparison. For example, I am leaving a customer site and they have an L6 series, within that processor there are: 10 periodic Tasks, Each task contains 10 - 30 Programs, each program contains 10-15 subroutines. Best guess is that it contains 1500 ish sub-routines, maybe 20,000 rungs of code total? You'll never see that within the Logix 500 realm. This example is of a large-scale plant integration piece, which explains why the program is so complex. Again, surprised to see a L7 controller on a "machine", but if that is what is required, you'll have a lot to learn in general!