I've been pulled into a project that deploys two CR1000 loggers at one site. A COM port from the primary logger is connected to the RS-232 port on the secondary logger. Both loggers run their own programs but they share certain datatable definitions exactly, variable for variable. At intervals the primary logger issues a GetDataRecord command to copy values from the secondary logger's copy of a datatable into the primary logger's copy of that datatable. The values in that datatable come from measurement instruction in the secondary logger that sample instruments connected to voltage ports, pulse counters, excitation ports, SDI12 ports, etc. There is room in their design to add a third (and maybe more) logger based on possible future needs.
Is this sort of thing common? Reasonable? Supported?
My main problem with the setup is timing. With one logger at a site you can adopt the convention that its clock is absolutely authoritative. With two loggers there is usually a slight drift of clock timing between the two that grows larger (very slowly) over time. So you open a can of worms about which timestamp is 'right'? And what if they drift far apart enough that your assumptions about certain events being co-incident are no longer valid? What if their datatables aren't called in the precise order you expect them to be?
Initially the logger programs as they came to me had code that would reset the clock of the secondary logger once per hour using time provided by the primary logger. Unfortunately at one site the idiosyncratic device timing was such that the secondary logger would occasionally reset itself with the wrong time from the primary. It's possible that this code could have been refined and corrected but the effect was kind of cataclysmic on our processing and in the short term it was simply commented-out, leaving the clocks to drift naturally.
Another problem that happened at two different sites was people connecting to one logger or the other using laptops running in local time with their LoggerNet set to automatically 'correct' the logger time to match the server time. So for a while the two loggers would run several hours off one another. Kind of sloppy but it happened at two out of four sites so that tells me it cannot be entirely avoided.
My other big problem was in integrating data into summary tables in the primary logger, to include individual parameters that were measured by one logger or the other. It's not like the 'copied' tables would write their data into the primary logger's variables where they could be averaged, min/max/sampled, whatever, on whatever time frame the primary logger wanted. I did test a version of the code for a while that used TABLE.PARAMETER syntax to sample the values from the table copied from the secondary logger so they could be included in other summary tables in the primary logger. But we only had a week to test this and subsequent to deployment I found there were rare-but-regular edge cases where the wrong record would be copied based on whether the relevant datatable was 'called' in time.
Yet another problem was some careless programming updates that left the primary/secondary 'cloned' datatables in slightly different format and then boom, no data could be copied between the loggers at all until it was fixed. I know this to have happened at one site and I have my suspicions about problems at a second site.
Okay I'll stop now, although I could go on. What I'm wondering, mainly, is does this setup strike people as something that could and should be made to work properly and, dare I say it, gracefully? Is this is a case where the concept is sound but the implementation is lacking? Or are the real problems inherent to the concept here?
The other side of this question is, what other ways/devices exist to 'extend' the number of control ports available on a CR1000 datalogger? I have a long history with SIO4s dating back to our CR23X days and we still use them with CR1000s. But the SIO4 buffers cannot always handle the throughput we want to throw at them and their format masks aren't sophisticated enough to (e.g.) read variably-formatted output. Both of which problems are easily overcome with SerialOpen/Out/In commands using a CR1000 COM port. But then you may run low on control ports. Another related issue is potentially running out of SDI12 ports, of which it's my understanding that the CR1000 only has four (C1/C3/C5/C7).
So on the flip side, my question is: are there any (dumb, non-timekeeping, non-programmable) devices that serve to extend the number of control/SDI12/COM ports on the CR1000, and will accept all the usual commands from the CR1000's program? If so, are such devices chainable in the same way that the SIO4s are, so that I could add more of them without using up additional ports on the CR1000?
Apologies for the verbosity, but I'd appreciate anyone's thoughts on how best to achieve extensibility, preferably in a way that is (more or less) without limits, as chaining two (or more) CR1000 dataloggers would be. Other than the devices I've mentioned (CR23X, CR1000, SDM-SIO4) my experience with CSI control devices is limited.
thanks,
Mike J+
I would look at this implementation a little differently. If you want all data to be compiled into one master logger then you should use that logger to trigger the slave loggers. Then your time is always based off the master.
There are a few ways to accomplish this but I would use the serialout command from the master and then you can address any slave you want with a simple character.
Then in the slave, you could use a waittrigger sequence to run every time the master requested data. Something like this:
BeginProg
'measurements
Scan (1,Sec,3,0)
PanelTemp (RefTemp,250)
TCDiff (TCTemp,1,mV2_5C,1,TypeT,RefTemp,True ,0,250,1.8,32)
SerialIn (SerialCharacter,COMRS232,10,"#",100)
If SerialCharacter = "logger1" Then
TriggerSequence (1,0)
EndIf
NextScan
SlowSequence
Do
'Proceed in this loop only when trigger occurs
WaitTriggerSequence
SendVariables (SendResult,COMRS232,0,4094,0000,0,"Public","VariableinDestination",VariabletoSend,1)
Loop
EndProg
This would send all variables to the master over the serial port when the master requested them. You could then save them in a table and everything would be in realtime.
Note: I have not tested the above code. I just threw it together for example purposes.
The SDM-SIO1 provides the serial port expansion that you are looking for. You can connect up to 15 of them to a single CR800/1000/3000. The same serial commands used for the control ports / RS-232 port are used with the SDM-SIO1. Additionally, you can add more serial ports to a logger by adding 5 MD485 or SC105's to the CS I/O port. They too will use the same serial commands used for the control port / RS-232 port.
Campbell does not carry an SDI-12 expansion device. The CR1000 has 4 SDI-12 ports (C1/C3/C5/C7). Each SDI-12 port can serve many sensors, depending on their cable lengths and impedance. For example, you could connect 5 sensors to each SDI-12 port. Each sensor on a single SDI-12 bus (for example C1) is addressable, often 0-9,A-Z, or a-z.
If more serial i/o and sdi-12 ports are needed, you could also take a look at the CR6. It has 6 U port pairs and 2 C port pairs. Each pair can be used for serial Tx/Rx. Each odd # channel can be used for SDI-12, i.e 8 SDI-12 I/O ports total possible.
If you want more measurement channels, then a multiplexer like the AM16/32B can be used to greatly expand the measurement channels on a datalogger. They are fairly easy to use - pulse, measure, pulse, measure, pulse, measure, etc.
There a number of ways to turn a remote logger into a "dumb" measurement device. One of those ways is to use the WaitDigTrig instruction. The central logger could pulse a control port that is wired to control ports on the dumb / remote loggers. This pulse will cause the remote loggers to go. Then the central logger could use getvariables, getrecord, sdi12recorder, modbusmaster, etc. to retrieve the data from the remotes over (for example) an MD485 RS-485 network that all the loggers are attached to.
central logger example:
Public MyData(8)
Public Station10Result
Public Station10Data(8)
Public Station20Result
Public Station20Data(8)
Dim i
DataTable (Test,1,1000)
DataInterval (0,5,Sec,10)
Sample (8,MyData(),IEEE4)
Sample (8,Station10Data(),IEEE4)
Sample (8,Station20Data(),IEEE4)
EndTable
BeginProg
Scan (5,Sec,0,0)
'trigger scan in other stations
PulsePort (1,10)
'take local measurements
VoltDiff (MyData,5,mV5000,1,True ,0,250,1.0,0)
'delay for good measure?
Delay (1,1,Sec)
'get data from other stations
For i = 1 To 3
GetVariables (Station10Result,ComSDC7,10,10,0000,0,"Public","MyData",Station10Data,8)
If Station10Result = 0 Then ExitFor 'success
Next i
If Station10Result <> 0 Then Station10Data() = NAN 'failed, set to NAN
For i = 1 To 3
GetVariables (Station20Result,ComSDC7,20,20,0000,0,"Public","MyData",Station20Data,8)
If Station20Result = 0 Then ExitFor 'success
Next i
If Station20Result <> 0 Then Station20Data() = NAN 'failed, set to NAN
CallTable Test
'broadcast a clock report
ClockReport (ComSDC7,0,4095)
NextScan
EndProg
remote logger example:
Public MyData(8)
BeginProg
'accept pakbus clock sets from station 1
PakBusClock (1)
Do
'wait to be triggered
WaitDigTrig (1 ,0)
'take local measurements
VoltDiff (MyData,5,mV5000,1,True ,0,250,1.0,0)
Loop
EndProg