Logging RS232 and analog data

[DSRTM]

Hi guys,

I'm trying to log data from my RS232 instrument, and also include a couple of analog inputs. 

The vi works "ok", but not great.  First off, the frequency on the daq assistant needs to be set very high to see a resonable refresh rate on the screen.   Secondly, the time sync is off on the data being logged from rs232 (unbundle node) and the analog inputs.

I like using the daq assistant and the write to file vi only because they are simple to set up.  Not too familiar with any other methods.

Any thought on how to make these 2 issues (plus a few more) better?

Formatting the front panel is still being tweaked. see attached.

This is a modified instrument driver vi, and the instrument driver vi library.  Hope this works for you guys.  Thanks for the help.

thanks

Darren 

[mikeporter]

You are going to have to live with the time sync problem because you can't syncronize to an RS232 source. There are way to many timing variables: how long it takes for whatever you're talking to to acquire (and process?) the data, how long it takes for it to make it available, how often you are asking for data, how long it takes to transfer the bits across the link, etc, etc, etc.

In terms of your other issue, I don't understand what you mean by "resonable refresh rate". Your sample rate should be a function of the spectral content of the signal you're measuring.

Mike...

[DSRTM]

Thanks Mike.

When I execute the vi, if the daq assistant doesn't have a rate (hz) of about 10000, I don't see any voltage numbers changing (load or pressure) on the front panel.  That's what I'm referring to as "refresh" rate.  Sorry for the confusion.

The logged file looks like it's saving data at about a 1-2hz rate through the daq assistant.  I don't really understand what the reason for that is.

Since these are physical parameters (load and pressure), I obviously don't need to log 10,000 hz.  However,  10-20 hz would be perfect.  I'm not getting that right now..

thanks

Darren

---

@mikeporter wrote:

You are going to have to live with the time sync problem because you can't syncronize to an RS232 source. There are way to many timing variables: how long it takes for whatever you're talking to to acquire (and process?) the data, how long it takes for it to make it available, how often you are asking for data, how long it takes to transfer the bits across the link, etc, etc, etc.

In terms of your other issue, I don't understand what you mean by "resonable refresh rate". Your sample rate should be a function of the spectral content of the signal you're measuring.

Mike...

---

[DSRTM]

I've worked on this a bit over the past couple of days.  I"m still not able to control the logging rate.  The instrument driver RS232 and the analog signals DAQ assistant don't seem to sync properly.

I have to put the daq assistant rate to 10,000 (hz) in order to see about 3 hz (3 points per second) logging into the data file, and I'm not too sure what the reason is (fundamentally not understanding the problem to be honest).

Looking for some help so I can learn why the logging rate is not controllable in this situation.

I'll post the lastes vi when I'm back at work, but the only difference is I've changed the "write" vi to the "set point" vi, since I'm only wanting to control the setpoint of my flow meter anyway.

Thanks

Darren

[DSRTM]

here is what I've done lately.  Not much different.  It's the RS232 cluster driving the logging rate. 

Looking for input on how to increase the logging rate of the RS232 data

thanks

Darren

[RavensFan]

If you had absolutley nothing else going on, no DAQ assistant, no logging to file, just reading data from your RS-232 port, how quickly could your loop run?  Dealing with serial ports, it generally takes time to send the command, wait for the instrument to act on it, and then wait for the response to come back.  Three times per second doesn't sound that bad.  What is your baud rate?  If the messages are short, and the baud rate is high enough, I don't think you can really expect more than about 10 readings per second from a serial device.

[DSRTM]

I've turned the baud rate up to 38600 thinking that may help my problem.  I'm not really clear what that instrument driver vi is sending to the instrument  - I'm simply opening a visa, and getting data streaming from the instrument.....? At least that's what I assumed.

So I disabled all the other data stuff, including the "set pont" vi which basically just changes the valve opening amount, and I still don't get anything greater than approximately 2-3 points per second.  I was attempting to eliminate everything else from the code to diagnose the source of the slow data rate.  This told me it's definitely the instrument driving the data rate.

However, when I open up hyperterminal, data streams by very fast.   Seems way faster than 2-3 data points per second.

@I attempted to turn the device ID from A to @, thinking this should turn the data to streaming from polling, but the communication didn't work (referring to  my vi didn't display data any longer).  .

I'd like to get about 10 per second.  I'm measuring pressure and mass flow, so that's about all I should be logging for a physical parameter

Thanks for the help.  I need it.  haha

Darren.

---

@Ravens Fan wrote:

If you had absolutley nothing else going on, no DAQ assistant, no logging to file, just reading data from your RS-232 port, how quickly could your loop run?  Dealing with serial ports, it generally takes time to send the command, wait for the instrument to act on it, and then wait for the response to come back.  Three times per second doesn't sound that bad.  What is your baud rate?  If the messages are short, and the baud rate is high enough, I don't think you can really expect more than about 10 readings per second from a serial device.

---

[RavensFan]

I don't have your subVI's, so I can't see what is going on inside them.  Could they be doing something like reconfiguring or initializing the port or the instrument on every use that is taking longer?  They must be doing something that Hyperterminal is not doing.

[DSRTM]

Hi Ravens Fan, the sub vi's are posted on my first post (.llb).

I was thinking along the same line as your thought this morning.  Any chance you could have a look and see what you think?

[RavensFan · Accepted solution]

In the Set Point.vi there is a subVI called ReadSerialBuffer.  It reads the port 1 byte at a time until it gets nothing or the carriage return character.  Then the loop ends and clears the buffer.

First, it shouldn't be necessary to clear the buffers because you've basically read until the buffer should be empty.  It may take some time for VISA to actually clear the buffers.  Since this is something that Hyperterminal is definitely not doing, it could be an explanation for the apparently longer time.

It looks like you have the termination character in your INIT vi, but it is set for a line feed character by default.  Your ReadSerialBuffer vi is reading until you get a carriage return character.  It would make more sense to set your termination character to be the carriage return, and then read a sufficiently large number of bytes.  It will automatically terminate on the carriage return.  It would be a lot more efficient then reading a byte at a time and no loop would be necessary.