Serial and COM Port Communication

[RavensFan]

---

@meshein wrote:

I did have the other program open at the same time.  Maybe only one program is able to read from serial at a time?  And could it be that once I have opened the other program, the serial is disabled from labview?  I could try a reboot and not open the other monitor program.

I did not get any error messages, but I will inspect to see if there are any errors on the wire.

Thank you

---

Of course only one program can read it at a time.  If the other one has the port open, you should be seeing an error on the error wire when you try to open it or use it within LabVIEW.  I'm sure you are getting an error message, but you probably aren't looking at it.  Put a probe or indicator on that error wire!

[RavensFan]

Your manual doesn't seem to say whether it is a line feed character of a carriage return separating the 3 lines.  So you might have to try either.  Even if you pick the wrong one to start, I'd still expect you'd see something coming through.

Actually, page 41 says that CrLf is used.  Or is at least the default.  So a decimal 10  (line feed) should be wired in for the termination character input, or left unwired since it defaults to that.

One thing I do see is that the manual on page 40 talks about it being 8 data bits and 2 stop bits.  You don't have any of those wired into the VISA configure which means it is default to 8 data bits and 1 stop bit.  You'll have communication errors with the wrong number of stop bits, I would assume a framing error.

Also be sure to read pages 41-42.  It looks like you can also set it to an inquiry mode where you send a character and the device responds with the data then.  Actually the command/response protocol is pretty much always a better system to use then a device that sends data continuously without being prompted.

[meshein]

Thank you for the information.  I assuming I can select a much quicker frequency with an inquiry mode.  Would you by chance know of a sample code that successfully employs this method of data acquisition?  I'm getting a feeling this would be a better method as this mode only transfers two lines of code and it is exactly the information I need.  I am not looking for Max and Min data and I have to filter it out of the string anyway.

[crossrulz]

---

@meshein wrote:

Would you by chance know of a sample code that successfully employs this method of data acquisition?

---

VISA Write followed by a a VISA Read.  I'll let you figure out the parsing of the string though.

[arteitle]

---

RavensFan wrote:

One thing I do see is that the manual on page 40 talks about it being 8 data bits and 2 stop bits.  You don't have any of those wired into the VISA configure which means it is default to 8 data bits and 1 stop bit.  You'll have communication errors with the wrong number of stop bits, I would assume a framing error.

---

If the sender is sending two stop bits and your receiver is only set for one this shouldn't cause a problem, because a stop bit is the same as an idle line, and two stop bits just means the line remains idle slightly longer between transmitted bytes. The other way around, with the sender only putting one stop bit between bytes, could cause problems if the receiver required two stop bits, but it would depend on the implementation of the receiver and why it actually required the two stop bits.

[arteitle]

---

@Dave123456789 wrote:

+0.005 in.H2O +0.0000 psi

Left Min: +0.0045 Max: +0.0053

Right Min: +0.0000 Max: +0.0000

---

If this in actual sample of the data the device is sending, then your String Conversion.vi is not going to work correctly on it, because that VI is looking for the substring "PSI" (note the capitalization) and expecting it to appear twice in the received data, whereas your sample only has "psi" (lower case) once. Since it never finds the "PSI" stubstring, the entire received string will be output as "Left PSI", and the first numeric part of it will be output as "Left Pressure", while the "Right PSI" output will be an empty string, and "Right Pressure" will output the default value of zero.

[OregonGumby]

There are some very basic problems with your code.  One is that you should eliminate your outer loop.  The com port only needs to be initialized once.  You need to follow that with a VISA close that runs after the main loop terminates.  It also looks like your visa source name comparison at the top of your loop is not doing anything.  Do not run your terminal program at the same time as your LabVIEW program.

[meshein]

I think I am missing something very basic here.

I am using the sample code attached with the following selections:

My device is set to inquiry, 9600 baud rate and an inquiry character of 4.00000.  I am trying all variations of ASII 4.0 character such as using EOF etc.  but I can't seem to get this to communicate any information.

Thank you for any advice you can give on this.

Michael

[crossrulz]

What device are you trying to talk to?  The manual usually gives the full protocol.  We need to know that in order to help any.

[Ben]

In addition to what Crosrulz asked the values you show in the screen shot and your post do not match-up.

"baud" is bits per second.

Using 1 stop bit and 8 data bits (an Ben being lazy rounds that up to 10) 9600 baud will only give you about 960 characters per second.

Again being lazy and rounding off that would require 40 seconds for 40000 charters at that speed.

Spoiler

Quoting from a "Fake News" report that was read live on TV after a jet crashed somewhere in California one of the pilot names was announced as;

"Sum Ting Wong"

Ben