File Streaming Doesn't Complete

[BusbyGT]

When trying to send a probing script (see attache) with .nc extension, the nightly builds will not properly sense the end of the file and I have to restart UGS. I tried both Platform and Classic. The same file works no problem in 1.0.9. I also tried different Gcode files and got similar results. I did not try an actual cut file for fear of the problem happening, just probing files. First saw this problem on 2/28 on Platform build and then downloaded the nightly Classic.

Z-Axis-Only.txt

CNC: Xcarve w/ Xcontroller GRBL: Inventables 1.0c Host: Raspberry Pi 3 running Raspian

[winder]

Was this working on the nightly build prior to 2/28?

[BusbyGT]

I hadn't used the nightly build before only 1.0.9.

The Platform version I downloaded was on 2/24/17 but hadn't tried cutting until 2/28 (I meant to state that originally). On 2/28, I downloaded the nightly Classic build thinking it was Platform specific but it wasn't.

Once the file has been completed, the UI shows -2 for "Remaining Rows".

[winder]

@BusbyGT Could you copy the console output from when you run this file? Using stock GRBL v1.1d it seems to work with no issue:

>>> G92Z0
>>> G20
>>> G38.2Z-1F2
>>> G92Z0.829
>>> G91
>>> G0Z0.125
ok
ok
[PRB:0.000,0.000,-27.235:1]
ok
ok
ok

**** Finished sending file in 00:00:02 ****

ok

[BusbyGT]

I went to reproduce this to grab the console output and it worked like I'd expect it. I had done some OS updates since I last tried it so maybe that solved it? I'll have to check what updates were installed. Either way, I think this issue can be considered closed as I can't even seem to reproduce it myself anymore.

[BusbyGT]

@winder This has popped back up.

Using the 6/11 nightly build (downloaded on 6/12)

I'm not sure if this is a GRBL issue, a UGCS issue, or a Pi issue, but now I know how to correct it when it happens. I have had it happen on the simple probing script like before and after a long cut file as well.

To remedy the issue, I enter a manual "$$" command in the console and when it responds back with the "ok" from the $$ command, it triggers UGCS to do it's end of file/stream actions for unlocking the GUI and whatnot. This works 100% of the time it happens.

To me, the issue could be: a) UGCS is somehow missing an "ok" response from GRBL b) UGCS is expecting one more "ok" responses than it should c) GRBL is not returning an "ok" when it should d) RaspberyPi is somehow losing a response back from GRBL

I'm still running 1.0c but am planning to flash to 1.1f this weekend.

I've got a console log when it happened after the end of a cut (attached) but not a log showing an entire file and the "$$" recovery hack. I'll try to reproduce and copy that this weekend. Simple files should allow for an easy counting of commands vs. responses. My machine is currently torn apart while upgrading.

error-ugcs-06-12-16.txt

[winder]

1.1f should definitely solve the problem. 1.0c is an unofficial build Inventables made, so it's hard for me to say exactly what's wrong here. I made some changes after 6/11 adding better support for carbide3d's unofficial build. Those changes should help with 1.0c as well, so try updating UGS as well.

[BusbyGT]

Looks like GRBL v1.1f and a UGCS update did not fix the problem.

Kodiak-129732.txt

error-7-8-ugcs.txt

I am using the 6/14 build (it was the semi-stable build when I grabbed it). I can update again if needed.

I count 26 "ok" responses from GRBL and 26 commands as UGCS interprets. The Gcode file shows "G91 G0 Y0.125" as 1 line but UGCS is processing it as two lines. As you can see though, the "Finished sending" doesn't show up until I enter in a "$$".

It's not every file as I did a few cuts after probing that worked just fine.

[BusbyGT]

Update: On the 9/10/17 build, this still happens but the "$$" only partially works. I can trigger the end of the file stream with a "$$" but the UI stays in a weird state until I go to Machine -> Jog and jog in a direct.

[trbLeeciN]

I am also having the same issue for a long time. I tried to bypass the problem but it doesn't work. I added G1X0Y0F1001 to the end of my gcode files. And I try to check if that command completed or not. It sends G1X0Y0F1001, but it sometimes crashes when it comes to complete. Actually not only last row but also last 3rd or 2nd row are also missing too. What happens is, ugs thinks it is still sending commands, so it stays in that condition.

@Override public void commandSent(final GcodeCommand command) { System.out.println("commandsent:"+command.getCommandString());

    java.awt.EventQueue.invokeLater(new Runnable() {
        @Override
        public void run() {
            // sent
            if (commandTableScrollPane.isEnabled()) {
                commandTable.addRow(command);
            }
            //commandTable.updateRow(command);
        }});
}

@Override
public void commandComplete(final GcodeCommand command) {

    System.out.println("commandcomplete:"+command.getCommandString());
    if(command.getCommandString().equals("G1X0Y0F1001")){
        try {
            Thread.sleep(100);
            backend.sendGcodeCommand("$$");
            Thread.sleep(100);
        } catch (Exception e) {
        }
    }

    // update gui
    java.awt.EventQueue.invokeLater(new Runnable() {
        @Override
        public void run() {
            if (commandTableScrollPane.isEnabled()) {
                commandTable.updateRow(command);
            }
            if (backend.isSendingFile()) {
                if (vw != null) {
                    vw.setCompletedCommandNumber(command.getCommandNumber());
                }
            }
        }});

}

[winder]

@trbLeeciN is your included code trying to "jump start" UGS?

[trbLeeciN]

I tried to findout why this problem occurs, since people said that file streaming doesn't complete, but they know it is finished, they manually command "$$", so UGS somehow completes last rows. So I wanted to check if all commands complete and it remains sending file or not, and it seems that it doesn't complete all rows, so it stucks in sending file state, but when user enters any command, UGS completes file stream and executes entered command.

[wmarkow]

To me, the issue could be: a) UGCS is somehow missing an "ok" response from GRBL b) UGCS is expecting one more "ok" responses than it should c) GRBL is not returning an "ok" when it should d) RaspberyPi is somehow losing a response back from GRBL

Hi, I have some kind of similar issue but I'm not sure how strong it is related to this issue report. My case is when I send the whole grbl file to the machine (I'm using Grbl 1.1h.), the machine seems to have a poor reaction on the commands that it receives (only first few commands are processed); it sends some ok back to UGS but the motors doesn't move; I just hear some noise like it looses steps. Other functionality, like homing and joging work nice.

Interesting thing: when I send commands manually from UGS by using console (enter one command and wait, enter second command and wait, etc.), then it works perfect.

Do you have any suggestions? I'm a developer so can debug the whole thing. @winder any suggestions where shoud I start with the debug?

[winder]

What version are you running? This issue has been around for a long time but I thought it was fixed.

The buffered communicator class is where most of the streaming is done. There are some notes about this here: http://winder.github.io/ugs_website/dev/backend_development/#streaming-strategy

[wmarkow]

I'm using a snapshot version from 2 April 2020.

I have put a breakpoint in com.willwinder.universalgcodesender.BufferedCommunicator.streamCommands()

inside of the while command. When I send commands step by step (and wait until it finishes) then it works fine. I have the feeling that the commands are send to fast without waiting until they finish, but I'm not so familiar with the code.

In this piece of code:

try {
    this.sendingCommand(commandString);
    connection.sendStringToComm(commandString + "\n");
    dispatchListenerEvents(COMMAND_SENT, command);
    nextCommand = null;
} catch (Exception e) {
    e.printStackTrace();
    System.exit(-1);
}

After the dispatchListenerEvents the machine still executes the command but the variable command is:

GcodeCommand[command=G01X89.9583Y64.2559Z-0.125F400,originalCommand=G01 X89.958328 Y64.255950 Z-0.125000 F400.000000,response=<null>,sent=true,isOk=false,isError=false,commandNum=79,isSkipped=false,isGenerated=false,comment=,isTemporaryParserModalChange=false,id=375]

so the flag sent is set to true immediatelly.

I hope this gives you some hint.

This issue has been around for a long time but I thought it was fixed.

@winder do you have an issue number for this?

[wmarkow]

@winder, please hold on for a while. I'm using this experimental servo plotter feature which I have merged into grbl-1.1h. It changes a bit the functionality of M3 and possibly of M5 commands to control the pen (moves it up or down). When I remove those commands from my gnc file, then the machine moves very nice (however it doesn't plot, because the pen is always up).

Maybe I have merged the feature incorrect with grbl-1.1h or the feature is not well designed to work with grbl-1.1h or there is something wrong with those M3 and M5 commands. I will try to find out.

[wmarkow]

@winder, everything is fine with UGS. I have retested again with the latest version from master branch.

I just didn't know that grbl have a special treatment when using M3, M4 and M5 commands in CNC mode (also in this servo mode feature); it is required to put dwell G4 Px after those Mx in the ngc file, otherwise the movement will be blocked.

Everything is described in grbl/grbl issue #951 . I'm sorry for misunderstanding.