Closed tatarize closed 5 years ago
Unplugging the device while it's running throws USB error 9: Status Request Failed. Pipe error. This error should be recoverable as no data was actually lost.
Unplugging to prevent error 9 in Status Request. USB error 4. Status Request Failed No such device(it may have been disconnected). Also, List
Turning device completely off triggers an USB error 4, status request failed. As well.
Disconnecting without reconnecting before the attempted recovery.
A problem getting status was detected. We will wait for the device. Device was not found. Attempting restart. Restart failed because: USB error 0: Device was not found.: Success Exception in thread "Thread-9" java.lang.IllegalArgumentException: handle must not be null at org.usb4java.LibUsb.bulkTransfer(Native Method) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb$1.run(K40NanoDriver.java:1571) java.lang.IllegalArgumentException: handle must not be null at org.usb4java.LibUsb.bulkTransfer(Native Method) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.update_status(K40NanoDriver.java:1638) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait(K40NanoDriver.java:1688) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait_for_ok(K40NanoDriver.java:1681) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Queue.execute(K40NanoDriver.java:1380) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.execute(K40NanoDriver.java:771) at com.t_oster.liblasercut.drivers.K40NanoDriver.sendJob(K40NanoDriver.java:250) at com.t_oster.visicut.VisicutModel.sendJob(VisicutModel.java:786)
Fixed null error. Holding pattern thread works too well. It weirdly recovers from being turned off. Thankfully in the streams of compactified commands there aren't useful commands but it could still be a problem. Better to fix channel without sending init ControlTransfer. After a poweroff this will keep it dead.
Trying to start the laser without the device on takes a good chunk of time before issuing:
org.usb4java.LibUsbException: USB error 0: Device was not found.: Success at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.findK40(K40NanoDriver.java:1740) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.open(K40NanoDriver.java:1481) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Queue.open(K40NanoDriver.java:1325) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.open(K40NanoDriver.java:468) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.open(K40NanoDriver.java:462) at com.t_oster.liblasercut.drivers.K40NanoDriver.sendJob(K40NanoDriver.java:99) at com.t_oster.visicut.VisicutModel.sendJob(VisicutModel.java:786) at com.t_oster.visicut.gui.MainView$65.run(MainView.java:2275) org.usb4java.LibUsbException: USB error 0: Device was not found.: Success at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.findK40(K40NanoDriver.java:1740) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.open(K40NanoDriver.java:1481) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Queue.open(K40NanoDriver.java:1325) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.open(K40NanoDriver.java:468) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.open(K40NanoDriver.java:462) at com.t_oster.liblasercut.drivers.K40NanoDriver.sendJob(K40NanoDriver.java:99) at com.t_oster.visicut.VisicutModel.sendJob(VisicutModel.java:786) at com.t_oster.visicut.gui.MainView$65.run(MainView.java:2275)
If the device is not sent the ControlTransfer it will issue 207 errors. These are currently listed as as CRC but they happen even when the CRC data is known to be fine. They actually must be PACKET_REJECTED. They happen with CRC errors but also on a device that was not initialized again after a reboot. This permits the detection of device off. 239 also happens at device power low, so that could be another clue.
Without the control packet it often won't recover from the usb unplug. The best bet here is likely time. If not recovered within 30 seconds, the project dies?
With full timeout the routine died with the following error (rather than the one I wanted). The initial error triggered the handle error at bulk transfer
Restart failed because: USB error 0: Device was not found.: Success Exception in thread "Thread-8" org.usb4java.LibUsbException: USB error 7: Failed to recover from USB errors.: Operation timed out at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb$1.run(K40NanoDriver.java:1569) java.lang.IllegalArgumentException: handle must not be null at org.usb4java.LibUsb.bulkTransfer(Native Method) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.update_status(K40NanoDriver.java:1611) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait(K40NanoDriver.java:1661) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait_for_ok(K40NanoDriver.java:1654) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Queue.execute(K40NanoDriver.java:1334) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.execute(K40NanoDriver.java:726) at com.t_oster.liblasercut.drivers.K40NanoDriver.sendJob(K40NanoDriver.java:294) at com.t_oster.visicut.VisicutModel.sendJob(VisicutModel.java:786) at com.t_oster.visicut.gui.MainView$65.run(MainView.java:2275) java.lang.IllegalArgumentException: handle must not be null at org.usb4java.LibUsb.bulkTransfer(Native Method) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.update_status(K40NanoDriver.java:1611) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait(K40NanoDriver.java:1661) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Usb.wait_for_ok(K40NanoDriver.java:1654) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Queue.execute(K40NanoDriver.java:1334) at com.t_oster.liblasercut.drivers.K40NanoDriver$K40Device.execute(K40NanoDriver.java:726) at com.t_oster.liblasercut.drivers.K40NanoDriver.sendJob(K40NanoDriver.java:294) at com.t_oster.visicut.VisicutModel.sendJob(VisicutModel.java:786) at com.t_oster.visicut.gui.MainView$65.run(MainView.java:2275)
As is, if the USB connection suffers a problem or something odd happens it will merely throw an error. It's possible for the queue routine to deal with those errors more robustly and then rethrow them if things are problematic without losing the elements currently in the queue.
Even if elements are lost, it might be possible to move back some commands and continue the project. Most embroidery machines permit that.