Announcement

Collapse
No announcement yet.

PxK : Use RS485 Port Ready bit

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


  • PxK : Use RS485 Port Ready bit


    I am attempting to add the RS485 Port Ready status bit to 'existing' code.
    Does this code appear to have handled the bases for using the Port Ready status bit?


    The existing code (in black) cycles thru reading/writing from/to two Solo temperature controllers.
    The new code (in red) is to recover from comms locking up during a RUNTIME project transfer.

    The reads/writes are divided into 'modules' 1 - 9.
    Modules 1-6 are for normal operation.
    At the start of the heat cycle, I enable modules 7-9 to allow steam to be slowly introduced into the plumbing/heat exchanger to minimize any condensate's conversion to steam. (PurgeMode)
    The code below does the COMMS portion (correctly, it seems)
    Tag description:
    _ACTIVE is a bitfield WORD that tracks which comms module is currently active.
    _INIT is a bitfield WORD that tracks which comms modules that have been initialized in this round-robin cycle.

    _ACTIVE:x gets reset on Comms Success
    _INIT:x gets reset on Comms Failout on retry

    both get reset at end of round-robin cycle

    So far, this has cycled without error - except during the occasional project transfer to cpu - so I want to incorporate the Port Ready bit(RED).
    I have observed that clearing the _ACTIVE and _INIT words will get the comms going again after a project transfer.
    So I will use the Port Ready false state to ZERO those words, and will use the true state to allow the timer to elapse, triggering the MATH that counts/cycles thru the comms modules.

    The first code block is the supervisory section for the comms
    There may be other ENABLE logic for TMR (COMM_T) -- not shown
    Code:
    .
    .         PurgeMode                                   | CPD
    .-----+-------]/[-------------------------------------+ 6       Max_Comms
    .     |                                               |
    .     |                                               +--------------------------
    .     |
    .     |    PurgeMode                                  | CPD
    .     +------] [--------------------------------------+ 9       Max_Comms
    .                                                     |
    .                                                     +--------------------------
    .
    .
    .
    .
    .
    .                            RS485_
    .          _Active          PortReady                 | TMR         COMM_T
    .------------] [---------------] [--------------------+
    .          AlwaysOff                                  |
    .------------] [--------------------------------------+ (x) mSec
    .           _RST                                      |
    .------------] [--------------------------------------+
    .                                                     |
    .                                                     +-----------------
    .
    .        COMM_T.Done                                  | Math    COMM_TASK
    .------------] [--------------------------------------+ COMM_TASK + 1
    .                                                     |
    .                                                     +------------------------
    .
    .
    . ~~~
    .        COMM_TASK
    .             Max_Comms                                         | CPD
    .------+-----]>=[------+----------------------------------------+ 0       COMM_TASK
    .      |               |                                        | 0       _INIT
    .      |   RS485_      |                                        | 0       _ACTIVE
    .      |   PortReady   |                                        |
    .      +------]/[------+                                        +------------------------
    .
    .
    .
    .
    . ~~~
    .
    The next code block is the actual read or write handler and success/timeout detect.
    I had trouble with using a .Success rising edge, so I used N.O. and reset it.
    Idea:
    Trigger comms,
    set _ACTIVE:1
    set _INIT:1
    (_INIT:1 disallows a double-triggering of the comms instruction on success.)
    Check for success, wait ~50mS for success.
    On success, clear _Active word which will allow the COMM_T timer to elapse, triggering the next comms module.
    If NOT success and timeout, increment err count, set ErrFlag - left a following code block handle retry

    I will clear the comms error count differently when finished. Right now, is it cumulative - it needd to be reset on a success - currently it is a visual aid.
    Code:
    [EDIT this code block is revised in later posts]
    .         COMM_TASK
    .                 1     _INIT:1                                     | MWX            TC_SP
    .-------------]=[----------]/[-----+----------------+---------------+
    .                                  |                |               |
    .                                  |                |               +------------------------
    .                                  |                |    
    .                                  |                |               | CPD
    .                                  |                +---------------+ 1       _INIT:1
    .                                  |                                | 1       _ACTIVE:1
    .                                  |                                |
    .                                  |                                +-----------------------
    .                                  |                    
    .                                  |  TC_SP.Success                 | CPD    
    .                                  +-----] [------------------------+ 0       _ACTIVE:1
    .                                  |                                | 0       TC_SP.Success
    .                                  |                                +------------------------                                
    .                                  |                    
    .                                  |  TC_SP.Success                 | STMR            TC_SP_Err
    .                                  +-----]/[--------+---------------+ (Pre = 5)
    .                                                   |               +------------------------                                
    .                                                   |   TC_SP_Err            
    .                                                   |    .Done      | MATH    TC_SP_ErrCt
    .                                                   +----] [----+---+ TC_SP_ErrCt + 1
    .                                                               |   |
    .                                                               |   +------------------------
    .                                                               |
    .                                                               |   | CPD
    .                                                               +---+ 1       TC_SP_ErrFlag
    .                                                                   |
    .                                                                   +------------------------
    .
    The next code block is for retrying and retry max limit checking
    If the previous code block sets the TC_SP_ErrFlag because of a comms fail,
    the next code block will wait and then retrigger the 'previous' code block up to 5 retries

    Code:
    .
    .       TC_SP_ErrFlag                                              | STMR TC_SP_Retry
    .------------] [---------+-----------------------------------------+
    .                        |                                         |(Pre = 10)
    .                        |                                         +-------------------------
    .                        |
    .                        | TC_SP_Retry        TC_SP_ErrCt
    .                        | .Done                     5             | MATH G_TC_SP_ErrCt
    .                        +-------] [-----+-------]>=[-----+--------+ G_TC_SP_ErrCt + 1
    .                                        |                |        |
    .                                        |                |        +-------------------------
    .                                        |                |
    .                                        |                |        | CPD
    .                                        |                +--------+ 1 TC_FAIL_CTXT
    .                                        |                         | 1 TC_FAIL_FLAG
    .                                        |                         | 0 TC_SP_ErrCt
    .                                        |                         | 0 TC_SP_ErrFlag
    .                                        |                         |
    .                                        |                         +-------------------------
    .                                        |  TC_SP_ErrCt
    .                                        |          5              | CPD
    .                                        +-------]>[---------------+ 0 _INIT:1
    .                                                                  | 0 TC_SO_ErrFlag
    .                                                                  |
    .                                                                  +-------------------------
    I do not use automatic polling because I cannot determine which comms instruction will be active if I stop and then restart the comms procedure (or because of locked-up comms after project transfer) -- in short, I can start/stop/sync this procedure to anything I need.
    Last edited by kewakl; 06-10-2019, 08:32 AM.


  • #2
    I do not see this working for the RS485 comms hang during a runtime transfer.
    Does the 485 PortReady bit go false during a runtime transfer?

    I am considering using the CPU Event Log String 01 entry - looking for a "NEW PROJ" entry instead of the 485 Port Ready bit.
    We use this concept on another project, so, I think it is doable.
    Last edited by kewakl; 06-03-2019, 11:15 AM.

    Comment



    • #3
      Originally posted by kewakl View Post
      I do not see this working for the RS485 comms hang during a runtime transfer.
      Does the 485 PortReady bit go false during a runtime transfer?
      It seems not!
      I used this timestamping rung. I never see the SoloCommsTimestamp word change after a runtime transfer.
      Code:
      .
      .
      .         MST-0.0.0.35                | CPD
      .-------+-----]^[-----+---------------+
      .       |             |               | SysTimeStamp     SoloCommsTimestamp
      .       |             |               |
      .       | MST-0.0.0.35|               +----------------------------------
      .       +-----]v[-----+
      .
      .
      .
      SysTimeStamp S32 formatted MMDDYYHHMN So I see 607191222

      Comment



      • #4
        So far, with the NodeBit from the _ACTIVE status register in its current place, I have had about 10 successful restarts after runmode transfers.
        ::crosses fingers::
        It is NOT consistent in firing WHEN the timer DONE goes true, but it (so far) eventually (withing seconds) starts COMMs again.
        Code:
        .         COMM_TASK
        .                 1     _INIT:1                                     | MWX            TC_SP
        .-------------]=[-----+----]/[-----+----------------+---------------+
        .                     |                             |               |
        .                     |                             |               +------------------------
        .                     |                             |    
        .                     |                             |               | CPD
        .                     |                             +---------------+ 1       _INIT:1
        .                     |                                             | 1       _ACTIVE:1
        .                     |                                             |
        .                     |                                             +-----------------------
        .                     |                                
        .                     | _ACTIVE:1     TC_SP.Success                  | CPD    
        .                     +----] [-----+-----] [------------------------+ 0       _ACTIVE:1
        .                                  |                                | 0       TC_SP.Success
        .                                  |                                +------------------------                                
        .                                  |                    
        .                                  |  TC_SP.Success                 | STMR            TC_SP_Err
        .                                  +-----]/[--------+---------------+ (Pre = 5)
        .                                                   |               +------------------------                                
        .                                                   |   TC_SP_Err            
        .                                                   |    .Done      | MATH    TC_SP_ErrCt
        .                                                   +----] [----+---+ TC_SP_ErrCt + 1
        .                                                               |   |
        .                                                               |   +------------------------
        .                                                               |
        .                                                               |   | CPD
        .                                                               +---+ 1       TC_SP_ErrFlag
        .                                                                   |
        .                                                                   +------------------------
        .
        [EDIT The forum is munging the CODE again]
        Last edited by kewakl; 06-10-2019, 08:32 AM.

        Comment



        • #5
          Click image for larger version  Name:	NP_RST.png Views:	0 Size:	29.4 KB ID:	123280
          This is the program change detection and attempt to reset the comms process


          On a post edit, why can't I put this text ABOVE the pic?
          Last edited by kewakl; 06-10-2019, 08:31 AM.

          Comment



          • #6
            We just released a new 1.2.7.39 firmware that may fix your issue you are seeing with your serial Modbus communications:

            1.) CPU may lockup with serial Modbus instructions when transitioning Run-Stop.

            If this does not fix your issue please contact our technical support team for additional help.
            If you have an urgent issue, please contact AutomationDirect's Technical Support team.

            AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

            Comment



            • #7
              I am seeing this on a Runtime transfer. Is there a Run-Stop transition during a Runtime transfer?

              Comment



              • #8
                Originally posted by kewakl View Post
                I am seeing this on a Runtime transfer. Is there a Run-Stop transition during a Runtime transfer?
                I always thought there was a very short one at the end of the transfer. I saw this on DL06's too. You could probably know for sure by putting a first scan contact in your program, have it go to a set coil. Make sure coil is off, then do a runtime transfer and see if the coil goes on. I would assume a first scan bit would go during any run-stop transition including one that happening during a runtime transfer.

                Comment



                • #9
                  What version of S/W and F/W are you using?

                  Can you go online with the CPU and create a system report and then attach to this thread of PM me? Our QA team would like to see if they can duplicate.
                  If you have an urgent issue, please contact AutomationDirect's Technical Support team.

                  AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

                  Comment



                  • #10
                    Originally posted by MikeN View Post

                    I always thought there was a very short one at the end of the transfer. I saw this on DL06's too. You could probably know for sure by putting a first scan contact in your program, have it go to a set coil. Make sure coil is off, then do a runtime transfer and see if the coil goes on. I would assume a first scan bit would go during any run-stop transition including one that happening during a runtime transfer.
                    During a Runtime transfer I am not seeing the tag go true when I use FirstScan to Set a tag.
                    I do on a StopMode or on a stop-run switch.-- as expected.

                    Comment



                    • #11
                      Originally posted by P3K_ADC_Eng View Post
                      What version of S/W and F/W are you using?

                      Can you go online with the CPU and create a system report and then attach to this thread of PM me? Our QA team would like to see if they can duplicate.
                      P3K_ADC_Eng I haven't been ignoring you, I have been working on MCVE for this issue.
                      Code:
                      I used code tags for text alignment
                      The project target device is a      P1-540 FW 1.2.7.37.
                      At my desk the target is a          P1-540 FW 1.2.5.38.
                      Both projects are                          SW 3.4.0.16.
                      Both P1K's exhibit this behavior, so it is not limited to the specific firmware.
                      I have not yet attempted the firmware that you suggested - because I am working on a RunTime issue. If I get time for the FW update, I will post results.

                      I have whittled the project to the solo comms and the project change detection routine.
                      If you navigate to the dataview named 'Purge', try multiple runtime transfers with and without the tag 'EN_ProgChgDetect' on.

                      System: P1-540, RS485 to two SOLO controllers (nodes 1 and 2) Node 1 is Temperature controller, Node 2 is overtemp. Modbus RTU, 9600 E81

                      I sanitized the file 'system_info.txt' to remove personally identifiable file/folder/path references. (username references were replaced with '__USER__')
                      Attached Files

                      Comment



                      • #12
                        Appreciate the information. I will get this over to our development team to begin investigating.
                        If you have an urgent issue, please contact AutomationDirect's Technical Support team.

                        AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

                        Comment



                        • #13
                          Originally posted by P3K_ADC_Eng View Post
                          Appreciate the information. I will get this over to our development team to begin investigating.
                          Thanks.

                          I upped to the currently available FW 1.2.8.25 and the supporting SW 3.5.0.16
                          Still seeing the comms not recover at Runtime transfer.

                          Comment



                          • #14
                            Are u transferring via Ethernet or USB? Have u tried USB and do you have the same issue?
                            How long is the transfer taking?
                            What is your network topology? (managed vs. unmanaged switches), etc.)
                            If you have an urgent issue, please contact AutomationDirect's Technical Support team.

                            AutomationDirect.com Technical Support: 1(800) 633-0405 or (770) 844-4200 Email Tech Support

                            Comment



                            • #15
                              Always ethernet. Stride SE2-SW5U and EA7-T15C
                              I have not tried USB.

                              There is one P3K on the switch. There will be 6 P3K's when finished.

                              On the bench I have a Netgear (FS726T) ProSafe 24 Port 10/100 Smart Switch. (for any ethernet sniffing needs)
                              Same issue, so other devices do not appear to be causing anything that cannot be modeled on the bench.



                              I just clocked some transfers.
                              Code:
                              Ethernet
                              Bench total with compile is   ~3.8  sec
                              Bench just transfer           ~2.5  sec
                              
                              Machine total with compile is ~8.3  sec
                              Machine just transfer         ~4.4  sec
                              
                              USB
                              Bench total with compile is   ~3.7  sec
                              Bench just transfer is        ~2.5  sec
                              It will be difficult to do a USB transfer on the machine, If I can do it, I will update here.


                              NOTE: While editing the code for the reproduction, I errored in Task 'Solo' on Rung 24.2 The third and fourth tags in the CPD should be OT_PV_ErrCt and OT_PV_ErrFlag.
                              I CTRL-V pasted on one too many CPD instructions.
                              If you notice that comms will not restart and the tag G_OT_PV_ErrCt is incrementing, change the tags mentioned in 24.2

                              Comment

                              Working...
                              X