I am trying to communicate with a WETLabs ECO using the SerialInRecord and am having no luck. I have been able to use SerialIn with SplitStr, but I get strings of different lengths every so often (the first few columns are dropped).
Here are the SerialIn commands...
SerialOpen (Com3,19200,0,0,10000)
SerialFlush (Com3)
SerialIn (InString,Com3,100,10,50)
SerialFlush (Com3)
SplitStr (ParseStr(1),InString,CHR(09),4,4)
Eco_counts = ParseStr(3)
SerialClose (Com3)
The SerialInRecord that I have been trying is...
SerialInRecord (Com3,Testing,0,0,&H0D0A,Huh,01)
The data coming from the instrument looks like....
09/20/10 08:53:21 460 16380 535
09/20/10 08:53:22 460 16380 535
09/20/10 08:53:22 460 16380 535
09/20/10 08:53:23 460 16380 535
09/20/10 08:53:23 460 16380 535
09/20/10 08:53:24 460 16380 535
In your first program, I suggest getting rid of the SerialFlush(Com3) command that is right after SerialOpen. It may be flushing out data in the buffer before you can read it. That could explain why you are getting varying amounts of data in.
With your SerialInRecord, you have told it an EndWord to look for, but have not told it to record any bytes prior to that end word. To fix it, change the NBytes parameter to be the number of bytes to store prior to the EndWord.
Good luck!
I have it from WETLabs that a line of data is 10 bytes long, so I put it in as ...
Public Testing As String * 100, Huh
SerialOpen (Com3,19200,0,0,10000)
SerialInRecord (Com3,Testing,0,10,&HOD,Huh,01)
SerialFlush (Com3)
SerialClose (Com3)
but I still get NAN.
A few questions:
What is Huh returning? If it is returning a negative number, then your data is overflowing the destination, and you should increase the number of bytes in the SerialInRecord command.
What data type does your sensor output? Does it output a string or does it output binary data?
Another thing to try is getting rid of your serial close function, at least in the Scan portion of your program.
huh is returning 0.
It outputs a string, as posted in my first post. At times the date/time stamp is dropped, other times other values are lost, but the rest of the data is there.
OK, just removing the SerialClose allowed osme data to get through. Why should that make a difference? It was closing the port after it was looking for data.
* Last updated by: sinusoid on 9/21/2010 @ 9:55 AM *
Serial sensors can be finicky sometimes, so try playing around with the SerialInRecord command. Try, for instance,
SerialInRecord (Com3,Testing,&H0D0A,30,0,Huh,01)
Another thing that could be happening is that the logger and the sensor aren't syncing up, so when the logger is checking for data, the sensor may not have put anything out yet. To check for that, you can try
Public ZeroBytes As Boolean
BeginProg
SerialOpen(ComRS232,4800,0,0,1000)
Scan (2,Sec,0,0)
SerialInRecord(Com3,Testing,&h0D0A,30,0,Huh,01)
If Huh = 0 Then
ZeroBytes = True
ContinueScan
Else
ZeroBytes = False
EndIf
NextScan
EndProg
Watch the Huh, ZeroBytes, and Testing variables on the Connect Screen, and see what they do over time. This will let you know if you need to change your scan interval, the size of your NBytes, or if there's something else out of place.
You could also try using
SerialInBlock(Com3,Testing,30)
to see what you get in.
I got it working by just removing the closeserial command. Doesn't make sense to me that closing the port after it trys to get the data would affect it though.
I'm curious about that too. I don't ever use SerialClose, so this is good for me to learn.
The SerialOpen and the SerialClose commands take some time to execute. In fact, often people will put a delay after the SerialOpen so they don't try making measurements before it is ready. Perhaps the scan was too fast to be doing both of those within one scan.
Do you know whether the program was compiled in Serial or Pipeline mode?
It says compiled in SequentialMode
A few tips on using serialinrecord with sensor that sends data asynchronously (without prompting):
1) SerialOpen automatically clears the buffer (so includes the equivalent of a serialflush).
2) Serialinrecord normally does not need serialflush nor regular opening and closing of the serialport if there are distinct start and end characters and if you use the option to get the last record, as you will always get the latest whole record in the serial buffer. (The instruction also avoids issues with reading data part way through a transmission being received.)
3) You still need to open the serialport once though, although on the same serial port you are reading the data from. (I hope you spotted the minor error in "Skippers" example program above)
4) On trick that can be used if there is no distinct start sequence and a variable length message, but a carriage return, linefeed termination sequence is to set the start character as linefeed and the end character as carriage return. This works OK, providing there are no extraneous character between the messages.
There needs to be at least one full message output from the sensor per scan of the logger program to guarantee picking up a record every scan. Even then a record may be lost occasionally if the sensor timebase runs even a fraction slower than the logger clock.