RS232 Port read to detect CR event, set flag, repeat

[NateTheGrate]

I have a project reading an RS-232 communication string  in LabVIEW on Com1 using a duplex spy cable between a PC and a microscope under control (RTS/CTS). When the microscope receives a command from the PC to move the stage it sends back a serial port ASCII string ending in "CR/0D" about every 15 seconds which I intercept in my spy cable LabVIEW serial read program.   I need to capture these "CR" events of byte strings greater than 14 to trigger a Boolean True to eventually activate another VI.   For now I use a front panel TRUE indicator. The PC RS-232 communication is easily read in TERMITE, but using the LabVIEW demo serial programs, I get serial VISA  framing errors (− 1073807253), hence the need to trap them. I am new to LabVIEW.  Tracing (bulb) the code reads the VISA ASCII string once, and then does nothing. Probably something is not being reset in the loop, which should run unless stopped manually.  I also need to reset the byte count at each read of CR. 

 

Any help gratefully appreciated, as few know LabVIEW here. 

 

 

 

SerialPortCR-Trig3.vi

[smithd]

I don't understand a lot of what you're trying to do, but the serial framing error isn't likely a visa problem. Are you sure you're configuring the port correctly with the right baud, stop bits, etc?

If so, look here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L38SAE

As for why its stopping after you enter the loop when you highlight execution, you're telling the loop to wait for 15 minutes (1,000,000 ms) between reads. That is probably not what you want. In fact, you don't need to have a wait in that at all, because you are already waiting on the VISA read. If you know your microscope will send a message every 15 seconds, set your visa timeout to a reasonable number (probably 20,000 ms rather than your current 100,000) and set the term char and thats it.

 

[NateTheGrate]

Thanks for responding. 

I am passively reading a duplex RS232 spy cable conversation between a microscope being commanded to move to new focus positions and PC. The RS232 spy cable duplex response of the microscope (now improved and believable) looks as follows. I want this to run until stopped by the user.

The code endlessly goes as follows... reported by Termite  (Ascii on right...note weird double comma characters) terminating in CR each time. I want to trigger on the code string...(best would be the 84 84 46 („„F ))CR  to send a Boolean to another VI. before the laser scan. Currently I trigger on the upper one.

Termite output...

84 84 c4 86 a5 f2 84 84 46                                   „„Ć¥ò„„F          
84 84 46                                                     „„F      

(scan)          

84 84 c4 86 85 f2 84 84 46                                   „„Ć…ò„„F          
84 84 46                                                     „„F   

(scan)   etc.....

When the code is run in Highlighted execution...it almost works, and and (Image Count) counts the scans correctly but with a large delay. But in free run..the image count.does not increase on the front panel.  Ascii reads seem to be lost too.

So it looks like some sort of timing issue. Remember the RS 232  read is passive, but Termite picks up the code just fine. 

I also get a VISA  framing errors (− 1073807253),  a lot...maybe this is a clue. 

Nate

 

Serial_ Synch4.vi

[smithd]

For the framing errors I'd suggest adding in the code from A here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L38SAE

VISA is probably caching errors in the background, so you want to basically clear out any old data and clear any framing errors during initialization. Once thats done, I would expect VISA to work equivalently to your terminal program. In fact, you might see if this works (as a starting point) -- that will tell you whether or not visa is the problem: https://forums.ni.com/t5/Washington-Community-Group/LabVIEW-Hyperterminal/gpm-p/3511381

Once you have your data coming in you can use http://zone.ni.com/reference/en-XX/help/371361M-01/glang/search_split_string/ to look for the key sequence. As for getting that boolean to another loop I'd normally say queues but the new channel (http://www.ni.com/white-paper/53423/en/) stuff may be a better fit to start with.

[NateTheGrate]

Thanks again for your insights.

I tried the to add a "wait on Msec" delay like in (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L38SAE) but it did not help. Note my VISA read also has a wait on Msec Icon in it.   Adding the flush on buffer made it worse, and I lost most of the data in the read buffer.  I tried two "wait on msec": one in the loop, one before, but that did not help much.  Again highlight execution always worked much better...so some sort of timing synchronization issue. My microscope is fairly old, so maybe things from c2005 may be the state of its serial ports. 

My code seems to get framing errors as it reads each line of ascii I think...that is one problem.

The good news is LVIEW really read the RS232 excellently, so something in those LVIEW code boxes did the trick. So you are right,  VISA can work in the right state. So I will try adapting the LVIEW code here, deleting the write section which I do not need.  I will take a look at the search split string next. 

So making a conditional of  a read buffer of 6 with 84 84 46 ( „„F)  might work best to avoid confusion with the longer upper strings.

 

Nate.

[ShaunR]

On 10/5/2018 at 4:11 PM, NateTheGrate said:

reported by Termite  (Ascii on right...note weird double comma characters) terminating in CR each time.

If you are seeing the CR char, it is likely that the termination is CRLF. Try setting you termination char to 0A (decimal 10)

Edited October 7, 2018 by ShaunR

[smithd]

22 hours ago, NateTheGrate said:

My code seems to get framing errors as it reads each line of ascii I think...that is one problem.

Are you sure its 8 data bits then? ASCII is 7 bits.

 

22 hours ago, NateTheGrate said:

Note my VISA read also has a wait on Msec Icon in it.   Adding the flush on buffer made it worse, and I lost most of the data in the read buffer.

The visa icon just indicates that it will wait, because it doesn't have a timeout input as I recall. The actual serial chip is running constantly. The KB is suggesting you give the system a few seconds to change the UART over to the proper settings before doing a read. However if the system is already running when you launch this labview application that will not help, as data is already coming in. 

[NateTheGrate]

Thanks for your reply. 

I modified the LVIEW code which oddly does not seem to call the visa icons and inserted my character filter and counter and now „„F counter functions perfectly.  Oddly the VI hierarchy seems to call .vis " Configure Serial Port.vi, Serial Port Read.vi, Bytes at Port.vi, but no VISA.vi.

One other weird issue I have is with an integer register I defined.  I16 Image Count ...it seems when I initialize it after running it-- it is stuck to 2 and not 1 or zero when I "reinitialize to default". Not sure how you fix this. But this is minor problem.  When it starts on execution the first time, the register is zero in Image Count, so while good I am a bit confused why it defaults to 2. 

Now I need to link this code to a Boolean button = True in another VI.

Thanks Everyone. ;<)

Nate.