Continuous data capture, single point logging

[ShalimarA]

It would just log data continuously. I'm just curious to see what would happen with your data, if the problem would still occur. 

[Bandit]

OK, I will give it a try.

But as the example we tried earlier logging samples continuously managed to write them to file in the correct order, I believe this will work too.

Regards,

Bandit.

[Bandit]

Hi again,

I've tried this, and columns of data are written in the order they are acquired, just as in the example text file you attached.

Regards,

Bandit

[ShalimarA]

Hi Bandit,

I think I can definitively say that this is a bug. I'm going to submit a corrective action request because I've observed it in 2012 as well now. I've come up with a workaround though, hopefully you can utilise it. 

In the 'Start Conditions' page of the recording options, you can select 'Restart start/stop cycle in' to 'new log'. This worked for me, it created several new logs rather than 1 but thankfully they were all in the right order. I've observed that the first reading is in the correct order but the others are where it goes off. I also suggest that you not use 'Software Trigger A' as a stop condition as well as a start condition. This isn't the best programming practice and if you observe the recording light, SignalExpress doesn't work well when it's configured in this way. 

As I said, I'm going to file a corrective action request for this. 

[Bandit]

Hi ShalimarA,

Thanks. Now I know it's not something I'm doing, and will try a workround.

I note what you say about using the same software trigger for start and stop, but it was the only way I could find to configure that function to capture just one set of data. Which doesn't make it best practice, but probably good enough to complete the task I was attempting.

Thanks again for your help on this.

Regards.

Bandit

[ShalimarA]

No problem. I've found that if I used software trigger B as a stop condition, it captured one set of data, so you can try that and see if it helps? 

[ShalimarA]

No problem. I've found that if I used software trigger B as a stop condition, it captured one set of data, so you can try that and see if it helps? 

[Bandit]

The workround does seem to capture data in the correct order. But stopping with software trigger B means I can catch one set of data, or two, or occasionally (and confusingly) none at all, depending how fast I am on the trigger A / trigger B buttons.

I think for now my only solution is to capture data continuously and post process to pick out the data points required.

If there is a publicly accessible way to track it's progress please post the CAR number here so I can follow it to completion.

Regards, 

Bandit

[ShalimarA]

Hi,

I'm aware that you've been in contact with one of my colleagues. I'm submitting the CAR today but unfortunately there isn't a way to publicly access it. I believe he said he'd be in contact with you when we find out the results of it, though. 

[Bandit]

Hi Shalimar,

Yes, I spoke with your colleague yesterday. I understand that the CAR is an internal process, I suspected it would be. I look forward to hearing about the result in due course.

Regards.

Bandit.