Jump to content

Flex727

MVP 2023
  • Posts

    3,276
  • Joined

  • Last visited

  • Days Won

    239

Posts posted by Flex727

  1. It's not possible to give you a definitive answer without knowing your logic (for example, what is turning on MB13?), but It would seem that you need to use a TE (Extended Pulse) timer if you want the output to be on for exactly 10 seconds. You should also use a Positive Transition contact to activate the timer, especially if it's a pushbutton.

    If you're wanting to DELAY the keg rinse operation by 10 seconds, then you're using the correct timer.

     

    You're welcome to post your project file here if you want more detailed help. By the way, you will get better help if you post to the VisiLogic forum rather than the UniLogic forum, as it appears you are using VisiLogic.

  2. Yes and yes. Use the "Load Timer/Counter Preset" (under the Store Menu) to move the TD1 preset into an ML and then "Store Timer/Counter Preset" to move the ML value into TD2. You can detect an update of the TD1 Preset by using the "Legal Entry" bit in the operator entry function. It will go high when an update is made. You can then use a Positive Transition of this bit to do the Load & Store for TD2.

  3. I'm using  V1210 (also only has 4 sockets) to connect to 12 different remote PLCs using MODBUS TCP using only a single socket. You simply re-initialize the IP Configuration FB with the new IP Address, Re-connect the Socket, perform the communications, Close the Socket, then index to the next PLC and repeat. I allow 2 seconds for the entire process for each PLC to complete. Perhaps it could be performed more quickly, but this has been extremely reliable.

  4. I normally detect and log power off and power on conditions in the software I write. I do this by storing the date and time in an MI vector on every PLC cycle. On power up, I use the SB2 bit to prevent storing the Date and time to the MI vector prior to logging the power off condition. This provides the last date and time stored, which was at power off. Then, I log the power on date and time, also using SB2. From that you can determine anything you need, such as the length of time the PLC was powered off.

     

    Regarding where the PLC was in the program loop at the time of power loss, operands retain their value through a power loss if the battery is installed and working. If there are critical intermediate steps, you can keep track of them with operands that will tell you where you are.

  5. There is absolutely no reason to chain all that logic into a single ladder rung. This forum topic is "Best Programming Practices" and it should be noted that every bit of added complexity in a single ladder rung increases the chances that the compiled code will not be what you expected. In this case, it SHOULD all work, but why do it? Your example should be broken into 3 ladder rungs.

     

    Also note, you don't need SB1 (I find SB1 to be very useful to chain items in parallel, but you don't need it here when everything is in series), and MI20 is counting up to 6 seconds, not 60 seconds. Is that what you want?

  6. Frankly, I've never tried to place multiple subroutine calls in a single ladder rung - perhaps it works, but there is no reason to do that. Separate the calls to ALARMS, FUEL & TRANSFER SYSTEM, and POWER PLANT into separate ladder rungs. Further, when MI 0 is equal to 219, you have an ambiguous situation. When MI 0 equals 219, should MI 13 equal 0 or should it equal 1?

  7. Please send your contact information to me at blanier@arc-controls.com. I'm interested in taking a look at what your requirements are for this, as I believe I can help you and this looks like an interesting project.

     

    I am certified by Unitronics and have substantial experience in writing software to automate chemical delivery systems.

     

    I look forward to hearing from you.

     

    Best regards,

    Barry Lanier

  8. Further commentary would be most interesting!

     

    Any of us who consider ourselves real programmers are always looking for the most efficient, economical, and clever solution to a programming problem. But in reality, it's probably more important to write the code in such a way that it is clear and understandable to another person trying to read it. I like using a State Machine, when applicable, because it's very clear what is happening and it's very clear where in the algorithm you are when online with the PLC. Another side benefit is that it forces you to do what Joe Tauser suggests - organize and document your logic.

     

    I do other things, such as group similar or related short pieces of code using SB1, as follows:

     

      SB1

    --| |-- <one line of code>

            |

             <another, related line of code>

            |

             <yet another, related line of code>

     

    This minimizes the number of ladder rungs and helps readability.

     

    Another important thing to do that surprisingly many people don't is to name the Operands in such a way that it is VERY obvious what that operand does. A few extra keystrokes today can dramatically reduce the time spent trying to understand what you were doing two years ago when you wrote the code and now have forgotten.

     

    I learned early on NOT to use the "Links & Jumps" tab to link operands on pushbuttons to jump to different displays. You will inevitably forget to enter one in the provided field. What I do is have a Subroutine called "HMI PBs" where I enter every display jump condition (I use a single MB for each display I will be wanting to jump to) and then everytime I have a jump PB in any HMI display, it will already be in the code and there is nothing to remember to make it work.

     

    I have an HMI screen where I display the vlp filename and the Visilogic version number so that I know what file and version was used when the PLC program was last downloaded. It also includes important information like the PLC Name and the Ethernet address, when applicable, so that it is handy.

     

    I always use Input and Output buffering, this can be important when the hardware unexpectedly has to be changed (change I/O module, or the technician mis-wired something). It also makes it easy to troubleshoot using an extra bit that can be controlled while online, or on a special screen, without having to "Force" I/O.

     

    I turn OFF access to INFO mode (set SI50 to zero) to the customer, unless properly logged in (I use multiple login levels on every program I write). This helps prevent problems. When access to INFO mode is needed I use SB36 instead of changing SI50. I also provide a button for a soft reset (using SB300) so the customer doesn't have to power cycle in the event of a system change or problem that necessitates a restart.

     

    This is off the top of my head - I'll add more stuff as I think of it.

    • Upvote 1
  9. I don't think tonymony was complaining about the lack of C++, but was merely explaining that he is transitioning from C++ to Ladder Logic.

     

    Tonymony, the picture you posted is too small to tell if your logic will work, but the way I would do it is to simply Store Direct either the number 1. 2, or 3 into an MI depending on whether I1, I2, or I3 is on, respectively. You can then use List of Texts, or List of Images to display the information on the HMI screen. There will be more complexity if 2 or more of the inputs can be on simultaneously.

     

      I1          1               MI0     

    -| |---------Store Direct--

     

      I2          2               MI0     

    -| |---------Store Direct--

     

      I3          3               MI0     

    -| |---------Store Direct--

×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.