jimdi4

MrPLC Member
  • Content count

    116
  • Joined

  • Last visited

Community Reputation

2 Neutral

About jimdi4

  • Rank
    Sparky

Contact Methods

  • Website URL http://
  • ICQ 0

Profile Information

  • Gender Male
  • Country Lithuania
  1. Actually this information can be found in this pub; Publication 1769-UM011F-EN-P - January 2007 Exactly how Ron spelled it out is in there...Pg 67, 68, 69
  2. Owasso? Is that Oklahoma? We have 2 feet and about 4 feet plus in drifts here in Chi-Town ,Illinois...
  3. Anyone know how to access the UDT tags in Clogix 5000? I am putting together a validation MMI for a Clogix 5000 application and it has many User Defined tags that I need to animate in RsView ME Studio 5.00.00 (CPR9). I can see the online tags but not the UDT's...Any ideas?
  4. PLC 5 Quirk

    Try it...first load the PLC 5 with a file for simplicity call it file A.... Then go online... Open up another RSlogix 5 session then open up file B.... Then then attempt to go online with file B... It will go online with file B and the filename on-top toolbar will change to the File A name and both sessions will be in run mode and both will show file A at the top toolbar... this may have existed for a long time with RSlogix 5 but we discovered it here accidentally while someone was doing a program validation...and ther person thought they loaded the correct program but did not...
  5. We have several PLC5 530 processors. We can view the online file on a laptop running ver 7.30 Rslogix 5. We have another file open on the laptop, thats basically identical to the online file. Includes same processor name different checksum though becasuse we made a change....Now heres the quirk...If I stay online with the laptop and open up another session of RSlogix 5 and open up a new file and then select run mode with the offline file, the offline file will go onlne with both files....its very strange...there is not even a prompt to say that the offline file doen't match the online file and please select a file...both files show that there both in run!!!! Rockwells explanation is logical, and the behaivior they explain for file selection and checksum generation and determination appear to have always worked in the past (at least what I experienced seeing), but what blows away Rockwells expalnation are two things that happen... 1). We had the file located on our desktop not in the Project File Search Path as Rockwell noted to do , and we still were able to load the offline file. 2). We made a change to the offline file and left it open... which should have altrered the checksum value, so now we have a file with the same porcessor name but different checksum....(also note the file was not in the Project FIle Search Path but on the desktop)...as the Rockwell rules stated Anyone else experience the same?
  6. Once a routine is protected, users without the source key are prevented from altering the logic of the routine. You will need to go to the original programmer and get the source key... RSLogix 5000 allows a programmer to lockout the source code from viewing or viewing & modifying. The RSLogix 5000 Source Protection feature allows you to protect the contents of your routines from being viewed by anyone who does not have the source key required for accessing them. In order to use the Source Protection feature, you must activate it via a registry entry. The RSLogix 5000 software includes .reg files you can click on to add the required registry key. What is Protected? Once a routine is protected, users without the source key will be prevented from viewing the logic of the routine. This affects the following features: § Editing - the Language editor does not open and the Controller Organizer's edit menus are disabled. In addition, the routine icon is disabled. § Printing - attempting to print a protected routine displays the message: "Unable to print the routine. Source not available." § Exporting - no entry appears in the export file for the protected routine. A warning message appears in the Results window stating the routine was not exported. § Routine Properties - All controls on the Routine Properties dialog are disabled for a protected routine. The message "Source not available" appears at the bottom of the dialog, as well as in its title bar. § Search and Replace - The only search type that is allowed to look into a protected routine is Find All. Find Next, Replace All, and Replace Next all skip the protected routine. When the protected routine is skipped, the following message appears on the status bar: Unable to search the routine <Routine Name>. Source not available. Note: This message is also logged to the search results tab when perform a Replace All search. Since you cannot view protected routine's logic, the Find All search results items do not navigate to the found locations. § Navigation - You cannot navigate to a protected routine. § Verification - You cannot navigate to an error in a protected routine. § Cross Reference - cross reference information is displayed for items referenced within a protected routine, but you are not allowed to navigate to the location within the protected routine. Double clicking to navigate to a protected routine beeps and displays the following message on the status bar. Unable to edit the routine <Routine Name>. Source not available. The Go to Location menu item is disabled. § Go To - There is no edit item in the Go To dialog for a protected routine. § Cut/Copy/Paste - You can copy, paste, and drag and drop protected routines from the Controller Organizer. I beleive there is one aspect of the source code protection that the Rockwell manuals left off. You could loose your source code protected routine if you follow the following scenario. 1) I use my laptop to create the rslogix 5k file. I then protect certain routines with one password. I can see the password in text when I open sk.dat in a notepad. 2) I copy the .acd file to the customers computer (minus the sk.dat) file and download to the PLC. During debug, I make some online changes and save the acd file. 3) I copy the .acd file from the customers PC into my laptop (since the customers PC has the latest code now). When I try to open the source protected files, I simply can not. Even though I have the original sk.dat file in my laptop. 4) I tried deleting the sk.dat file and created a new one. Entered the SAME password as before, yet the source protected routines can not be opened.
  7. Ok ...(If you are using RS-VIEW ME) What I discovered is that the @MODE, @STATUS, and @everyyhingelse is located in the RSView ME Tag browser under <Diagnostic Items> In order to get the display to properly work do the following: Click on <OBJECTS> NUMERIC and STRING> String Display> Put down your little square box, Double Click on it and go to the Connections Tab at the top. Doubleclick on <Connections>, then Tag> Select Diagnostic Items> Then pick the @MODE tag. make sure your Online with the PLC and its running,,,Then Go to the top of RS-VIEW Me Select the Test Display button > switch the key-switch on the PLC and watch it change values on the RS-VIEW ME String. I believe this answers the original question by the thread starter....
  8. (hard to use because the bits dont change when its in program, remote program, or remote run; only in Run.)
  9. If you want to check the processor status from within an HMI, RS-Linx at least has several predefined tags that DO NOT SHOW UP in the tag browser that you can use. They are @Status (returns "OK" or "Faulted"), @Mode (returns Run, Program, Remote Run, or Remote Program), and @IsPresent (1 if the processor is responding or 0 if it's not).
  10. In Contrologix 5000: I already know about checking for individual tags, but I was wondering if there was a way to do an "over all" multiple OTE check....to see if I have any OTE's with the same Output tagname?
  11. <Resolution> I was able to get rid of the major fault...I had a JSR in the Main program also referencing the other JSR called program. (Warning_Handler)...Now this is strange but seem to have fixed it...I deleted the JSR in the Main program....Added the Input pararmeters back to all the original JSR's and then downloaded the program. NO Major fault anymore. Ok , so I put back the JSR I deleted from the Main program , then added an input parameter to it , and downloaded, and CPU went back to RUN mode w/o any major fault....Go Figure!!! Jim
  12. The input parameters were stricky some number constant not even a tag name like everyone is thinking....The constant(s) don't even show in the tag database, so perhaps they are being ignored....during conversion The SBR's input parameters though reference a tag name (DINT) in both instances of the Warning_Handler routine as well as the Fault_Handler routine... Warning Handler SBR references the tag Warning_Number (DINT) and Fault_Handler SBR references tag Minor_Fault_Number The RET has no input parameters...Now keep in mind the Fault_Handler routine doesn't cause the fault....Yet its exactly coded (I think) the same exact way...
  13. Now thats interesting...but the input parameter is just a number constant like "400" ...there are allot of JSR's starting with input parameter going up to 300... the previous programmer used quite a few... I believe the input parameter was not used as a parameter pass so to speak but just to number the amount of JSR's used...1- 300 for Faults 400-450 for warnings... **Paralleled them across each output that produced a fault or warning tag and then wrote to a waring and fault handler for the date and time of the fault or warning stack...up to 10... The code for the Waring and fault is very similar code, (See above**) however, the fault stack does not fault and I am still using the input parameters on the fault JSR's without a problem.... Here's something from the Program Control Instructions Clogix book Do not use a JSR instruction to call (execute) the main routine. • You can put a JSR instruction in the main routine or any other routine. • If you use a JSR instruction to call the main routine and then put a RET instruction in the main routine, a major fault occurs (type 4, code 31). I do have a JSR in the main but its calling the Warning w/o a RET. The JSR instruction jumps execution to a different routine. The SBR and RET instructions are optional instructions that exchange data with the JSR instruction. As stated earlier to get around the major fault; remove the input paramters on the JSR's and delete the SBR and RET in the routine or leave the input parameters (just found this out today) and just simply remove the SBR and RET in the called routine, since the END does the same as RET anyway and the SBR is now considered Optional....This kept the processor from faulting any further. Ok that was the solution to the problem but I still don't understand what is meant by A Major Fault Will Occur If Fault Type Fault Code JSR instruction has fewer input parameters than SBR instruction 4 31
  14. Thanks Paul, Removing the input parameters DID NOT appear to hurt any thing and I no longer get the major fault. Ok thats a great explanation on how JSR's operate but I'm still at a loss on why the major fault? i was just wondering why I was getting this fault in the first place??? Since I also have a fault routine that is basically coded the same (This was converted from a PLC 5 program that someone else did) and is functioning fine w/o any major faults.... (See original post at beginning of thread)