Enqueue Element not working!

[Zifikis]

Hi Folks,

I am working on a serial port forwarder with the intention of logging the read buffer from an instrument to a file while it is communicating with control software. I intend to do this by enqueuing the data from the buffer (COM30 buffer in the vi) to be processed in a parallel loop, except that nothing is being enqueued despite the rest of the application working as intended (i.e., successful back and forth communication between both ports). Not sure if I'm missing something, but any help would be appreciated. I have attached the vi for reference.

Best,

Zifikis

[pincpanter]

Do you mean that # elements in queue is always null? The Enqueue Element will always work unless an error is received in input.

[dkfire]

What code is read the queue ? 

Do you get any errors in the code ? 

The way your code is setup with some read byte at port, you need to disable the termination charactor for your ports. 

[RTSLVU]

Most serial communication issues can be solved by watching this video: VIWeek 2020/Proper way to communicate over serial

[RTSLVU]

Honestly I don't quite understand what you are doing in your code. More information about your serial data would be helpful because the type of data you are receiving makes a difference in how you need to handle it. You will know what I mean after you watch the video I linked to in my previous post.

But in general I am guessing you want to receive the incoming data on one port, save a copy of it to a file, and pass the data out on another port.

A Producer/Consumer architecture would work well for this, especially if you are receiving at high speeds.

The Producer Loop will receive the data, put a copy into a Queue and transmit the data out the other port.

The Consumer Loop will Deque the data and display/save it.

[Zifikis]

Yes, that is what I am attempting to do (the producer/consumer pattern that is) but before building out the code any more I am trying to diagnose the issue with the enqueuer. I am receiving ASCII data, although only some of the responses are terminated with with the character pair \r\n. The data packet that I am most interested in is transmitted as 4096 bytes without terminating characters. Since I am effectively sniffing the communication between the device and the control software, the data comes in intermittently, which is why I am using the bytes at port function. Given that the data is being read and displayed, I figured that I could just wire this to the enqueuer, but then I run into the issue mentioned previously. I have wired the get queue status function to monitor the number of elements in the queue, but it doesn't count up and just remains blank. The feedback node loop was just used to check that the case structure was executing.

[RTSLVU]

To be honest I don't have a lot of experience with serial data that is does not use a termination character.

Again I refer you to the video I linked to.

Instead of worrying about the "enqueue issue", get your program to just reliably receive and display the data you're interested in first.

Then add in the enqueue part and make it a Producer/Consumer

[Minions · Accepted solution]

---

@Zifikis wrote:

... I am receiving ASCII data, although only some of the responses are terminated with with the character pair \r\n. ...

---

You are attempting to write data in an asynchronous manner.  If the data read or written does not have the termination characters (and they are not being added by your I/O configuration), the VISA Write or VISA Read will timeout and flag an error.  [The fact that you mention that much of the data read is unterminated, will cause this failure mode.]  This will prevent all following wired primitives using the error from working properly and will be bypassed.  Change the Synchronous I/O Modes of the VISA Write or VISA Read to synchronous to avoid the timeout.  They will now write or read whatever is in the buffer.  

This will create a different issue in that you will need to enqueue the buffer only when a complete command is received; otherwise, the command queue will be filled with incomplete partial junk.

[wiebe@CARYA]

---

@Zifikis wrote:

I am working on a serial port forwarder with the intention of logging the read buffer from an instrument to a file while it is communicating with control software.

---

You know there's software that does this, right?

Terminal (google.com)

Serial port sniffer. How to use RS232 sniffer software. (serial-port-monitor.org)

Null-modem emulator (com0com) - virtual serial port driver for Windows (sourceforge.net) is also a great tool, that routes com to tcp, com to com, tcp to com, etc.

[Zifikis]

Hi Minions,

Thank you for the suggestions. After further investigations, I was in fact getting a framing error (-1073807253) likely due to the unterminated data resulting in the following enqueuer being bypassed once the error was propagated. I have unconnected them and this has seemed to fix the issue for the time being.

Thank you for taking the time to look at this!

Best,

Zifikis