LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial Communication fails after a minute or so of running

Solved!
Go to solution

This is great info cbutcher, thank you for your help. What I remember from the manual is that the user program or vi is in complete control of the serial communication, the 340 doesn't have an capability to send on a schedule, or control timing, or flow.

 

Good call about the arrow in the corner of the command string control! I hadn't noticed/or paid attention to it. I will have to expand it and see what may be hiding that we cant currently see. 

 

If I'm not in \ view, should I just see KRDG A? I will also have to check what view I'm in and verify what the string is. 

 

Everyone has been really helpful, I greatly appreciate it!

0 Kudos
Message 21 of 25
(737 Views)

@Nadweb wrote:

If I'm not in \ view, should I just see KRDG A? I will also have to check what view I'm in and verify what the string is. 

 


If you're not in \ view, it's a bit tricky if you're inputting the termination character in the string because it's whitespace, so you can't see it well. You'll see the string and then an empty line, but the empty line is invisible!

 

If you follow the VB example in the manual, you see that they append the termination characters (they use both, it's not clear to me if this is required or optional) to the supplied user string.

You could do this in LabVIEW using Concatenate Strings, and then not input any line end characters in the control (I'd generally suggest that if you're writing a library to simplify the user of the instrument in other 'application' code).


GCentral
Message 22 of 25
(734 Views)

I feel like it must be optional. The terminator settings on the 340 are CR, LF, CR LF, and LF CR, so they should all be valid for any program. Currently it's set to LF, but I can follow the VB example when I'm back to my computer and try CR LF and append them as you suggested, so the command control is just KRDG A? and the block diagram adds a \r and then a \n. 

 

I'll have to report back what I learn 

0 Kudos
Message 23 of 25
(728 Views)

@Nadweb wrote:

I feel like it must be optional. The terminator settings on the 340 are CR, LF, CR LF, and LF CR, so they should all be valid for any program. Currently it's set to LF, ...


Ah, so there's a configurable value on the device that allows you to choose? Good to know - in that case, you could pick whatever you want, but a) make sure you match that in LabVIEW, and b) if you choose a single character it will be easier, so your LF choice is probably the best option.

 


@Nadweb wrote:

I can [...] append them as you suggested, so the command control is just KRDG A? and the block diagram adds a [\r and then a] \n. 

 

I'll have to report back what I learn 


If you have it set to use only LF, then stick with that. But yeah, exactly as you said here, writing just the "command" bit and then using constants on the Block Diagram with Concatenate Strings (or Format into String, as appropriate, depending on how you're already set up for adding numeric values etc) can be a nice choice to simplify usage (and avoid your "user" - perhaps also you, but anyway... - having to know too much about underlying details).


GCentral
Message 24 of 25
(703 Views)

So, optimistically, it seems like we have solved the problem!

 

I expanded the command control box, with the arrow in the corner, on the front panel to reveal anything that was maybe hidden. This was not in \ mode. When I expanded the control box the arrow went away but nothing new was revealed. So I switched to \ mode, which revealed my command string was actually HTR?\\n\n, or whatever command I was using, but it always ended in \\n\n. So in \ mode, I erased everything but the command so it just read HTR? and in the block diagram I used Concatenate Strings to add a \n. This seemed to fix my issues. I used a 9600 Baud Rate, 7 data bits, odd parity, 1 stop bit, no flow control, and a single LF terminator. I made sure the 340 settings matched the LV settings.

 

Now it seems like my serial connection is stable, and I'm not missing out on data every other(ish) iteration. Seems to be working as expected!

 

Thank you cbutcher and everyone else who has responded to this, not sure I would have got this straightened out by myself, plus I learned a lot.

 

0 Kudos
Message 25 of 25
(685 Views)