Bill Linne

MrPLC Member
 View profile  See their activity

  • Content count

    157

  • Joined

  • Last visited

Posts posted by Bill Linne

  3. Posted

    LIM will work if you multiply RTC Hour X100 and add RTC Min into one memory location (so, N7:5 (for example) becomes 0630 through 2330). That also eliminates the need for a latch. If you want to start later in the day and stop early the next day, just put the later (higher number) in the MIN field of the LIM, and the smaller number (earlier in day) in the MAX field of the LIM instructions. I've controlled many pump routines this way to avoid running pumps when power costs are highest.

  4. Posted

    The array approach might work better if you store the ORDER of lamps lighting in Array1, and the ORDER of button presses in Array2. Let's say the lamps light 2-3-1-4. Logic detects lamp 2 and moves a 2 into Array1, 0. Then logic detects lamp 3 and moves a 3 to Array1, 2. Etcetera. You obviously will need logic to increment the position to fill in the array. Array1 eventually holds the values 2-3-1-4. Then, the same thing happens with button presses. When the arrays match, start over. This is grossly simplified, but do you get the idea?

  7. Posted

    Ron: I had tried clicking the little freckle, the topic name, and the number last night. Seeing your reply this morning, I've tried all those again; still nothing. First attempt today (as last night) was on my iPad. When that failed, I tried my PC, using Google Chrome; no go. Oddly, in Chrome, when I cursor over the left side of the screen, the pointer turns into the miniature magnifying glass, and all I accomplish by clicking is to change the size of the text & icons. They shift from original size to larger, next click they get smaller. etcetera. Then I tried Internet Explorer, and when I move the cursor over the left side of the screen, regardless if I'm over a 'link' or not, the cursor never changes to the little finger, and there is zero response to clicking. I dunno.

  11. Posted

    Jeremy: Thanks for your detailed input. I now understand the operation of the FFU/FFL pair. I've attached the version of my logic that has been running all night and works fine. Using the MOV instruction to "reset" the FFL .POS pointer to zero (when the FFL goes .DN) avoids loss of data in the array. I also had to modify the operation of my SUB instruction, once I better understood that the .POS value is where the next value will be written, not where the last value was written. Thanks again for your help! Bill

  13. Posted

    Good Morning: Using a 1756-L61 running version 17.2, I FAULTED the processor with the attached logic. Fault was not immediate, but didn't take more than a couple minutes. In my haste to get the processor back on-line (plant was running) I did not thoroughly examine the Fault Code, just saw that it was rung 108. So, first question: Does the processor/L5K keep track of historic faults in a file somewhere that I can access? The object of the new logic is to determine tank level decrease in the past hour. It is my first use of FIFO. I see that the FFL and FFU instructions may be used in pairs, but is that a requirement? I don't think the FFU does me any good in this application. Is that correct? Next, am I correctly dealing with the DN bit of the FFL by MOV'ing a zero to .POS of the Control Word? (I did that because the help file states that a major fault occurs if: (starting element + .POS) > FIFO array size). Is there a better way to "reset" the FFU? Last point of confusion is the gray background color behind the actual values in the SUB instruction. Makes me think something is not cool with my indirect addressing. And since that is the rung that faulted the processor, I'm doubly suspicious. I've never faulted with a SUB instruction before. Any hints? Note: I added the AFI to rung 108 in order to bring the processor back on-line. The AFI was not there when the fault occurred. Thanks in advance for any education you can provide. Bill

  15. Posted · Edited by Bill Linne

    MSG instruction will work. Keep in mind DINT is 32 bits and PLC-5 is 16-bit memory. So the data will occupy two words in the PLC-5. Do you need to do this transfer when the data changes in the CLX or would it suffice to have the PLC-5 read the data from the CLX every xx seconds? The answer to this determines whether you use a MSG Write in the CLX or a MSG Read in the PLC-5. If you need more details on MSG configuration, I can help. Let me know which way (Write or Read) you want to do it. Bill

  16. Posted

    It depends on how quickly you need the output (of PLC #2) to respond to PLC #1. A Read MSG in PLC #2 will work, but it means PLC #2 is constantly asking PLC #1 when to energize the output. The other way to do it is to have PLC #1 Write a MSG to PLC #2 at the instant PLC #2 needs to change the output condition. This is known as "report by exception". You will MSG at least one word. So, create a timer in PLC #1 set for 100ms (or whatever is appropriate for the reaction time you desire), and every time the timer is DN, it MOV's the word you will MSG to an unused word in the SAME PLC. Next rung, if the two words are not equal (NEQ), trigger the Write MSG to PLC #2. (Every 100ms you are checking to see if the word to be messaged has changed. If it has (and is therefore not equal to the copy made 100ms ago), send the change to PLC #2.) Then, as a parallel branch at the input of the MSG rung, use an bit from the internal clock to also send the MSG (say once per minute (or whatever is appropriate)). This allows a periodic update whether the word changed or not, but is infrequent enough to no hog network bandwidth. Then in PLC#2 monitor the bit(s) of the word of interest to control the output. Bill

  18. Posted

    Cindy: Simply create a tag in the Logix processor of the data type INT, and make it whatever length you need to handle the data points. For example, if you need eight words of digital data (these are 16-bit words) and two words for your analogs, your new tag would be ten words in length (when you create the tag, the box for assigning one of the dimensions is greyed-out, the other is not). In the box not greyed-out, enter 10. So, now we have New_Tag, which is ten words in length. You will refer to these words as New_tag[0] through New_Tag[9], and at the bit level, New_Tag [0].0 through New_Tag[0].15 (and so-on). Now to populate these words, you can either "map" them in ladder logic bit-by-bit, or assign hardware inputs to them directly (in the tag editor). How you message the data to the PLC-5 depends on what "drives" the need for the data. If simple timed updates are okay, you can read this array from the PLC-5. Establish a MSG instruction in the 5 as usual, but in the Target PLC data address field enter "New_Tag[0]". Important: The quotation marks must be included! This is a bit of a work-around to the documented need to establish a data table of all tags you intend to communicate to PLC-5's. So, after the target field is filled-in, enter a length of 10. This will be a multi-hop message with the usual formatting for getting from the communication module (an Enet module, probably) to the slot where the processor lives. If you need help with this, I have more details at the shop, just "holler". If the need to send data to the PLC-5 is based on something happening at the source end, then your MSG instruction should be a Write type and live in the Logix processor (and obviously conditioned to execute when whatever-it-is changes). Note: Read type messages are more efficient than Write type messages (less network overhead and housekeeping). Note: I usually establish my source arrays at a length longer than I really need. Then, if I need to communicate more data to that particular PLC-5 in the future, just increase the number of words the MSG instruction is reading (or writing); no need to take either processor out of RUN mode. Just be sure to leave room for expansion at the destination, too. Hope this helps. Bill

  20. Posted

    The key is that you must know what the 0-10" represents. I have several venturi meters, all different (0-15 MGD, 5-50 MGD, etc). Each of the transmitters is ranged to match the mechanical device (the respective venturi). Once you know the range, it is very simple to bring that 4-20 signal to the analog input module of your PLC. Then configure that particular channel of the A/I module to match the range of the transmitter. Viola, the actual flow value will be displayed as the raw analog. Am I on the right track, or was this not what you were asking? Bill

  22. Posted

    If the configuration you quoted is in the CLX, and it is READing the PLC-5, try deleting everything after the IP Address (delete the 1, 21). I have many such MSG instructions running, as we just finished a massive Plant expansion that uses all CLX processors, while several PLC-5's remain in service. Please reply if you need more help. In my case, all controllers are on the same subnet (10.10.28.xxx). Bill

  23. Posted

    This is a REAL long-shot, but I have seen many weird problems resolved by simply deleting the Harmony.xxx files in the C:\Program Files\Rockwell Software\RSCommon folder. Stop RSLinx, then delete the file(s). These files will automatically re-generate the next time you start RSLinx. They are simple text files, but have been a "bugaboo" to RSLinx since DOS days. If something that is logged in a Harmony file changes, very strange things begin to happen. This may not help, but it will not hurt. Bill

  24. Posted

    Interesting, Bob. Thanks for the heads-up. What I don't understand is why it took 30 to 90 minutes for this to manifest as a problem. Seems like dupe IP's would be a problem from the jump. I was expecting you to say that something was causing an on-the-fly CHANGE to an established IP, and therefore causing the conflict. Maybe someone with more Ethernet savvy can explain this for us. Bill

  25. Posted

    Problem resolved. Took the processor and modules off the rail and turned them upside down, tapping them firmly on a piece of clean paper. Not too surprisingly, some small specs of steel collected on the paper. Examining the mounting rail, I found chips there, too (much larger). None of the chips I captured seemed really large enough to be of harm, but obviously at least one of them was lodged in a bad spot. Upon reassembly, all works fine. Now to see if anyone actually admits culpability. All the craftsmen on this job seem to be "a cut above" the norm, but obviously this is not cool. I'll let the construction management firm sort it out. Bill