读卡与成绩评估
InstaPunch的读卡与成统是分离的。这并不是InstaPunch首创，大名鼎鼎的Mulka2亦是这个设计思路，但InstaPunch在某些层面更胜一筹：我们用WebSocket做为传输协议，以较低的开销实现网络成统，并为SaaS模式下的成绩统计铺平道路。
读卡监控面板
读卡功能需要额外打开一个读卡面板，在已经打开数据库的情况下，点击菜单栏的赛事-读卡，即可打开读卡监控面板。读卡监控面板提供了众多功能，按功能去可以分成下图中的五个区域。
前置条件
读卡的前提是打开了数据库
监控面板如下图所示。红色区域是当前成绩的数据，包括对应的运动员下哦毛线哦、个人成绩、队伍成绩、以及有效性备注等。
绿色区域是过点记录，你可以通过底部的显示过点时间复选框来将中间一栏的间隔时间切换为绝对时间。
蓝色区域是读卡监控区，这里按时间倒序排列着该数据库所有通过主站读入的读卡记录。
橙色显示当前正在连接到本成统中心的InstaPunchReader情况，包括它们的读卡器ID、远端地址，也可以配置读卡数据的转发策略，以及往某个读卡器终端发送打印数据等。
紫色可以通过中间的小箭头展开收起，该栏主要管理当前评估的竞赛日、评估策略以及读卡服务器配置。
InstaPunch Reader
你需要额外启动InstaPunchReader来实现真正的读卡过程。
连接主站与打印机
请先获取主站、打印机的COM端口号。打开软件后即可在左上角选择硬件类型，然后在右侧表格中进行连接操作，连接成功会给对应的端口行标注颜色。如果拔插了主站，可以使用刷新按钮更新
连接成统软件
如果成统中心在本电脑，读卡服务器的地址请填写127.0.0.1，否则填写对应电脑的IP地址，端口默认为6001，密码默认为空，这块配置需要与你期望连接的成统中心软件一致。
请留意防火墙设置
打开读卡服务器时，软件会试图在127.0.0.1的对应端口创建Socket，如果勾选了允许外部连接则会试图在0.0.0.0的对应端口创建Socket。在部分机器上会触发防火墙警告，请确保予以放行，否则将无法连接。
关于ReaderID
Reader ID重复概率很低，每次打开InstaPunchReader都会生成一个新的Reader ID，在人可以感知的时间内不会重复。
你需要先打开读卡监控面板，再尝试链接WebSocket
如果意外丢失链接，Reader会定时尝试重连，如果想立刻重连可以直接切换连接状态。
读卡拓扑
下面是一些常用的读卡拓扑结构，你可以根据赛事复杂程度选择合适的使用。
Standalone - 单电脑单主站
Standalone模式下只需要一台电脑和一套主站、打印机设备，这也是大多数活动采取的成统模式，因为其成本最低且方便搭建。
该模式下在同一台电脑打开InstaPunchReader与InstaPunch，两者通过本地环路通信收发读卡和打印数据。
Multiplex Standalone - 单电脑多主站
Standalone模式固然方便，但弊端也很明显：只有一套主站/打印机。对于多个项目同时进行的活动容易产生排队成统的情况。
对于这种场景，多上几个主站与打印机便能很好削峰，这一模式称为Multiplex Standalone，下图便是该模式的拓扑图。
实际使用该模式其实与Standalone模式一样，只需要再开一个InstaPunchReader软件实例。具体操作如下图所示。
Dedicated Server - 多电脑多主站
即便Multiplex Standalone模式已经能解决大部分情况，但并不是全部。大型赛事甚至会出现多终点的配置情况。
在这一复杂场景下，通常不同的终点会有独立的成统，以便运动员尽早将成绩录入系统。为了适应这种场景，InstaPunch也支持基于局域网的DS成统模式。
评估流程
读卡监控打开后默认不选中任何赛事进行评估，此时运动员打主站产生的数据不带有任何评估数据，在读卡日志中显示为灰色，并带有<Not Evaluate>标记。 此时，如果在评估赛事区域选择若干赛事，便会对每次读入的读卡数据，从上往下寻找可以对应参加比赛的运动员。具体的寻找规则如下：
其中，灰色、白色的成绩不参与排名与导出。红色成绩是由于各种问题导致总用时无法被正确计算有效性标记为ICT，请参考有效性标记-ICT处理
有效性标记
你会在有效性一栏看到若干种标记组合，这些标记可以让你快速判断成绩是否存在问题。以下是InstaPunch目前提供的有效性标记：
| 缩写 | 含义 |
|---|---|
| DNS | 没有起点 |
| DNF | 没有终点 |
| MP | 有未到访的检查点 |
| OVT | 超时 |
| ICT | 无效的总用时 |
| DQ | 取消成绩 |
下面针对这些标记进行详细讲解
DNS & DNF
没有起点指的是运动员的读卡原始记录中没有起点，且对应的出发时间策略也没能找到相关内容。没有终点指的是运动员的读卡原始记录中没有终点。起点时间和终点时间的赋值流程如下图所示。
从上面的流程可以看出，InstaPunch最终都会展示起点时间和终点时间，但后面会打上*，以表示这个起点/终点时间可能包含潜在问题。
MP
有没到访的检查点，该标记显然需要绑定了通道和路线才会有效，MP检测只会检查路线中的有序检查点。当然，团队赛中的队伍有效性会考虑路线的无序检查点。
OVT
OVT指超出有效时间，该标记显然需要绑定了通道和路线并设定了有效时间才会有效。
ICT
ICT表示成绩的总用时不合法，此时会直接赋值00:00:00，所有零用时都会认为是ICT。如下图所示，这些ICT读卡记录会被标记为红色，对应的竞赛时间显示区域也会标记为红色。
该问题通常来说是有以下几种异常：
- 对时错误，造成终点比起点还早。
- 跨日比赛，造成计时溢出，如晚上11点出发到凌晨1点回来。
- 设定的出发时间错误，比如接力赛集体出发的运动员没有在通道处设置集体出发的时间，且集体出发的运动员比上一棒更早返回，此时默认依然采用上一棒终点时间，导致该棒出发时间 = 上一棒返回时间 > 该棒终点时间。
遇到这种情况，请先排查到底属于哪一种异常，手动计算正确时间后再使用成绩编辑功能写入正确的参赛时间。
多赛事评估
综合上述内容，我们使用一个简单的例子让大家更好理解多赛事场景下成绩评估流程的运作情况。
假定现在有一位测试运动员，使用的指卡号为1001，参加D1~D4四场比赛，的运动员参赛情况：
我们每隔两秒读入一条卡号为1001的读卡数据，持续读取6次，评估赛事按照D4, D3, D2, D1的顺序勾选：
最终的评估结果如下方动图所示，
上面六次读卡中，1001指卡对应的评估结果发生了如下事情：
- 第一次，四场待评估的赛事都没被评估过，按勾选顺序找到的评估赛事为
D1。由于绑定了通道和路线，评估成功且成绩有效，标记为绿色。 - 第二次，
D1已被评估，按勾选顺序找到的评估赛事为D2。由于绑定了通道和路线，评估成功且成绩有效，标记为绿色。 - 第三次：
D1, D2已被评估，按勾选顺序找到的评估赛事为D3。由于绑定了通道但没有绑定路线，评估中断，弹框提示并标记为白色 - 第四次：
D1, D2, D3已被评估，按勾选顺序找到的评估赛事为D4。由于没有绑定通道，评估中断，弹框提示并标记为白色。 - 第五次：四场待评估赛事都已被评估过，按照勾选顺序选择
D1并提示覆盖。由于选择不覆盖，评估取消，标记为灰色，显示为未评估。 - 第六次：四场待评估赛事都已被评估过，按照勾选顺序选择
D1并提示覆盖。由于选择覆盖，评估成功且成绩有效，标记为绿色。同时第一次读卡评估的D1成绩被禁用（显示为未启用），这是因为一个运动员在一场竞赛日的一次出场中只能被评估一次。
多棒接力赛的特殊规则
如果一个竞赛日是多棒接力赛，那么会额外按照出场顺序进行匹配，如果运动员连续打主站，会直接对该运动员后续的出场进行评估，直到全部出场次序都已经有成绩才会提示覆盖。因此强烈建议在多棒接力赛中开启禁止重复读卡
手动评估
赛事实际过程中不可能保障运动员打完主站后的评估结果不会更改。诸如修改指卡、路线、名单都可能在运动员打卡后才发生。
InstaPunch的成绩可以取消评估和重新评估。取消评估是将成绩还原为原始读卡状态，具体来说就是变成灰色状态，不和任何运动员进行绑定。 重新评估则是取消评估后用指定的竞赛日强制执行评估操作，如果是多棒接力赛，还需要额外选择具体的出场次序。
下面的动图展示了如何队已有成绩进行重新评估。评估时务必要选择正确的出发时间评估策略。
如果有多个一样的卡号，先后使用同一个竞赛日进行评估，那么最后评估的成绩会生效，之前的成绩会解除启用状态，变成白色的未启用状态，表示该成绩被评估过
优先录入读卡记录
无论遇到什么问题，请优先把读卡数据录入成统数据库，在此之后的任何问题都可以通过重新评估与修改成绩来解决。
禁止重复读卡
为了解决现实条件下很多运动员重复读卡的问题，InstaPunch定义了Readout Hash，该值用以唯一确定一次读卡记录，避免同一个成绩被有意或无意地重复录入成统数据库。
当你读卡时打开这个开关，同一指卡号哈希值一样的读卡记录会直接丢弃，不进入数据库，其工作原理为：
定义哈希函数 Hash(data1, data2, ..., dataN), 则一个读卡记录的Hash值为
HashVal = Hash(Hash(清除时间),Hash(出发时间),Hash(终点时间), Hash(Hash(检查点[1]的编号, 检查点[1]的时间), ..., Hash(检查点[N]的编号, 检查点[N]的时间)))只有指卡号、清除时间、起点时间、终点时间、到访检查点的顺序+编号+时间都完全一致时才认为是一个不重复的读卡记录，这在实际的单场活动中几乎是不可能出现的，可以很安全地作为标识一次读卡记录的哈希值。
打印个人成绩纸条
读卡后默认会向读卡数据的来源Reader发送打印的小纸条数据，个人成绩条的样式如下图所示：
具体的打印数据流向可以通过后面的小节来配置
主动打印个人成绩条
如果需要补打成绩条，可以先双击需要打印的成绩，然后在对应的Reader行的打印操作中点击个人成绩，即可向对应的InstaPunchReader发送打印数据。
读卡后个人成绩条打印数据转发模式
InstaPunch支持分布式成绩统计模式，打印数据亦支持若干种转发规则，读卡后的成绩条传输行为可以通过转发模式修改。如下图所示，这一功能主要通过读卡日志下方的Reader列表进行配置,现在支持原路返回、聚合组、广播三种模式。
原路返回
该模式为默认模式，在这一模式下，运动员在哪个主站打卡，就把个人成绩打印数据发回到对应的InstaPunchReader，如果对应的Reader连接了打印机，便会打印个人成绩条。
聚合组
使用聚合组模式时，如果在连接列表中把某个Reader的用作聚合组选中，则在读卡时会对每个聚合点都发送一份成绩条数据，或者你可以理解为这是一种分组广播模式。这一模式通常用于需要打印备份成绩条的特殊场景下使用，实现一次打卡，多次出条。
广播
使用广播模式时，读卡时会对每个连接到成统中心的连接点都发送一份成绩条数据。这个模式用于补充聚合组模式，通常不会使用。
打印临时成绩
InstaPunch支持临时成绩打印，只需手动在对应的Reader行点击临时成绩，并在弹出的对话框中选择临时成绩的竞赛日、分组模式、筛选的前N名（0表示全部）即可进行打印。
打印的样式如下图所示：
其他读卡设置
除了上述关键设置，第四栏下方包含若干读卡设置
- 模式：可以再读卡评估和指卡录入模式切换，处于读卡录入模式时，可以将读到的指卡号转发到运动员页面，完成指卡录入操作。具体操作可以参考运动员
- 出发时间评估策略：对于非接力赛，可以使用这个来覆盖出发时间，可选的包括出发时刻表和通道上配置的出发时间。
- 监听端口和密码：控制读卡服务器的端口和密码，通常情况下可以不用修改。
- 允许外部连接：控制读卡服务器是否允许外部电脑的连接，默认关闭。
- 读卡服务器：开关读卡服务器，默认打开，关闭后InstaPuncher无法连接到该成统中心。
读卡记录恢复
InstaPunchReader会在读卡后立刻将该读卡数据加密并存储到其所在目录下的dump文件夹中，这些数据以ReaderId进行命名、以.iprd结尾，且无论该Reader是否连接到成统软件都可以工作。需要恢复时，只需要在读卡服务器处于关闭状态下点击从IPRD文件恢复按钮，选择获得的dump文件即可。由于所有的dump记录都有hash值，不用担心重复导入。
这一部分的dump属于系统外部备份，也是赛事数据安全防护的最底层的保障。即使你的赛事数据库因为各种问题遭受毁灭性破坏，甚至压根就没有数据库文件，也能够先使用Reader进行读卡数据录入，然后通过dump出来的iprd备份文件按照实际读卡的先后顺序重建整个读卡评估过程。
TIP
dump文件务必保留好。这个也丢失，那就真的没办法了😓😅
恭喜！🎉 至此，你成功学会使用InstaPunch进行读卡评估，接下来的内容将是赛事看板。