Announcement

Collapse
No announcement yet.

Timers, Email & other multi scan items in subroutines

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Timers, Email & other multi scan items in subroutines

    I made the switch from Click to Do-More a couple of months ago & I love the features of the Do-More. My question is. Why could I place timers & other multi scan items in the subroutine of the click but I can't in the Do-More? I have a pretty large program That I have broken up into subroutines to help with trouble shooting & just to keep the program clean. My only draw back is that I wrote the program in the subroutine but had to place the timer in the main program. This makes trouble shooting or adjusting timers a nightmare. Also, we have a pump system that will "Text" the maintenance tech when a low pressure situation is triggered. We have different maint. techs working different shifts. I would like to place the email feature in a subroutine that is called only when they're at work. I am using this now but I had to write it in a program. I call this program using the day of week & time of day. it would be much easier having all of these items in a subroutine.

  • #2
    All Do-more platforms support Programs, Tasks, and Subroutine code-blocks. Interrupt Service Routines are on BRX.

    In Do-more, Subroutines are called inline, like a MATH function. You can't put asynchronmous/multi-scan instructions inside a Subroutine code-block.

    You probably want to stick it in a user created PROGRAM or TASK code-block. Those you can control when they run via the RUN or ENTASK instruction (vs. CALL subroutine). So your $Main can have controlled running of "NotifyMaintenance" PROGRAM. Then in $Main, you can "RUN NotifyMaintenance" conditionally, and then monitor the completion of it via NotifyMaintenance.Done bit.
    There are 10 kinds of people in this world, those who know binary, and those who do not.

    Comment


    • #3
      You're just going to want to use the Do-more's Program like you used the CLICK's Sub Routine in most places.

      For the EMAIL to the technician on call, you could load all the destination addresses into a block of strings, then load the appropriate person into a string to use during their shift. This could be date /time logic, or HMI selection for example.

      Comment


      • #4
        I completely understand. I just thought it would be nice to not have to clutter up the main program if I could place everything in the subroutine or program window. Below is teh program for the email function which is in a program.
        Attached Files

        Comment


        • #5
          Originally posted by jrayb View Post
          I completely understand. I just thought it would be nice to not have to clutter up the main program if I could place everything in the subroutine or program window. Below is teh program for the email function which is in a program.
          Put that logic in a subroutine or task that sets a single bit to trigger. It doesn't need to be in $Main.

          Comment


          • #6
            Originally posted by jrayb View Post
            I completely understand. I just thought it would be nice to not have to clutter up the main program if I could place everything in the subroutine or program window. Below is teh program for the email function which is in a program.
            Or all in one row, not too cluttery. Symbolic constants for Days, possibly variables for shift hours.
            Attached Files

            Comment


            • #7
              Originally posted by BobO View Post

              Put that logic in a subroutine or task that sets a single bit to trigger. It doesn't need to be in $Main.
              Got it. I moved the logic to a subroutine & used a bit to enable the email rung with a leading edge contact for the email. I would have never thought to do it like that. cleaned up the program quite a bit. Thanks!!

              Comment

              Working...
              X