12-05-2012 07:03 AM
It would just log data continuously. I'm just curious to see what would happen with your data, if the problem would still occur.
12-05-2012 07:10 AM
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.
12-05-2012 09:22 AM
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
12-05-2012 10:03 AM
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.
12-05-2012 10:57 AM
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
12-05-2012 11:00 AM
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?
12-05-2012 11:00 AM
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?
12-06-2012 03:59 AM
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
12-07-2012 03:20 AM
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.
12-07-2012 04:51 AM
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.