View Issue Details

IDProjectCategoryView StatusLast Update
0002084CCdciel[All Projects] Generalpublic19-02-22 23:23
ReporterhanAssigned ToPatrick Chevalley 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version 
Target Version1.0Fixed in Version 
Summary0002084: After succesfull focus, program move to wrong focus position
DescriptionThis night I have a strange focus problem. After an autofocus, the program moves to a wrong focus position.

E,g see below. the best focus is at 32768, but the focuser is after completion moved to 30634. Disabling temperature compensation or " autofocus after an delta T" doesn't help. Restart of the programs doesn't help. In the beginning of the evening it was working most of the time well. I'm using CCDCIEL 0.9.52-873-7fbb56e

2019-02-15T00:32:33.839 3: ASCOM.USB_Focus.Focuser: Focuser move to 32002
2019-02-15T00:32:41.951 3: Autofocus running, hfd=3.3 peak:16185.9 snr:124.9
2019-02-15T00:32:42.122 3: ASCOM.USB_Focus.Focuser: Focuser move to 32252
2019-02-15T00:32:50.234 3: Autofocus running, hfd=2.6 peak:29959.0 snr:171.3
2019-02-15T00:32:50.250 3: ASCOM.USB_Focus.Focuser: Focuser move to 32502
2019-02-15T00:32:58.300 3: Autofocus running, hfd=2.4 peak:29870.6 snr:171.1
2019-02-15T00:32:58.315 3: ASCOM.USB_Focus.Focuser: Focuser move to 32752
2019-02-15T00:33:06.458 3: Autofocus running, hfd=2.7 peak:25915.2 snr:159.1
2019-02-15T00:33:06.474 3: ASCOM.USB_Focus.Focuser: Focuser move to 33002
2019-02-15T00:33:14.040 3: Autofocus running, hfd=3.1 peak:16126.7 snr:124.6
2019-02-15T00:33:14.056 3: ASCOM.USB_Focus.Focuser: Focuser move to 33252
2019-02-15T00:33:22.121 3: Autofocus running, hfd=4.0 peak:9046.8 snr:92.0
2019-02-15T00:33:22.136 3: ASCOM.USB_Focus.Focuser: Focuser move to 33502
2019-02-15T00:33:30.155 3: Autofocus running, hfd=4.9 peak:5606.0 snr:71.0
2019-02-15T00:33:30.404 3: ASCOM.USB_Focus.Focuser: Focuser move to 33752
2019-02-15T00:33:38.407 3: Autofocus running, hfd=5.9 peak:4098.9 snr:59.7
2019-02-15T00:33:38.470 3: HYPERBOLA curve fitting focus at 6.063, remaining curve fit error 0.0713, iteration cycles 4
2019-02-15T00:33:38.485 3: ASCOM.USB_Focus.Focuser: Focuser move to 32268 - 400 Backlash compensation
2019-02-15T00:33:43.774 3: ASCOM.USB_Focus.Focuser: Focuser move to 32268
2019-02-15T00:33:48.095 3: ASCOM.USB_Focus.Focuser: Focuser move to 30634 <=====???????????????????????????????????????????????
2019-02-15T00:33:56.129 2: Autofocus finished, POS=30634 HFD=8.1 PEAK:3875.0 SNR:57.8 TEMP:1.9C
TagsNo tags attached.



19-02-15 01:09


Log_20190215_003129.log (21,722 bytes)


19-02-15 01:20

reporter   ~0005391

The problem occurred whole evening. I thought is was bad seeing, but it happens every time. Attached an earlier log.

Log_20190214_185149.log (64,822 bytes)

Patrick Chevalley

19-02-15 10:17

administrator   ~0005392

You have other problem with bad seeing and not enough move during the night. Maybe increasing the movement between points from 250 to 500 can help in this case.
But I not think this is the problem here.
It look like only your first autofocus at 18:53 was successful, after that it show this wrong final movement.

The two move (three with backlash) to focus position is expected. It first go to focusposition-focusstep and then to focusposition, this is to respect the focus direction choice.

Here the hyperbola computation give the position focus at 6.063, this is short after the measurement point 6, so 32502 + 0.063*250 = 32518.
It go first to 32518-250 = 32268.
Next it must go to 32518 but instead it go to 30634.

As you focus in the OUT direction the code for that is in fu_starprofile between lines 1044 and 1047.
This use relative focuser movement because this function is compatible with relative focuser.

The faulty last focusout() is processed in pu_main at line 4589 where it convert this relative move to an absolute move.
To match the reported value it must have received a move step of -1634 instead of +250, or the focuser read position was 30384 instead of 32268. I cannot explain any of this options.
Also very strange it fail only for this last move because the same is used for every move during the dynamic curve measurement.

All of this code as not changed for more than one year.

To have a better idea of what is wrong you can compile after removing the comment for {$define debug_ascom} at the top of cu_ascomfocuser, this will print in the log all the values send and received from the the focuser.

Patrick Chevalley

19-02-15 13:15

administrator   ~0005397

I have to add that I cannot reproduce the problem by using the INDI simulators.


19-02-15 16:09

reporter   ~0005398

Last edited: 19-02-15 17:03

View 5 revisions

I have setup a simulation and fed the Ascom position back to th HFD value. All worked well without any problem.

I have added some extra messages and activated the Ascom debug option. Loaded the tweaked software at my observatory. Managed to focus on a hot pixel (using option to accept one pixel star), See log attached
Here it goes wrong:
2019-02-15T15:54:32.846 0: debug: Request via ascom position: 32338
2019-02-15T15:54:32.848 3: ASCOM.USB_Focus.Focuser: Move 32338 32338
2019-02-15T15:54:32.853 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-15T15:54:32.853 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-15T15:54:36.859 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-15T15:54:37.085 3: ASCOM.USB_Focus.Focuser: Position = 30326

So why is the USB focuser reporting 30326??? That's puzzling. All other move request are executed properly by USB_focus.

Maybe the request are too quick. At the end there are three requests:

2019-02-15T15:54:27.699 3: ASCOM.USB_Focus.Focuser: Focuser move to 32338 - 400 Backlash compensation
2019-02-15T15:54:32.843 3: ASCOM.USB_Focus.Focuser: Focuser move to 32338
2019-02-15T15:54:37.930 3: ASCOM.USB_Focus.Focuser: Focuser move to 30576

The second request is redundant. It is also the one which goes wrong.

Log_20190215_155235.log (14,967 bytes)


19-02-15 17:11

reporter   ~0005399

The second move takes only 200 ms. That's wrong. Adding 100 ms delay solves the problem. Then a move takes 2 seconds:

2019-02-15T17:00:48.192 3: ASCOM.USB_Focus.Focuser: Focuser move to 28535 - 400 Backlash compensation
2019-02-15T17:00:48.192 0: debug: Request via ascom position: 28135
2019-02-15T17:00:48.192 3: ASCOM.USB_Focus.Focuser: Move 28135 28135
2019-02-15T17:00:48.192 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-15T17:00:48.192 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-15T17:00:52.373 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-15T17:00:53.699 3: ASCOM.USB_Focus.Focuser: Position = 28135
2019-02-15T17:00:53.699 3: ASCOM.USB_Focus.Focuser: Focuser move to 28535
2019-02-15T17:00:53.714 0: debug: Request via ascom position: 28535
2019-02-15T17:00:53.714 3: ASCOM.USB_Focus.Focuser: Move 28535 28535
2019-02-15T17:00:54.635 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-15T17:00:54.635 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-15T17:00:55.711 3: ASCOM.USB_Focus.Focuser: Position = 28535
2019-02-15T17:00:55.711 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-15T17:00:58.769 0: debug: at Tf_main.FocusOUT, existing value focuser.Position: 28535
2019-02-15T17:00:58.784 0: debug: at Tf_main.FocusOUT, delta value p: 250
2019-02-15T17:00:58.800 3: ASCOM.USB_Focus.Focuser: Focuser move to 28785

2019-02-15T17:00:58.800 0: debug: Request via ascom position: 28785
2019-02-15T17:00:58.800 3: ASCOM.USB_Focus.Focuser: Move 28785 28785
2019-02-15T17:00:59.814 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-15T17:00:59.814 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-15T17:01:00.329 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-15T17:01:01.717 3: ASCOM.USB_Focus.Focuser: Position = 28785

2019-02-15T17:01:02.404 0: debug: at Tf_main.FocusOUT, new value focuser.Position: 28785
2019-02-15T17:01:07.973 2: Autofocus finished, POS=28785 HFD=0.7 PEAK:684.7 SNR:19.1 TEMP:17.1C
2019-02-15T17:01:07.973 3: ASCOM.ASICamera2.Camera: Set binning 1x1
2019-02-15T17:01:09.018 2: Camera frame x=1260 y=504 width=808 height=800
2019-02-15T17:01:11.108 2: Camera frame x=0 y=0 width=4656 height=3520
2019-02-15T17:01:11.108 1: AutoFocus successful

My delay setting was as 0. I have swapped cameras pas 2 weeks ago and somehow ended with zero delay. This is an old problem. This could happen to many other people. So I would suggest the following fix in the wait command in cu_focuser.pas:

procedure T_focuser.SetPositionInt(p:integer);
  if FBacklashActive and ((p<Position)<>FBacklashDirection) then begin // p<position = focus IN
    if FBacklashDirection then
       msg(Format(rsFocuserMoveT, [inttostr(p)])+' + '+inttostr(FBacklash)+' '+rsBacklashComp);
       SetPosition(p+FBacklash); // backlash IN, go OUT first
       Wait(1); // some focuser need a delay to refresh their position
       msg(Format(rsFocuserMoveT, [inttostr(p)])+' - '+inttostr(FBacklash)+' '+rsBacklashComp);
       SetPosition(p-FBacklash); // backlash OUT, go IN first
       Wait(1); // some focuser need a delay to refresh their position
  msg(Format(rsFocuserMoveT, [inttostr(p)]));
  SetPosition(p); // go to final position
// if FDelay>0 then Wait(FDelay);
  Wait(FDelay+1); //wait 100ms minimum for correct communication with some focusers

I'm an happy person again!! :)

Patrick Chevalley

19-02-15 17:30

administrator   ~0005400

Last edited: 19-02-15 17:32

View 2 revisions

Forget this, I not see you second response.

Patrick Chevalley

19-02-15 17:43

administrator   ~0005401

Now I remember this delay after move option we added some time ago.

Anyway it is good to not stress a focuser, I commit your change :


19-02-18 00:19

reporter   ~0005408

This night, after a good start the problems started to happen random again. Adding a delay in the settings up to seconds didn't help. Reason is now clear. In the routine two wait() procedures didn't have Fdelay included. These two define the wait time between the two final setposition commands. So variable Fdelay should be included. Increasing to minimum wait time to 200 mS solved my problem. I have been continuous focusing now for the last hour and it seems now reliable for my setup. The 200 ms will do no harm since it is shorter then the focuser movement, I assume.

Changes: See below change all three Wait() statements to Wait(FDelay+2)

procedure T_focuser.SetPositionInt(p:integer);
  if FBacklashActive and ((p<Position)<>FBacklashDirection) then begin // p<position = focus IN
    if FBacklashDirection then
       msg(Format(rsFocuserMoveT, [inttostr(p)])+' + '+inttostr(FBacklash)+' '+rsBacklashComp);
       SetPosition(p+FBacklash); // backlash IN, go OUT first
       Wait(FDelay+2); // some focusers need a delay of 200 ms to refresh their position
       msg(Format(rsFocuserMoveT, [inttostr(p)])+' - '+inttostr(FBacklash)+' '+rsBacklashComp);
       SetPosition(p-FBacklash); // backlash OUT, go IN first
       Wait(FDelay+2); // some focusers need a delay of 200 ms to refresh their position
  msg(Format(rsFocuserMoveT, [inttostr(p)]));
  SetPosition(p); // go to final position
  Wait(FDelay+2); //wait 200ms minimum for correct communication with some focusers

Patrick Chevalley

19-02-18 14:28

administrator   ~0005409

I remark now there is an error in the comment text for this function, the wait() parameter is in second, not in unit of 100ms.
So the old delay was 1 second between the backlash move and the final move, then FDelay+1 second after the final move.

Is it OK for you if I change all the Wait(FDelay+2) above to Wait(FDelay+1) because I not want to make a 2 second wait for all the focuser that not need this trick.
If need you can increase your delay parameter in the config.
I we really need 200ms delay I can change the wait() parameter from integer to float.

This issue is very specific to the usb-focus Ascom driver, probably a bug. I try several time to install a Ascom development environment to look at the problem but it never compile anything successfully, Visual Studio is always failing with some cryptic error that not look related in any way with the project.
I have recently make some fix for the Indi usb-focus driver and now it work better. The main problem is the usb-focus serial command do not include any synchronization character so it is very easy to get lost.


19-02-18 15:22

reporter   ~0005410

Yes 2 seconds is too long. That will slow down focusing for many users.

I have to fix it with 2 seconds in the config parameter. Yes no problem. Maybe it better for you to change the wait to 100 mS. That will require a modification of the wait procedure. So something like

wait (fdelay,0.1);

I assume it is safer to do this for all wait()

Since it is very tricky error, maybe it is good to report in the log a discrepancy between the requested position and reported focuser position. That will warn usb-focus users and others of the problem. They can fix it with a delay in config. E.g. some ideas:

if GetPosition<>p then message('Error reading focus');

or more advanced fix:

while GetPosition<>p wait(fdelay,0.1);

Does this last fix work?

Patrick Chevalley

19-02-18 16:24

administrator   ~0005411

OK, next try.
I replace all the backlash delay by Wait(FDelay+0.1) so you can configure all with the focuser delay setting.

I also remark my Tf_main.FocusIN() function put some stress on the focuser driver by using:
because reading or writing Position request a command to the serial port.

I change it this way:

Can you try if this work now?

It is good if we can avoid a getposition afterward because this is one more "perturbation" for the driver.


19-02-18 22:56

reporter   ~0005412

Last edited: 19-02-18 22:57

View 2 revisions

Yes this works. Tested it here in a hazy but clear sky.

It works with 2 seconds delay in config. It doesn't works with 0 seconds, so the removal of focuser.Position:=focuser.Position-p has no significant impact.

The wait() statements in "procedure Tf_starprofile.doAutofocusDynamic;" are unnecessary and can be removed decreasing the total auto focus execution time with typical 9x1 second even with my 2 seconds delay in config. I tested it and it works and faster. The dedicated wait statement in " procedure T_focuser.SetPositionInt(p:integer);" are sufficient.

With a default delay of 0.1 seconds, could that give problems for some users?


19-02-19 09:49

reporter   ~0005413

I'm asking myself is should the delay be depending on the step size? For my setup I make steps of 250 but for backlash a step of 400.

and also is a final getposition check after focussing effective? P is iterative reached so:

if GetPosition<>p then message('Warning haven't reached final focus position. Consider increasing delay.');

This depends if the focuser is communicating while moving.

I will test it if the weather allows.

Patrick Chevalley

19-02-19 11:10

administrator   ~0005414

If adding a delay in FocusIN() do not change anything I revert to focuser.Position:=focuser.Position-p for simplicity.
Yes, now there is wait in the focuser function this additional delay in doAutofocusDynamic are unnecessary, I remove them.
This two point are in:

I not think this additional 0.1 sec. wait will do any problem.

This delay is independent of the step size because all the time the focuser is moving we wait in T_ascomfocuser.WaitFocuserMoving()
The function check the Ascom property IsMoving that is set to true when the driver receive the Move command with a new position and is set to false when it read a * in the serial message.
This is probably this last point that is problematic because the * can be send when it is processing another command, for example reading the position, and in this case it set IsMoving=false immediately before the end of the current command.
The change I like to try in the driver is to set an internal variable when the * is received but set IsMoving=false only after a new position as been read.

Other command running during the move are controlled by T_ascomfocuser.StatusTimerTimer(), maybe it can help in your case to not send this command when the focuser is moving. You can try by adding "if V.IsMoving then exit;" at the top of this function. But in this case you will not see the position updated during a large move.

If we want to check the final position the problem is the dynamic focus work with relative position, so the final position is not know in doAutofocusDynamic and when this position is computed in FocusIN() by focuser.Position-p it get a wrong value. So checking for this wrong value in T_focuser.SetPositionInt() will not help.

Another idea after writing all of this, maybe we can add a call to GetPosition in T_ascomfocuser.WaitFocuserMoving() after it finish the loop and after result:=(count<maxcount);
If this work we can test if the driver name is usb-focus to make this extra call.


19-02-19 12:11

reporter   ~0005415

I was testing the ascom simulator and it never failed due to function T_ascomfocuser.WaitFocuserMoving. So this is a robust check.

But your testing immediately V.IsMoving. Is this immediately available? Maybe the 0.1 sec should be before V.IsMoving test in cu_ascomfocuser.pas or cu_ascomrestfocuser.pas?. If the usb-focuser is working correctly, the current config delay should be unnecessary.

>>we can add a call to GetPosition in T_ascomfocuser.WaitFocuserMoving() after it finish the loop and after result:=(count<maxcount);
I will test this. This could avoid unnecessary wait() statements. I like to have to autofocus loop as fast a possible. Currently it takes 9x12 seconds.


19-02-19 13:33

reporter   ~0005416

The wait for V.IsMoving is working correctly for usb_focus.. The usb_focus misses commands only if a second setposition command is given immediately. So a delay is only necessary if backlash compensation is active. In other cases there is a delay by taking an image. This could help to speedup the process.

2019-02-19T13:09:21.309 3: ASCOM.USB_Focus.Focuser: Focuser move to 28000 - 4000 Backlash compensation
2019-02-19T13:09:21.324 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-19T13:09:21.324 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-19T13:09:31.636 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-19T13:09:31.776 3: ASCOM.USB_Focus.Focuser: Focuser move to 28000
2019-02-19T13:09:31.792 3: ASCOM.USB_Focus.Focuser: Wait moving ...
2019-02-19T13:09:31.823 3: ASCOM.USB_Focus.Focuser: Wait moving, IsMoving = True
2019-02-19T13:09:34.413 3: ASCOM.USB_Focus.Focuser: Move completed True
2019-02-19T13:09:36.207 3: ASCOM.USB_Focus.Focuser: Position = 23000


19-02-19 14:36

reporter   ~0005417

Last edited: 19-02-19 14:41

View 2 revisions

I found a fix. First I removed all delays including the 100 ms. Then I placed a getposition loop in ascomfocuser.SetPosition as below. Strange enough it is never looping. So a getposition is sufficient to fix my focuser. The problem seems now gone. The fix takes only 16 ms execution time, so much better then a delay. But let me test with real stars.

2019-02-19T14:33:08.496 3: ASCOM.USB_Focus.Focuser: Start fix
2019-02-19T14:33:08.512 3: ASCOM.USB_Focus.Focuser: End fix

procedure T_ascomfocuser.SetPosition(p:integer);
{$ifdef mswindows}
var n,count: integer;
 {$ifdef mswindows}
 if not VarIsEmpty(V) then begin
   if FPositionRange<>NullRange then
   {$ifdef debug_ascom}msg('Move '+inttostr(p)+' '+inttostr(n));{$endif}

   {begin fix}
   if ((getposition<>p) and (count<5)) then begin msg('Waiting for correct position focuser',0); sleep(1000); inc(count); end; {fix for some poor written focuser drivers. The getposition is already sufficient to fix the problem, so message should never occur.}
   {end fix}

    on E: Exception do msg('Error, can''t move to. ' + E.Message,0);

Patrick Chevalley

19-02-19 14:38

administrator   ~0005418

Do you meant that Wait(FDelay+0.1); is only necessary in T_focuser.SetPositionInt() after the backlash move but not at the end after the final move?
This can improve the performance, in this case the option description is "delay after backlash move"


19-02-19 14:59

reporter   ~0005419

>>>Do you meant that Wait(FDelay+0.1); is only necessary in T_focuser.SetPositionInt() after the backlash move but not at the end after the final move?

Yes that was the original idea, but now they can be all removed which is better. The existing if V.IsMoving check is working well. Only my focuser requires the above "getposition fix".

Patrick Chevalley

19-02-19 17:00

administrator   ~0005420

OK, I remove the intermediate wait(fdelay) in the backlash procedure, now the delay is applied only one time after the focuser is no more moving and can be used as a stabilization delay as described in the options. I let the option, maybe the motor that move the primary mirror of a SCT need that.

I apply your fix in T_ascomfocuser.SetPosition, with a test for Fdevice='ASCOM.USB_Focus.Focuser' and only an error message if the position is not right.


19-02-20 00:50

reporter   ~0005422

Had one hour of clear sky this night. Last mod is working well. Made 23 star images and done 23 dynamic auto focus. All auto focus runs where good a HFD of all images is good. Focusing is significant faster will all delays removed. Will do more testing tomorrow night, but pretty sure it will be the same.


19-02-22 22:39

reporter   ~0005434

Did today an other test in partly clear sky. Worked flawlessly. Topic can be closed.

Patrick Chevalley

19-02-22 23:23

administrator   ~0005435


I also apply the fix to the Ascom Alpaca driver:

Issue History

Date Modified Username Field Change
19-02-15 01:09 han New Issue
19-02-15 01:09 han File Added: Log_20190215_003129.log
19-02-15 01:20 han File Added: Log_20190214_185149.log
19-02-15 01:20 han Note Added: 0005391
19-02-15 10:17 Patrick Chevalley Note Added: 0005392
19-02-15 13:15 Patrick Chevalley Note Added: 0005397
19-02-15 16:09 han File Added: Log_20190215_155235.log
19-02-15 16:09 han Note Added: 0005398
19-02-15 16:11 han Note Edited: 0005398 View Revisions
19-02-15 16:11 han Note Edited: 0005398 View Revisions
19-02-15 16:25 han Note Edited: 0005398 View Revisions
19-02-15 17:03 han Note Edited: 0005398 View Revisions
19-02-15 17:11 han Note Added: 0005399
19-02-15 17:30 Patrick Chevalley Note Added: 0005400
19-02-15 17:32 Patrick Chevalley Note Edited: 0005400 View Revisions
19-02-15 17:43 Patrick Chevalley Assigned To => Patrick Chevalley
19-02-15 17:43 Patrick Chevalley Status new => resolved
19-02-15 17:43 Patrick Chevalley Resolution open => fixed
19-02-15 17:43 Patrick Chevalley Target Version => 1.0
19-02-15 17:43 Patrick Chevalley Note Added: 0005401
19-02-18 00:19 han Status resolved => new
19-02-18 00:19 han Resolution fixed => reopened
19-02-18 00:19 han Note Added: 0005408
19-02-18 14:28 Patrick Chevalley Note Added: 0005409
19-02-18 15:22 han Note Added: 0005410
19-02-18 16:24 Patrick Chevalley Note Added: 0005411
19-02-18 22:56 han Note Added: 0005412
19-02-18 22:57 han Note Edited: 0005412 View Revisions
19-02-19 09:49 han Note Added: 0005413
19-02-19 11:10 Patrick Chevalley Note Added: 0005414
19-02-19 12:11 han Note Added: 0005415
19-02-19 13:33 han Note Added: 0005416
19-02-19 14:36 han Note Added: 0005417
19-02-19 14:38 Patrick Chevalley Note Added: 0005418
19-02-19 14:41 han Note Edited: 0005417 View Revisions
19-02-19 14:59 han Note Added: 0005419
19-02-19 17:00 Patrick Chevalley Note Added: 0005420
19-02-20 00:50 han Note Added: 0005422
19-02-22 22:39 han Note Added: 0005434
19-02-22 23:23 Patrick Chevalley Status new => resolved
19-02-22 23:23 Patrick Chevalley Resolution reopened => fixed
19-02-22 23:23 Patrick Chevalley Note Added: 0005435