kewakl (Customer) asked a question.
All tasks are Run Every Scan.
The timer [ESRRETRYDWELL] in the lower task window should run while the first conditional is true and the compare contact is true.
As shown in the attached video, the first conditional[Seq(31)] is false -- and the timer is running. I included a xref of the timer struct for reference.
If the first conditional [Seq(31)] were ever toggling true/false, I would expect the timer accumulator to reset and the TMC [StretchedPulse] in the upper task window to occasionally go true.
In the upper task window, Seq(5) is a decision branching between Seq steps 6 and 31.
This decision is based on the .Success or .Timeout in the RX instruction in the middle task window
The lower task window shows RX .Timeout retry count limit, dwell and retry.
Rung 4 in the lower window is a counter which counts rising edge transitions of Seq(31) -- if we see more than 5 rising edge transitions of Seq(31) we have an RX issue.
-- if we see less than 5 rising edge transitions of Seq(31) we run the timer (Seq(5) step bit *should* be false. When the timer expires (~200mS), we turn turn off Seq(31) and turn on Seq(5) which should re-enable the RX instruction.
This count is reset whenever we have an RX .Success
I first noticed this behavior in SW 3.9.0.26 FW 1.2.9.30
This CPU is now at SW 3.9.1.5 FW 1.2.9.30. I do not see a later FW rev that addresses any STMR/TMR issues.
I DID do the double-clutch STOP-MODE downloading as suggested in a previous AD post. https://community.automationdirect.com/s/question/0D53u00003mQCSZCA4/p1540-error-message-e04310-what-does-it-really-mean
Did the 4312 error go away on run time transfer that you were getting before using 3.9.0.26?
'go away' would be difficult to declare, as I only have one entry in the error log, and that error was weeks ago.
I do not see repeat entries in the log.
I think that I have an idea. I find that I must RESET the .Timeout status bit when I disable the RX instruction.
Odd, this has worked (with accumulating counts) before. I have seen the accumulated count at 3 before failing.
I will test some more.
In an attempt at completeness, I am now resetting the .Timeout and .Success members in the sequence step preceding the RX and in the TimeoutRecovery routine.
I am leaning toward my incorrect thinking about the process - as far as my process hanging, but I do not understand why my initial attempts to trap a race condition (TMC triggering in earlier post) failed.
The routine (see post ~07/22 first attached image) will cause the TMC to trigger.
IF I change the trigger contact (Seq(2) from N.O. to N.O.E. Rising, it works as expected.
The routine in the first part of the second image will NOT trigger the TMC.
I don't get it, Big Dan!
I tested a similar piece of (TMC TRIGGER) code on a P3-550 in SW3.9.1.5. The TMC seems to behave differently.
The help file gives ZERO hard-fast rules for the TMC trigger requirement.
From the timing chart, one could ASSUME that a TMC requires two scans, but from experimentation, ONE scan can trigger (in my P3-550 example)
My P1-540 is busy, so I cannot test on it.
In the P1-540, the TMC (in the Sequence task [second image] ) does not respond to the quick (one scan) bit SEQ(33) ON state. --> you can watch in the video attached to OP
In the P3-550, the TMC does respond to a (one scan) trigger [first image] --> in the P3, I could use the [PrtScr] key to capture the TMC ON state
---- hmmm attached images flow from last to first. Odd.