Serial port trouble

[ASCIIWarrior]

Good Morning,

I am working with an Acuity Laser, Prima Confocal Sensor, and I am having a very difficult time getting the serial port to cooperate. I've tried the standard serial communication examples, but continuously have overrun, timeout, and connectivity errors.

The best thing that I have found is crossrulz actor framework for serial communications that came from the VI week video. 

But now, the actor framework is pretty advanced and I just want to pull the data that is in the read buffer out of the actor framework and also send a couple automated commands when the time is right. 

I've also had to slow the sensor down to 100Hz and am still getting occasional overrun errors popping up, though the actor just plows right past the error, which is nice. 

You can see the live data in the read buffer and singular commands being sent. 

[LLindenbauer]

Your problem description is probably too unspecific to provide useful help. Maybe you can post the actual code or more details about the machine you are communicating with. Posting data sheets and attaching .vis will increase the chance of useful replies.

[Kyle97330]

I took a brief look and it looks like this is a device that is continually sending measurements over RS232, while also responding to commands that you send by inserting those responses into the data stream.  Is this correct?

If so, it is no wonder "standard" communications fail.  Most "standard" communications work based on the notion that you usually only get data in response to sending data, so you can alternate writes with reads and it all comes out OK.

However, in this scenario you can't really count on that approach working consistently and reliably.  If you send a command and look for a response, you run the risk that your expected response will instead be the next regularly expected set of measurement data.  And if you have something continually reading the measurement data, it could occasionally grab out a reply to a specific query instead by mistake.  Plus, when you first start listening you have to account for the fact that you might be in the middle of a set of measurement data so you might need to wait for the next set to come in to start.

If this is the case, you might need to have one actor that does nothing but run a continual loop of reads, and each time a termination character comes in it analyzes what it gets and sends it to another more specific actor depending on the content.  At a minimum, you would probably want  3 receivers... one for replies to commands, one for normal measurement, and one for data it can't interpret (for logging, error handling, or discarding, whichever seems the most appropriate).

If that's not how it works then perhaps I just skimmed the device docs too briefly, but it would explain why you only have moderate success at the lowest sample rate, because when it's that slow it has the least chance of messages and replies getting crossed between two code sections.

[crossrulz]

---

@Kyle97330 wrote:

If this is the case, you might need to have one actor that does nothing but run a continual loop of reads, and each time a termination character comes in it analyzes what it gets and sends it to another more specific actor depending on the content.  At a minimum, you would probably want  3 receivers... one for replies to commands, one for normal measurement, and one for data it can't interpret (for logging, error handling, or discarding, whichever seems the most appropriate).

---

For these situations, I have had a lot of success with just the 1 loop doing the reading and writing from/to the serial port.  My real library allows for filters on the read strings and send the replies through different queues.  Those queues can be used to talk to other loops ("actors") and let them parse the data and do whatever.  Of course, this depends on the instrument having a well defined outputs in order to screen for a normal read versus a reply to a command/query.

Ultimately, I need to see documentation on the instrument in order to really give any advice.  I don't see anything here that would allow me to point to a solution.

[ASCIIWarrior]

---

@Kyle97330 wrote:

I took a brief look and it looks like this is a device that is continually sending measurements over RS232, while also responding to commands that you send by inserting those responses into the data stream.  Is this correct?

Yes, this is correct. Though, I have had decent luck by closing the data channels to stop the continuous measurements be sent in. 

If so, it is no wonder "standard" communications fail.  Most "standard" communications work based on the notion that you usually only get data in response to sending data, so you can alternate writes with reads and it all comes out OK.

However, in this scenario you can't really count on that approach working consistently and reliably.  If you send a command and look for a response, you run the risk that your expected response will instead be the next regularly expected set of measurement data.  And if you have something continually reading the measurement data, it could occasionally grab out a reply to a specific query instead by mistake.  Plus, when you first start listening you have to account for the fact that you might be in the middle of a set of measurement data so you might need to wait for the next set to come in to start.

I have seen this instance, when commands are sent there are typically at least several lines still being read and occasionally has a portion of the measurement data with it. I had also attempted brute forcing the commands by placing in a while loop and waiting until the read returned the expected value. This seemed to work for a bit, but then still lead to consistent overrun, timeout, etc.. errors. 

If this is the case, you might need to have one actor that does nothing but run a continual loop of reads, and each time a termination character comes in it analyzes what it gets and sends it to another more specific actor depending on the content.  At a minimum, you would probably want  3 receivers... one for replies to commands, one for normal measurement, and one for data it can't interpret (for logging, error handling, or discarding, whichever seems the most appropriate).

I can attempt this today. Then I'm also working on piping the data out side of the actor framework because this is all part of a much larger VI, which I think would be accomplished by the secondary normal measurement reciever. 

If that's not how it works then perhaps I just skimmed the device docs too briefly, but it would explain why you only have moderate success at the lowest sample rate, because when it's that slow it has the least chance of messages and replies getting crossed between two code sections.

I'm attaching the device documentation here.

---

Thank you for your help. I will continue to work through this issue. 

[ASCIIWarrior]

---

@crossrulz wrote:

---

@Kyle97330 wrote:

If this is the case, you might need to have one actor that does nothing but run a continual loop of reads, and each time a termination character comes in it analyzes what it gets and sends it to another more specific actor depending on the content.  At a minimum, you would probably want  3 receivers... one for replies to commands, one for normal measurement, and one for data it can't interpret (for logging, error handling, or discarding, whichever seems the most appropriate).

---

For these situations, I have had a lot of success with just the 1 loop doing the reading and writing from/to the serial port.  My real library allows for filters on the read strings and send the replies through different queues.  Those queues can be used to talk to other loops ("actors") and let them parse the data and do whatever.  Of course, this depends on the instrument having a well defined outputs in order to screen for a normal read versus a reply to a command/query.

Ultimately, I need to see documentation on the instrument in order to really give any advice.  I don't see anything here that would allow me to point to a solution.

---

Hi Crossrulz, 

Thank you for your reply! I have attached the documentation on this reply as well. I believe it does have well defined outputs, though I have had quite the hard time with the expected commanded triggers. I attempted multiple ways of turning the measurement data transmission on and off and the end result was that the only way I can successfully stop data transmission is to close the serial channels. 

I do have a process to parse the data, but I was only seeing the active measurements returned in the actor.vi read buffer. So, I put my parser in that location, but need access to it outside of the actor framework. 

[crossrulz]

I still see no documentation on the instrument here.

If you are having trouble keeping up with the data coming in, you can change the timeout for the Dequeue to 0.  If there is no message, the queue will timeout immediately and you go straight to checking for data in serial buffer.

[ASCIIWarrior]

Apologies, I dropped the PDF on each of the replies, but still don't see either. 

Here is the link to the manufacturer's site for the manual:

Acuity Prima User's Manual 

Ok, it does seem like it's having trouble keeping up with the data coming in. I had it running at 400hz and there was a continuous overrun error. At 100hz it at least processes the data and will only occasionally have the overrun. 

[GerdW]

Hi ASCII,

uploading the PDF  works for me…

[crossrulz]

---

@ASCIIWarrior wrote:

Ok, it does seem like it's having trouble keeping up with the data coming in. I had it running at 400hz and there was a continuous overrun error. At 100hz it at least processes the data and will only occasionally have the overrun. 

---

Definitely lower the Dequeue's timeout.  At a 10ms timeout, the best rate you could theoretically keep up with would be 100Hz (a message every 10ms).  So I would go ahead and set the timeout to either 0 (timeout immediately) or 1 (wait up to 1ms to allow something else to act).