search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.89k stars 765 forks source link

ugs cli - File stream is disabled when GRBL is in the Alarm state. #1616

Closed kh9341101 closed 2 years ago

kh9341101 commented 3 years ago

Describe the bug I am not sure how to get rid of this error when I used ugs cli to send a file. (I downloaded it from nightly build) I have used --home option to home the machine first, then when I run the --file command, it will still tell me GRBL is in the Alarm state. Is there anyway I can solve this? Any help will be appreciated.

To reproduce Steps to reproduce the behavior:

  1. java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --controller GRBL --port COM26 --baud 115200 --print-progressbar --home
  2. java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --controller GRBL --port COM26 --baud 115200 --print-progressbar --file probe.txt

Expected behavior I was hoping to see my file sent and start running the gcode

Screenshots image

Version UGS Classic Nightly builds, v2.0.7, v2.0.6, v2.0.5

Hardware Sainsmart 3018-prover

Operating system (please complete the following information): Windows 10,

Additional context I am just trying to use CLI to execute gcode commands, I remember I was able to do that back when I saw this post https://github.com/winder/Universal-G-Code-Sender/issues/1171, but the jar file seems to be different than what I was using then

breiler commented 3 years ago

When UGS makes a connection to GRBL it will be resetted and will require homing before sending a file. So when you split up the commands into two it will make a new connection to the controller each time.

Try combining the command into one like this: java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --controller GRBL --port COM26 --baud 115200 --print-progressbar --home --file probe.txt

abb25727 commented 3 years ago

I have a similar issue. I was able to get around the GBRL alarm state by homing the CNC machine manually but I now have a "GRBL has not finished booting" error when I run the following command: java -cp UniversalGcodeSender.jar com.willwinder.ugs.cli.TerminalClient --controller GRBL --port COM5 --baud 115200 --print-progressbar --file test.txt

Any ideas on what could be causing this error?

Screenshot of error: image

abb25727 commented 3 years ago

I should add that I can connect and control the machine with the UGS terminal but I would like to loop a set of commands using the Windows terminal instead.

kh9341101 commented 3 years ago

Thanks for both of the reply. I did try to combine --home and --file in the same script but the CNC only perform the home part, not the file part. image Seems to be that since there is this home command, I can't perform other in same command line?

J-Dunn commented 3 years ago

BTW , this error msg "GRBL has not finished booting" is very unhelpful ( this is not a new problem ).

It is not reporting what the actual problem is but someone's guess as to what the cause may be. An error msg should report the error. Since GRBL is very fast to boot , it is very unlikely this will be reason it is not responding.

For example, if I'm using a debugger on GRBL, it HAS booted, run several commands and I halt it with the debugger, or it hits a breakpoint, then UGS tells me it has not finished booting. Wrong Guess !

I'm assuming this is caused by a lack of communication with the /dev/ttyACMx device , so the error msg should reflect the actual problem. It is actually very unhelpful and confusing assuming the cause of the error. Reporting the real error would aid the user in working out what is wrong.

breiler commented 3 years ago

@J-Dunn sure, we should strive for having clear error messages that are easy to understand. In this case it is reasonable that the error message should be changed to something that reflects that UGS couldn't establish connection to the controller while waiting for the GRBL welcome message.

@kh9341101, @abb25727 this is probably a bug, we need to wait until the homing sequence has finished before starting the file stream.

J-Dunn commented 3 years ago

thanks. I'm pretty sure this is not just on start up. I'll double check with the debugger situation I described above next time I'm on the machine. I'm fairly sure if grbl does not respond at any point, UGS displays this error.

breiler commented 2 years ago

Should have been fixed in the latest nightly build

J-Dunn commented 2 years ago

Thanks for digging into this. Did the error msg ( which will hopefully get see a lot less now ) get changed to something more directly related to what the actual problem is ?

As I said above, it highly unlikely that "GRBL has not finished booting" will ever be true. Whatever the actual communications issue is should be reported directly IMO. ie "no response from /dev/ttyACM1 " or whatever is really happening.

Take my debugging example above. The debugger puts the GRBL controlling in a non running state at some arbitrary point of execution. The serial port will stop responding. The error should reflect what is happening, not guess at why that may be. There may be some other condition causes a comms problem. UGS should report what REALLY went wrong, to be as helpful as possible in determining the cause.

I'll will try to find time to test the new update, next time the machine free ( and I am ).