Bytes at Port inconsistent, leads to faulty data

[rch5124]

Hi,

I've searched across the forums and cannot find a solution to my problem. For my program, the bytes at port / number of bytes read keeps changing. It starts off usually at 55, and fluctuates between 51 and 55. This isn't a big issue as the data isn't affected until several hours later when the bytes read becomes as high as 150 or as low as 30, and the data being collected becomes completely faulty (extremities). I've been messing around with different settings trying to fix it but it's hard to test because the program runs completely normal for hours (last check was about 7 hours) before messing up. What should I do?

Thanks in advance for the help,

Robert H

[Wayne.C]

Robert H,

To quote the robot in that old movie.  "Need input"

Let's start with some background.    What instrument are you connected to?  RS485, RS232?  Builtin port, PCI card, USB adapter?

[rch5124]

Wayne C,

Im using an RS232 serial port which connects to a campbell scientific micrologger

Robert H.

[smercurio_fc]

Having an inconsistent number of bytes at the serial port is not really unusual. There are numerous factors that can affect this, both at the source and at the receiving end. Are you basing your parsing on receiving a specific number of bytes? If so you would really need to change it so that you accumulate bytes until you've received a full "message", whatever that happens to be in your situation. If the micrologger you're using uses a termination character to end its messages then you don't even need to worry about the number of bytes, since you can configure VISA to look for the termination character on reads. See the serial port examples that ship with LabVIEW.

[johnsold]

Robert H.,

It would help if you post your code so we do not need to guess at what it is doing.

Does each batch of data have delimiters? What else is the computer doing while reading this data (like disk indexing or checking for upgrades)?

Lynn

[RTSLVU]

I have been using "bytes at port" in my serial routines for years with great success.

Post your code so we can see what is going on.

[rch5124]

I tried basing the program off a specific number of bytes based on what how the program was running (just to see if it would help) but it didn't. Unfortunately I do not think the micrologger has a termination character

The only program running on the computer is labview. there isn't internet hooked up to it so it's never checking for updates or anything. There are no delimiters for the data.

I'm attaching the code here. There are 2 sub-vi's in the code which i am also uploading. I don't think they're relevant in the issue, but just in case. The main file is called "Thermo_v2" though

[johnsold]

Try wiring the error clusters on the Match Regular Expression functions.  This may give a clue about the problem.

But, my guess is that over time the timing of the transmission by the logger happens to occur occasionally during the read and you only get part of a transmission.  It gets decoded incorrectly. The next read gets the rest of the first transmission and most or all of the next one (maybe even the next two).  It also decodes incorrectly.

You cannot rely on unsynchronized timing by two different devices to stay lined up.  If your protocol does not include some kind of termination character or some way of uniquely identifying the start or end of a transmission, then you will have problems.

Does the logger always send a transmission of relatively short duration followed by a pause before starting the next transmission?  If so, you could look for the pauses as a frame delimiter.  Messier, but possibly doable.

Lynn

[Wayne.C]

rch5124,

Is the micrologger setup to use the PakBus network protocol?

[RTSLVU]

You program has a lot going on in one big loop. You might consider putting the serial port read in it's own loop and process the data outside...

Here is a snippet of what I have been doing for years, seems to work for me.