edwardewilliams Posted October 21, 2008 Share Posted October 21, 2008 We use the following custom sequence to poll remote serial device over telemetry links. The link is established elswhere in DF and the Device Number (dn) is passed to this function. function PollLogger(dn) ispolling = 1 try private string datain = "junk" private string chan private ch private val private count = 0 while (1) try purge() write(chr(13)) delay(2) write(chr(13)) delay(2) write(chr(13)) delay(3) read(3) purge() if (resetpulse[dn]) //sitenum or dn? write("ch,p1"+chr(13)) delay(3) purge() write("pm=3"+chr(13)) delay(3) purge() resetpulse[dn] = 0//sitenum or dn? endif write("cr,a"+chr(13)) break catch() ? strLastError endcatch count++ if (count > 3) return endif delay(10) endwhile while (1) try datain = readuntil(10) // read a line: BV: 12.831310 chan = right(parse(datain,0,":"),2) val = strtodouble(parse(datain,1,":")) if (val == NaN()) val = 0 endif if (chan == "BV") ch = 0 else ch = strtodouble(mid(chan,1,10)) endif chan = left(chan,1) switch case (chan == "B") Channel.AddValue(strDevice,dn,"BatteryVoltage",0,val) case (chan == "S") Channel.AddValue(strDevice,dn,"SDISensor",ch,val) case (chan == "A") Channel.AddValue(strDevice,dn,"AnalogInput",ch,val) case (chan == "P") Channel.AddValue(strDevice,dn,"PulseInput",ch,val) endcase catch() ? "PollLogger: " + strLastError timepolled[dn] = systime() return endcatch endwhile catch() ? strLastError endcatch timepolled[dn] = systime() This has worked well for us in the past, but recently we've started having a problem where the last value read and placed in the "DATAIN" string will continue to parse over and over and over again - about every 8 seconds or so. Setting the timeout for the remote device to a shorter time solves the problem (the sequence relies on comm timeout to move on out of the read/parse loop) but then we have a problem where some of the devices may not connect since sometimes, depending on the device, it can take 10-15 seconds to obtain a connect - if device timeout is set shorter than that to avoid this problem, then we never connect in the first place. Thoughts as to how to make this more predictable? We can't have a "hard out" from the read/parse loop since depending on the device, we get a different number and combination of channels and channel types with no "end of data" character or similar termination sequence available. Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.