I am working on a application which uses serial port communication via USB to Serial cable, which uses FTDI driver.
My application has multiple threads, with different priorities.
Now the issue I am seeing is, when I connect/disconnect the cable, I have seen that the application's threads, whose priority is less than Normal, will be stuck, and will not respond, where as the normal priority threads will keep on working.
Now the questions are:
Is it possible to keep the low priority threads running.
If not, then is it possible to recover from this situation, by restoring the serial port. I have seen, that even if I try to recover the serial port from the high priority thread, then also the low priority threaeds will not start functioning.
Are you running with the latest version of the FTDI driver? The 1.1.0.20 release has fixes for "surprise removal".
If that doesn't fix your problem, then try breaking in to the application with the debugger or by writing a kdmp. See what threads in the system are actively running. If the thread that's blocking you is in the USB driver you may need to contact the manufacturer of your device and ask for an update.
Related
I have a c#/unity application which utilizes serial port to establish bluetooth connection with one device which then sends some data in real time back to the application.
The problem is, that sometimes, it seems like totaly random, but at least once a minute, serial port connection/data transfer speed drops dramatically, device buffer is filled an thus data is lost. Turning wifi on makes matters even worse but predictable. When I tur on wifi data transfer speed dropps emidiately but in cca 3 seconds grows back to normal.
Tryed the same aplication on another similar computer and it is a bit better - speed dropps less often, and also ona a android device where it dropps even more often, but picks up the slack almost right away.
Are there any serial port settings or Sistem settings that should I take into account. Is there a way to solve this problem in code.
thx
Without code samples in your questions it is hard to give a good answer.
But from the sounds of it you are probably getting interference on the 2.4GHz radio frequence that your bluetooth device is on.
Wi-Fi is perhaps the biggest and most problematic one, as are other Bluetooth receivers and devices, which can interfere with one another.
Microwaves , Direct Satellite Service, 2.4GHz and 5GHz phones, wireless speakers, external monitors, baby monitors, and any wireless device that talks over a 2.4GHz radio frequency can interfere with your signal.
Things you can do.
1) work in a quite RF environment. one with out a lot of other devices communicating
2) physical materials can cause all sort of RF issues. Reflections / Collisions. Try to remove any physical barriers that you are communicating though. Stay away from Fluorescent Lighting and Microwaves ( both emit 2.4 GHz )
3) move your devices closer together
Because this is run as a virtual com port there are no Serial Port or System settings that can positively affect this. Might have more luck implementing your own bluetooth device driver.
Ok this might be a vague question, but I'll try to keep it specific!
In C#, I'm running 1 server that listens for UDP sockets. The server runs a Timer object to monitor the client's last packet sent "time" to decide whether to forget it after 15 seconds.
For each of the UDP clients launched (in their own process / terminal), they ALSO run their own Timer object to send a packet every now and then (more or less to keep it alive).
Now, I ran a stress test and could "only" reach about 104 simultaneous UDP clients connections in their own terminals / command-line windows. After that, it just gives up and shows me this:
So, being new to network programming and all, I don't have a sweet clue which specific resource it ran-out off or what limit it reached to cause it to hang at that specific nth process. Makes it difficult to understand how some frameworks claim to reach >100,000 concurrent connections!
Now, if I was to take a few guesses, I'm thinking I've ran into a limit of:
UDP sockets?
Used up as much concurrent ports the OS allows?
Timers the OS can process? (I sure hope not!)
Too many terminal windows open, especially from the same process *.exe?
Thread-Locking the wrong parts / at the wrong time?
Maybe my tests are just wrong / poorly conducted? (Maybe instead of testing individual UDP clients in their own process, I should batch a few in the same terminal?)
For the more visual, here's basically what's happening:
I'm looking to interrupt network connection and or cause lag to the point where nothing will go through, basically clogging the line.
I'm making a "lag-switch" you could say.
I've tried using Windows Firewall API and blocking an application but that causes an instant disconnect rather than the lag I was hoping to achieve.
Original idea was to only block one application but I'm not sure how doable that is unless I can limit the bandwidth usage of said application so the latency would skyrocket. Blocking the entire local connection would be plan B.
Anything that immediately closes the connection will disconnect instantly.
I havn't tried anything else than blocking applications via firewall.
If someone could give me a kick in the back it would be real helpful!
I've found that sending tons of UDP packets to any address (say, 127.0.0.1) in a while loop with no delay causes immense network lag, but I haven't tested this in Windows.
I have a GPIB device that I'm communicating with using a National Instruments USB to GPIB. the USB to GPIB works great.
I am wondering what can cause a GPIB device to be unresponsive? If I Turn off the device and turn it back on it will respond, but when I run my program it will respond at first. It then cuts off I can't even communicate with the GPIB device it just times out.
Did I fill up the buffer?
Some specifics from another questioner
I'm controlling a National Instruments GPIB card (not USB) with PyVisa. The instrument on the GPIB bus is a Newport ESP300 motion controller. During a session of several hours (all the while sending commands to and reading from the ESP300) the ESP300 will sometimes stop listening and become unresponsive. All reads time out, and not even *idn? produces a response.
Is there something I can do that is likely to clear this state? e.g. drive the IFC line?
Since you are using National Instruments hardware you can run NI Trace in the background to check all the commands that is send out from the Program. In the Trace do check the last command and its parameters that is send out from the program that causes the hardware to hang.
You can download NI IO Trace here
There should be a clear command (something like "*CLS?", but dont quote me on that). I always run that when i first connect to a device. Then make sure you have a good timeout duration. I found for my device around 1 second works. Less then 1 second makes it so I miss the read after a write. Most of the time, a timeout is because you just missed it or you are reading after a command without a return. Make sure you are also checking for errors in the error queue in between write to make sure the write actually properly when through.
Even the command *CLS will not work if the device is not listening anymore (which might be the case here). The only way to force resetting the device's interface whatever its status (listening or not) is to send the low-level gpib bus message "Selected Device Clear" (it is implemented by the function "ibclr" of the standard gpib library, e.g. https://www.l-com.com/multimedia/manuals/M_USB-488.PDF page 3-7, but I don't know what is the equivalent in Python). This command is intended to be used whenever a GPIB error occurs, I'm always doing it and never had problems. For this to work well you should also monitor the return values of all gpib calls - usually people don't do it so they are unaware of errors until the program hangs.
I've written some C# code that checks whether a device is present on any SerialPort by issuing a command on the port and listening for a reply. When I just set the port speed, open the port, get the serial stream and start processing, it works 100% of the time. However, some of our devices work at different speeds and I am trying to probe for a device at various speeds to autonegotiate a connection as well as detect device presence.
When I do all this in a single thread there are no problems. However, 3s timeout at ten speeds is 30s per serial port, and there may be several. Hence the desire to probe all ports concurrently.
Sometimes this works. Sometimes Vista bluescreens. When I use threads to probe all the ports simultaneously it nearly always bluescreens. When I force everything to run in one thread it never happens.
A USB-serial Prolific PL-2303 adaptor is in use with x64 drivers.
#Vinko - thanks for the tip on reading minidumps.
As near as I can tell, the crux of the problem is that by starting a new asynchronous I/O operation from a different thread it is possible to give a whole new meaning to overlapped I/O, inducing a race condition inside the driver. Since the driver executes in kernel mode, BLAM!
Epilogue
Except for kicking off, don't use BeginXxx outside of the callback handler and don't call BeginXxx until you've called EndXxx, because you'll induce a race condition in driver code that runs in kernel mode.
Postscript
I have found that this also applies to socket streams.
Having written Windows drivers for one of these sort of device once, my advice would be not to waste your time with WinDbg trying to prove what you already know - i.e. that the driver you're using is buggy.
If you can find a more up-to-date driver from the PL2302, then try that, but my recommendation is that if you have to use USB->Serial adaptors, the FTDI-based ones are the best. (They're not the one I wrote the drivers for, either...)
You can also disable "Automatic Restart" under System Properties\Advanced\Start and Recovery\Settings. Once you disable that, you can see the BSOD and look for the error message, e.g. IRQL_LESS_OR_EQUAL, by searching for that error name, you can usually narrow down to the source of the problem.
Btw, not many notebook comes with serial ports nowadays, so you must be using USB-Serial converter? If that's the case, the driver might have been an issue to start with, since most manufacturer wrote the serial port driver as virtual driver.
BSOD usually means buggy drivers.
What kind of HW ports do you use? I've had BSODs with SiLabs CP21xx USB to Serial converters drivers.
There are FTDI drivers that are stable under x64 vista and win7. I second the person who said to use FTDI chipsets only.
Most of the cheap serial to usb dongles at the shops near me (Toronto, Canada) seem to be FTDI chips. It's never on the box, so I buy one, and if it's good, I go buy a box full of them.
W