Hello everyone,
I am trying to write a program that will contain two different scan intervals. I have a Young Model 05103 Wind Monitor that I would like to sample at 1 time per second. Within the same program I have several biaxial clinometers that need to be sampled every 100 mSec or ten times per second.
My question is if I write a second scan interval below the first one directly underneath NextScan will the two scans run concurrently or one after another? I usually use ShortCut to write my programs as I have not had much experience with LoggerNet but I cannot figure out how to set two separate scan intervals in ShortCut.
Any help or suggestions would be very appreciated.
Thank you
I think you can use a slow sequence 1 time / sec and your main scan to 100 mS , it will work with no loss of data
It is important to use the pipeline mode (not the sequantial mode). I use this configuration for all my datalogger and it works perfectly!
Sincerely!
Take a look at the SubScan Instruction:
Scan(1,Sec,10,0)
'1 second measurements
'Call 1 second output table
SubScan(100,mSec,10)
'10 hz measurements
'Call 10hz output table
NextSubScan
NextScan
Read more in the CRBasic Help Topic for SubScan/NextSubScan
Hi,
I would like to add four fanspeed tachometer on the four pulse port of a CR3000 that is currently only used to eddycovariance measurements (Li7200 plus Gill HS-50 on the COM 1 RS232 port)
The current program run at 20hz (scan at 50ms) but I dont need to measure fanspeed at high frequency.
I tried to add a subscan(1) or a slowsequence(2) command but
for (1) I can't put a SerialInRecord on a Subscan and (2) I can't put a pulsecount on a slowsequence ...
How can I do?
Thanks a lot,
Daniel
For timing reasons there are limitations on where you can out the pulsecount. This instruction does not take long to run so I would include it in the main scan but look at using a value >1 in the pulse count option parameter that gives you the running average of frequency over a longer period than the scan interval.
Ok, so with a scan of 50ms and taking into account that tachometer give 2 pulses per revolution, if I put a Pulsecount into the scan with the following characteristics ...
PulseCount(Fanspeed(),4,1,0,1,1/60,0)
...and a DataTable as following ...
DataTable(FanSpeed,true,-1)
DataInterval (0,30,Min,10)
Totalize(4,Fanspeed(),FP2,False)
EndTable
...I will recover the fanspeed in my tab every 30 min in rpm, right?
Not quite. If you used this:
PulseCount(fanspeed(),4,1,0,10000,30,0)
The instruction will continuously calculate the average speed in RPM averaged over the last 10 seconds (or what ever interval you choose - set by the 10000). You can then sample or average that value in a datatable (Note the 30 multiplier to allow for the 2 pulses per rev)
Alternatively, and faster to execute, if you do not need a real time value you could use:
PulseCount(fanspeed(),4,1,0,1,30,0)
The realtime readings in this case will look eratic because in a 20 Hz scan most of the time the frequency will be zero but jump to 600 rpm every time one pulse is measured in a 50 ms interval (more if > 1 pulse). However, when averaged in a datatable over 30 mins this will give the correct average frequency in RPM for that 30 mins period.
Ah ok, I understand.
Now, maybe it will not run properly in this last condition:
On the EddyCov CR3000 program, I put the PulseCount(fanspeed(),4,1,0,10000,30,0) command but data are not recorded, just read. On another CR1000 (scanrate at 30 sec, I get the variables through a TCPOpen and the GetVariable instructions as following:
TCPOpen_var = TCPOpen("xxx.xxx.xxx.xxx",6785,0)
GetVariables(ResultCode,TCPOpen_var,0,1,0,0,"Public","Fanspeed()",Fanspeed(3),4)
The four fanspeed (Fanspeed(1) to Fanspeed(4)) will be get back from the CR3000 and will be written on Fanspeed(3) to Fanspeed(6) on the CR1000.
That's OK?
Without setting it up and testing it I cannot say definitively but in principle what you are doing should work. If you are pulling the data off from the public table you will definitely need to using the running average option to ensure you avoid the problems with the readings jumping around, unless of course you store average data to a table and pull the data from that table into the remote logger.
A priori, it doesn't work!
Here are the detailed program of the CR3000 first and the CR1000 after:
CR3000 program:
'Variables for profil fanspeed
Dim Fanspeed(4)
Alias Fanspeed(1) = Fanspeed_17m
Alias Fanspeed(2) = Fanspeed_23m
Alias Fanspeed(3) = Fanspeed_29m
Alias Fanspeed(4) = Fanspeed_37m
'Main Program
BeginProg
Scan(50,mSec,0,0)
PulseCount(Fanspeed(),4,1,0,10000,30,0)
NextScan
EndProg
CR1000 program:
'Variables
Dim Fanspeed(6)
Alias Fanspeed(1) = Fanspeed_03m
Alias Fanspeed(2) = Fanspeed_11m
Alias Fanspeed(3) = Fanspeed_17m
Alias Fanspeed(4) = Fanspeed_23m
Alias Fanspeed(5) = Fanspeed_29m
Alias Fanspeed(6) = Fanspeed_37m
Dim TCPOpen_var
Dim ResultCode
'Define Data Tables
DataTable (Fanspeed,1,-1)
DataInterval (0,30,Min,10)
Average(6,Fanspeed(),FP2,False)
EndTable
'Main Program
BeginProg
Scan(30,Sec,1000,0)
'Fanspeed (03m, 11m)
PulseCount(Fanspeed(),2,1,0,0,1.0,0)
'Recovering Fanspeed (17m, 23m, 29m, 37m) from the CR3000
TCPOpen_var = TCPOpen("xxx.xxx.xxx.xxx",6785,0)
GetVariables(ResultCode,TCPOpen_var,0,1,0,0,"Public","Fanspeed()",Fanspeed(3),4)
'Call Data Tables
CallTable(Fanspeed)
NextScan
EndProg
On an half an hour, I have the following results:
Fanspeed_03m_Avg : 0
Fanspeed_11m_Avg : 0.683
Fanspeed_17m_Avg : 0.4
Fanspeed_23m_Avg : 0
Fanspeed_29m_Avg : 0.1
Fanspeed_37m_Avg : 0.25
What doesn't work?
It looks like you are getting values.
Are you are not getting the values you expected?
If it isn't working, what is the value of ResultCode?
Providing the fans are acutally running there seems to be an issue with detecting the pulses too as there is no reason the CR1000 would not record the counts from the sensors attached to it.
Can you tell us more about the type of pulses being generated. Are they digital pulses if so what amplitude. Perhaps it perhaps an AC pulse output though. If the latter then you need to change the pulsecount option from high frequency to low-level AC.
To Sam:
I expect values of fan speed at around 4200 rpm.
I dont no the value of result code because it is declared as Dim variable.
To Andrew:
The output signal is TTL 5V, 2 pulses per revolutions.
But I don't understand why the first pulsecount command, for reading the pulse count on P1 and P2 of the CR1000 does not work, it was OK just before. I used PulseCount(Fanspeed(1),1,1,0,0,1.0,0)
PulseCount(Fanspeed(2),1,1,0,0,1.0,0)
instead of
PulseCount(Fanspeed(),2,1,0,0,1.0,0)
On the CR3000, with the command line recommended by Andrew, ie PulseCount(Fanspeed(),4,1,0,10000,30,0), I don't see correct instantaneous values of fan speed: values are between 0 and 6 ?!?
* Last updated by: Otemohu on 2/21/2013 @ 8:41 AM *
Regarding the bad fan speed data measured on the CR1000, maybe the data recovered from the CR3000 via the GetVariable command overwrite the CR1000 data?
Maybe I have to clearly differentiate the CR3000 variables from the CR1000 ones into the GetVariable command, like "CR3000_Fanspeed()" for the PBFieldName parameter and let Fanspeed(3) for the PBVariable parameter?
I would concentrate first on getting the Pulsecount instruction to work. Comment out the logger intercommunications instructions and try to get good pulse readings in both loggers.
All of the variants of the pulsecount instructions should work as you listed in your last post.
Please check the sensor output does generate full 5V TTL signals and whether it needs any pull-up or pull-down resistors or bias. Please check the signals are being generated at the right frequency by using an independent meter.
For the story, I tried before to wire all the six tachometer on P1, P2, C4, C6, C7 and C8 (C1, C2 and C3 are using for SDM and C5 for SDI12 communication). There was no signal on C4, C6, C7 and C8 because not really 5V dc level (see post "PulseCount on Com port" posted 01/07/13 10:17 AM). DAM and Andrew said me, respectively, that I can buy SDM-INT8 or SDM-SIO16 to resolve.
But since a CR3000 is located just close to the CR1000 and that there four pulse ports were not used, I thought I can use it. So I extended the cable of four tachometers (3 to 6) to be wired on the CR3000.
I've just tried uploading my old program on the CR1000 to follow your advices. But there is 0 rpm on P1 and P2 (the two first tachometer 1 and 2.... I dont understand anything.
Do you think it's possible I broken down the tachometers because I did not power down the fans (and so the tachometer output TTL 5V) when I extended my wires by pewter welding? I think not but we never know...
Can you confirm the model number of the shields. Are they 43502 shields? The number in your other post does not relate to an aspirated shield.
If it is the 43502 can you confirm that you did order all of them with the tachometer option. Campbell Scientific up till now has not supplied the version with the tachometer outputs "as standard". The tachometer output is only fitted as a special order by RM Young - although all of the shields have a terminal labelled TACH. For most it is not connected to anything.
You can see if the tachometer option is there by looking at the wire that goes to the motor inside the shield. The tachometer version has three wires. The standard motor has two.
They are 43502H shields with HMP155A inside. Sure they have tachometer since I wired them myself on the CR1000 before.
It is possible they could be blown up then. There are warnings given about not connecting the output to a power source as it could be damaged.
I would check the outptus with a meter that can check the voltage and frequency independently.
Hi,
Yesterday, we solve our problem.
There was a ground issue. Tachometers use the reference of fan DC power (-) that are powered by a power supply that was not grounded on the same point than the datalogger.
We resolve that and all sounds good now.
Daniel
Just for information, it works well. It was not a problem in the CRBasci program either in the wiring.
We had issues regarding the grounding of tachometer and its power. Now the problem is resolved. The program written above is working well.