Serial port with Labview, RTS, DTR

[LLindenbauer]

At this point, trying System.IO.Ports.Serialport https://docs.microsoft.com/en-us/dotnet/api/system.io.ports.serialport?view=dotnet-plat-ext-6.0 seems to be worth a shot and the simplest way to go.

Wire (or Trace) manipulations only apply when there is a physical wire at all. There may well not be one.

[JÞB]

---

@LLindenbauer wrote:

Wire (or Trace) manipulations only apply when there is a physical wire at all. There may well not be one.

---

Trust me, there is a physical RTS conductor somewhere.  Serial over FC is not ready for market yet. 

Spoiler

(I really had to go there)

[rolfk]

I did the test and can confirm that even the "Load from Configuration" option on VISA Open unfortunately doesn't help. Those RTS and DTR toggle IRPs are still sent to the serial driver. I wish Dan Mondrik or someone of his caliber still would work in the VISA development team. He would likely long ago have solved that by at least allowing the "Load from Configuration" option to respect the "No Flow Control" setting for that port configuration or even better added an extra flag to the VISA Open option to not try to toggle any modem control lines on port initialization.

[THBU]

Thank you very much Rolf, for your effort of testing this.

[THBU]

Thank you for the suggestion to use System.IO.ports,  LLindenbauer.

However, the simple connectivity to hardware through VISA is one of key advantages of Labview, so I really do not want to work around this by using the Windows-based access to the serial port.

[LLindenbauer]

@THBU wrote:

Thank you for the suggestion to use System.IO.ports,  LLindenbauer.

However, the simple connectivity to hardware through VISA is one of key advantages of Labview,

Using the .NET port is not that difficult. I recommend giving it a try. The VISA functions practically have 1:1 correspondence with .NET functions and you can even reuse the wire.

---

@JÞB wrote:

---

@LLindenbauer wrote:

Wire (or Trace) manipulations only apply when there is a physical wire at all. There may well not be one.

---

Trust me, there is a physical RTS conductor somewhere.

We don't yet know the device in question here. Microcontrollers do have USB peripherals and are able to emulate the serial port in firmware. Arduinos have been mentioned, some of which have such emulated ports.

Spoiler

Imagine, if you will, a serial converter chip as two halves:

USB-to-Chip and RS-232-to-Chip.

Remove the RS-232 component, remove its trace and wires.

The device still talks like a USB-to-Serial converter,

but there is no Wire, there is only Chip.

[rolfk]

---

@THBU wrote:

Thank you for the suggestion to use System.IO.ports,  LLindenbauer.

However, the simple connectivity to hardware through VISA is one of key advantages of Labview, so I really do not want to work around this by using the Windows-based access to the serial port.

---

Unfortunately since NI-VISA is closed source and we can not make modifications to it ourselves, there really seems no other way than to use an alternative route. Of course only if that RTS/DTR toggle annoys you enough to actually consider making that effort. 😁.

Even if someone at NI would go and make that modification right now, it would be many months before you can download such a new driver. And it could not just be a simple removal of that toggling altogether, since this existed for about 25 years in NI-VISA and simply removing it would create 200% for sure compatibility problems with some existing users of NI-VISA where devices suddenly don't work anymore after installing the new version. NI-VISA is a huge project in itself and has accumulated quite a bit of legacy behaviour over the years that NI can't just throw out of the window on a hunch. The safest solution would be to add an extra option to the viOpen() access mode but that is an API change that has additional implications as it needs to propagate to other software projects including LabVIEW itself which would need to add that option to the according enum typedef. Not that it would be impossible to specify this new flag otherwise in an existing software as that flag is simply an integer value, so it is not a breaking issue but still.

[JÞB]

---

@rolfk wrote:

---

@THBU wrote:

Thank you for the suggestion to use System.IO.ports,  LLindenbauer.

However, the simple connectivity to hardware through VISA is one of key advantages of Labview, so I really do not want to work around this by using the Windows-based access to the serial port.

---

Unfortunately since NI-VISA is closed source and we can not make modifications to it ourselves, there really seems no other way than to use an alternative route. Of course only if that RTS/DTR toggle annoys you enough to actually consider making that effort. 😁.

Even if someone at NI would go and make that modification right now, it would be many months before you can download such a new driver. And it could not just be a simple removal of that toggling altogether, since this existed for about 25 years in NI-VISA and simply removing it would create 200% for sure compatibility problems with some existing users of NI-VISA where devices suddenly don't work anymore after installing the new version. NI-VISA is a huge project in itself and has accumulated quite a bit of legacy behaviour over the years that NI can't just throw out of the window on a hunch. The safest solution would be to add an extra option to the viOpen() access mode but that is an API change that has additional implications as it needs to propagate to other software projects including LabVIEW itself which would need to add that option to the according enum typedef. Not that it would be impossible to specify this new flag otherwise in an existing software as that flag is simply an integer value, so it is not a breaking issue but still.

---

You could post the desired behavior change over to the Idea Exchange. 

Of course that may have unexpected results for developers in Austin.   Luckily,  the headquarters is only 7 stories tall and VISA developers should be confined in a windowless sub basement area with padded walls and medicated anyway.

The VISA working group and IVI Consortium might agree to that modification in a decade but, I'd put better odds on a girlscout peewee league winning a Hells invitational hockey tournament. 

NI just cannot go and change behavior of NI VISA in ways that are not approved in the VISA standards and IVI build on VISA so every VISA hardware device may be impacted.  200% chance of compatability may be statistically impossible but, I don't think there is a machine epsilon small enough to make the calculated odds less than 1.

[rolfk]

---

@JÞB wrote:

NI just cannot go and change behavior of NI VISA in ways that are not approved in the VISA standards and IVI build on VISA so every VISA hardware device may be impacted.  200% chance of compatability may be statistically impossible but, I don't think there is a machine epsilon small enough to make the calculated odds less than 1.

---

200% odds was my tongue in cheek way of saying that it is actually guaranteed to hurt someone somewhere, and that someone might be not a person trying to interface to an Arduino or similar (with close to 0$ revenue for NI) but an employee of a company that buys many million $ per year in products from NI.

[JÞB]

---

@rolfk wrote:

---

@JÞB wrote:

NI just cannot go and change behavior of NI VISA in ways that are not approved in the VISA standards and IVI build on VISA so every VISA hardware device may be impacted.  200% chance of compatability may be statistically impossible but, I don't think there is a machine epsilon small enough to make the calculated odds less than 1.

---

200% odds was my tongue in cheek way of saying that it is actually guaranteed to hurt someone somewhere, and that someone might be not a person trying to interface to an Arduino or similar (with close to 0$ revenue for NI) but an employee of a company that buys many million $ per year in products from NI.

---

Of course my sympathies lie with those medicated developers in the padded cells that have delivered improbable code too many times.  

I'm doing better now.