Be more specific when you use that forum.. We not nearby to know what have been done..
The thread is still not well clear..
Screens hot showing different thing that you described..

 

And you still did not tel us where these auxiliaries contacts are from..

 

WalterCTPL2019,

Here's my questions. You keep saying you changed the sense of a contact in the "PSS rung" from NO to NC. SPECIFICALLY--What rung did you change? (Please post a pic of the rung you changed, and note which contact you changed the sense of.)

SPECIFICALLY--Which CSP segment was the PSS rung you changed the sense of the contact in? (Was it, perhaps, the same segment (SEQ_LOAD) that L59B_ALM is in???)

WHAT HAPPENS IF YOU FORCE L59B TO A LOGIC "0" and then back to a logic "1"? Both to the L59B contact in the L59B_ALM rung AND to the state of L59B_ALM?

What EEPROM partitions did you download after you made the change? What was the command you entered at the command prompt for the EEPROM download?

You mentioned " ... we had an alarm of 59B (on C core)...." WHAT DOES THAT MEAN? ALL alarms come to the operator interfaces through <C>--alarms from <Q> AND alarms from <C>. Are you trying to say that L59B is connected to <CD>, which is associated with/connected to the <C> core?

WHERE IN THE CSP IS THE L83PSS RUNG IN RELATION TO THE L59B_ALM RUNG? Is it in the same CSP segment, or a difference CSP segment? If it's in the same CSP segment as the L59B_ALM rung, is it immediately before the L59B_ALM rung, or immediately after the L59B_ALM rung? Is it several rungs before--or after--L59B_ALM?

Do you know what the sense of the L59B contact was in the L59B_ALM rung BEFORE the change was made?

I'm not a fan of TMOS operator interfaces; the few I have worked with have all had issues in some form or another--especially when trying to make changes to the Mark V configuration (CSP modifications; LVDT calibrations; I/O Configuration; even Control Constant changes). I don't know why, but it's just always been hit or miss--meaning they have never consistently just worked. Sometimes the change work; sometimes they don't. It shouldn't make a difference, but it might.

When you edited the rung with the PSS contact sense which needed changing, and exited the Control Sequence Editor and saved the changes when editing it should have created a file named SEQ_xxxx.BAK--a back-up of the original file. That's ONLY if you saved ONCE while editing and exiting. If you look at the file sizes and dates and timestamps of the two files (the original, and the .BAK), what are the two file sizes and what are the date and timestamps of the two files?

EEPROM downloading can be kind of tricky. Most people just type in the command, press ENTER, and think that's it--they don't have to do anything else. BUT, if there are any warnings or errors issued, they will be reported as the EEPROM Downloader is executing. And, many people just choose not to read or do anything about these messages. Which means something did not go right with the EEPROM Download.

I'm not familiar with TMOSMAKE.BAT but it kind of scares me that they couldn't just use MK5MAKE.BAT. It would be interesting to see what the difference(s) are between the two batch files.... If I'm not mistaken, when MK5MAKE.BAT runs it creates a .TXT or .LST file of the results (it's been a LONG time--and this is all from a rusty memory). I may be wrong about that, but I wonder if TMOSMAKE.BAT does something similar, and if so, what is in the file? (Can you post the contents of the file, presuming TMOSMAKE.BAT does make a file of the results?)

Since you didn't add any new signals or anything like that, nothing in <C> should have changed. Did you download to <C> with the EEPROM Downloader?

Finally, what happens when you reboot the operator interfaces....? This SHOULDN'T make any difference, but sometimes .... Stranger things have happened?

 

One more thing--if you used the TMOS HMI to make the changes to the CSP segment source file, you would need to have copied the modified CSP segment source file (and the resultant compiled version) over to the <I> for the <I> to know about the change that was made. AGAIN, any operator interface can only know about changes if the files with the changes are present in the proper directory. NO operator interface can directly see what is happening in the Mark V cores/processors.

So, if you made the changes using the TMOS HMI but didn't copy them to the <I>, then the <I> won't know about the changes and the rung you changed won't appear to be as you would expect it to be. Again, that's because the operator interface CANNOT directly see what is running in the Mark V core/processor RAM--it can only know what is in the file used to create the downloadable file. That's why it's SO IMPORTANT that changes made using one operator interface be copied to all other operator interfaces--otherwise things can get very, Very, VERY messy--and ugly.

Now, that doesn't really explain why you're seeing what you're seeing. My best guesstimate--based on the information provided--is that a bit is "stuck" in one or more of the <Q> cores/processors, or maybe even in <C> (though that's unlikely). My best recommendation at this time would be to re-boot the cores/processors ONE AT A TIME, WAITING AT LEAST THREE (3) MINUTES AFTER A REBOOTED CORE/PROCESSOR RETURNS TO A7 BEFORE REBOOTING THE NEXT CORE/PROCESSOR. This includes <C>.

And, I also strongly recommend using the switches in the <PD> module for re-booting the cores/processors, and NOT using the little white button on the DCC/SDCC cards. I strongly recommend waiting at least 15-30 seconds after switching the power supply switch to OFF before switching it back to ON. (If there are not switches in the <PD> module, then unplug the cable for each core/processor's power supply and after 15-30 seconds, plug it back in.)

 

WalterCTPL2019
Can you update on this thread ...thx