LabView Serial Communication vs Terminal Program

[scoppi]

Hello,

I am having an issue using Serial Communication with LabView.  I am admittedly new to using serial communication, not just with LV but in general.  I have searched the net and forums and haven't yet come across a solution to this problem.  

I am trying to communicate with a Cypress PSoC chip over my PCs USB using a custom commands.  I am able to communicate with it using terminal programs such as SmarTTY and PuTTY but LV is not working.  I'm assuming this isn't necessarily an LV problem and more that the terminal programs are doing something in the background that I can't see.  I have tried adding termination characters at the end of my commands and have not gotten any results.  

Does anyone have knowledge about how a terminal program may differ from "standard" serial communication?  Any suggestions are greatly appreciated.

Thanks

[GerdW]

Hi Scoppi,

most probably the terminal program is appending a LineFeed or CarriageReturn (or both) to the command and so sends 5 or 6 bytes instead of the 4 bytes you sent in MAX...

[HorseBattery_Stapleguy]

Do you have the same settings for both terminals? Stop bits, parity, baud-rate, etc.

In the MAX terminal there's options to define whether the termination character gets included in writes, and whether the reads stop when one is read, etc. Have you modified those yet?

Like GerdW said, you're probably missing the \r and \n (Carriage return) and (Line Feed) characters. Try disabling termination in the options, and adding the termination characters with codes manually. (And combinations of them)

[scoppi]

All serial port settings are the same.

I've tried enabling and disabling the termination characters and then adding them myself.  I've tried them individually as well as together.  Same results.  The information is not being read properly.  Every now and then I will get a "command is not recognised response" (which is a response I programmed in the PSoC) or a "The command exceeds the size allowed", which I don't understand.  I can't seem to find a pattern as to when these responses are given and not.  I can hit Read/ Write or Query without changing any settings and get different responses.

[HorseBattery_Stapleguy · Accepted solution]

---

@scoppi  ha escrito:

All serial port settings are the same.

I've tried enabling and disabling the termination characters and then adding them myself.  I've tried them individually as well as together.  Same results.  The information is not being read properly.  Every now and then I will get a "command is not recognised response" (which is a response I programmed in the PSoC) or a "The command exceeds the size allowed", which I don't understand.  I can't seem to find a pattern as to when these responses are given and not.  I can hit Read/ Write or Query without changing any settings and get different responses.

---

Hmm, maybe it could be that it handles one byte at a time.

Try with this: Serial Write One Character at a Time. - NI Community

[crossrulz]

---

@scoppi wrote:

I am trying to communicate with a Cypress PSoC chip over my PCs USB using a custom commands.  I am able to communicate with it using terminal programs such as SmarTTY and PuTTY but LV is not working.  I'm assuming this isn't necessarily an LV problem and more that the terminal programs are doing something in the background that I can't see.  I have tried adding termination characters at the end of my commands and have not gotten any results.

---

So where's the LabVIEW code for us to examine?  MAX is not very good at debugging a terminal, especially when many lines can be returned.

For some good references, might I suggest a shameless plug: VIWeek 2020/Proper way to communicate over serial

[scoppi]

Writing one bit at a time did the trick.  Thanks for the help.

I actually looked at that video the other day while trying to troubleshoot on my own.  Thanks!

[RavensFan]

---

@scoppi wrote:

Writing one bit at a time did the trick. 

---

"Byte" not "bit".  Those two words have very specific meanings that you shouldn't confuse.