Sensors project; Queue Slowing down my producer loop.

[garthenar]

I am currently working on a project which requires me to use LabVIEW to collect data from multiple sensors. Two sensors will be hooked to a unit that send the data in eight bytes of ASCII over an Ethernet cable to a comport on a PC.Right now, on the LabVIEW side, I am having trouble with using two queues to transport data from my producer loop to my consumer loop. I managed to fix the consumer loop but the producer is still running painfully slow (executing once every 6 seconds).

The unit constantly posts the last data readings to the serial port so I wrote a simple loop that checks it every tenth of a second (the sensors are triggered at 10 Hz) and sends that data to a consumer loop for processing and storage (well, it will store the data once I add that in).

If there is some way for me to use the results of the timeout on the enqueue element to signal the loop to complete I think that would solve the problem.

I have attached images of my code (including the subVI) and one of my attempts to fix the problem.

Thank you for the help.

- garthenar

Also, ignore the Globals, I am working on getting rid of them.

Fig. 1: My code

 Fig. 2 Inside the subVI

 

[garthenar]

Update.

- I tried replacing my queues with channel wires and encountered the same problem.

- Altering the millisecond multiple didn't fix anything, it didn't even change the observed behavior.

[RavensFan]

Is there a reason you are using two different queues to send data?  Why not 1 queue that consists of either a cluster or an array of the two data points?

Why, according to your subject line, do you think the queues are slowing down the producer loop?  If your producer loop is taking 6 seconds, then it is probably an issue with your serial communication.  Looking at that one picture, the fact you are using Bytes at Port suggests a problem.  What does a full message look like from the device?  Does it end with a termination character?  I'm sure there is a much simpler way to do read and interpret the data from the serial port.

[garthenar]

Thank you for your response RavensFan. I truly appreciate it.

---

@RavensFan wrote:

Is there a reason you are using two different queues to send data? 

---

Inexperience. I will do as you recommend and change it to one queue for a cluster or an array.

---

Why, according to your subject line, do you think the queues are slowing down the producer loop?  If your producer loop is taking 6 seconds, then it is probably an issue with your serial communication. 

---

I thought it was the queues because those are the most recent Items I added to the code. The moment I read what you wrote about it probably being the serial port I went to the lab and checked - someone stole my cable... I'll have to fix that in the morning and test my program again. I'll keep you updated.

---

Looking at that one picture, the fact you are using Bytes at Port suggests a problem.  What does a full message look like from the device?  Does it end with a termination character?  I'm sure there is a much simpler way to do read and interpret the data from the serial port.

---

That's inherited code written by the manufacturer. It has been working so I've been focused on other problems. But I knew (from fixing their other code) that I'd have to work on it eventually. The manual for the device says it sends 15 bytes of ASCII (I'm assuming they mean 15 ASCII characters as that's how it's depicted in the manual). As soon as I get my cable back, I'll runs some tests to confirm. If you have any recommendations I'm all ears.

Note: this is my first time working with a serial port or Ethernet. In classes I have worked with UART and in my last project (programming a micro-controller in C) I worked with I2C.

[RavensFan]

If you know it sends 15 bytes, then read 15 bytes.  Then you don;t have to worry about reading bytes piecemeal and putting them back together.  An ideal protocol would have X number of bytes and also end in a termination character.  That way if you start reading in the middle of the message, you'll know you have the end of a partial message,  but all messages after that will be intact and complete.

[rolfk]

Also note that you say you didn’t work with serial ports in the past but only uarts and I2C, But uarts are actually synonymous with serial ports. 
While a serial port usually refers to a typical RS-232 or sometimes RS-422/485 port, uart is simply usually the hardware implementation of the serial bitstream interface but for all practical purposes also simply a serial port.

[garthenar]

---

@RavensFan wrote:

If you know it sends 15 bytes, then read 15 bytes.  Then you don;t have to worry about reading bytes piecemeal and putting them back together.  An ideal protocol would have X number of bytes and also end in a termination character.  That way if you start reading in the middle of the message, you'll know you have the end of a partial message,  but all messages after that will be intact and complete.

---

That just went verbatim, with credit given, into my engineering notebook.

I'm working from home today so I cant test it immediately but as soon as I get back into work I'll start testing it. How the sensor is sending the data is actually the choke point on my project right now (I thought I had it figured out but I did some more work and now I'm not so sure). 

Also, I have replaced the two queues with one for an array. I'm going to play around more with arrays, structs, etc today but this is what I have so far.

 

Thank you.

[garthenar]

---

@rolfk wrote:

Also note that you say you didn’t work with serial ports in the past but only uarts and I2C, But uarts are actually synonymous with serial ports. 
While a serial port usually refers to a typical RS-232 or sometimes RS-422/485 port, uart is simply usually the hardware implementation of the serial bitstream interface but for all practical purposes also simply a serial port.

---

(*Panics in undergrad*)

I'll go ahead and move RS-232 to the front of the "To Research" List and pull out my UART notes. Wait.... Yes, I just checked the manual and the device does communicate through RS-232.

serial bitstream interface... Definitely looking into that. 

I'm doing well in my classes but I have learned nothing compared to what I have learned working on this project for the last three weeks. And this forum is a big help. It's like going from 0-100 in 2 seconds flat.

Thank you for the help