More questions...
I'm using the CR1000 to make a few measurements of reflected light etc. This is done by turning on a LED, making a reading, turning off the LED, making a reading, etc for a set number of samples.
eg:
'Loop
For i = 1 To SAMPLES
'Turn on LED
PortSet (TRB_LED_CTRL, 1)
'Make the measurement
VoltSe (t_high,1,mv5000,TRB_CHAN,True,0,250,1,0)
'Turn off LED
PortSet (TRB_LED_CTRL, 0)
'Make the measurement
VoltSe (t_low,1,mv5000,TRB_CHAN,True,0,250,1,0)
'Calculate
t_samples(i) = t_high - t_low
Next
The problem I have is that the timing between the PortSet and VoltSE commands varies. I need consistent timing because the output of the light sensor goes through various filters and therefore it has an influence as the signal decays due to capacitors charging etc.
Anyway to do this? I thought about controlling the LEDs with the VX1 and VX2 lines as it seems like they wait an exact time before the measurement occurs
Geo,
Just a shot in the dark here, take a look at compiling in SequentialMode vs PipeLineMode which your program is probably defaulting to.
IslandMan
If the OS in the datalogger isn't very old, it's probably automatically compiling in sequential mode because of the PortSet commands existence within a loop. Perhaps a Delay instruction with a precise delay between PortSet and VoltSE would improve the timing.
To get accurate timing you must write the program to run into pipeline mode. The reason is that in sequentialmode even a lot of communications activity with the logger can add jitter to the timing of the measurements.
To get into pipeline mode replace the for loop with a subscan instruction (with no interval). See an example below.
Public PTemp, batt_volt, i, t_high, t_low, t_samples(10)
Const TRB_LED_CTRL =1
Const trb_chan=1
Const samples=16
'Main Program
BeginProg
Scan (1,Sec,0,0)
i=1
'Loop
SubScan (0,Sec,samples)
'Turn on LED
PortSet (TRB_LED_CTRL, 1)
'Make the measurement
VoltSe (t_high,1,mv5000,trb_chan,True,0,250,1,0)
'Turn off LED
PortSet (TRB_LED_CTRL, 0)
'Make the measurement
VoltSe (t_low,1,mv5000,trb_chan,True,0,250,1,0)
'Calculate
t_samples(i) = t_high - t_low
i=i+1
NextSubScan
NextScan
EndProg
Hi all,
Thanks for the replies. It is compiling in sequential mode as you said. I'm going to change the program to use the SubScan command - somehow missed that one - and do some tests. Will post back if it all works. Thanks for the info, much appreciated!
Ross
The pipeline mode worked. The timing is now just right and the measurements are very consistent.
However after reading the manual some more I just want to be certain that the program will run as expected.
The basic layout is:
Scan
PortSet to turn on sensors
Delay to let sensors settle
SubScan for sensor 1
NextSubScan
Calculations for sensor 1
SubScan for sensor 2
NextSubScan
Calculations for sensor 2
SubScan for sensor 3
NextSubScan
Calculations for sensor 3
SubScan for sensor 4
NextSubScan
Calculations for sensor 4
PortSet to turn off sensors
Average and Standard Deviation calculations for all sensors
CallTable
NextScan
It all seems to work fine, but I want to be sure that the calculations and portsets occur in that order. eg will the average and standard deviation calculations always occur after all the subscans are complete, and will the port set to turn on the sensors happen at the right times.
Another problem I have is that I must operate a servo motor every two hours.
Previously I did this with the following code:
SlowSequence
Scan (120,Min,0,0)
Dim k
Dim dutycycle
'Turn on power to servo
PortSet(2,1)
'Operate servo using PWM
For k = 1 To 8
If k = 1 Then dutycycle = 0.105
If k = 2 Then dutycycle = 0
If k = 3 Then dutycycle = 0.045
If k = 4 Then dutycycle = 0
If k = 5 Then dutycycle = 0.105
If k = 6 Then dutycycle = 0
If k = 7 Then dutycycle = 0.045
If k = 8 Then dutycycle = 0
PWM (dutycycle,4,20,mSec)
Delay(1,700,mSec)
Next
'Turn off power to servo
PortSet(2,0)
NextScan
Now, in pipeline mode, the PortSet(2,x) commands are not run.
Also in what is probably an OS bug, only one PWM command per PWM channel can be in a scan. Any more and the PWM commands no longer work after the second scan.
Thanks
Ross
Question one: in pipeline mode all the measurements are done and buffered in memory before any processing starts. This buffering works pretty well as long as you steer clear of conditional processing. Generally anything that is not likely to work will force the logger to sequential mode, so to be sure, leave out the Pipeline command in the program and make sure that when you compile the program that it is compiled in pipeline mode and does not try to switch to sequential mode.
Addendum: in a few cases like putting writeio in the slow sequence, the compiler may take a cautious approach and switch to sequential mode, however in that case it is valid to over-ride the automatic mode selection and force pipeline mode.
BTW: If your system could get very busy you can increase the buffering of data by increasing the scan buffer in the scan instruction. This will allow the logger to continue on for longer taking the measurements if it gets behind with its processing.
The key thing with pipeline mode is that all the measurements and certain other instructions, including Portset, are run in exact sequence and with exact timing so you can be assured this will be OK in your program.
Coming onto the second issue re use of the portset in the slow sequence. There can be issues with using Portset in slowsequences when in pipeline mode. Checked: in this case it is because Portset is still being sequenced in with the measurements whilst your delays are set to be processing delays - they will happen out of phase with the portset commands which will turn on and immediately turn off that port in this instance.
What you should do is use the WriteIo instruction instead of Portset as this can be used even in conditional statements or slowsequences when running in pipeline mode - although it should not be used if close sequencing of when ports are set with measurements is required in the main scan.
I will have the issue of the PWM command checked out, although I expect running one PWM per scan is a limit and attempt to run more should have been trapped.
* Last updated by: aps on 9/9/2009 @ 11:51 AM *
Regarding the PWM issue can you please email me the whole program as it stands that appears to show the PWM stopping after the second scan. email to (editing to remove the antispam changes):
andrew dot sandford at campbellsci dot co dot uk
Can you confirm if the PWM changes eight times within the first and second scans but stays on or off? thereafter?
Blank
* Last updated by: aps on 9/9/2009 @ 11:59 AM *