LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sending Commands via Serial Port Only One Time

Solved!
Go to solution

Hello, and a preemptive thank you to anyone who will be helping me out,

 

The problem I am having in LabView is about sending commands. I am using an old spectrometer, the MS257 Oriel, and have been communicating with it via a serial port. My VI is attached to the post and the code works as intended except that whenever I want to send a command to the spectrometer that requires a reading of the output buffer (ex. ?GRAT or ?PS), I have to send the command 2 or 3 times before I can get it to work, which is why they appear in for loops. This is not the case with commands that do not require a reading of the buffer (ex. !GS or !MS), I only need to send these once.

 

The spectrometer command manual is also attached.

 

If you know what the issue is, could you please tell me how I can adjust my code so that I don't need a for loop and I only need to send the command once?

 

If you have any questions, let me know.

 

 

 

Download All
0 Kudos
Message 1 of 18
(315 Views)

You configured your port to end reads on the (unwired) default termination character which is a linefeed (aka LF, 0x0A, '\n').  When your device always sends a termination character, best practice is to request a large # bytes in the Read.  A Read will end on the earliest of:

- receiving the requested # bytes

- receiving a termination character

- reaching the timeout

 

Page 6 of the manual shows that Read commands respond in the format:

[CR][LF]##.##>

 

So your 1st Read ends at the LF character and the 2nd Read ends after either a timeout or the (wrong) requested # bytes.

 

That's the other problem.  All your Reads request a # bytes equal to the # you just wrote in the command.  That doesn't make sense -- there's no reason to expect the reply string length to match the command string length.

 

Solution:

When you configure and open your serial port connection, set your termination character to be '>' = 0x3E.  When you do your Reads, request a large # bytes like 128 or 1024, knowing that the Read will terminate and return as soon as you get the '>' character at the end of every reply.

 

 

-Kevin P

0 Kudos
Message 2 of 18
(292 Views)

I think this may help you.

VIWeek 2020/Proper way to communicate over serial

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 18
(274 Views)

Adding to Kevin_Price

 

You should also add some delays in some places, like at the start you go from !GS 0 command immediately into ?GRAT without any delay. If the device is still processing the !GS 0 command, then it'll likely ignore the following command until it finishes with the first.

0 Kudos
Message 4 of 18
(250 Views)

@AeroSoul wrote:

Adding to Kevin_Price

 

You should also add some delays in some places, like at the start you go from !GS 0 command immediately into ?GRAT without any delay. If the device is still processing the !GS 0 command, then it'll likely ignore the following command until it finishes with the first.


Adding waits shouldn't be needed. I sure never needed it for normal serial communication.

 

Send a command, then read with a timeout long enough. The device should be ready, at least for receiving the next command.

 

If a command does take time to process, solve this by increasing the timeout.

 

There's a big difference between a wait and a timeout. The wait will always wait it's time, while the timeout will never wait longer then needed. The wait will slow down the program, the timeout is as fast as possible.

 

EDIT: If you feel you absolutely must add waits, make sure the waits are skipped if there's an error. Nothing more annoying then having to wait for a device that isn't even there.

0 Kudos
Message 5 of 18
(237 Views)

wiebe@CARYA wrote:

Adding waits shouldn't be needed. I sure never needed it for normal serial communication.

 

Send a command, then read with a timeout long enough. The device should be ready, at least for receiving the next command.

 

If a command does take time to process, solve this by increasing the timeout.


There are plenty of commands that do not get a response.  And those take time to process.  And some instruments do not handle a message coming in while another is being processed.  I even ran into this with an oscilloscope over GPIB.  In that particular example, I had to add 500ms delays for the messages to be processed properly.  This is not typical.  Most devices I have used do not need a delay.  But those who do typically need no more than 10-20ms.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 18
(224 Views)

@crossrulz wrote:

wiebe@CARYA wrote:

Adding waits shouldn't be needed. I sure never needed it for normal serial communication.

 

Send a command, then read with a timeout long enough. The device should be ready, at least for receiving the next command.

 

If a command does take time to process, solve this by increasing the timeout.


There are plenty of commands that do not get a response.  And those take time to process.  And some instruments do not handle a message coming in while another is being processed.  I even ran into this with an oscilloscope over GPIB.  In that particular example, I had to add 500ms delays for the messages to be processed properly.  This is not typical.  Most devices I have used do not need a delay.  But those who do typically need no more than 10-20ms.


I can't say for sure I never had to add a wait, but just that it usually can be avoided, and that it sucks if it can't. If it can't be avoided, make them as small as possible, and make them skip on errors.

 

I think we're on the same page here.

0 Kudos
Message 7 of 18
(209 Views)

My take on hard-coded waits: Usually, if you need hard-coded waits, you do not have a complete grasp of the communications protocol.  That being said, I've actually had a power supply that stated in the manual to add a wait of 20 ms between commands to ensure that the last command was processed.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 18
(202 Views)

wiebe@CARYA wrote:

I can't say for sure I never had to add a wait, but just that it usually can be avoided, and that it sucks if it can't. If it can't be avoided, make them as small as possible, and make them skip on errors.


Yep, the reason I don't like to use the Stall Data Flow.vim.  Please go give this idea a kudos: Stall Data Flow should be a no-op in the event of an error 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 18
(191 Views)

Hey Kevin,

 

Thank you for your response, it did not solve the problem, but it helped me understand what was going on a bit more. I changed the termination character and the requested number of bytes, but I still cannot get it to read the buffer on the first try. Do you have any other ideas? You mentioned something about the timeout of the code, could you please elaborate on that?

 

Thank you.

0 Kudos
Message 10 of 18
(185 Views)