<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-06-06T19:25:50Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Verified in Datapro 4.0.959.48820 and 4.1.315.48822 
Tested as follows ..

 Created a test setup for a slice nano base and bridge and ran test to diagnostics , clicked to run  diagnostics and then pulled bridge unit off of the base unit immediately after. This Causes the slice bus no response after diagnostics gets to about 4 percent on progress bar the error is shown in Datapro to the user.






</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-06-06T17:43:24Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-24T20:58:28Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-05-23T17:27:07Z</TimeStamp>
    <ReleaseNote>SLICEBusNoResponse should now always be surfaced to user</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-05-16T22:44:24Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1@48773
 
this will be a one time build that has the purposeful communication hassling in it, so I will renamed the build on the server with "DO NOT USE", future builds after that will contain the new code, but not the purposeful communication interference.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-05-16T21:43:32Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-16T18:06:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-05-16T18:05:35Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>This issue comes from a request from nate.  A SLICEBusNoResponse status for a command means that a command was issued to a bridge on the slicebus by a base and the bridge did not respond.  The primary reason this would happen is hardware damage, but it can happen with brown out and other conditions as well.  It might be possible to reproduce a SLICEBusNoResponse by setting the power supply with enough current that it can boot up, but with not enough that when excitation is turned off the bridge will fail to respond.  Because duplicating the issue that way is a bit error prone and unreliable I built a purposeful error into the patch.
 
+                        //fail 10% of the time randomly
 +                        if ( _random.Next(100) &lt; 10)
 +                        {
 +                            baseResponse.Status = DFConstantsAndEnums.CommandStatus.StatusSlicebusNoResponse;
 +                        }
 
 
 
this will make communicates fail randomly with slicebusnoresponse roughly 10% of the time.  This will be checked in after patch acceptance for SQA to be able to test, then removed for subsequent builds.
 
I wanted to verify behavior when you have many units fail at once, so I tried it with a 8 unit S6 system.  When testing with the 8 unit SLICE6 system I noticed only the first message showed the error and all subsequent prompts showed "Please correct the errors in red to continue".
 
I tracked this down to how the errorprompt itself was working.  The error prompt would set the prompt string when it was first requested to display, but wouldn't queue those messages and additionally when the OK button was pressed would change the message to the please correct error for all the additional prompts.
 
I changed this by removing the behavior to set "Please correct the errors in red" that was being set in the ok button press and having it queue the messages to display so that it now shows all the messages.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-16T18:04:49Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-05-16T14:28:38Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>moving to 4.1.19</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-09T14:21:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-01T14:05:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>This is a known error condition when a module (lets say a bridge) on a slice bus does not respond to a command.  In most cases this will be strictly a hardware issue.  We should surface to the user that there is a hardware issue and the specific hardware that the issue is on.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-01T14:04:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-01T14:02:58Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-05-01T14:02:44Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-05-01T14:01:37Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>2023-04-25 12:24:50.225 &lt;-  Arm - Arm [00053125]\[00053125] - (311.1676ms), SL62078 StatusSlicebusNoResponse
2023-04-25 12:24:50.225 !!  An exception of type: System.Exception occurred Module: ICommand.dll, Name: InternalSyncExecuteMessage: SL62078 was executing  DTS.DASLib.Command.SLICE.Arm   and reported SyncExecute: response.Status = StatusSlicebusNoResponse for sequence 53125\53125.  Please report this information to Technical Support StackTrace:    at DTS.DASLib.Command.AbstractCommandBase.InternalSyncExecute() StackTrace:    at DTS.DASLib.Command.AbstractCommandBase.SyncExecute()    at DTS.DASLib.Service.Slice`1.AsyncPreparedArm(Object asyncInfo)
 
ZD 11814</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-05-01T14:01:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>