Instrument Control (GPIB, Serial, VISA, IVI)
USB to 232 serial communication issues Mass Flow Controller
Solved!
I have been having issues troubleshooting serial communication from a MKS mass flow controller, MKS647C, which had been using a software handshake to communicate through a serial to USB driver. There are lots of unknowns for me here, like why is the prolific driver randomly appearing with "THIS IS NOT PROLIFIC PL2302" when yesterday it had been appearing fine. The issues with this setup occurred to the best of my knowledge when there were updates on the computer six months ago and I had to reload the driver setup. The instrument says its making use of XON/XOFF which i took from the manual to be a software handshake. Is there more settings I need to configure in device manager? I have tried reinstalling serial drivers but no luck. Any guidance on how to go about troubleshooting this would be very helpful. I have never encountered the Ni-Max error that it has found the correct resource but cannot open a VISA session, and I looked through this forum for similar errors but found none of their steps to be applicable.
@Andy_7 wrote:
What ended up working for me was: Replacing the USB to serial cable. Turns out it was a very old prolific USB to serial, which was part of the reason it would show up strangely in Device Manager. Took me a while to get there because I thought the issue would be in the driver or LabVIEW layers. Lesson learned to not take old adapters for granted!
Anecdotally, I hear a lot of complaints with Prolific based USB-RS232 adapters. However, I have had a lot of success with a specific prolific adapter (I am unable to find the model number at the moment). Most people seem to really like FTDI adapters. Personally, I have had the most success with adapters from StarTech, such as ICUSB2324i which are based on a TI chip. Granted, I get the industrial-grade adapters, so they are pricey.
I’ve recently been trying to control the MKS 647C remotely via my computer, but since I’m new to serial communication, I’m having some trouble and could use some help.
According to the 647C manual (https://www.mks.com/mam/celum/celum_assets/resources/647Cman.pdf, page 30), I connected the 647C to a USB-RS232 adapter (ICUSB2324I) with a a customized serial cable, and then plugged the adapter into my computer via USB. The 647C is supposed to automatically detect the communication type based on the cable. But after I connected everything, I noticed the RS232 status showing errors like FE, PE, and OE. I’ve double-checked the settings on both the computer and the 647C, and both are set to the same parameters with flow control set to None, but I’m still seeing these errors. I’m wondering if I need to install any specific drivers for the 647C on my computer, and how I should set the communication parameters for both the 647C and the computer depending on the cable type.
Also, I noticed the LabVIEW Plug and Play Instrument Driver for the 647C is no longer supported (https://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=9AC4F43A67732360E04400144F1EF...). Do you happen to have a copy of it that you could share with me?
@JohnEx2025 wrote:
I connected the 647C to a USB-RS232 adapter (ICUSB2324I) with a customized serial cable and then plugged the adapter into my computer via USB.
After double checking the communication parameters (baud rate, parity, etc.) that cable would be my next suspect.
Also, I would do my hardware debugging with a terminal program like Putty. It is a way to isolate your code from the list of issues. Once you have proven you can send the messages and the device properly responds, then start looking at your code.
@crossrulz wrote:
Granted, I get the industrial-grade adapters, so they are pricey.
While this is no guarantee that everything will always work fine, it is one of the bigger factors for sure. Most people try to use the low cost adapter they got in some more or less seedy store and is often just a cheap knockoff of an industrial grade controller chip. The chip manufacturer often tries to surf on the success of the original manufacturer by providing a chip that looks and theoretically works like the original at a fraction of the cost. Trivial to be cheap if you don't invest anything into software driver development and maintenance, because your chip is supposed to be compatible with the industry standard and can use its drivers. Except that the original manufacturer isn't very thrilled about that and of course sooner or later updates their drivers to work better with their own hardware and intentionally or not makes it incompatible with the knockoff hardware.
.PNG){kind=link}
@rolfk wrote:
Except that the original manufacturer isn't very thrilled about that and of course sooner or later updates their drivers to work better with their own hardware and intentionally or not makes it incompatible with the knockoff hardware.
I've even heard stories of FTDI putting in code in their driver to actually destroy counterfeits.
But to your first point, you are correct. You often get what you pay for. I go for commercial grade because I need the reliability in my test setups. Startech has also repeatedly earned my trust, so I often go there for adapters. Yes, it is pricey. But compared to the thousands of dollars I drop on test equipment, especially good RF test equipment, it is a drop in the bucket.
@crossrulz wrote:
@rolfk wrote:
Except that the original manufacturer isn't very thrilled about that and of course sooner or later updates their drivers to work better with their own hardware and intentionally or not makes it incompatible with the knockoff hardware.I've even heard stories of FTDI putting in code in their driver to actually destroy counterfeits.
But to your first point, you are correct. You often get what you pay for. I go for commercial grade because I need the reliability in my test setups. Startech has also repeatedly earned my trust, so I often go there for adapters. Yes, it is pricey. But compared to the thousands of dollars I drop on test equipment, especially good RF test equipment, it is a drop in the bucket.
From what I remember it wasn't just stories but they really updated the driver to intentionally brick the non-genuine chip on such adapters. However they quickly came back on that as it was legally a very shaky thing to do. You can't just brick someone else hardware on a whim as it is still destruction of their property, even if that broke in on your copyright.
But nobody can forbid you to make your software NOT support a competitors product, so they still try to detect counterfeit chips but simply make the driver fail to properly work for such hardware.
