Has anyone else had problems getting Xojo to communicate reliably with Prolific 2303 chip based USB-RS232 serial adapters?
I occasionally hear from customers that my software will not communicate with their device - in my case it is an astronomical video camera, always the same make and model. The serial port is detected in the application, and apparently opens correctly, but no serial communications occur, in or out.
The weird thing is that if the user runs the basic software which ships with the camera (written in a different language), it works just fine, and then if they immediately close and run my software it will often start communicating perfectly.
I’ve been able to narrow the problem down to the Windows build of my app (XP/7/8 doesn’t seem to matter) and a USB to serial adapter based on the Prolific 2303 chipset. Like I said, programs developed in other languages seem to be able to initialize the port correctly and (in many cases) will leave the port in a state where Xojo can then communicate over it.
It seems to be an issue with the way that Xojo is initializing the serial port. Has anyone else seen this type of issue?
When you say it does not “communicate reliably” what exactly do you mean? Are you checking for errors upon opening the port? Is there some initialization code required to get the device to come alive and talk, what is the protocol for establishing communications? Could it be a timing issue, etc. It is difficult to determine without seeing some code…
Have you considered writing a quick app to monitor communications between the software that ships with the device and the device itself to see if you are missing something?
I don’t have experience with the Prolific 2303 but I have used EasySync in numerous applications without issues.
Check the POWER settings. Windoz has a nasty tendency to turn off, or brown out the USB device. This started rather slowly but as MS added more and more power control (and of course Intel gave the OS access to all of the power rails), this became more and more evident over the last 5-7 years.
In Win7, Windows appears to mostly respect the settings. However they can revert back to default, on occassion, when the OS is updated. With XP, it was disrespected and reverted to MS defaults much more frequently.
In any case, this what we found/did to solve the problem.
Tim
I appreciate both of your responses, but this is clearly a Xojo problem. Joseph, yes there I’m doing plenty of error checking and nothing is unusual about how the port is being opened. Remember that this works for almost all of my customers, and for the ones where it doesn’t work, software written in VisualStudio using the exact same communications technique works just fine.
When this first started surfacing about a year ago I thought that it might have something to do with how Xojo was handling hardware handshaking so I even explicitly set Serial.CTS and Serial.DTR to False thinking that there might be some HH loop through in the DB-9 connection on the computer end, even though the camera uses only three wires (TX/RCV and GND).
For ALL of the people who had problems, switching serial adapters would eventually fix the problem, but also for ALL of them the VisualStudio app would communicate just fine with their original hardware setup.
Are you using RTS at all? If so, then it is definitely a Xojo problem. I reported an issue with this several years ago and it STILL has not been fixed. I had to develop new hardware to automate RTS rather than using software…
If you are only using TX/RC & Ground it can’t get more simple. Because this is only isolated to a few devices I assume you cannot test the actual condition and am working blind? Is the issue receiving data or sending?
Although this is a total guess I will describe a situation that I had, perhaps it will help, perhaps not. BUT if your software is requiring receiving specific data then it might be useful:
I will say that I have had issues with the serial.DataAvailable event. The issue here is that there is no documentation on how many bytes or the timing related to that event firing. So let’s say you need to receive the command “Ready” from the connected device before you send back a command. The Serial.DataAvailable may fire when “Re” is received, you go to do a "Serial.ReadAll and don’t recognize it or ignore it. Since you read the buffer it clears it, then you get another event and get the “ady” and again you ignore.
What complicates this is going through a USB to RS232 device, because you don’t really have control over the timing, etc.
What I did is just read all the data and store it, I then append any new data received and append that to the previously stored data, I then search my new saved data for valid received data, then act accordingly on that.
The VisualStudio project may do a better job of firing the receive event.
Anyway, just an observation I have seen, hope it might help.
Joseph and Tim, it’s not a problem with bytes getting dropped or timing, no data is going in - or out - of the port. It’s almost as if the HW handshaking settings weren’t being honored. The odd thing is that it works for most of my customers, but for those where it doesn’t work, the only solution (so far) has been to suggest that they purchase a different USB to Serial Adapter that Xojo can manage correctly. It’s a bit embarrassing since, like I said, the Visual Studio app has no problems at all. I suspect that there is something in the Windows serial API that isn’t getting initialized correctly when the port is opened.
Thanks Bob, I wish that it was a driver issue, but alas even with the absolute latest Prolific drivers, the problem happens. Plus, a driver issue wouldn’t explain why the device would work perfectly with a VS app and then fail to communicate with the Xojo one.
I was just hoping that someone who has written a communications intensive application in Xojo might be able to corroborate this issue.
I’ve worked mostly with embedded applications and we stay away from any USB dongle with a Prolific device. When we started having issues we traced it back to these devices. You can search on the WEB and will find many stories like yours (and none that I remember had any mention of XOJO). Again, we have pretty much control of the build of our embedded application, so now we are pretty standardized in FTDI devices (and we also use some cheap east asia clone which works just like the FTDI one).
If I would venture to guess why VS may be more tolerant it is perhaps because I think the serial functions work directly with the low level hardware layer, and I believe XOJO utilizes some higher level functions (available through Windows still, but I don’t believe are low-level enough).
EDIT: This is not to say the Prolific devices are junk. They work, but in our experience they seem to be not as tolerant as other device manufacturers. Maybe you can play with the buffer settings of the device (in the device settings).
I did a lot of investigation into this when I had the problem (2010). Xojo is using the standard USB API. Visual Studio is using something different and is intercepting the serial port calls at a level that is much closer to the hardware where Xojo is doing it much farther down the chain.
I fought this problem for several weeks convinced that it was a Real Studio problem. Finally, after searching and reading about all the problems that Prolific has I found several websites that had newer drivers. Problem went away IMMEDIATELY. On another machine that was having the same problem I used a different serial to USB converter (forget which manufacturer it was but they were big in the Mac market) and the problem went away IMMEDIATELY.
I just updated this project last week (so it’s fresh in my mind). The drivers I found in 2010 did not work in Windows 8 nor in Mavericks. Again, I did the searching and found beta drivers (not from Prolific but from the branding put on the cable).
Bottom line is that Prolific sucks. Avoid them if you can.
I agree that Prolific devices tend to be problematic. I think part of that has to do with the fact that their USB-Serial chipset has been cloned and there are many non-standard versions of it out there. Take a look here about half way down the page.
Unfortunately the US camera distributor, by default, ships these devices with Sabrent (Prolific 2303 based) USB to Serial adapters, so that’s what most of my customers have. I’m completely with you in recommending FTDI based devices (or Keyspan - now Tripp Lite).
Hopefully in a future update to Xojo they’ll get this figured out.
[quote=60327:@Tim Seyfarth]Bob,
why is. xojo using USB when it should be using serial for serial control… did I miss something here?
Tim[/quote]
Um…because most computers only come with USB ports and not pure serial ports. Therefore the OS is using the drivers that Serial to USB device manufacturers provide.
Keyspan worked like a charm the instant I plugged it in on Mac OS X and Windows. Prolific sucks.
I maintain that this is not a Xojo problem. They are simply using the information the driver provides. Since the internet is filled with Prolific complaints, again, I can’t fault Xojo. And from my own experience, you get a new driver (that works) and the problems go away.
I feel your pain. I beat my head up against a wall for weeks on this. This is not a Xojo problem. If it was, the internet wouldn’t be filled with complaints.
[quote]I maintain that this is not a Xojo problem. They are simply using the information the driver provides. Since the internet is filled with Prolific complaints, again, I can’t fault Xojo. And from my own experience, you get a new driver (that works) and the problems go away.
I feel your pain. I beat my head up against a wall for weeks on this. This is not a Xojo problem. If it was, the internet wouldn’t be filled with complaints.
[/quote]
I’m not arguing with you Bob, but I disagree that it’s not a Xojo problem, otherwise how can you explain running a VisualStudio app first with no communications issues, and then running the Xojo app on the exact same machine and nothing happens. It’s not a timing issue. The initial communications with the camera is a simple ENQ/ACK handshake. I send the ENQ (actually I send one every 5 seconds until I get an ACK) and no response is ever received. Unfortunately (or fortunately) it’s rare enough that I’ve never been able to reproduce the problem on a Windows VM, so I can’t put a signal analyzer on it to see what’s really going on. Like I said, I think that it has something to do with how Xojo is initializing the serial port.
That said, your assessment of Prolific is dead on.
The two are using different API. Visual Studio is not using the same API that Xojo is using. I had this discussion with a Real Software engineer at the time and we spent a lot of time looking at it.
Thats what I was afraid of. Oh well, I’ll just keep suggesting that people purchase a different serial port adapter.
Sorry I won’t be able to get out to see you in Vegas at XDC Bob, it looks like you have some interesting presentations going on. Unfortunately it’s the week after Chico State’s spring break and, even though the students would love it, I just can’t get away. Hopefully next year.
William,
If you look at it with a scope, there are funny things that happen - especially with rts. I was not using handshaking so I cannot attest to that, but definitely with rts.
@Bob
Using USB port is the whole reason for the adapter. But this means that xojo is not using a USB API, but a serial API.
Could be one, the other, or most likely both. FTDI is much better than the others, but I also know, as I wrote before, of other serial related issues within rs/xojo.