jan.krajniak

Contr_Conn: Thanks a lot for your help! I only have version 15 right now, and whether v.16 will be made available to me depends on whether the company that is sponsoring my teams project decides to get 16. At least now I have another argument supporting my claim that they need to get maintenance on their license so that we can get version 16 :). Again, thanks a lot!! Jan quote name='Contr_Conn' date='Mar 16 2007, 05:56 PM' post='51583'] If you install ver 16 correctly, these files will be there I will not email them bacause you must install ver 16 anyway to use them

Thank you both for your reply! However, I am still in a little bit of a pickle here: I did search my help/demo options before I posted my question, and didn't find anything. When you posted the two file names for the examples I though I missed it, so I went back and searched my whole computer. It seems like those two files did not come included with my RSLogix 5000. Therefore, I was wondering, would it be possible for any of you to send me those two files? My email is krajniak@ufl.edu. Thank you very much, I really appreciate your help. Jan

Hello everyone: I am using a 1769-L31 controller on a condensate pump. The ladder logic is based around a PID; the PV for the PID is the RPM measurement of the pump, the Setpoint is a desired RPM and the CV is the output leading to a pump that regulates pressure in a torque transfer assembly. There are 4 modes of operation - Remote Auto (SP signal received from remote location), Local Auto (SP entered through HMI), Local Manual (output to pressure pump entered through HMI directly: 4-20mA) and Shutdown. I am running into a problem though. Whenever I switch into manual mode and change the RPM manually, after switching back to Auto modes, the PID resumes activity from the last state and I get a big bump. To illustrate better: 1. I start the controller on Local Auto with SP=750RPM 2. When at 300 RPM, I switch to Local Manual 3. In local manual, I change the current so that the RPM climbs to 1000 4. Then, I switch back to Local Auto. At that point, RPM falls back down to 300 and starts slowly ramping up instead of ramping down from 1000 to 750. I thought that the tieback function has something to do with this, so I tried several "tieback" variables like the current RPM, the actual manual output, but for some reason none of those work. I also tried copying the output from manual mode into the .OUT bit of the PID and several other things, but none seem to work. Can anybody help me with this or provide any suggestions? Oh, by the way, the logic is set up so that the PID is "on" (i.e. Examine ON bits for Local/Remote Auto) only when in local or remote auto (yes, I did change it to also being "on" when in manual, didn't work). Thank you very much!!! Jan

Hello everyone: I am back with more questions ... sorry :). My team has decided, that it is a good idea to store tag values from our logic (such as the value of RPM, pressure, ...) on a CFII card (we are not using the official 1784-CF64 card, but a 512MB Platinum card from SanDisk). My understanding of the PLC logic design is enough to design a working control mechanism (very basic :) ), but I am very unfamiliar with instructing the PLC to do "external operations". If I wish to store the values of certain tags with a time index in a database (organized by time/date index for example), can I use some of the file functions? If so, how do I set the PLC to save the tags on the CF card (for that manner, can the PLC be set to read the logic from the CF card in case the program is lost when cycling power?). I understand that a complete answer would be to long and complicated to explain, so if you could at least point me in the direction of a manual/tutorial? (I couldn't find any), I would really appreciate it. Thanks a lot! Jan

Hey manav, thanks a lot for the advice! I agree, personally I would have switched to ENet the second I saw that only a serial port connection would be available. My problem is this: the PLC is not mine, nor am I working for the company (and thus I have no say :) ), which owns the PLC. I am party of a university engineering team (made up entrirely of students) who are working on a project sponsored by a company. Thus, we are bound by the scope of the project as determined by that company, and our tools are also limited by their decision :). THey didn't want to spend the extra money on the ethernet, so we have to deal. We found a way to bypass our problem though - we are transferring all information using compact flash cards. That works fine and fast, and it seems like an easy upgrade/update approach for the company (instead of carrying a computer to the PLC in the plant, they will just bring a flash card with the updated version ...). Again, thanks a lot! Jan

Hello Manav! Yes, I would quite definitely say our problem is serial port related. Also, what you say seems to make sense - different wires seem to make different "stuff" work. For example, we had a wire that is supposed to be "null-modem wire" (so not straight through), and that one would connect the PLC and the PC, the PC to the PV+, but NOT the PV+ to the PLC. I went out to radio shack and bought an RS-232 straight through DB9 female-female (my understanding of NC13). This cable seems to have removed the problem of connecting the PV+ to the PLC, yet now the PC cannot connect to the PLC (from RSView, and even RSLinx has problems recognizing our module) nor can we connect to the PV+ (from RSView, the ENet connection that we have set up to communicate between the PC and PV+ seems to have failed - either the device doesn't get recognized, or we get a "destination is not a valid device" error when trying to download our application to the PV+). So in essence, it seems like our system doesn't want to have two things working at the same time. There is a chance that the problems are being caused by the development computer (because when trying to fix the problem we encountered some strange issues with the COM ports ..), so I will be trying out the connections on my personal computer today. If that fails too, we know its either our wires or something else ... Again, thanks a lot for your input. Jan

Hello Ken: Well, it seems like our problem is more deep rooted than that. Essentially, I walked into our team meeting today and the HMI was working perfectly fine. However, at that point we started getting other connection problems. First, the ethernet connection from the computer to the PLC stopped working (without any settings being changed). We have tried to fix the situation, but nothing seemed to work. Again, we are running into the problem of RSView not recognizing the display (we know it was RSView, because RSLogix connected just fine). Then, after a little while, the computer couldn't even connect to the PLC anymore. It seems that the COM1 port (and all the other COM ports for that matter) is somehow failing. Thus, now the situation is completely switched - the physical HMI is successfully connecting to the PLC and controlling the PLC, but the HMI application when run from the computer is not able to do so. It seems like both avenues are not allowed to work at the same time :). I wonder if the laboratory computer is broken and is simply not able to communicate with either device anymore. Do you know if a problem of this type could be caused by the computer or by the PLC (possibly even HMI)??? Thanks a lot! Jan

Ken, I will try and find a straight through cable (or an adapter) somewhere in our building and check if that might be the problem. Thanks for the input! Jan

Ken, thank you very much for your response! I have followed your suggestions and set the Autoconfigure to YEs, which automatically set the platform to "Logix Platform" and the COM port to 1 (even on the target driver configuration). I also checked the target configuration, and it matches that on the terminal (and even the local, which means that the development computer is also using COM1). However, the HMI still doesn't work when run on the PanelView Plus. It seems like the connection to the PLC fails (yet when run off the computer, the HMI application works just fine). Do you think it might a configuration issue with the PLC/HMI, or maybe I just have a faulty PV Plus? Again, thank a lot! Jan

Hi everyone: I have been asking many questions recently, and it seems like another one has to be added. My team and I have essentially finished our ladder logic (designed in RSLogix 5000 v15.0.2 to control a 1769-L31 microprocessor with the following modules: HSC, OF4CI, IF4I, OW8I, and IA8I) and have tested it on our laboratory setup. We have also finished the HMI application (RSView Studio Machine Edition, release number 4.00) and are now trying to download the application to the actual HMI (Allen Bradley PanelView Plus 600) and use it to control the PLC. We have managed to download the application to the HMI, but upon actually loading the application, the HMI seems to fail to connect to the PLC. The error that seems to relate to this issue is: (CLXDP) XIP Connection (0) open rejected (Error 2040101) on route to .... . We checked in the help files of the RSView applications, where it indicates that there is either a timeout, the controller is unavailable, or the controller timed out (the "controller unavailable" seems to be the one since the Channel 0 light on the PLC doesn't turn on even though the serial cable to the HMI is connected). We have tried several things, but are at a slight loss right now. Are there any settings which need to be specified before the HMI can run? We have gone through the options on the HMI, and the only category that seems to apply is the "Networks and Communications". Within Networks and Communications, we were changing the settings of RSLinx Enterprise Communications, specifically for the tab Serial-DF1, under which our processor (CompactLogix L31) is listed. We have the driver for the Serial-DF1 set to the following: Use Auto-Configuration NO Device PLC5 Error Check BCC Parity None Baud 19200 Stop Bits 1 Ack/Poll Timeouts 3000 Max Retries 3 Station number 0 COM Port 3 The ComplactLogix Processor Properties are: Address 1 Does anybody have an idea for what could be causing our problems? Thank you very much for your help! Jan

Hello, I am trying to connect several tags from my PLC(CompactLogix 1769 L31) to my HMI(Panelview Plus 600) and am having trouble creating a runtime application due to an error that states that it is "unable to save tag database". I am linking my PC which is running RSviewME to the PLC. It seems to recognize the correct PLC device and I can correctly see/connect the PLC ladder logic tags to the HMI buttons etc. The problem only occurs when I try to run/create a runtime application. Can anyone point me in the right direction as to what is causing the error to occur, or what I can do to remedy this. Thank you in advance

Thanks a lot Gerry. Yeah, we have been thinking about the fouling of the logic. It seems that if first the tags you want turned on are turned on and then the remaining tags are turned off, the logic stays steady.

First of all, GOOO GATORS!!!!! As far as the topic goes, you are correct, a "misunderstanding" occured (different than what you think, but it lead to the same result :) ). Essentially, before we could have our HMI edit tag values for our controller, we had to "connect" the HMI tags to the PLC tags. However, the person who was responsible for that part of the project was not able to do so, because the PLC tags were not showing up within RSView. So, we tried various methods (among them the whole exporting - and you correctly pointed out that was stupid - you put it in nicer terms :) ), and failed until we realized that the PLC has to be in a specific mode for us to be able to do what we need to do. So that problem is fixed, but thank you very much for your input Ken! However, I do have another question, and you might be able to help we with this. Essentially, we have 4 modes of operation: Remote Auto, Local auto, Manual, Shutdown. Within the HMI, a menu provides the option to select each of those operating modes (by turning the corresponding PLC tag on). However, what we would also like for the HMI to do is to turn off all the other tags (i.e. when I select "Local Auto", the Local Auto tag is set to 1, but the Remote Auto, Manual, and Shutdown tags are simultaneously set to 0). Do you know if there is a way to do this (i.e. run a macro or set up some if statements?). If there is, could you please point us to where this can be done (PLEASE DON'T tell me HOW it can be done, we are trying to "do this ourselves"). THank you very much, I really appreciate your help. By the way, we are using RSView ME. Thanks again, Jan

Thank you both very much for your help!! I think both of you are correct, ergo it should work. It seems like the problem is not with the move function, but with some of the input hardware. Apparently, when I had "move" in there before, we had the hardware configured a little differently (just the position of a speed probe on an electric motor), and when that was moved around (believe it or not, just the tilt of the motor), it would work fine. Coincidentally, when we tilted the motor we also changed the functions to add/multiply. Once everything worked, we assumed the problem was "move". Now, when we removed the tilt of the motor, it stopped working again :). I will check to see if this is really the cause of the problem tomorrow morning (been on campus for 12 hours now having classes/working, getting kinda hungry :) ). I am thinking it is the speed probe, cause the program is "breaking" at very low RPM only, and when a more aggressive gain is set for the controlling PID (which gets past that reagion fast ..), there seems to be no problem. Thanks a lot so far, I will post an update. Jan

Both are defined as REAL. Just a sample "rung". The Entered_Setpoint is a value provided by the HMI. When a certain conditions are fulfilled (and I know they are, because using math functions makes it work), Entered_Setpoint is "moved" to System_Setpoint. Thank you for helping!