I’ve got an interesting issue with an SLC Message instruction which won’t clear error message 38h without cycling the key switch.
I have 2 SLCs on separate sites talking to each other via modems / phone line.
The arrangement is:
SLC5/05 Ch0 set to DH485 —— KE card, DF1 to modem—phone line— modem to KE CARD DF1 —— DH485 to SLC 5/03 Ch1
What we get from time to time on the SLC5/05 end is some fault either on the phone line or with a modem etc, and the link drops then it latches error 38 hex into the message instruction and locks up - a key switch cycle clears it.
I want to get the PLC to clear the error and try again without cycling the key but can’t work out if this is possible.
The message is coded to trigger the message every 6 seconds, and is sequenced with 2 other messages. All the messages have a rung of code underneath each which unlatched the msg enable bit when either error or done is recorded.
I’ve set this up on a bench to test it. When first powered up and nothing connected I replicated the error 38h which displayed and the message was locked up - this was with no cabling connected. I then changed the ports to be DF1 rather than DH485, as I was interested to see if it was protocol specific or not. Using DF1 everything worked fine. I then returned to DH485 settings - but then that worked fine too and I could not replicate error 38h. I decided to wipe the CPUs by draining the capacitor - and downloaded again, but again DH485 on CH0 was working fine and I couldn’t replicate the issue any more.
What I managed to do originally when I was getting error 38 is to cycle the key switch and see what was happening subsequently with no link connected. It starts with no message error, when the message is first enabled it times out and drops into error 37h, this is then retained and the unlatch logic doesn’t remove error. With error 37h still present the logic tries the message again, at which point error 38h is logged and won’t go away without key switch cycle.
I thought I’d try not only unlatching the enable bit, but also in parallel unlatching the error bit - it did appear to unlatch it - but never removed error 37h or subsequently 38h. so it just made it more confusing by taking the error flag away but leaving the error hidden.
The short question is (based on the above) - what actually makes error 38h activate? And what can I do to automatically clear the errors 37h and 38h when they occur?
PS - I’ve searched Tech Connect database and I didn’t come up with anything that helped…
Andy
I have 2 SLCs on separate sites talking to each other via modems / phone line.
The arrangement is:
SLC5/05 Ch0 set to DH485 —— KE card, DF1 to modem—phone line— modem to KE CARD DF1 —— DH485 to SLC 5/03 Ch1
What we get from time to time on the SLC5/05 end is some fault either on the phone line or with a modem etc, and the link drops then it latches error 38 hex into the message instruction and locks up - a key switch cycle clears it.
I want to get the PLC to clear the error and try again without cycling the key but can’t work out if this is possible.
The message is coded to trigger the message every 6 seconds, and is sequenced with 2 other messages. All the messages have a rung of code underneath each which unlatched the msg enable bit when either error or done is recorded.
I’ve set this up on a bench to test it. When first powered up and nothing connected I replicated the error 38h which displayed and the message was locked up - this was with no cabling connected. I then changed the ports to be DF1 rather than DH485, as I was interested to see if it was protocol specific or not. Using DF1 everything worked fine. I then returned to DH485 settings - but then that worked fine too and I could not replicate error 38h. I decided to wipe the CPUs by draining the capacitor - and downloaded again, but again DH485 on CH0 was working fine and I couldn’t replicate the issue any more.
What I managed to do originally when I was getting error 38 is to cycle the key switch and see what was happening subsequently with no link connected. It starts with no message error, when the message is first enabled it times out and drops into error 37h, this is then retained and the unlatch logic doesn’t remove error. With error 37h still present the logic tries the message again, at which point error 38h is logged and won’t go away without key switch cycle.
I thought I’d try not only unlatching the enable bit, but also in parallel unlatching the error bit - it did appear to unlatch it - but never removed error 37h or subsequently 38h. so it just made it more confusing by taking the error flag away but leaving the error hidden.
The short question is (based on the above) - what actually makes error 38h activate? And what can I do to automatically clear the errors 37h and 38h when they occur?
PS - I’ve searched Tech Connect database and I didn’t come up with anything that helped…
Andy
