So bear with me while I explain the problem. I have a device that we connect to via USB port. Xojo recognizes the serial port and I can write to it. However, the device never responds. The only thing I know I have to do is set RequestToSend = false when I’m opening it up (more on this in a bit).
After going round and round with the vendor on possible causes he sent me a test utility made in .NET that simply looks at the properties of the serial port and my app then connects and communicates just fine. If I use their utility (again presumably written in .NET) used for Factory Acceptance testing and quit it, my app connects and communicates just fine as well. If I restart the Win 10 64 bit computer my app no longer communicates with the device. I must use one of their utilities first before I can communicate with the device.
Obviously this is not an acceptable solution. If I have to resort to creating a small .NET app that I call when starting my app I can but that seems silly.
I have tried every possible combination of Serial properties so I’m starting to think it’s something lacking in the Xojo Serial Class that’s causing the failure. Does anyone have any insight into this issue? Recommendations? Naturally, I’m onsite with the client.
Well ive played alot with different settings RTS CTS and such, i bet if you try a different combination it will probably work. You might be able to find the settings in the windows device manager properties of the com port.
I will reiterate this again: If the .NET utility apps simply connect and quit my app starts working with no setting changes. That’s what’s so mysterious about it.
That doesnt instantly say the default settings are the same as xojo.
If the .NET app works, maybe you can decompile it and check what the working code is doing during connection and communication with the port, verses what your code is doing? It’ll mean deciphering some C#, but it’s not that hard to follow, usually.
A typical .NET app can easily be decompiled to view the original source-code, unless the developer deliberately obfuscated it.
There are several different .NET decompilers available (free or trial) that might suite your short-term purposes https://www.bing.com/search?q=decompile+.NET+app
I hope that helps. Good luck Bob.
This is the entirety of their app:
public partial class Form1 : Form
cmbPorts.DataSource = SerialPort.GetPortNames();
private void cmbPorts_SelectedIndexChanged(object sender, EventArgs e)
_port = new SerialPort((string)cmbPorts.SelectedItem);
private void btnGetSettings_Click(object sender, EventArgs e)
if (_port == null)
MessageBox.Show("No port selected");
//Iterate throgh the port's properties using reflection
foreach (var prop in _port.GetType().GetProperties())
string property = prop.Name + ": " + (prop.GetValue(_port) != null ? prop.GetValue(_port).ToString() : "NULL");
txtSettings.Text += property + Environment.NewLine;
catch (Exception ex)
I guess I’ll work up a similar app in Xojo to compare properties.
Yeah, the utility apps isn’t doing much.
If it helps, you can also look at the .NET source for System.IO.Ports.SerialPorts
Which is utilizing the SerialStream class. The constructor on this page might make more sense to you than me, given I’ve never done anything with Serial ports.
Here are the default values that C# sets the comms port to, maybe it will help:
private const int defaultDataBits = 8;
private const Parity defaultParity = Parity.None;
private const StopBits defaultStopBits = StopBits.One;
private const Handshake defaultHandshake = Handshake.None;
private const int defaultBufferSize = 1024;
private const string defaultPortName = "COM1";
private const int defaultBaudRate = 9600;
private const bool defaultDtrEnable = false;
private const bool defaultRtsEnable = false;
private const bool defaultDiscardNull = false;
private const byte defaultParityReplace = (byte) '?';
private const int defaultReceivedBytesThreshold = 1;
private const int defaultReadTimeout = SerialPort.InfiniteTimeout;
private const int defaultWriteTimeout = SerialPort.InfiniteTimeout;
private const int defaultReadBufferSize = 4096;
private const int defaultWriteBufferSize = 2048;
private const int maxDataBits = 8;
private const int minDataBits = 5;
private const string defaultNewLine = "\
If you have no luck, try installing Wireshark which has the ability to sniff USB traffic so you can see what the actual differences are, if any, between the .Net app and your app.
That should at least let you know what you’re missing on Xojo and/or if its a framework issue if you get the throughput the same.
I don’t know if this is related, but I’ve had connection problems using Windows, while the same app works fine on a Mac. For handling the serial interface connection, my app used the code from the Xojo serial port example, that included a listbox to show available serial ports. It appeared that if you unplugged the USB cable and then plugged it in again, Windows would add a new port number, but not forget the old one. So, there would be two (or more) port numbers for the same device, but only one would work. Since the code to update the serial port list was called regularly by a timer, the port list should have been current, but it wasn’t.
I found that to get the app to connect properly, I had to click on several different port numbers before it would finally connect, and the one that finally worked would not always work the first time I selected it. I might have to go back and forth a couple of times.
Doing a similar introspection app in Xojo hasn’t brought anything to light. Without setting anything it opens up that COM port at 57,600 baud, n, 8, 1. But whatever the .NET app is doing the Xojo app isn’t.
Does WireShark give you port settings? When communication works it works great. It’s that initial establishing of comms that doesn’t work.
Or, it could just be that Xojo Serial doesn’t work properly in Windows 10 without some help.
Anyone willing to do a quick .NET app for me that simply does the introspection of a given COM port in a console app?
I’ll give wireshark a go and let you know, I’ve not done a usb sniff in a while.
What happens if you connect with some other terminal app? Does anything show up? I guess where I am going with this is does it behave any different if you connect using Coolterm?
Did you solve the problem?
This was two years ago! And there were several solutions. The first is that with Julian’s help we created a little .Net helper app that did nothing but set the properties on the serial port.
Then at XDC 2018 I took the serial device with me and had William look at it. He discovered an very old bug in the serial port class that was changed in one of the 2018 releases and this project is on 2019 R1 or 3 (don’t remember).
So it was fixed for me two years ago.
I think it was fixed in feedback://showreport?report_id=51583 “Now honoring the Serial.RequestToSend property.” in 2018r2 but I can’t confirm as its a private ticket.