JStevens

What scanner are you using (make and exact model please)? Do you have any communication modules in your PLC? Are there other devices communicating with the PLC? How fast do the scans have to take place (i.e. at a rate of ___ per second)? If you can give us some more information, I am sure we can help you.

I don't own a 1400, but I do own an 1100, but I imagine this should be true for both controllers: the SCD value is read only from the program. That is, you cannot set the bit from within the ladder logic. You can, I believe, set the bit from the controller's function file before you download the program to the controller. This should force the controller to start with the customized display every time the controller enters RUN mode until you manually clear the bit from the function file. It has been a long time since I had to do this, but I am pretty sure that this should work.

Hmmm, there is one piece of hardware at which we have not looked yet: the ethernet switch. What type of switch is it, managed or unmanaged? Better yet, give us the manufacturer and the full model number. If it is managed, then there may be some odd configuration problem. If it's unmanaged, we may have a traffic problem. Although it probably is not a switch issue, it is something worth looking at.

Since this is an input, I am inclined to say that there is something that fried on the inside. To the best of my knowledge, there is no way to "lock" to inputs together on a ML1000. Can you tell me what the application is and if there is current protection on the inputs? If nobody changed anything in the software, then it must be a hardware malfunction, in which case you should call your Rockwell distributor for a replacement. I am very curious to find out what it is.

I think it is Rockwell's [poor] attempt to get service contracts that they could use to increase their hardware sales. For a long time, Rockwell has been steadily expanding their design and support services and trying to make a profit off of it (Tech Connect, anyone?). I think they have been facing increased competition from other brands whose products offer a better value, thus the need to profit from their technical support. I believe that Rockwell wants to be the one to service these systems because when they break, RA can come in and say "this, that, and the other is broken/wrong/failed, but luckily we have the exact product you need." This way they could surreptitiously supplant competing hardware with their own and none of the higher ups will question it because "they are the experts." This is an attitude I have experienced very often, so I think Rockwell is also aware of this and wants to capitalize off of it. Just my rather cynical take on the whole thing. RA's motivation aside, I agree that it is odd and I wonder how much success they will have. I can foresee in-house techs, programmers, and engineers going away in favor of third party companies managing these systems. I think it is foolhardy because you need people on site who can fix problems when they arise, without having to pay an arm and a leg for "emergency support."

This sentence is confusing me a little. Are you saying that in the field for the DNS server you have placed the computer's actual IP or the same DNS address that the computer is using? Perhaps I am not familiar enough with PV+, but I suspect that this may be the problem. If you used the hostname of the computer, the PV needs a domain name server to find out the computer's IP. You can test this by changing \\pcname\folder to \\PC_IP_Address\folder. ~Jeff

I am unable to open your project. What version of RSLogix500 do you have and what level is it? Example: version 7.20 and RSLogix500 Starter edition. ~Jeff

Correct, if you use immediate addressing (i.e., placing "500" in the instruction itself). You can use an integer or another floating point address as the comparison and then store the number of gallons in that address. Then they can adjust that through the HMI. ~Jeff

I missed that requirement that it pumps 500 gal and then turns off. This makes more sense and is easier to implement. I actually think he would want to use a LES, not a GEQ, because he wants the pump to run until it reaches 500. If you use a GEQ, the pump won't stay running until it reaches 500+ gallons. Try this: Pump_Start_Logic.pdf At 10:00:00AM, the first (top) branch becomes true and starts the pump. It will remain true for 1 second. After the first scan which turned on the pump, the second branch will remain true until the total flow reaches 500. This method assumes that your total flow is stored in a floating point elsewhere and is reset every time the flow is equal to or exceeds 500. The total flow must be calculated elsewhere. Most flow meters I have encountered only tell you the instantaneous flow at that point in time and you have to use a totalizer to find the total flow, but I don't know what you intend to use. ~Jeff

I suggest you download and save a copy of this manual. It includes the entire instruction set for the ML1400, as well as addressing requirements and data file types. I would read the introduction, the table of contents, the preface, and the first 4 chapters (pages 1-98 in the manual, or pages 1-100 in the PDF) as general reference for programming your controller. Then look up specific instructions as needed. AB is really good at producing documentation; I would take advantage of it. ~Jeff

With regard to X and Y, these are values that you need to either measure yourself or find from Wika. I did a little reading, and it seems as though Wika produces the LS-10 in multiple pressure ranges. The closest I can see to 100m is the 0-10 Bar unit, which should be 0-102mH2O. You will have to verify this as being accurate. The minimum depth, X, is 0 Bars. Meaning that at 0mH2O, the sensor will output 4mA. To find the maximum depth your sensor can handle, Y, multiply the maximum number of bars by 10.2 to find the depth in meters. At this depth, in meters, the sensor will be outputting 20mA. Source: Wika LS-10 Datasheet Now for the scaling. Make sure the analog configuration is set for "4 to 20 mA" and "Raw/Proportional". Having the data format set to raw, will give you a bigger input range, which will make all of your math more accurate. At 4mA, the ML1400 will read 6240. At 20mA, the PLC will read 31200. This applies to the IF4 card only; the ML1400 base cannot accept current inputs. Source: AB ML1400 Reference Manual (Page 20) To put it all together, your SCP parameters should be as follows: Input: the address of the analog input word Input Min: 6240 Input Max: 31200 Scaled Min: 0 Scaled Max: [Pressure Range Maximum]*10.2 (You must calculate this yourself based on your actual sensor.) Output: the address of your destination (I recommend a floating point file, because you are sure to have a decimal and this will allow you to easily perform math in the PLC) Bear in mind, that this is based on the documentation I can find on the web, which may be inaccurate for your particular models. If there is a problem with this, let me/us know and I/we will do my/our best to help. ~Jeff

This would definitely be the easiest method. Instead of your scaled min and max being 4 and 20 respectively, make it X and Y respectively, where X is the depth at 4mA and Y is the depth at 20mA. This way you can do native calculations on the depth instead of using mA values. This number should be stored as an integer. Then your PV can read the integer's value and display that as your depth. You did not state which controller you are using, but not all AB PLCs have selectable analog ranges. For example, on a ML1100 with the raw/proportional data format, 4mA corresponds to 6240 and 20mA corresponds to 31200. ~Jeff

You also need to consider how long the timer is going to be and when it will be triggered. If you want the timer to trigger at exactly 10:00:00 AM with no other qualifying logic and it is less than an hour long, then a single EQU statement for RTC:0.HR=10 will be sufficient (Rung 0). The rung will be true for the entire 10AM hour, allowing the timer to complete and then set the DN bit. If the timer is longer than an hour, then you will also need to put the timer's TT bit on a branch to keep the timer true until it finishes (Rung 1). If you have other qualifying logic on the rung, then you may run into a condition where the timer can re-trigger during the 10AM hour. To prevent this, you add another EQU statement for RTC:0.MIN=0 so the timer can only trigger during the first minute of the 10AM hour. To further refine it, you can add a third EQU statement for RTC:0.SEC, so it will only trigger during the first second of the first minute of 10AM. To keep the rung true, you will need the TT bit on a parallel branch (Rung 2). If you want to take this to the extreme, then you can use just the first EQU for RTC:0.HR=10 and a ONS instruction to turn on a bit. On the next rung, the bit will trigger the timer. With this logic, the rung will only be true for the first scan of the 10AM hour. To keep the run true to continue the timer execution, you put the timer's TT bit on a parallel branch (Rung 3). This logic was written for a ML1100 not a ML1400, but for this example, the two are the same. Timer_Example_Logic.pdf ~Jeff

If he can successfully ping both devices from the same computer without changing the wiring or computer configuration, then they are inherently on the same network (and subnet too). There is one exception to this, and that is if he is sending a ping command from his computer to be executed by a router, in which case, the router sends it out of one of its interfaces (it does not tell you which). The latter is not the case here, but it is useful information for those who configure routers. In RSLogix, make sure you have your channel configuration correct. Your IP settings seem right, but make sure you have selected the correct protocol for the HMI. Also, your PLC must have a static IP address, meaning that BootP is not enabled.

This is an interesting issue. Without knowing much about Railswitches, my hunch is that it does not like your OS. When any browser (one that is in standards compliance, at least) requests a web page, it sends a user agent string. This contains, among other things, your OS, your browser type and version. The Railswitch was probably programmed to accept only certain user agent strings. If you are willing, a way to test this theory is to download the Mozilla Firefox User Agent Switcher. After it is installed, using this site, find the correct user agent for the successful browser on XP and copy it. In Firefox, go to "Tools," hover over the "Default User Agent" item, and choose the "Edit User Agent". Select "New" and then "New User Agent...". Give it whatever description you like and then paste the string into the "User Agent" field. Delete the contents from the rest of the fields. Click "Ok" in both open windows. Then, go back to the "Tools" menu, hover over "Default User Agent" and select the one you just wrote. Now, try accessing your switch. I'll be curious if this works. If not, you've got me... Oh, one more thing. If you want to be sure that you are putting the correct user agent string into Firefox, go to the computer that works correctly. In IE's address bar, type: "java script:alert(navigator.userAgent)" This is case sensitive, and pressing return will open an alert box displaying the full user agent of that installation of IE. You can use that in Firefox and hopefully, it will work. If not, then we may be looking at some internal compatibility issue between the computer and switch. Either way, let us know.