Hi,
I'm trying to send data out the serial port of the datalogger whenever a new record is stored in a data table. The data table is called by means of the AcceptDataRecords instruction. So, I was using the "TableName.Output" instruction to do this but it does not work out the same way as with the "CallTable" instruction because the AcceptDataRecords only calls the table whenever the remote record is received and not at every scan. So, this means that the TableName.Output is going to be true on every scan which is not what I'm looking for. Below is an example of what I'm trying to do. The remote records are received every second but it's sending duplicate data every 500 msec out the serial port. Any way to overcome this?
DataTable(Station_1A_Meas,True,-1)
Sample (1,WindSpeed,IEEE4)
Sample (1,WindDirection,IEEE4)
Sample (1,AirTemp,IEEE4)
Sample (1,RH,IEEE4)
EndTable
BeginProg
SerialOpen (COMRS232,115200,3,0,100000)
Scan (500,mSec,1,0)
AcceptDataRecords (5,32769,Station_1A_Meas)
DataOut=Station_1A_Meas.Output(1,1)
If DataOut Then
GetRecord (RecordTable,Station_1A_Meas,1)
SerialOut (ComRS232,String_1A_Meas,"",1,0)
EndIf
NextScan
EndProg
If it's difficult to see it at this rate, try receiving the remote records once a minute and have the scan rate be one second.
Thanks.
I had a look at this and it seems once a record is received into the table the Output flag goes true but is never reset - I suspect because it is normally reset on the next call of the table.
A work around to this is shown below, where you track the record number of the last record in the table rather than the output flag.
Note for my test I changed the serial ports and also added some test code in a slow sequence which you won't need. I also corrected an error in your program in the SerialOut command where you output the table name not the string as intended.
---------
Public windspeed, winddirection, airtemp, rh, dataout As Boolean, recordtable As String * 1000, recordno, lastrecordno, go As Boolean
DataTable(Station_1A_Meas,True,-1)
Sample (1,windspeed,IEEE4)
Sample (1,winddirection,IEEE4)
Sample (1,airtemp,IEEE4)
Sample (1,rh,IEEE4)
EndTable
BeginProg
SerialOpen (ComME,-9600,3,0,1000)
lastrecordno=0
Scan (500,mSec,1,0)
AcceptDataRecords (5,32769,Station_1A_Meas)
recordno=Station_1A_Meas.record(1,1)
dataout = recordno>lastrecordno
If dataout Then
GetRecord (recordtable,Station_1A_Meas,1)
SerialOut (ComME,recordtable,"",1,0)
lastrecordno=recordno
EndIf
NextScan
'This is just test code to emulate receipt of data from a remote logger
'The go boolena is set manually
SlowSequence
Scan (10,Sec,3,0)
If go Then CallTable station_1a_meas
NextScan
EndProg
Thank you Andrew. I will take a look at this.
I have another question. I have an application in which I send data from 14 dataloggers over TCP/IP to a remote datalogger. The remote datalogger has a similar program as above but with 14 tables and some additional instructions. Data should be received by the remote datalogger every second and this data is then sent out from one of the remote datalogger's serial port. Now, I've noticed that sometimes the remote datalogger receives two or more records at once (from the TCP/IP transmission) leaving intervals in which I don't receive any data until later. Now, I'm not sure if this could be some type of network delay issue or if there could be something else going on. Any thoughts?
Thanks.
I think what you are seeing is almost certainly caused by network delays as the logger would not try to group Senddata packets together. The only reason it might do would be if there was a lot of Pakbus communications going on to the logger sending the data and the senddata stuff was backed up in the outgoing transmit queue.
One thing I would question on this though is the reliablity of what you are doing. Senddata in this context is truely a one way data transmission with no checking for records lost between two loggers.
If you worked the other way around and had the master logger collect the data from the remote loggers you have more control over retries and timing etc. In the very latest operating system (to hit the website in the next few days) Getdatarecord, the command used to pull data, will also support getting more than one record at a time, e.g. get can get multiple uncollected records, in one go. This is a far more reliable way of ensuring data is collected back to a master logger.
This requires more data traffic between the two systems so it is not always appropriate if you are collating the data for a display or something similar.
Hi Andrew,
Thank you for your response.
Can you expand a little bit more on how using the GetDataRecord instruction will provide greater reliability in collecting the data from the remote dataloggers? How would this tell me how many records have been lost between the remote and the other loggers? I would have to keep track of the record-to-record transition in order to determine this? Would this way be more reliable as far as the likelihood of not having missing records?
The network delays represent a problem for me right now because this 1-second data needs to be displayed "real time" so the fact that I'm receiving two or more records at a time is not good. If this would add more traffic in the network, I'm not sure if I should go that route.
With current operating systems, you can specify the timeout and number of retries the instruction will use to get the record from a remote logger.
This means the logger will retry to get the record if something goes wrong, as opposed to Senddata, which just sends off one record and hopes it gets to the destination.
For Getdatarecord in the next OS it will include an extra parameter to let you specify the number of records to collect which will collect any uncollected records up to that maximum number. The logger tracks what the last record was it collected so you do not need to bother about tracking this.
If you use Senddata over TCP/IP the underlying reliability of TCP/IP should get the record through to the other end though, so it may may be an issue in your application. Sounds like network traffic or a slow or broken router in the path might be causing a problem. Is this a hardwired network or GPRS?