adccommunitymod (AutomationDirect) asked a question.
Created Date: May 31,2019
Created By: kewakl
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
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 . . PurgeMode | CPD .-----+-------]/ . . . . . . RS485_ . _Active PortReady | TMR COMM_T .------------] ] --------------------+ . AlwaysOff | .------------] >= 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. . COMM_TASK . 1 _INIT:1 | MWX TC_SP .-------------]= / / 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 . . TC_SP_ErrFlag | STMR TC_SP_Retry .------------] >= > 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.
Created Date: June 03,2019
Created by: kewakl
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.
Created Date: June 07,2019
Created by: kewakl
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.
.
.
. MST-0.0.0.35 | CPD
.-------+-----]^
. | | |
. | MST-0.0.0.35| +----------------------------------
. +-----]v
SysTimeStamp S32 formatted MMDDYYHHMN So I see 607191222
Created Date: June 07,2019
Created by: kewakl
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.
. COMM_TASK
. 1 _INIT:1 | MWX TC_SP
.-------------]= / _ACTIVE:1 TC_SP.Success | CPD
. + ----] +-----] /
Created Date: June 10,2019
Created by: kewakl
{ "alt ": "Click image for larger version Name:\tNP_RST.png Views:\t0 Size:\t29.4 KB ID:\t123280 ", "data-align ": "none ", "data-attachmentid ": "123280 ", "data-size ": "full "}
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?
Created Date: June 10,2019
Created by: ADC_CommTeam02
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.
Created Date: June 10,2019
Created by: kewakl
I am seeing this on a Runtime transfer. Is there a Run-Stop transition during a Runtime transfer?
Created Date: June 10,2019
Created by: MikeN
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.
Created Date: June 10,2019
Created by: ADC_CommTeam02
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.
Created Date: June 11,2019
Created by: kewakl
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.
Created Date: June 11,2019
Created by: kewakl
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.
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__ ')