.NET framework and serial port issue 3F

[alejandromxl]

Hi, I'm trying to communicate to the serial port of my computer using the .NET framework (VISA sometimes gives some error and I need to restart the system, so I'm looking for another way to control the serial port), I am able to read the bytes out of the serial port, using ReadByte and BytesToRead methods (I was having some issues with the enconding when I was using the method Read() ), but now I ran into a similar; when I try to write to something to the serial port, it writes it correctly from 00 to 7F, but when I go further I always write 3F and not any value from 80 to FF.

I read about some enconding issues, but I haven't found a solution that I can use with LabVIEW (I'm using LabVIEW 7.1)

Do you know what can be the problem.

[billko]

I think your time would be much better spent learning how to communicate with the built-in VISA functions in LabVIEW.  It's so easy to use.  Have you checked out the LabVIEW examples included with your dev software?  Have you tried searching for a solution here on the forums?

[alejandromxl · Accepted solution]

Hi Bill,

I've been working with the built-in VISA functions, but even though they work fine and are easy to work, every now and then I had some strange behaviours and I need to restart the system, I read that is normal, but I was looking for a different approach because apparently with the .NET environment it is more stable.

Anyway I already found a solution using comPort.Enconding = system.text.encoding.getencoding(28591), and for finding the secondo term in LabVIEW you need to look for it from the .NET block itself (otherwise you need a constructor from the System.Text class which does not exist for that term).

Any way thank you for the response

[billko]

---

@alejandromxl wrote:

Hi Bill,

I've been working with the built-in VISA functions, but even though they work fine and are easy to work, every now and then I had some strange behaviours and I need to restart the system, I read that is normal, but I was looking for a different approach because apparently with the .NET environment it is more stable.

Anyway I already found a solution using comPort.Enconding = system.text.encoding.getencoding(28591), and for finding the secondo term in LabVIEW you need to look for it from the .NET block itself (otherwise you need a constructor from the System.Text class which does not exist for that term).

Any way thank you for the response

---

I respectfully submit that, with proper coding, LabVIEW VISA drivers will be as stable, or even more so, than running an end-around LabVIEW, because LabVIEW gives up control of the app and will politely wait for control to be returned to it... and if something happens to prevent LabVIEW from assuming control again, you'll be left with an unresponsive application - with no clues as to what happened.  Since you are never leaving LabVIEW when using the LabVIEW VISA drivers, it will always return some kind of error code to let you know something happened.

If you look through the forums, you'll see that just about every issue a poster has had implementing LabVIEW VISA, it has been due to a lack of understanding on some level with communication concepts in general.  I've never heard of VISA-related restarts being normal.  Whatever gave you that idea?  Personally, I do TONS of VISA - GPIB and VISA - serial programming and have never run across "strange behaviors" that wasn't my fault!  😉