I am using the ICUSB23216FD with the latest FTDI driver installed.
i have software written in delphi that access the COM ports and reads and writes data on a 1 minute cycle time, it can read up to 16 ports at once and has been used by my company for years for simple data logging.
It creates the com port handle, the reads or writes to the com port.
The problem is that after a few days the com ports start failing with the error acces denied, this is on the call to the WriteFile, not the CreateFile.
I have never seen a failure like this before, so has anyone had issues with this product or anythign that uses the same drver.
Is there a buffer that gets ‘full’ and causes the com port to stop processing data after a time period?
Is there a problem with this product using all 16 ports at once?
The delphi software we have used for years with no problems but we previously used moxa hardware and drivers. It is pretty basic code that appears to do serial comms in a standard way.
Thanks for any assistance or suggestions on how to further debug this issue.
Hello @rhona and thank you for your interest in our Community.
I am sorry to hear about the issues you’ve been experiencing. For this type of situation, it would be best to perform comparative tests in order to isolate the potential source of the issue. For example: could we try accessing the ports directly through PuTTY to see if this is an issue specific to the custom software?
Furthermore, have we tried the same operation on a different computer?
And ultimately, what needs to be done for the issue to be (temporarily) fixed? Disconnecting and reconnecting our device, or does it require a full computer restart?
Thank you in advance and we look forward to hearing back from you!
it happens on at least 3 computers that are running the software and actually restarting the PC did not solve the issue, which makes me think its something in the startech as i didn’t remove power from the startech devices when i rebooted the PC. it seemed that the situation was recovered when disconnecting and reconnecting from the com port a couple of times within the software.
Unfortunately it is happening in a production setup and so i cannot do much debugging other than just get it running again. I am trying to get a test setup established where i can maybe run wireshark to see if that sheds any light on the issue. Is there any startech software that could be used for debugging?
Unfortunately, we do not have any debugging software. You’ve mentioned that the issue happens on at least 3 computers all running the software. Have you been able to test it on a computer not running the software? Mostly, we would like to see if you still get the problem on a computer not running the software. Do you still get the issue when testing with PuTTY or simply having the cards present? And one other question: do you only have or have you only tested with one of our ICUSB23216FD, or do you own multiple units?
Thank you very much for your time and we look forward to hearing back from you!
We have multiple startechs , some daisy chained and multiple PC’s. So worried that it is a problem that will affect lots of production.
It seems to be a problem when we are communicating on at least 8 of the 16 available ports at once. We unfortunately do not have 16 of our product to test with other than the ones that are in production. I am trying to get a test setup so we can load up the comms and see if we can get a failure in a test environment.
I have not yet run hyperterminal with constant comms running to see if we get the same error not using our software.
The software opens the comms port, keeps hold of the connection, then every minute sends a short message and gets a short response. it does this for up to 16 devices connected to the startech at a time. So the COM port is actually open for days, The COM port is closed either when manually disconnected in the user interface or when the software detects too many errors and it automatically stops comms on the port and closes it. This automatic stop on error is what is happening as eventuality we get the error access denied when we call Write file on the COM port handle that we previously opened.
At this point, the best would be to wait for the results when testing without the software as it would be important to isolate which direction we’ll need to troubleshoot: is this an issue with only the unit at the production location, is this reproducible at your location with a different unit, and is this an issue specific to the custom software or does it happen with any kind of usage?
Thank you very much for your time and we look forward to hearing back from you!
Hi, we have had this issue across a few devices and PC’s now. Can I ask a question about the wiring for RS232.
For each device connected to the startech 16 port unit, we have pins 2,3 ( swapped) and 5 connected.
If one of the device connected to the startech had a different ground voltage to that of the other connected devices and/or different to that of the startech, would this affect the comms? are the grounds within the startech isolated and so can be different or are they always expected to be the same for each port on the startech? and is the ground at each end of the cable expected to be common?
Would it be possible to please have a bit more detail about the context of this installation? For example, could I know what operating system you are using, what versions of the drivers are you on (from our web site or auto installed), as well as the brand and model of the serial device you are trying to communicate to please.
Thank you very much for your time and we look forward to hearing back from you!
Hi, I am using the ICUSB23216FD with the latest FTDI driver installed. Windows 10.
One PC, one startech plugged into a USB port, providing 16 com ports in windows device manager, one exernal serial device connected to one of the COM ports. Bespoke software sending a message every 60 seconds to the external device, device responds via serial 232. Cabling is using the startech cable.( all pins connected, pins 2/3 swapped).
Communication can run happily for several days, before our log files eventually show failures due to ‘Access Denied’ when trying the WriteFile function.
It appears that a comms ‘glitch’ on one serial port, takes down all the serial ports on the startech.
We have several similar setups and all exhibit this issue.
We also have setups that use two startech daisy chained, and we can have either one or 12 or so external devices connected. The issue occurs in all setups.
Would it be possible to confirm the driver version number, and if you’ve installed it from our web site or let Windows auto-install it? Also, may we have the make and model of the device you are trying to communicate to please? (as in, our ICUSB23216FD → {device} ?)
Thank you very much for your time and we look forward to hearing back from you!
The device we are trying to communicate to is an internal Product that implements the AK protocol. The Product is old and we have used the same bespoke software with it for years. We previously used Moxa usb to serial com port hardware and now we are using Startech we are having this issue.
The driver version is FTDI 2.12.36.4.
It is the latest version according to yours and the FTDI website and it came already installed with the OS.
To answer one of your earlier questions: The grounds are shared. More specifically: all the grounds on all the ports, pin 5, and the chassis are all tied to GND. We have not tested any scenario where the grounds were at a different potential level.
Secondly, have you had the opportunity yet to test with PuTTY (or other terminal application) what happens when you try to connect to a COM port that’s had the error?
And lastly: has this been tested on a different model of computer? And are we connecting each of the USB devices directly into a motherboard back-port or is this going through a USB hub of any kind? If so, please try without any hub or equipment between. You’ll also want to make sure to disable any USB power saving option.
Thank you very much for your time and we look forward to hearing back from you!
Hi,
I checked the usb power settings and none were set to power save. We have not experienced the problem for a few months now, though have not actively changed anything to fix the problem. It is still a mystery as to what the problem is/was.
Thanks
Hi, Update on this issue, it is still happening and it appears to be related to if you touch a cable whilst it already has communication on one of the the other ports. It is also happening with just hyper terminal software. I am seeing Access denied error 5 and also error 997.
Once it is in this state it doesn’t recover and all communication on the device stops.
Is there a later driver that might solve this problem as at the moment it is a very unstable solution for us as the nature if our use is that we do need to connect and disconnect cables frequently whilst it is in operation.
Thanks.
[2024-05-13 09:30:51.911] [comport] [warning] Call WriteFile(m_handle, ptr, size, &m_writeBytes, &m_ovsend) (318) failed: Overlapped I/O operation is in progress. (997)
Hi, Update on this issue, it is NOT solved at all, it is still happening and it appears to be related to if you touch a cable whilst it already has communication on one of the the other ports. It is also happening with just hyper terminal software. I am seeing Access denied error 5 and also error 997.
Once it is in this state it doesn’t recover and all communication on the device stops.
Is there a later driver that might solve this problem as at the moment it is a very unstable solution for us as the nature if our use is that we do need to connect and disconnect cables frequently whilst it is in operation.
Thanks.
[2024-05-13 09:30:51.911] [comport] [warning] Call WriteFile(m_handle, ptr, size, &m_writeBytes, &m_ovsend) (318) failed: Overlapped I/O operation is in progress. (997)
using the power adapter provided, if we just used the usb supplied power not all COM ports appear in the device manager
no we have no tested swapping serial devices when user is grounded, this is not feasible as the devices are wheeled on a trolly to the cables we have preset up, we then plug the cable into the device. Is this recommended operation?
it happens with all of our serial devices of which there are a few different types, it happens with a loopback device, though the original problem that then cascades to affect all ports is probably one of our analysers
this did not happen with Moxa provided serial usb hubs.
the startech device does not fully recover until it is totally powered off and back on again, if you disconnect the com port and reconnect before it has been powered off it will resume communications again but drop comms an indistinct number of hours later. The only way to gurantee comms is to power off an don again and it will work until the next time anyone touches a cable. Note it is not everytime someone touches a cable , just occasionally and it is the nature of our use that we conenct a disconnect devices a few times a day and each device is connected for a few days at a time.
Would it be possible for you to test with a unit setup in your office, connected to a serial device, touch the cables and see if you get all the lights activated on the startech ports, then they all go out?
Also as it is not all the time this happens and they can go for months with no issues then it is really difficult to tell if the problem is solved or not.