PLCMentor.com

Wow I have too many questions. There are many factors that could be at work here. Two amps doesnt seem like a huge amount of current draw at 24VDC, but I guess it could be on some systems. First what size is the SLC power supply (ie, what is the amp rating)? What size rack and what I/O cards? Is the SLC power supply used to power any cards that require external power? All of these things will affect your current draw. That all said, my gut feeling from what you said the system was doing is that you have a bad SLC power supply.

At first glance that looks like you have used that same tag for the ZSO somewhere else in your program or possibly that the rung is not being scanned. Do a cross reference on your tag and check for duplicates. Also, make sure that the routine you have is being scanned (ie, is the main routing or has a JSR from the main)

check out this previous forum topic: http://forums.mrplc.com/index.php?showtopic=7850 It looks like Red Lion has a product that will work. I dont think you are going to get Mitsi and AB to talk directly, but the red lion protocol converters work well and you dont have to rely on a PC being up and running.

I would suggest this gateway: GW1000-ABEIP Ethernet/IP & AB Ethernet interface to AB DH+ http://www.datalinkconverters.com/ethernetip-to-dh It is an Ethernet I/P to DH+ gateway and it works quite well. It communicates nicely with RSLink and I have worked with it successfully with Inductive Automation's Ignition SCADA package using their built in OPC-UA module. It's especially nice if you have an existing DH+ network as you can just put this on the existing network and port it over to Ethernet I/P. Of course there is also the option to use a Control Logix setup as a gateway but that is much more expensive.

I dont think I have ever passed text, but I dont know why you couldn't preload several tags with the text you want and then just pass the tag as part of the parameter file.

I had heard that the Logix was based somewhat on the Automax. I've used both and really dont see it but thats what I was told. I would be interested in seeing a conversion that worked well. Usually they are a mess even if they work. It's kinda like upgrading and still keeping your old system all at once. I'd put in a vote for Bob's method. Sounds like a solid method to be able to fall back on the existing system until you are comfortable with the new one. The way you can buffer your I/O in the logix, phase 2 should be relatively painless.

We regularly use ethenet I/P for our control networks as do many places from our discussions with our local rep (I have not noticed many errors accumulating as you mentioned so that may be an issue with your network). We also use the flex I/O as I think it is more straight forward for installation and troubleshooting than the point I/O. It eliminates the need for interposing terminals necessary for rack I/O due to the separate base/electronics design. Generally the plant IT guys are instantly familiar with the network and comfortable with it. High network speeds, as you mentioned, tend to make up for any issues with it being non-deterministic. It is cheaper to install and quicker to bring up than any of the other network topologies. The only gotcha I see in using ethernet I/P for control is the need for a managed switch. Without a managed switch in your design, you risk the possibility of overloading some components on your network. The AB drives are an example. They can handle a relatively low number of packets and can be overwhelmed if there are a large number of devices communicating without a managed switch. Shielded ethernet cable for your field runs are suggested. Limiting or eliminating a connection to the plant business network is also advisable.

Not sure I see any need for PID control here. You are doing a simple fill to setpoint and closing the valve. I see someone determined that a modulating control valve should be used to eliminate hammering. I guess that will work; however, I think a cheaper solution may have been to put something on the vent of an on/off valve to slow down how fast it closed. I suspect everything has already been purchased and this is what you have to work with. You may want to experiment with your new valve. Depending on the size control valve you have, I doubt it closes fast enough to cause hammering. That means you have to do absolutely nothing in your program to prevent this. That's best case. If you do need to do something I would suggest just ramping the valve closed. This is not PID, but just a simple bit of ramp logic. I dont think there is a ramp function in the 1100; however you can just setup a SUB and a timer in such a way that you slowly close the valve over time (ie, every time the timer is done subtract some from the output to the valve). You can then control how fast or slow the valve closes by adjusting the timer preset or how much you subtract. You will also need to add some sort of cutoff value to your logic that closes the valve. This is a small amount that gets subtracted from your setpoint to allow the valve to close a little early. This will allow your logic to close the valve a little early so that the slow closure doesnt go over your setpoint. This is also necessary if you have enough pipe after your valve that will end up draining into your tank after closure. Make the cutoff an integer data location or something that is easily adjustable so you can change it as you watch things work. Let me know if I somehow missed how you intended to use PID in this app. I just dont see it.

I am not sure why you are having a problem with this. You are correct that you dont need a mem card. The fact that you have successfully loaded new firmware proves good comms. Why dont you try just going online with the processor first to see if you can get past that hurdle. You also might want to try going online with the comm port or your other ethernet card. I have only used one L4x processor, but I think it has an on board comm port. Starting with that may eliminate any issues with the ethernet cards or configuration. It doesnt really sound like you are doing anything wrong so I would resort to trying something different.

Ok, so I would have to see your network topology to be able to answer this question. I can make some guesses. I had to do a little reading into dupline as I have never heard of it before. Dupline is a fieldbus type network that can transmit up to 10km. Maybe that is the reason they used it. Ethernet is only good for about 300 feet or less. You will have to look at how things are connected to determine the actual functionality of what each network is doing. I suspect now that the modbus cards are used to communicate with the Dupline master and then it communicates to remote dupline modules. The ethernet is the best network for communicating with an HMI or PC and is generally very good for connecting Remote I/O cabinets as long as the distance is close enough. All of that is a guess. I have seen people do weird things with network installations. I have even seen where engineers used as many networks as they could to learn how to use them. Not good for the end user, but I have seen it done. Hope some of this helps shed light. You need to have some sort of network diagram for such a system and if you dont then you need to start investigating what is connected to what to better understand your system. The Logix platform will generally shed some light into all this as many of the network connections will show up in the program configuration. I am not sure about this Dupline setup though. It will probably not show up in the Logix configuration.

You never told me you were applying FM principles to this... Glad its working.

Here is another thread on this: http://forums.mrplc.com/index.php?showtopic=22373 In it there is mention of setting the PLC comm port to CRC instead of the default BCC. Might be worth a try.

Well there goes the simple solution! Generally with comm problems I would start with RSLinx and exhaust all my options there. I dont remember what information is available from the ENI, but can you go into RSLinx and look at the config info to see if it matches what you would expect on the comm port or see if there is a valid comm link to the PLC5? Also, I think the ENI has a web page that has diagnostic info on it. Can you go to that and see what is going on between the ENI and the 5. You are communicating with the ENI properly and you can communicate directly to the 5 with a comm cable. I suspect the ENI is not communicating with the 5. Are you sure the cable from the ENI to the 5 is correct?

So I'm not completely sure I understand all you are describing and I am not even sure I completely understand your question so here is how I understand it. You have a controlLogix with remote I/O. The remote I/O uses modbus to communicate. I think there is another comm network but I am completely lost on that one. Your question is, why distribute I/O in this manner? I would assume that in the past your I/O has been all local and possibly located in the rack with the processor. The simplest reason to use distributed I/O is to cut down on wiring and the installation costs associated with such. You place I/O locally close to the field devices and limit the distance that wire needs to be pulled. The information gathered by the rack is then communicated, in your case, by modbus back to the CPU. There are other advantages such as modular designs allowing for organized expansion, but generally the costs savings by locating your I/O locally is enough.

OK, just a wild stab, but you aren't really using RSLogix500 are you?

So it works now? Because it looks like to me that you have your totalizer in ProgOper mode instead of ProgProg mode and you are using the ProgResetReq not the OperResetReq. I really dont like all their "flexible" modes that they have so I usually just set my function blocks up with the ProgProgReq set to 1 and the ProgOperReq set to 0. To me that keeps things a little more straight forward.

Well I would suggest that you went wrong by using indirect addressing. It is always hard for others to follow and very difficult to troubleshoot. I would suggest thinking twice (maybe even 3x) about using it. That said, I understand that it's not real helpful with the issue you have. The error says that the file type doesnt match the file number. That points to the N7:9 value not being valid for the data file locations you have created. Assuming that you have a file number created for all possible outcomes of your counter then I would look to the possibility that your pointer value is not being copied into N7:9 before your copy statement. The other possibility is that the counter accumulator has a value in it higher than the available file numbers you have created. I would suggest at the very least putting a limit instruction before your copy to check and see that N7:0 is a value from 10 to 50. better yet would be to use an EQU to check each valid value, ie if N7:9 = 10 then go ahead and do the copy. Also, have you checked the value in N7:9 after the fault? Is it valid? You mention a warning, I would assume that an invalid pointer would lead to a major fault in the processor. That should kill everything and allow you to see what value was in N7:9 at the time of the fault. Hope one of these ideas helps.

I gotta say that I despise automated conversion programs. Usually leaves the poor maintenance guy with a mess to sort through. Not to mention I remember the slc to logix conversion converts the slc addresses to something similar in the logix. The user misses out on one of the wonderful things about the logix which is tag names that mean something. Seems that a client that is willing to pay the difference between a compact and control logix just to standardize may be willing to pay for the time to convert the program to a real logix program. Might be worth checking on as it would be better for both of you. Better program for them - more work for you (assuming thats a good thing).

Nooooooooo! Been there and done that. What a mess. I was talked into it because it would be cheaper. The setup and design time involved eliminate any hardware savings and it is a permanent pain in the rear to configure and work with. It was kinda cool to put together and get up and running, but I would never let anyone talk me into that again. RS485 would be better. Almost anything would be better...

Can you setup the ethernet port for modbus TCP? I dont think that is possible. I would be very interested to know if it is. I know you can setup the com port for modbus rtu - that may be an option. I would also suggest the compact logix if it fits in your budget. Point I/O via ethernet i/p with a control logix would work. The point I/O does have a learning curve. Physical setup and wiring are strange and (in my opinion) not intuitive.

Yeah I got that card also. Probably went to everyone with a toolkit. I do use the flex quite a bit, but not the modules listed.

thanks! I stumble around looking for that every time I need to use something out of those tabs. Must be some sort of mind block.

Well that changes things a little... The 1100 is a great little controller for the price so I can say anything negative there. It's hard to justify the big leap to the compact pricing when you have a little thing called a budget. There are still options in the micro - or there are supposed to be. Everything I see in the docs indicates that it has the capability to have an STI file. I think with that you can accurately totalize the analog signal. There doesnt seem to be a tab for it in my structured status, but S:30 and S:31 seem to be the locations to setup the file. It might be worth playing with or maybe someone can fill me in on an alternative method to configure the STI in these controllers. The documentation speaks of an STI tab, but I dont have one.

Hi Michael - Always good to be able to bounce questions off a few hundred friends... I think staying with the pulse method is trying to cram a new measuring method into the old. I would suggest looking into the totalizer FB with a periodic task for accuracy.

I tend to agree with Michael. One question would be what stops it from going over 24? Possibly the inaccuracy is due to how you stop the accumulation or reset it. If it is a timing issue - what type of task is it in? Possibly you could put this in a fast periodic task and make the problem go away.