We have an odd problem with one station. On that station we have a CR1000, HygroVue10, SnowVUE, In-Situ Troll water level, and a Sutron Fischer Porter weighing gauge, all of those sensors are SDI-12 devices. Prior to installing the SnowVUE sensor, all of the sensors were reporting fine. The Troll was on C1, the HygroVUE10 was on C3, and the Sutron was on C5. C7 and C8 are tied together for a door open switch. The SDI12 address for each sensor is different, the Troll is 6, the SnowVUE is 1, the HygroVUE is 0, the Sutron is 5.
The issue is that after we installed the SnowVue, sharing the C1 port with the Troll, the Troll stopped reporting data. I checked all of the connections and they are ok, tight and correctly wired. We then changed the program to move the Troll from the main body to its own slow sequence. The other three devices are already in their own slow sequences. The change in program did not rectify the problem. We changed buffer in the SnowVUE from 1 to 3. The buffer for the Troll is 1, the buffer for the HygroVue is 1, the buffer for the Sutron is 3. We thought maybe the SnowVUE doesn't play well with others and moved the Troll to C3 to share with the HygroVue. No Joy.
Any help would be appreciated.
I realized I forgot one important factor, I can directly talk to the Troll via the terminal emulator. Both the SnowVUE and the Troll respond appropriately when wired on C1 and when wired separately on C1 (SV) and C3 (Troll & HV).
Look at the SemaphoreGet() instruction in CRBasic. One of the examples shown is how to resolve an SDI-12 issue that might be running into. If you have SDI-12 instructions in multiple sequences for the same port, you can run into timing conflicts.
JDavis, thanks for the suggestion. Before any of this started, we had an SR50A in the same spot as the SnowVUE and everything worked fine. The replacement of the SR50A with the SnowVUE seems to be the cause of the problem. Moving the SnowVUE from C1 to C3 shoud have helped, since the two devices are not in the same sequence. They are both in their own SlowSequence at 1 minute, but should they not complete the command sequence entirely before moving on to the next sequence? Isn't that the point of the SlowSequence command in Sequential Mode?
The code in the SlowSequence follows for you to examine:
SlowSequence
Scan (1,Min,3,0)
' **** SnowVue10 Sensor - Snow Depth ****
SDI12Recorder (SnowVue10(),1,1,"M1!",1.0,0)
Temp_Corr_Distance = Raw_Dist*(SQR((AirT_C+273.15)/273.15))
SnowDepth_m = Initial_Distance-Temp_Corr_Distance
SignalQuality = SignalQuality_a
SDI12Recorder(SnowVue10_SN,1,1,"I!",0,0)
SDI12Recorder(SnowVue10_OS,1,1,"V!",0,0)
SDI12Recorder (SV10(),1,1,"M9!",1.0,0)
NextScan
EndSequence
SlowSequence
Scan (1,Min,1,0)
' **** Troll Well Level Sensor ****
' Output in PSI and deg C
SDI12Recorder (TrollData,3,6,"M!",1.0,0)
Water_Depth_m = Water_Pressure_psi * 0.704 ' Convert psi to meters
Well_DTW_m = sensor_depth_m - Water_Depth_m ' Depth to water in the well in meters
Well_Level_m = reference_elevation - Well_DTW_m ' Absolute elevation of the well groundwater in meters NAVD88
NextScan
EndSequence
If an SDI12 sensor says it will have data ready in 1 second, the data logger will jump to working on a different sequence while waiting on that sensor from the first sequence.
JDavis, I put the SemaphoreGet/Release commands around the code for the SnowVUE and nothing changed. The syntax is to place the SemaphoreGet (#) before the code and SemaphoreRelease (#) after that code. Is there somewhere else I should place it? This started after installing the SnowVUE and its code, so I presume that is the cause.
You have to wrap all lines of code that use that data logger channel. So, in addition to what you added around the SnowVue code, wrap the code in the other sequence that uses the same channel. Use the same semaphore number.