Very strange problem with a networked Brother MFC9140-CDN printer.
Some PCs on the network can reliably ping the printer which is on 10.0.0.203, however the majority of PCs sometimes get a response from the printer and other times get a timeout. In "Devices and Printers" you can sit and watch the printer change from Online to Offline and back again every so often, the majority of the time it is offline but occasionally for no apparent reason it will work for a while.
Related
I make this post because I didn't find the answer (I made some searches with tag Shutdown, Reboot and SSH).
Since fews months, I've got 2 Corals (out of 3) that shutdown unexplicaly and then become unreachable.
When this occur, I'm forced to go the device (the serial connectivity doesn't work either and the fan doesn't works at this time), unplug and then re-plug the power in order to be able to reconnect through SSH.
What the best thing to do ?
Thanks a lot.
I've seen similar behavior with low power. Be sure you are connecting your board to a 2-3 A power supply. A couple indications that this might be your problem are:
Your board is connected to your computer USB power
Your board runs fine until you load it (i.e. start inferencing on the TPU)
That's the first things I would look for.
My company recently started installing IO modules to production machines to capture data to our database. To do so we outsourced a 3rd party programmer to create an IO pulling software to draw data from IO module to a database in a collector PC.
The IO pulling software is running on the collector PC and will continue to draw data from machines into its local database for as long as the software is left open. No data will come in if the collector PC is shut down or the software is turned off.
The program works well but there was a bit of an oversight. If a machine gets unplugged or disconnected from the network (connection made via Ethernet cables), an unhandled exception error will appear for the pulling software for that particular machine.
Clearly its due to there being no connection and clicking Continue will solve this problem. But I'm afraid it will affect the quality of the data captured. Also our contract with the programmer who made this expired, so I'm the one who has to fix it.
The program was done in VB and I was thinking of just adding a procedure into the code to automatically bypass this error or at least tell the program to automatically select Continue and move on without human intervention. As I'm new to programming I'm not sure if my approach is even possible. Any ideas?
I took over a GUI which has the purpose to communicate on USB (via a PEAK USB/CAN device) with an Electronic Control Unit. The problem is that, sometimes, when some Windows events take place (take the PC out of the docking station/ take the monitor out of the laptop, sometimes when plugging in a USB mem stick), my GUI (MainForm) gets stuck/ freezes in the background without any possibility to access it with the mouse, keyboard or from the Task Manger (only close it but not bring to front) but it is still working and updating values received from the PEAK system via USB.
Can you help me with this issue, please? Take into account that this project was not started by me I just took over in order to update it's features when the guy left. Can this issue appear due to the PCAN drivers? Can I find a work around?
this may be a simply question but I hope its not.
I run some very long winded SQL operations on my local PC, which is hard wired to an ADSL modem for internet. The SQL Server and databases are ALL local on my PC, and the processing seems fine. (as fast as normal).
However, if my internet drops out - which happens perhaps a few times a night (at later hours usually), my SQL connection also drops with the familiar Connection lost error. (An error one would get if connecting to SQL over a network)
For me this does not make sense, my SQL connection string refers to the local instance only and no processing is over a network of any kind (I have VPN sometimes active, but not always when this happens)
I can run the same SQL processing without the modem connected with no issues at all. (Although sometimes it can take many many hours so I prefer to have the modem connected)
Could this possibly be due to the extra SQL Services ie Browser - that is somehow affected by the modem losing its internet connection?
(I would like to know that my ISP-provided modem is not doing any funny business in the background - like examining my data / traffic / etc)
Any help appreciated
Try this connection string:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Initial Catalog=DATABASE_I_USE;Data Source=127.0.0.1\INSTANCENAME
This should force the traffic onto the loopback adapter, which will allow it to avoid cases where your physical card's network link may drop.
If that does not work, try explicitly installing a loopback adapter.
One of our current milestones on our (open source) project at the moment is to complete USB support, and as such we're working hard on drivers at the moment. Our current development focuses on EHCI on both x86 and ARM (OMAP35xx SoC specifically, EHCI-only in the silicon of the board). We have mostly everything running smoothly in a variety of emulators - VMware (free and non-free versions), QEMU, and VirtualBox.
When we do testing on real hardware however, we get absolutely nowhere. The basic routine for device enumeration in our system goes something like this:
Turn on port power (if the option is available) and wait for power to stabilise to the device
Perform a port reset (held for 50 ms) and then wait as long as needed for the reset to complete (while loop)
If the port has a device present, and is enabled, notify the system that a new USB device is available for initialisation.
Send the SET ADDRESS command to assign an address to the device. This is where we run into problems everywhere:
The SETUP transaction for this command completes without error
The zero-length IN transaction (status phase) throws a transaction error, halts the qTD, and disables the port.
Our timing delays are basically the same as Linux's driver (if anything, longer).
According to the USB 2.0 specification, this behaviour is a "Port Error" (section 11.8) but to be completely honest I don't see how to translate its description of a port error into a working solution for our driver. As we are an open source project we also don't have the money to go out and purchase a proper hardware USB protocol analyser to investigate exactly what's going on on the line either.
Has anyone faced a similar problem and knows a solution?
We have identified the cause of this problem has been a timing issue, but in our case the issue was too much of a delay.
By modifying our qTD/QH creation code to create a single QH with multiple linked qTDs associated with it, we've been able to get successful runs on physical hardware.
We also had to use te EHCI 64-bit data structures, which had not been implemented previously.