Closed cojarbi closed 7 years ago
@cojarbi I was able to replicate the problem. But I got an additional message in the console:
Error: Writing to COM port (GetOverlappedResult): Unknown error code 31
Now I nedd to investigate, what could cause it. At least it has nothing to do with OSX, as I am on Windows 10.
Ok, error code 31 seems to mean:
ERROR_GEN_FAILURE 31 (0x1F) A device attached to the system is not functioning.
which basically means that the serial port of Grbl is blocked.
I don't know if this is something we even can influence from our side.
@chamnit : Do you have an idea what could cause this problem?
To resolve the blockage, I had to unplug an replug the USB port. Just disonnecting the serial port by software did not help.
Did I mention that I was able to complete the gcode via ugs
@cprezzi : This seems like a USB connection issue. These can be problematic with noisy electrical environments. Usually due to a spindle drawing a lot power nearby. Don't know how lasers would effect things. Likely less. Also, I can check with some nodeJS devs to see if they ran into similar issues and how they resolved it.
@chamnit my error was generated by using a router not a laser. I don't think I have any powerful electronic near the board nor the cable. @cprezzi is there any coincidence on where it stopped working for you as in mine?
@cojarbi : genuine arduino, or chinese CH340 based fake? I get that often with the CH340 driver. The port doesn't disappear from device manager, yet also doesn't appear anymore to OS calls
On Dec 30, 2016 6:05 PM, "Ariel Yahni" notifications@github.com wrote:
@chamnit https://github.com/chamnit my error was generated by using a router not a laser. I don't think I have any powerful electronic near the board nor the cable. @cprezzi https://github.com/cprezzi is there any coincidence on where it stopped working for you as in mine?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/208#issuecomment-269788391, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr23cflOXpi29l2whhwx-mTDV8Bz1nks5rNSvfgaJpZM4LYJYH .
@chamnit: I found that there was some issues like this on node.serialport, but allready some time ago. My test was a flying installation on the desk, just Adruino Uno with CNC-Shield an two steppers, no spindle or laser. Probably it's caused by the USB converter (or it's driver), like Peter suggested.
@openhardwarecoza : I'm using chinese Arduinos with CH340. The CH340 is known to have some issues with fast baudrates, but that should be over 115'000.
@cojarbi : My test stopped somewhere on the very last outlines. That's a part where you have long lines (no big gcode density).
I have now changed the code a bit, mainly to suppress the ugly false error message after connecting and some connection state cleanups, but that seems to have solved the problem (at least I'm not able to replicate anymore). Can you please pull the new version (master) and try if that solved the problem for you?
@openhardwarecoza Im using a gshield from synthetos @cprezzi I'm gone for the weekend will try next week
Spindles create a lot of noise on the electrical circuit itself, not just around the spindle and its cord. I would test if it runs without the spindle connected.
The CH380 USB serial chip is known to fail at all baudrates. Just some less than others. It is particularly bad when sending a lot of data, like with the character counting protocol. The CH380 chip has poor buffer management and drops overflow characters without any notifications.
I cannot duplicate at the moment i could run the complete project without issues. Note it was done via Rpi 2
@cprezzi attached the gcode and screenshot of the workspace and terminal at the moment of freeze. Running latest grbl 1.1e on a gshield with LW3 on Chrome OSX Sierra
gcode (25) copy.gcode.txt