I often get ERROR_SEM_TIMEOUT errors using the WinUSB WritePipe function. This would seem to indicate that there is a timeout, but if I wait a period of time and try again I'm never able to write. I'm writing in 64 byte chucks to the USB device and often don't have problems. Once I start getting the error, I may have to unplug the USB and and close my app before trying again. Has anybody experienced this problem?
Related
I've been trying to send commands from a Raspberry PI 3 to an Arduino using the I2C bus with the Smbus library.
The code is written so you can send PWM value from the raspberry to the arduino to drive motors while the arduino is returning variables about motor speed.
The detection is working and the program runs several epochs until it crashes throwing Error 121 Remote I/O.
After lots of search on the web I tried to apply fixes to overcome the issue but nothing seems to work.
Python Code throwing errors
bus.write_i2c_block_data(0x13, 0, data) # Error 121 after a random runtime
block = bus.read_i2c_block_data(0x13, 0, numBytes) # Error 121 after a random runtime
I am exploring next solutions:
Force program to rerun on errors (smbus throwing error cause the whole script to stop)
Set i2c clock frequency
Use time.sleep in program to let the I2C commands completely execute
It seems that the connection become unstable when changes occurs to the motors (speed, direction), there is possibly noise from these charges on the circuit.
Is it possible to ignore error, flush the bus for extra informations and restart de process?
Thanks a lot for your help.
After more research I found a post on raspberry stackexchange pointing to the issue I faced.
https://raspberrypi.stackexchange.com/questions/104975/how-to-automatically-rerun-python-script-if-error-occurs
while True:
<all your code>
if <some error occurs>:
time.sleep(10)
continue
the proper statement is to use try and except IOError calling continue on error
while True:
try:
bus.write_byte()
except IOError:
continue
This ignore bus communication error and continue running the program. On next epoch the function will run again.
Looking for a way to clear the bus with left datas.
I am controlling a device over serial connection using LabVIEW (version 7.0). It is connected using USB, and is installed as a virtual serial port on the computer (running Windows XP). Every now and then my device crashes when my program sends a command, and it is unable to accept any more input (the device itself also stops working) until it has timed out.
I've looked at the serial port traffic using Portmon. Whenever the device crashes the serial driver sends the command I send using my program four times instead of just once, with an IOCTL_SERIAL_GET_COMMSTATUS command in between. I cannot see what this last command returns, but I assume something happens in the communication earlier on. I'm thinking my configuration of the port is not entirely right, but I have no idea how or why. I open and close the connection to my device every time I want to write something to it.
For completeness' sake: it has a baud rate of 9600, 8 bits, no parity, 1 stop bit, and no flow control. I'm aware that the correct settings of these parameters depend on the device, but the manufacturer has not supplied any recommended settings.
The driver is a DLL of some sort? If so, this is the most likely source of your problem, and you likely will need to contact the author of the driver. LabVIEW does have crashing bugs, but by far the most common source of crashes in simple communications apps is a buggy third-party DLL.
In other words, I doubt this is a LabVIEW problem at all and that you would have the same difficulty if you wrote a C program to talk to this driver. I only know what you've posted here about your system, but after many years of chasing down such issues, I would start with the device manufacturer/driver author.
If you have evidence to the contrary, please share.
I'm working on an Arduino Uno + ESP8266 project.
I try to use them as a web server on Wi-Fi network to control a motor that connects to Arduino - basically a trigger system that receives signals via Wi-Fi. Currently, I've successfully connected ESP8266 to my access point by sending AT commands from Arduino. Another client on the same network can statically access ESP8266's assigned IP address.
However, when I try to catch some HTTP queries (I want to use them as conditions to control the motor) I occasionally encountered the non-ASCII characters in HTTP request. I use serial comm to debug, please look at the screenshot in the link below:
Arduino - Computer serial communication for debugging
The line ",519:POST ..." should contain a complete number following "/?", but there's some strange characters instead. So I cannot determine the input data to control motor. Once in a blue moon, the expected format of request shows up as follows:
The correct data received
There's no issue with the HTTP response part, even though I got the uninterpretable request, I can still send the JSON error message back to client.
Attempt Note:
The Arduino uses different serial ports to talk to computer and ESP8266. Since the connection can be established, and the data being sent, I believe that the baud rate is simply correct on both side. (115200 for ESP8266, 9600 for computer - also tried 115200 for both and got the same result)
I use V3.3 from Arduino as power source for ESP8266. But I also use voltage regulator to smooth out the current as many people suggest that. The problem still remains.
I'm struggled with this issue for a few days, just want to know if anybody had the similar experience, or could give some clue for the next step.
After a considerable effort to stabilize the circuit, I switched to NodeMCU and got the system working perfectly. I assume that ESP8266 alone is somehow not robust enough without other components, which I unfortunately have no knowledge on.
So I'd like to close this thread with a short recommendation for anybody struggling with the same issue to switch to NodeMCU (which would replace both Arduino and ESP8266); if that could support the requirement.
I've been trying to establish serial (UART) communication between a Raspberry Pi Model B Revision 2.0 (checked the model like described on this page) and Arduino Mega 2560. I made a service on the Pi that writes to UART and then expects a message and a coworker programmed the Arduino with an echo program. While they were communicating, I had trouble receiving data, meaning that it was clustered in 8 byte pieces and I had to introduce a timeout for waiting between them (I was actually as much as available and calling select()for the next cluster but it turned to be 8bytes a cluster, except for maybe the last one. As explained in a question I found on this site, the programmer is the one to take care of the protocol and can not rely that the whole message will be ready to read at once (that is logical).
However, when I just connected Pi's TXD and RXD pins, no matter how much bytes I tried sending, it sends them in one go (I've gone up to a bit more than 256, that's more than enough for my purposes). I also have around 50 milliseconds of duration difference, measured directly from within the program, using gettimeofday() function.
So, could anybody clear things for me:
Why is this happening?
Is this difference in behaviour expected?
Is there a potential problem in either of the devices (if that can even be concluded from the given information).
Of course, any additional information is welcome, in case I forgot asking something that is deemed important.
Why is this happening?
I tried some time back communicating Arduino-Arduino and Arduino-Pi. I faced some problems with UART communication. However, you might want to keep same Baud rate on both the devices. With Pi, you might need to trigger an event if you receive data from Arduino. On the other side, if you code runs longer, then you might lose some data i.e. your Arduino code is running something else while Pi sends data over UART.
Is this difference in behaviour expected?
Yes. Arduino is a microcontroller based device while Pi is microprocessor based (runs on OS)
Is there a potential problem in either of the devices (if that can even be concluded from the given information).
I don't think there could be any hardware problem unless it is not functioning at all.
Also, because of this issues, I switched from UART communication to SPI communication. This solved my problem completely.
I'm writing a Linux program (using Qt 4.8 and libusb 1.0) which will communicate with a custom USB device (currently being programmed by a co-worker).
Step 1 is to have a "heartbeat" going back and forth over USB at regular intervals.
I'm currently using asynchronous bulk transfer.
For testing, I've put my "Send_Heartbeat()" on a button click. If I click on the button a LOT and queue up a number of messages to send, as long as I keep my queue busy, the messages keep sending and my USB device keeps receiving them.
If I stop for a few seconds, then resume and add more messages to the queue, the USB device stops receiving them.
BUT, my program's Transfer Callback DOES return with a transfer status code of 0, indicating success, even though my USB device isn't receiving them.
My questions:
Why does the callback's transfer status indicate success if my USB device appears to have stopped receiving them?
Has anyone heard of this type of behaviour?
It's worth noting that if I disconnect the USB device, I get proper status codes returned in my callback indicating that the device has gone away.
If the USB Device is left connected and running, and I "Detatch" and then again "Attach" to force a re-connection and try sending more test heartbeats, it works! The USB device starts receiving messages again.
My "Detatch" is the following calls:
libusb_release_interface()
libusb_reset_device()
libusb_close()
Then my "Attach" is:
libusb_get_device_list()
libusb_get_device_descriptor()
libusb_open()
libusb_set_configuration()
libusb_claim_interface()
My next step is to narrow down which of the libusb commands is re-establishing the communication.
Meanwhile, I'm hoping someone recognizes these symptoms and has a suggestion.
As it's my first time programming USB communication, I'm wondering if there is some fundamental which I've missed.
Thanks!
The issue is here I guess:
My "Detatch" is the following calls:
libusb_release_interface();
In your detatch, you need to attach kernel driver
detatch_kernel_driver();
libusb_reset_device();
libusb_close();
Then my "Attach" is:
libusb_get_device_list();
libusb_get_device_descriptor();
libusb_open();
libusb_set_configuration();
Here you need to check if the kernel driver is active or not. So,
check what attach_kernel_driver(); returns, and call detatch_kernel_driver(); if needed
libusb_claim_interface();