hdfirmware

Clone Tools

Stats

Commits this week: 0
Total Committers: 17
Last Commit: 19 Nov
Commits this week: 0

Lines of code count not available

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Monday 07 Jun 2021
10:35 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:34 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:34 am

qnguyen  (deleted user)

Per Dara Navaei, we will need to implement this functions.

Per Dara Navaei, we will need to implement this functions.

10:34 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:34 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:32 am

qnguyen  (deleted user)

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

9:27 am

Sean Nash

Good point. Test will need to be longer than 50ms anyway - FPGA ramps the sound and there is a ~250ms time constant in the electronics. But I will want the sound to at least get started immediately.

Good point. Test will need to be longer than 50ms anyway - FPGA ramps the sound and there is a ~250ms time constant in the electronics. But I will want the sound to at least get started immediately.

Friday 04 Jun 2021
10:31 am

qnguyen  (deleted user)

Should we call setAlarmAudio here? This test is running at 50 ms while the setAlarmAudio is running at 250 ms. The alarm audio might not be set when we switch to else part.

Should we call setAlarmAudio here?
This test is running at 50 ms while the setAlarmAudio is running at 250 ms. The alarm audio might not be set when we switch to else part.

10:19 am

qnguyen  (deleted user)

The flag is latched by using OR with the local updated noNewTreatment status.

The flag is latched by using OR with the local updated noNewTreatment status.

10:15 am

Sean Nash

But now in order to use the status flag, I think we can't allow that flag to go from TRUE to FALSE - need to latch it.

But now in order to use the status flag, I think we can't allow that flag to go from TRUE to FALSE - need to latch it.

Thursday 03 Jun 2021
10:55 am

qnguyen  (deleted user)

Removed this extra flag and used alarm status noNewTreatment flag.

Removed this extra flag and used alarm status noNewTreatment flag.

10:54 am

qnguyen  (deleted user)

Removed this extra flag.

Removed this extra flag.

10:51 am

qnguyen  (deleted user)

Done.

Done.

10:33 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:32 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:27 am

qnguyen  (deleted user)

Yes, and we checked for DG restarted (after it has started by HD) in DGInterface. Sample water sub-mode has to check before DG started.

Yes, and we checked for DG restarted (after it has started by HD) in DGInterface.
Sample water sub-mode has to check before DG started.

9:07 am

Sean Nash

Looks like you are latching the noEndTreatment status. Maybe we can have that status be latching so we don't need two flags.

Looks like you are latching the noEndTreatment status. Maybe we can have that status be latching so we don't need two flags.

9:03 am

Sean Nash

Is this different than alarmStatus.noNewTreatment?

Is this different than alarmStatus.noNewTreatment?

9:01 am

Sean Nash

Shouldn't this be checked more broadly (not just in water sample sub-mode)?

Shouldn't this be checked more broadly (not just in water sample sub-mode)?

Saturday 29 May 2021
1:06 am

qnguyen  (deleted user)

Removed.

Removed.

Friday 28 May 2021
3:32 pm

Sean Nash

I think rather than 37, these should be the lowest high priority rank (i.e. 49) so we can add new alarms and not have to renumber these. Also, I think the range for high priority alarms should have...

I think rather than 37, these should be the lowest high priority rank (i.e. 49) so we can add new alarms and not have to renumber these. Also, I think the range for high priority alarms should have room for more than 50 alarms. Maybe high priority could be 1..499, medium priority 500..599, and low priority 600..699.

3:23 pm

Sean Nash

Dara, do we need these handlers or not?

Dara, do we need these handlers or not?

3:23 pm

Sean Nash

We should delete this dead code as well.

We should delete this dead code as well.

10:34 am

qnguyen  (deleted user)

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

10:33 am

qnguyen  (deleted user)

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Thursday 27 May 2021
10:31 am

pmontazemi  (deleted user)

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Wednesday 26 May 2021
11:22 am

Dara Navaei

11:22 am

Dara Navaei

Tuesday 25 May 2021
2:30 pm

qnguyen  (deleted user) and Sean Nash

Friday 21 May 2021
10:38 am

Sean Nash

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.