<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Randy Chu</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-02-27T18:40:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Randy Chu</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-08T22:07:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-02T16:20:00Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Reactivating and Dan said he will attempt to reproduce by replacing a found sensor with  one from the sensor db with id that is not physically on das   I get this result 

</Comment>
    <StatusString>Reactivated</StatusString>
    <TimeStamp>2023-10-12T20:53:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Reactivated</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>I am still getting the same result in 4.2.182 , with no warning when a channel is assigned with id and that id is not physically on the das .

</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-10-12T19:48:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-10-05T22:49:45Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>sorry, could not reproduce, using 4.2.168 it goes to the expected incomplete, 1 channel(s) require manual identification.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-10-05T21:44:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>happy to check it out</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-10-05T21:24:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Reopening because Datapro 4.2 versions do not  show an error when manually assigning a sensor with an eid that isnt physically attached to das in quick checkout &gt; check sensor ID but ..

Datapro versions 4 0 1052 49567 and 4.1.446.49612 work as expected ,


this seems to be issue with dp versions 4.2.148.49617 and 4.2.165.49680
Steps to reproduce issue...



1. SPS with Ecm  and 2 sensors with eid ( can use load cells etc.) 
2. Add sensors to sensor db  with isocodes and have at least one sensor in db with another eid that isnt physically present on the das . 
3. Navigate to quick checkout tab and  query das .
4. Check to maunally assign sensors and manually assign some other sensor from your db that has an id  that isnt physically on the das.
5. Click to run test  and proceed to check sensor id   , In dp versions  40 and 41 you will get  message" Incomplete .1 channel  requires manual identification and you will have an extra sensor shown .  In datapro version 4.2  There is no error message but an extra sensor is displayed .
6. If you move sensors out of position  after query it works as expected  notifying you in check sensor step in all 3 versions of datapro .



  </Comment>
    <StatusString>Reactivated</StatusString>
    <TimeStamp>2023-10-05T18:52:51Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Reactivated</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-09-19T18:26:51Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-08-29T20:45:21Z</TimeStamp>
    <ReleaseNote>Addresses an issue with Sensor quick checkout and EID channels</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.1/4.2@49397</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-08-18T14:26:05Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>To duplicate the issue you'll need a database with at least two sensors with EIDs and hardware that you can attach those sensors to. 
 
For ease I used a SPS connected via USB Controller with two stamp load cells connected on channels 1 and 2.  You'll also need to turn on the MIRA settings for warning when a sensor id is on the wrong physical channel:
 
in System settings-&gt;Test settings
 
make sure "Warn when a sensor with ID is out of position" is turned on.  Make sure "Allow data collection with a sensor id out of position" is turned off.
 
 
Click on Quick Checkout, it's a yellow tab before run test.  Select your DAS (or if it's on a USB controller and attached it will already be selected) and click "Query selected"
 
 
after querying it should show your channels with IDs.
 
 
Click on Run check.
 
Prior to the patch you should see what Kate shows, or channels out of position.
 
 
this would happen because of the "StartAutoResolution" method in ResolveChannels.xaml.cs
 
it would build a lookup of group channel id to hardware id, here's an example:
 
                    if (!_channelIdToOriginalHardware.ContainsKey(ch.Id))
                     {
                         continue;
                     }
 
The issue here is that all the channels in the test setup have ID =-1 as the test setup is never saved and the channels have no database id.  This causes the lookup to find the hardware assignment for the last channel inserted rather than any given channel, resulting in the algorithm thinking the hardware id of channels before the last one have changed.
 
The solution in the patch is in QuickSensorCheck.xaml.cs in CreateNewGroupChannels to give the channels unique negative channel ids.  This restricts the changes to only affect quick sensor check out, which doesn't arm or collect data (it only shows realtime and diagnostics) and doesn't affect the behavior of run test at all, so I think this is the quickest, simplest solution.
 
After the patch the channels should resolve normally;
 
 
An additional concern of Kate was what would happen with manually assigned channels/sensors.
 
If you manually assign a sensor with an id that isn't present it should warn you that the sensor EID was not found.  If you move the sensors after query selected and before run test the sensors should show as "Out of position"</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-08-17T17:52:20Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>this happens because of this section:
 
                    if (!_channelIdToOriginalHardware.ContainsKey(ch.Id))
                     {
                         continue;
                     }
 
in this case both channel ids are the same (-1) as the test setup has never been saved.  It's possible if we used -1, -2, ... -n this would be fixed.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-16T23:42:00Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-08-15T20:18:05Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-15T15:36:56Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-02T15:46:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-08-02T15:45:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>##- Please type your reply above this line -##
 
You are a follower on this request (#12121, #dtsweb.zendesk.com/agent/tickets/12121). Reply to this email to add an internal note to the request.
 
 
 
          
Kate Martin (DTS)
 
Aug 2, 2023, 16:07 GMT+1
 
Hi Dan
  
 Back on the bleeding edge working with MIRA today and we came across this issue :-
  
 
  
 So I have 2 sensors in channels 1 and 2 of a S6A both of which are in my sensor DB and one sensor plugged into channel 6 that is not set up in the sensor DB.
  
 Liking this for the pink sensor..
  
 
  
  
 But then this happens ..
  
 
  
 
  
 nothing has changed.
  
 This is the line flagging the issue from the sensor ID check in Run Check ..
  
 2023-08-02 15:57:17.198 -&gt;  Information - QueryStackSensorIDs [00001399], S6A0083, local: 192.168.0.99:50779, Remote: 192.168.0.83:8301 Stack Channel: 0
  
 2023-08-02 15:57:17.335 &lt;-  Information - QueryStackSensorIDs [00001399]\[00001399] - (137.1831ms), S6A0083 Number of Stack Channels: 6 Channel: 0, Type 1, IDS: 4A0000161D6E1801, Channel: 1, Type 1, IDS: 92000013DAFF7D01, Channel: 2, Type 1, IDS: 0000000000000000, Channel: 3, Type 1, IDS: 0000000000000000, Channel: 4, Type 1, IDS: 0000000000000000, Channel: 5, Type 1, IDS: 9E000001E5DC692D
  
 and the same query from the initial query selected page of Quick CheckOut which matches the above ...
  
 2023-08-02 15:50:12.431 -&gt;  Information - QueryStackSensorIDs [00001294], S6A0083, local: 192.168.0.99:50633, Remote: 192.168.0.83:8301 Stack Channel: 0
  
 2023-08-02 15:50:12.568 &lt;-  Information - QueryStackSensorIDs [00001294]\[00001294] - (137.4812ms), S6A0083 Number of Stack Channels: 6 Channel: 0, Type 1, IDS: 4A0000161D6E1801, Channel: 1, Type 1, IDS: 92000013DAFF7D01, Channel: 2, Type 1, IDS: 0000000000000000, Channel: 3, Type 1, IDS: 0000000000000000, Channel: 4, Type 1, IDS: 0000000000000000, Channel: 5, Type 1, IDS: 9E000001E5DC692D
  
  
 I think it may be related to this defacto MIRA setting that they have ..
  
 
  
  
 Because when it is not ticked ..
  
 
  
 It isn;t as simple as just ignoring this because users could use this on the main screen ..
  
 
  
 in which case we do need to check that sensor ID's haven;t moved from their assignment here to when "Run Check" is actually run.
  
 Can you take a look plz
  
 Thxs
 Kate
  
  
 
 
 
Attachment(s)
 DataPRO.log
         
 
          
Dan McFadden (DTS)
 
Jul 20, 2023, 18:27 GMT+1
    Private note    
 
https://dts.box.com/s/bhmxhjnvz4w7y9a1b97uzub6qcunqhuj
 
4.2.46
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 On 7/20/2023 9:33 AM, Kate Martin (DTS) wrote:
 
 
 
         
 
          
Kate Martin (DTS)
 
Jul 20, 2023, 17:33 GMT+1
 
Hi Dan
  
 Could I get a link to 4.2.36 or later please ?
  
 
  
 Thxs
 Kate
 
 
         
 
          
Kate Martin (DTS)
 
Jul 20, 2023, 17:25 GMT+1
    Private note    
Hi Dan
  
 It maybe at the start with a new install but MIRA will always be migrating from 1.10 when they evaluate so it won;t be there.
  
 Just stopping on the quickcheck out main screen showing Dallas ID's with no associated DB entry is good enough to get over this issue. They can then remove those sensors to continue or fix the sensor association.
  
 Thxs
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 13, 2023, 16:59 GMT+1
    Private note    
 
it's there by default in 4.2;
 
http://manuscript.dts.local/f/cases/29764/Auto-Add-Voltage-Input-Analog-sensor-in-Test-Setup
 
but sure, I can find a different work around again.
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 On 7/13/2023 8:47 AM, Kate Martin (DTS) wrote:
 
 
 
         
 
          
Kate Martin (DTS)
 
Jul 13, 2023, 16:47 GMT+1
 
Hi Dan
  
 They won't have the generic voltage entry in their DB so they have asked that the system just displays all found Dallas ID on the query screen so that they can stop there and work out why Dallas ID's have been found that are not in the sensor DB.
  
 Or if they proceed the Dallas ID step will then still show the fact that Dallas ID's exist that are not associated with sensors.
  
 Thxs
 Kate
  
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 12, 2023, 19:03 GMT+1
    Private note    
 
Is this a viable solution?
 
for any hardware channels that have EIDs on hardware channels that support full bridge and the EID isn't in the sensor database, quick checkout could put voltage input reading sensors on those channels with the EID.
 
The user can then still run quick sensor checkout with it as a voltage input sensor, or they can manually drop the sensor onto the channel and run it that way?
 
Would that work?
 
 
 
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 On 7/12/2023 10:10 AM, Kate Martin (DTS) wrote:
 
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 12, 2023, 18:10 GMT+1
    Private note    
 
*of any detected ids*
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 On 7/12/2023 10:06 AM, Dan McFadden wrote:
 
 
understood, I've re-activated
 
http://manuscript.dts.local/f/cases/31802/Add-Dallas-ID-column-to-quickcheckout
 
with the knowledge that they explicitly want the DALLAS-ID of any detected sensors.
 
 
 
 
         
 
          
Kate Martin (DTS)
 
Jul 12, 2023, 18:10 GMT+1
    Private note    
Thxs Dan.
  
 Sorry about this - they seem to just make it up as they go along reacting to issues that really are is in their hands to sort at source.
 
 
         
 
          
Dan McFadden (DTS)
 
Jul 12, 2023, 18:07 GMT+1
    Private note    
 
understood, I've re-activated
 
http://manuscript.dts.local/f/cases/31802/Add-Dallas-ID-column-to-quickcheckout
 
with the knowledge that they explicitly want the DALLAS-ID of any detected sensors.
 
 
                                                                                              Dan McFadden​   Software Engineering Manager               Diversified Technical Systems, Inc.  |  Seal Beach ,  CA                   e:     dan.mcfadden@dtsweb.com     |         o:     +1 562 493 0158 x137     |     www.dtsweb.com                                       CONFIDENTIALITY: This email and any attachments may contain information from Diversified Technical Systems, Inc. (DTS) which​ is confidential ​and/or proprietary. If you received this transmission in error, any use, reproduction or dissemination of this transmission​ is strictly prohibited. ​Please delete this message and notify sender immediately.  
 ​EXPORT CONTROL NOTICE: This e-mail may contain technical data whose export, transfer, and/or disclosure may be controlled by​ the US ​International Traffic in Arms Regulation (ITAR) 22 CFR part 120-130 or the Export Administration Regulations (Commerce).
 ​
 ​                                  
 On 7/12/2023 10:04 AM, Kate Martin (DTS) wrote:
 
 
 
         
 
          
Kate Martin (DTS)
 
Jul 12, 2023, 18:04 GMT+1
 
Hi Dan
  
 In the never ending effort to get MIRA to move on from 1.1.0 this came up today which is another request for us to cover off their DB woes ...
  
 
  
 basically it transpires that they can "fat finger" DallasID entries for new sensors when the calibration dept create a new sensor record (apparently they have no money for a 3 channel Micro stack in calibration to check out sensor entries that they create) and so it can be that when running quickcheck in the crashlab for new sensors physical Dallas ID will be read that are not associated with a sensor (because they entered the 16 char ID wrong).
  
 In this case they want DataPro to display ALL found sensors on the above page irrespective of weather it is associated with a sensor or not please. In the above screen show I have a 6DX connected with only 1 channel set up in the DB for example - they want to also see the other 5 unassociated ID's please.
  
 Thxs
 Kate 
 
 
         
 
----------------------------------------------
 Customer Details:
 Name: Kate Martin ( kate.martin@dtsweb.com )
 Organization: DTS
 
----------------------------------------------
 If you no longer wish to see notifications for this ticket, please use the 'Unfollow' option in the Followers List.
 
 
You are an agent. Add a comment by replying to this email or view ticket in Zendesk Support.
    Ticket # 12121   Status On-hold   Requester Kate Martin   CCs -   Followers Chris Balogh, Dan McFadden   Group Support   Assignee Kate Martin   Priority Normal   Type Question   Channel Web Form    
 
 This email is a service from DTS. Delivered by Zendesk.
 
 [PYDL0E-ME59N]Ticket-Id:12121Account-Subdomain:dtsweb</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-08-02T15:45:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>