PLCMentor.com

Have you tried calling the OEM to see if they will unlock the program for you? Sometimes OEMs lock the program until payment is received. Of course if there is still and outstanding balance.. well many of us here are OEM's or integrators and kinda like to get paid. Seriously, the logix seems to be pretty good at protecting programs. I would contact the OEM and let them know you feel comfortable doing the edits in house. If they have logic that they think is proprietary, then ask them if they can lock that portion and unlock the portion you need to work with if it is in another area of the program. The logix has some flexibility there if they set it up properly. In the future I would recommend you tell whoever does the purchase specs for your company to make sure it is in the agreement to be provided with an unlocked version of the program when the final invoice has been paid.

In my experience, the unrecognized device will show as a question mark, but will not keep me from communicating. Have you tried going into your program, selecting communications from the top menu, selecting who active, selecting the ip address of your device and clicking on the online button? Also, I have had problems with the ethernet ip driver and my firewall; however the standard ethernet comm driver will work. I have also been on networks where my ethernet ip driver has problems and the standard ethernet driver works.

Italy?? I'll travel!

I think that is more along the line of what he is looking for except you will need a NOT instead of the NEG. With 2's complement integers, the negative will not be a simple inversion but an inversion +1.

Oh now thats different. No it would not work. OSR is a oneshot. A traditional oneshot looks for the value before it to go from a 0 to a 1. One shot rising (OSR) does the same. The reason this is not working is that the value of N9:1 is always greater than 0 in your case. If the first bit is still set when the second bit goes on, the oneshot still sees a 1 at the output of the GRT statement.

not sure what the sor is but the rest of it looks like it would do what you are looking for. keep in mind that the OSR bit will turn on and stay on until the condition if front of it is false (or 0). It will only pass that true (or 1) condition through for one scan. So in your case, if the result of the GRT instruction is true, then the osr bit will be on; however, the otl instruction will only see a true condition before it for one scan. You should be able to toggle that bit at will even though the osr bit is true. The bit assigned to the OSR instruction is just used to show that it has already performed its oneshot function.

First check delivery on the 1400 and make sure it will meet your schedule. Seems to be a delivery problem with the micros right now. As for your question, I think I need to understand it better because to me it doesnt sound like you need PID control. This is what I gather from your text: 1. you have 8 analog outs you need to control (4-20ma) 2. you want to be able to set the outputs from the panelview 3. you need to be able to plug a value into the panelview and have the outputs change due to those values I think all you are looking for is for the program to move the value entered into the panelview to the analog output. You will probably need to scale the value according to the entry on the panelview and the required output action, but I dont see a PID application with the info you give. You dont discuss analog inputs and you mention setting your setpoint at 100 - I dont understand that. Maybe you dont need PID? If Im off then bump me back on track and I will try to help from there.

Yeah I think most of us are lacking in the IT arena. Their world is a little like ours in that it takes time to keep up with the constant changes. I think if you mention adding the device and checking the router tables they will have somewhere to start. IT and controls guys traditionally bump heads, but in this environment where our two worlds are combining and crossing over so much it pays to develop that relationship to get you through problems such as this. Good luck and I look forward to hearing what the solution is. Russell

Tom, I think Paul missed the fact that you are able to access the I/O with the RSLinx that is on the RSView station that is sitting on the production network. Your point I/O is up working and accessible at that station unless I missed something. You cant ping the I/O block from your desktop and as Paul mentioned, if you cant ping it then there is no need to try anything else. I think you have an IT problem with the Router. You need to talk with whoever setup the Router and work with them to enable your I/O to talk across it. I am somewhat a dummy on professional routers where ip tables have to be configured, but it may be as simple as your new point I/O not being configured to talk through the Router. Check with IT. Russell

Well at least you can access the device from the computer that you eventually want to. Have you tried pinging the device from your desktop?

Never apologize for being long winded. Rarely do we see too much information here generally the opposite. I do want to clarify something you mentioned. When you say you entered the gateway address in the point I/O, are you saying that you entered the same address there in the point I/O that you saw in the ENBT card configuration? That sounds right. Maybe you should check with IT to make sure that this is really the address of the router separating the areas. The first time I read it I wondered if you were talking about the address of the computer running the RSLinx gateway. Have you checked your subnets? Usually they are 255.255.255.0, but there are times when they are configured differently and it is easy to miss that when adding a device. Can you drill into the ENBT card and back out and see the I/O? I think that would work in the instance you have given.

Ok Steve. Interesting idea. I can agree with having a list of "go to" people for situations like we have now. I'm not a real fan of the Micro line except for the new 1100 and 1400's. I would suggest that another avenue for people caught in this situation would be to go up to the L2x series of the compact line. If you have been putting in a lot of logix into your facility, that may have been the better (albeit more expensive) path anyway. I would also suggest that deciding to go a different direction not be a knee jerk reaction but take some time to think it through to make sure it is really necessary. That out of the way, we would be willing to help migrate people to a different platform if necessary and practical. We have good experience with Siemens and I like it just about as much as the AB stuff - just not their local support. We also have good experience in GE though I would pick the Siemens first. We have had experience with many others and would be willing to discuss the pros and cons of other systems on a case by case basis. As a suggestion, start by looking at what your currently have installed in your facility and the type of service you have experienced with the non-ab stuff. If you have something that is working - no need to look further. If you have stuff that is nothing but headaches - no need to go down that road again.

Kinda makes you say, "Oh JIT"

bummer. Looks like you may have a 5 hour drive ahead of you. I have had a problem in the office where I downloaded a program and had the same error. My program validated with no errors, same processor, etc. but crapped out the processor. I was able to download an older program to the processor successfully. You might want to try downloading a single rung program to the processor just to see if you can install a program remotely. If that works then the drive isnt going to do you any good - you must have some sort of weird error in the program. I never have figured out what the problem was with my program that did that. The fact that you can see the processor is some indication that there is hope to solve this remotely. Beware of those bad phone connections. One of our engineers wiped a remote program because of a bad connection once in the past. Try establishing that you can load a token program first and then work your way up from there. If not then looks like a nice drive in the country.

Well unfortunately your question has created more questions than answers for me... I will start with the info I can give. You will need RSLogix500 or RSLogixMicro to program the PLC. RSLinx lite comes with the programming packages (lite means it can only be used with the RSLogix programming software). Realistically a system such as this would just need pushbuttons going to the PLC to operate; however you mention Visual FoxPro. This is where the questions start. Fist let us all know if this is a class. Sometimes classroom projects are created more to teach a point than to be a realistic operation system. Do you understand ladder logic? You will need a basic understanding off ladder to program the PLC. How will the FoxPro application communicate with the PLC? It will need some sort of communication interface to be able to talk with the PLC. RSLinx is the communications interface between the RSLogix softare and the PLC in what I have described above. You can use RSLinx as a communications interface also, but you will need the non-lite version to be able to do this. I am sure Foxpro can handle linking to the RSLinx if you have the proper RSLinx version, but that will be an exercise in itself. I know Foxpro is versatile, but I have never used it like this before so I cant give further information on that setup. I guess I have assumed that this is a class project, but if not then maybe we need to talk about a better design for this application.

In any case it would be a lot of redesign and reprogramming. Both tasks far outweigh the cost of any hardware in the $500 range. The 1100 and 1400 filled a nice hole that AB had in the lower end (but still functional) category. It would be a shame if they screw it up with the availability problem.

No such luck. The PLC5 is pre-SCP. Not sure why they didnt add it with the later versions of the PLC5's, but they didnt. But on the bright side, just think of all the fun you will get to have with math instructions! That and working with block transfers should allow for hours of fun. Seriously, the PLC5 methodology looks pretty dated with all the cool stuff we get in PLC's now but it's a rock. The processor and the I/O can be abused and take a beating without missing a beat.

As I mentioned, there are exceptions to every rule. Documenting and tagging like a lockout would make some sense in those rare cases. Maybe my view is an SI point of view, but in 20+ years of programming I have never left a unit with test edits in it. I have never seen a reason to. I am not going to add an edit to an operating system unless I know what that edit is going to do. Yes, I have come across some squirely code that does things you would not expect, but I usually see that when I first test it and if it is something that needs a long wait to determine I will just assemble the code and I can change it back if I have to. The point is that leaving stuff in test is not what someone coming into a program will expect. They either will be locked out of making changes or could accidentally assemble the tested code leaving the person that left it there in a pinch if they were expecting to use that to go back with. Too many ways to go wrong for me. I like the idea of physically documenting (external to the processor) forces and tests such as these if necessary. I think I may have to start implementing projects with that tagging in mind. Thanks Ken.

does this problem extend to the 1100 as well? Yeah no ethernet and no online programming capability. Thats the problem with the rest of the Mico line - they are pretty much neutered.

OK, I'll bite. This sounds like a trap that someone would leave for me - however unintentional it is! First it sounds like the guy doesnt know what he is doing and is possibly leaving the edits without realizing he needs to assemble the program. Maybe a little on the job training is necessary. When the edits are in test mode, it will lock out anyone being able to make edits to the program. With multiple parties going into the system it possible that someone would just assemble the edits or more problematically for production they may untest the edits which changes the operating conditions of the system. Part of the reason for all the accept, test, assemble stuff is to make online edits a careful process. Changing the online conditions for a running system can be critical and have significant affect on the system's actions. Care must be taken when making those changes and leaving edits unassembled on a regular basis shows carelessness. With any rule there is generally an exception so maybe there is that once in a blue moon situation where a person would want to leave the system in test for ??? (to be determined). I would never leave a site with a PLC in test for any edit I perform.

Conor, Sorry I didnt subscribe to this topic and i just saw your question. I dont know the max right off the top of my head, but if you just have one msg then you wont have an issue. I am out of the office so i cant look it up right now. Generally not an issue unless you have a bunch of msg statements. If you have a lot then cycle them so that they all dont slam the queue at once. Russell

One last thing. Pay attention to the CIP usage. There is a limit to the amount you can drop off of any logix PLC. If you are not familiar with CIP and you plan on more than a few I/O, you need to research it as it is a gotcha. Russell

I usually like ethernet for my remote i/o flex; however, you bring up an issue that controlnet is particularly well suited for. I think the remote block in this situation could be more reliable if configured properly. Wiring back to the panel just changes the failure point from the comm link to hardwired cables. Wiring back just gives you longer runs that can be disrupted like the comm cable can. Setting up your flex for proper fail states I would think would give you greater reliability. Similarly, I think some of the point I/O will give you wire break detection and other failure detection such as you get with the slot type i/o modules. With redundant controlnet you can route your cable via two different paths minimizing loss due to cable damage. With ethernet you can also set up a ring type of system with switches but controlnet seems better suited for this application. Of course redundant cabling only passes the failure point to another location. You will always have the possibility of failure up and down the chain. Do you have redundant processors? What happens if that faults/fails? On the other end, are your valves set to fail properly on air or power loss? You need to examine the whole system carefully with something that can go boom.

You can use the flex blocks or point i/o (ab or other).

conor, Make sure you add a few extra MG locations so you have room for future expansion - that is if your free memory will allow it. Generally you will have a fair amount of free memory and you should have spare locations for data types such as this. You also might want to check other memory types while you are down to evaluate if spare locations should be added there also. You will just need a BT in one processor. In fact, I like to designate one processor to handle all my reads and writes if possible. I have found that the PLC5 platform seems to be more stable with the message statements so I generally handle my messages between slc and 5's in the 5. With all this said, you have a maximum queue available for your messages so if you have a lot of messages, make sure you dont overload the communications queue. You should not have problems like that if you just have one mg to grab the data you indicated. russell