Add support for SmoothieWare #204

Open
Leary opened this Issue Nov 16, 2014 · 85 comments

Projects

None yet
@Leary
Leary commented Nov 16, 2014

When I try to use Universal GCode Sender with my new Shapeoko running Smoothieware I get this;

**** Connected to COM10 @ 9600 baud ****
Smoothie
[verbose][Error] Error while processing response : Attempting to complete a command that doesn't exist: <(-1)>ok

Then if I try to send gcode I get
"Error while starting file stream: Grbl has not finished booting"

@arthurwolf

This sounds super easy to fix. Appart from the boot message, Smoothie should be mostly GRBL-compatible ...
Somebody wants a Smoothieboard to try to get this to work ?
Can contact me at wolf.arthur@gmail.com if so.

@winder
Owner
winder commented Feb 5, 2015

If you un-comment the TinyG line in FirmwareUtils the TinyG plugin might work for Smoothie. The "plugin" model here was never fully developed but most of the architectural changes were finished before I ran out of steam.

@GeorgeIoak

Would somebody mind uncommenting that Smoothie (line 41) line and compiling a test version for me please. I don't have NetBeans installed and would be willing to test this and report back

@GeorgeIoak

I had some free time at lunch so I thought I'd try this. I'm on a MAC OS X, cloned the project, installed NetBeans, and tried to build (with that line uncommented). Didn't get too far so I thought I'd post this in case you see it and have a quick answer as to what's missing.

ant -f /Users/george/Documents/Github/Universal-G-Code-Sender onejar-build-release
Creating new property file: /Users/george/Documents/Github/Universal-G-Code-Sender/src/resources/build.properties
init:
deps-jar:
Created dir: /Users/george/Documents/Github/Universal-G-Code-Sender/build
Updating property file: /Users/george/Documents/Github/Universal-G-Code-Sender/build/built-jar.properties
Created dir: /Users/george/Documents/Github/Universal-G-Code-Sender/build/classes
Created dir: /Users/george/Documents/Github/Universal-G-Code-Sender/build/empty
Created dir: /Users/george/Documents/Github/Universal-G-Code-Sender/build/generated-sources/ap-source-output
Compiling 56 source files to /Users/george/Documents/Github/Universal-G-Code-Sender/build/classes
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:121: error: cannot find symbol
        systemStateBean.setMachineX(Utils.formatter.format(this.machineCoord.getX()));
  symbol:   method getX()
  location: variable machineCoord of type Point3d
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:122: error: cannot find symbol
        systemStateBean.setMachineY(Utils.formatter.format(this.machineCoord.getY()));
  symbol:   method getY()
  location: variable machineCoord of type Point3d
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:123: error: cannot find symbol
        systemStateBean.setMachineZ(Utils.formatter.format(this.machineCoord.getZ()));
  symbol:   method getZ()
  location: variable machineCoord of type Point3d
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:127: error: cannot find symbol
        systemStateBean.setWorkX(Utils.formatter.format(this.workCoord.getX()));
  symbol:   method getX()
  location: variable workCoord of type Point3d
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:128: error: cannot find symbol
        systemStateBean.setWorkY(Utils.formatter.format(this.workCoord.getY()));
  symbol:   method getY()
  location: variable workCoord of type Point3d
/Users/george/Documents/Github/Universal-G-Code-Sender/src/com/willwinder/universalgcodesender/GUIBackend.java:129: error: cannot find symbol
        systemStateBean.setWorkZ(Utils.formatter.format(this.workCoord.getZ()));
  symbol:   method getZ()
  location: variable workCoord of type Point3d
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
6 errors
/Users/george/Documents/Github/Universal-G-Code-Sender/nbproject/build-impl.xml:923: The following error occurred while executing this line:
/Users/george/Documents/Github/Universal-G-Code-Sender/nbproject/build-impl.xml:263: Compile failed; see the compiler error output for details.
BUILD FAILED (total time: 5 seconds)
@GeorgeIoak

FYI, if I download version 1.0.8 it will compile without errors yet TinyG does not successfully issue any commands. Interestingly the visualizer does not work either (did not work for me on the other builds either).

If I switch to the edge branch the visualizer and compile work but TinyG does not work either.

Looks like more work is needed to support different responses and setups for anything other than GRBL.

Maybe a better first test is to edit the code to also look for a Smoothie response and accept that along with the GRBL 0.8/0.9 responses?

@winder
Owner
winder commented Feb 27, 2015

@GeorgeIoak You're absolutely right. If you take a look here you can see that Smoothie is not implemented at all. You can also see the pattern setup for switching between different gcode types. Its just like you suggested - a way to support different responses and setups! A lot of the legwork is done I just haven't found the time to setup the electronics for my TinyG and fix the bugs. That work would be done in TinyGCommunicator and TinyGController. For Smoothie two more files would be created to implement these interfaces.

@GeorgeIoak

@winder I did make a quick change and bypassed the version check just to confirm that that I could run a file. The good news is that I was able to start a job but the bad news is that the job stopped at the same place 2 times about 1/2 way through (1150/2249 I think). The code that it stopped on (G3) had run successfully earlier in the job so I'm not sure why it stops here.

I think Smoothie would be easier than TinyG in that I think Smoothie is a direct port of GRBL and TinyG was branched off of GRBL. I could be wrong on that so don't quote me!

Not having the visualizer work is a bit of a bummer and I found some clues to try to get it to work but didn't succeed yet. Once I get a job to run successfully I can help create and test SmoothieCommunicator and SmoothieController.

@arthurwolf

Hey.

Smoothie currently has a G3 problem, so that's probably not a problem with
your code. So you can ignore this.

This does sound like you got Smoothie to work with UGS :)

Cheers.

On Sat, Feb 28, 2015 at 2:32 AM, George Ioakimedes <notifications@github.com

wrote:

@winder https://github.com/winder I did make a quick change and
bypassed the version check just to confirm that that I could run a file.
The good news is that I was able to start a job but the bad news is that
the job stopped at the same place 2 times about 1/2 way through (1150/2249
I think). The code that it stopped on (G3) had run successfully earlier in
the job so I'm not sure why it stops here.

I think Smoothie would be easier than TinyG in that I think Smoothie is a
direct port of GRBL and TinyG was branched off of GRBL. I could be wrong on
that so don't quote me!

Not having the visualizer work is a bit of a bummer and I found some clues
to try to get it to work but didn't succeed yet. Once I get a job to run
successfully I can help create and test SmoothieCommunicator and
SmoothieController.


Reply to this email directly or view it on GitHub
#204 (comment)
.

Courage et bonne humeur.

@GeorgeIoak

I'll have to pop over to the Smoothie forums and look into this problem. The code did work once last night using Pronterface but that might have been luck of the draw as I thought I had tested it before and it failed as well. For reference the file I'm experimenting with can be viewed here.

Yes, UGS and Smoothie worked together. I'm a hardware design guy mostly so coding doesn't come naturally for me but I'll start taking a look on how we can officially get Smoothie support. I just happen to be testing with a Mac so that might be throwing in some other issues.

@soundstorm

@GeorgeIoak Just ran into the same error. Replaced the code snipped (as the Point3d that's being included has no .getX()):

    public void updateSystemState(SystemStateBean systemStateBean) {
        logger.log(Level.INFO, "Getting system state 'updateSystemState'");
        double[] mp = new double[3];
        this.machineCoord.get(mp);
        double[] wp = new double[3];
        this.machineCoord.get(wp);
        systemStateBean.setFileName(gcodeFile.getAbsolutePath());
        systemStateBean.setLatestComment(lastComment);
        systemStateBean.setActiveState(activeState);
        systemStateBean.setControlState(controlState);
        systemStateBean.setDuration(String.valueOf(this.getSendDuration()));
        systemStateBean.setEstimatedTimeRemaining(String.valueOf(this.getSendRemainingDuration()));
        systemStateBean.setMachineX(Utils.formatter.format(mp[0]));
        systemStateBean.setMachineY(Utils.formatter.format(mp[1]));
        systemStateBean.setMachineZ(Utils.formatter.format(mp[2]));
        systemStateBean.setRemainingRows(String.valueOf(this.getNumRemainingRows()));
        systemStateBean.setRowsInFile(String.valueOf(this.getNumRows()));
        systemStateBean.setSentRows(String.valueOf(this.getNumSentRows()));
        systemStateBean.setWorkX(Utils.formatter.format(wp[0]));
        systemStateBean.setWorkY(Utils.formatter.format(wp[1]));
        systemStateBean.setWorkZ(Utils.formatter.format(wp[2]));
        systemStateBean.setSendButtonText(openCloseButtonText);
        systemStateBean.setSendButtonEnabled(openCloseButtonEnabled);
        systemStateBean.setPauseResumeButtonText(pauseButtonText);
        systemStateBean.setPauseResumeButtonEnabled(this.canPause());
        systemStateBean.setCancelButtonText(cancelButtonText);
        systemStateBean.setCancelButtonEnabled(this.canCancel());
    }

Now the code is executed without the error.

@kg5000
kg5000 commented Jun 1, 2015

I should have a SmoothieBoard in my mailbox today! I am a professional Java developer with 15+ years experience. I do mostly Point-of-Sale automation and control system development with J2SE. I did some enterprise/web stuff for a while but it's been years.

I'd be very interested in helping to get this working with Smoothie.

Is there any code committed for Smoothie support? If not how can I get what's been implemented so far to help with the cause?

Ken

@winder
Owner
winder commented Jun 1, 2015

There's an API for adding additional controllers. Currently there is just GRBL and an almost-complete TinyG implementation. You've been working with Java for longer than I have, so I'll be curious to hear you're opinions.

Here's a high level overview of how the backend is implemented:
https://github.com/winder/Universal-G-Code-Sender/wiki/Code-Overview

Adding full smoothie support shouldn't be bad, it may just be a matter of extending the GRBL controller class and re-implementing a couple functions which are handled differently in smoothie (i.e. version checking).

@kg5000
kg5000 commented Jun 1, 2015

Thanks for the overview link. I will take a look a little later and get familiarized. I've been using Eclipse for years and have very little NetBeans experience. I need to download NB to get going on this.

Ken

@morrowsend

I've been trying to get the Smoothie board working. It seems that when it connects, Universal Gcode sender doesn't catch the "Smoothie" hello message. If I force it by setting "isReady" to "true" I can get it to at least allow me to send commands, but each time I get the same error as the timing issue mentioned in #214

Here's a screencast of the weirdness I'm encountering.

Another interesting thing is that if I use a serial terminal to connect to the smoothieboard, I get the hello message, but if I connect to Universal Gcode sender, close the connection, then try the serial terminal, I no longer catch the hello message, but I can send commands and receive replies.

I tried Smoothie firmware from Jan 15th and June 21, 2015

@arthurwolf

Hey.

This does sound like some weirdness on windows' serial driver's part, I
think you'll need to modify the code so it's a bit more tolerant.

One thing you can do : instead of just "waiting" for Smoothie to say
"Smoothie", send the "version" command to the board upon connection. That
will force Smoothie to print out a welcome message.

About the "ok"s, I have no idea what is going on there ... maybe it's
expecting the line to end with \n and we end it with \r\n or something ?

Cheers.

On Thu, Jun 25, 2015 at 7:50 AM, morrowsend notifications@github.com
wrote:

I've been trying to get the Smoothie board working. It seems that when it
connects, Universal Gcode sender doesn't catch the "Smoothie" hello
message. If I force it by setting "isReady" to "true" I can get it to at
least allow me to send commands, but each time I get the same error as the
timing issue mentioned in #214
#214

Here's a screencast of the weirdness I'm encountering.
http://youtu.be/p1Ht4iqDl34

Another interesting thing is that if I use a serial terminal to connect to
the smoothieboard, I get the hello message, but if I connect to Universal
Gcode sender, close the connection, then try the serial terminal, I no
longer catch the hello message, but I can send commands and receive replies.

I tried Smoothie firmware from Jan 15th and June 21, 2015


Reply to this email directly or view it on GitHub
#204 (comment)
.

Courage et bonne humeur.

@winder
Owner
winder commented Jun 25, 2015

@morrowsend it sounds like you're on the right track. GRBL/Arduino restart themself when connected by USB, it sounds like Smoothie might not have this feature. I've actually been considering whether UGS should rely on it for GRBL as well. Something like Arthur's suggestion is a great first step, there is a function in AbstractController called "openCommAfterEvent" that you can implement to send "version" in your Controller.

I recently made a bare bones streaming program to test out some communication changes, you might consider working off of that project while troubleshooting these weird serial issues.
https://github.com/winder/simpleJavaGrblStreamer

Finally... sorry about this, but I pushed a bunch of optimizations to the AbstractController class recently and there might be a couple merge conflicts. You should pull those changes down as they fix some fundamental issues with the AbstractController (it was overly complicated, slow, had concurrency issuese, etc).

@morrowsend

All good ideas to help me figure this out. Thanks guys! winder, I forked it last night so I could hack on it to my heart's content (like 12 hours ago from this post) so I assume that the newest changes were implemented at that point. I'll take a look to see if anything is different with the AbstractController class to make sure though.

@morrowsend

After playing a bit with it today, I still haven't made progress, but here's what I tried playing around with the openCommAfterEvent method in Abstract Controller:

  • For any of this to work, I must set "isReady" in the SmootiheController.java to true. If I don't then regardless of what I try, I get the error pop stating "Error opening connection (java.lang.Exception): SmoothieBoard Grbl has not finished booting" and the console shows:

    **** Connected to COM12 @ 115200 baud ****
    Smoothie
    [verbose][Error] Error while processing response : nullok

This is weird because it actually does block the port, however the GUI acts as if it is not opened. I have no ability to send commands and when I try to press the Open button, I get an error popup stating the port is already in use.

So with isReady set to true, I did the following:

  • I added a "version" request as soon as the connection is made. All the console shows is:

    **** Connected to COM12 @ 115200 baud ****
    .>>> version

  • Trying "version/n" and "version/r" both result in the same output on the console:

    **** Connected to COM12 @ 115200 baud ****
    .>>> version

[verbose][Error] Command <version

does not equal expected command

  • If I try multiple "version" requests I finally get a response (for 2 requests see below):

    **** Connected to COM12 @ 115200 baud ****
    .>>> version
    .>>> version
    Smoothie
    ok
    Build version: edge-4fc7801, Build date: Jun 21 2015 18:00:57, MCU: LPC1769, System Clock: 120MHz

Throughout all of this, I have a breakpoint set at the rawResponseHandler in the SmoothieController.java (just a clone of Grblcontroller). This breakpoint is NEVER tripped.

So my thought are:

  1. I'll never be able to set "isReady" true if it never runs the rawResponseHandler.
  2. If I force isReady true, it still doesn't fix the problem of this weird buffer thing where I must send multiple commands to start before it will finally print what is in the receive buffer.
  3. With isReady true I still have the problem receiving the "ok" replies from the Smoothieboard
  4. The /r/n isn't a problem. I changed every instance of "\r\n" in the project to just \r and then just \n and I get the exact same results. Even the MockGrbl seems to output /r/n and I suspect that's what was used to build the rest of UniversalGcodeSender.
  5. I tested the simpleGcodeStreamer and it completed sending a full file without issue.

I'm at a bit of a loss on what else to try. You can see what I've done so far (not much) here: https://github.com/morrowsend/Universal-G-Code-Sender/tree/master/src/com/willwinder/universalgcodesender

@winder
Owner
winder commented Jun 25, 2015

A couple things. It looks like I am manually resetting GRBL after opening the connection, so you are sending the GRBL reset signal to Smoothie, which might be causing the weird behavior. Did you change this part to send version? You'll need to change "sendByteImmediately" to "sendStringToComm":

    @Override
    protected void openCommAfterEvent() throws Exception {
        // GRBL_RESET_COMMAND is 0x18
        this.comm.sendByteImmediately(GrblUtils.GRBL_RESET_COMMAND);
    }

Another thing you can try, is in GrblCommunicator.java change "\r\n" to just "\n"

The weirdest thing I'm seeing in your update is the "nullok" response. I'm not really sure what thats about. I think the error part is happening because UGS doesn't think its sent a command, but its getting a response anyway, but I'm not sure why it says "null".

@morrowsend

Great, I've got an update.
So changing the line terminator to "/n" only in GrblCommunicator removed the weird "nullok", though I get double "ok" when I issue any command (see new screencast)

I had to make sendStringToComm public in AbstractController public but that fixed the issue of check if it receives the hello message.

I was able to successfully manually drive the machine, but I get an error when I try to send a file.

Error: Cannot stream when there are active commands (controller)

@winder
Owner
winder commented Jun 25, 2015

Ah, sorry I gave you the wrong method. Don't change sendStringToComm to public, use the public version which is "sendCommandImmediately". That should fix the file send error.

The multiple OK thing looks like it might be sending an OK for each command in the line. For instance the first line in your screencast was "G21 G91 G0 Y1", that has 3 G commands and received 3 OK's. The second command was "G91 G0 Y-1", 2 G commands and 2 OK's. This is going to be a trickier problem to solve since the current code assumes a single OK for each line sent.

You can test it out by sending something like "G21 G21 G21 G21 G21" and seeing if Smoothie responds with 5 OK's

I need to figure out that "/n" vs "/r/n" thing. I had the same issue when making the simple gcode sender so I'm not sure how UGS is working in GRBL. Reworking the serial code is next on my list of things to cleanup.

@morrowsend

Thanks for the quick reply. I had previously tried sendCommandImmediately, but when I use that, it doesn't even open the port. isReadyToSendCommandsEvent() throws the exception before it will even open the port. The sendStringToComm at least allowed me to open the port.

And you are correct about the OK replies, G21 G21 G21 G21 G21 gives me 5 OKs.

@winder
Owner
winder commented Jun 25, 2015

Ok, I'll see if I can figure out why thats happening soon. I think you need to use sendCommandImmediately for this, it's probably a bug that sendByteImmediately works (and another bug that neither of them works in this afterCommOpenEvent method).

@morrowsend

It's a chicken and egg thing. If I force "isReady" true, then I can use sendCommandImmediately, but if I want to use isReady, then sendStringToComm has to be public.

Regardless, if I set isReady true, and use sendCommandImmediately, I still get the same issue when I try to stream the file. Thanks for all the help so far.

@winder
Owner
winder commented Jun 26, 2015

Any of the constructs created in GrblController are specific to Grbl and can be removed if they don't make any sense for Smoothie. Thats the intention anyway. In this case it looks like isReady exists because it made sense for Grbl - there are features that get conditionally enabled depending on the Grbl version. It sounds like it doesn't make sense for Smoothie so you can just take it out completely in SmoothieController.

I think the "Error: Cannot stream when there are active commands" problem is related to the multiple OK's. In AbstractController there is a single ArrayList with all the commands in it. I use indexes into that array to determine which commands have been sent, which are waiting on responses and which have completed. One of those indexes gets incremented for each OK received which is going to cause issues.

I'm surprised that the standalone gcode streaming app worked, since it counts OK messages in the same way. If you remove isReady and remove the "version" query then send a file before sending any other commands I think it will appear to stream the file correctly, but the indexes will be corrupt.

@morrowsend

I did what you said, (just keeping isReady true, and removing the "version" command). I can send it a file, but it only executes about 5 lines then stops streaming. This is repeatable with different files.

I can get the entire file sent using the simpleJavaStreamer with no problem.

@winder
Owner
winder commented Jun 26, 2015

Thats probably the multiple ok's, were you able to figure out if that was because of multiple gcodes per line?

You could try running something like stress_test.gcode which happens to only have 1 command per line.

@morrowsend

The stress test code gets stuck on the 11th line in UGS. It works in the
simple streamer though.
On Jun 26, 2015 11:25 AM, "Will Winder" notifications@github.com wrote:

Thats probably the multiple ok's, were you able to figure out if that was
because of multiple gcodes per line?

You could try running something like stress_test.gcode
https://github.com/winder/Universal-G-Code-Sender/blob/master/test_files/stress_test.gcode
which happens to only have 1 command per line.


Reply to this email directly or view it on GitHub
#204 (comment)
.

@winder
Owner
winder commented Jun 29, 2015

I spent some time this weekend adding TinyG support. The AbstractController interface worked pretty well, I really didn't need to change anything there. The Communicator also worked pretty well, the TinyG / Grbl buffered communication was 95% identical so I re-factored it so they both extend a "BufferedCommunicator", Smoothie may want to extend that as well to implement the "processedCommand" function to deal with those multiple OK messages. We might need to add a "sentCommand" function to implement for smoothie as well to deal with the multiple ok messages. Take a look at TinyGController and TinyGCommunicator, maybe this will make a little more sense with a simpler example.

I was hoping to find a bug in the AbstractController that might be causing your problem, but everything seemed to behave as designed.

Another possibility is that the status messages are causing an issue, try disabling those (there's a GUI setting).

@morrowsend

I created two smoothie controllers to test. Once based on TinyGController and one on GRBLController. I get the same kinds of issues with each one. Here's a screencast if you are interested: http://youtu.be/uVYziAp3KLg

I forgot to show it, but I also tried disabling the status messages. When I do so, I cannot use the TinyGSmoothie class, it says it there was a problem setting one or more of these controller features:
max command length
truncated decimal length
single step mode
remove all whitespace
convert arcs to lines
status updates
status update rate.

@winder
Owner
winder commented Jun 29, 2015

To answer some of the comments from your video.

The stream is stopping after it sends 123 bytes (GRBL) or 127 bytes (TinyG), see the "getBufferSize" function.

UGS has to manage these buffers because there is limited space in the controller, so it wont send any additional commands until one of the previously sent commands is marked as complete. Commands are marked complete in the "rawResponseHandler", see the "commandComplete" function.

In the GrblCommunicator, have you tried changing the "\r\n" to just "\n"?

Once you get past this hurdle, you're going to have to figure out the multiple ok issue eventually. Does "G21 G21 G21 G21" return 4 oks?

@morrowsend

I already changed the line ending to \n only (I have a GrblSmoothieCommunicator class where this happens).

I just tested the 4 commands again. The first command I send always gets ignored, but the second and all subsequent times I send G21 G21 G21 G21 i get 4 OKs:

>>> G21 G21 G21 G21
ok
ok
ok
ok

When I use the TinyGSmoothieController and TinyGSmoothiCommunicator, there are never any OK messages.

I made the ArrayList of commands in AbstractController public for a second just so I could read how many commands were being left uncounted every time rawResponseHandler ran. In my GrblSmoothieController, I then added the following:

    @Override
    protected void rawResponseHandler(String response) {
 Logger.getLogger(GrblSmoothieController.class.getName()).log(Level.INFO,"Size of Commands not yet completed = "+this.commands.size());

I then connected and send 6 manual control commands, here's the output of the UGS console:

**** Connected to COM12 @ 115200 baud ****
>>> G21 G91 G0  Y1
>>> G91 G0  Y1
Smoothie
ok
ok
ok
>>> G91 G0  Y1
ok
ok
>>> G91 G0  Y1
ok
ok
>>> G91 G0  Y1
ok
ok
>>> G91 G0  Y1
ok
ok

And here is the output of Netbeans console:

Jun 29, 2015 8:28:14 PM com.willwinder.universalgcodesender.utils.SettingsFactory loadSettings
INFO: Loading settings.
Jun 29, 2015 8:28:14 PM com.willwinder.universalgcodesender.utils.SettingsFactory loadSettings
INFO: Settings file location: C:\Users\ALaptop\UniversalGcodeSender.json
Jun 29, 2015 8:28:15 PM com.willwinder.universalgcodesender.model.GUIBackend applySettings
INFO: Applying settings.
Jun 29, 2015 8:28:15 PM com.willwinder.universalgcodesender.model.GUIBackend addControllerListener
INFO: Adding controller listener.
Jun 29, 2015 8:28:15 PM com.willwinder.universalgcodesender.model.GUIBackend addControlStateListener
INFO: Adding control state listener.
Jun 29, 2015 8:28:17 PM com.willwinder.universalgcodesender.model.GUIBackend connect
INFO: Connecting to Grbl Smoothie on port COM12
Jun 29, 2015 8:28:17 PM com.willwinder.universalgcodesender.model.GUIBackend sendControlStateEvent
INFO: Sending control state change.
Jun 29, 2015 8:28:17 PM com.willwinder.universalgcodesender.model.GUIBackend getFile
INFO: Getting gcode file.
Jun 29, 2015 8:28:17 PM com.willwinder.universalgcodesender.model.GUIBackend getControlState
INFO: Getting control state.
Jun 29, 2015 8:28:17 PM com.willwinder.universalgcodesender.model.GUIBackend getFile
INFO: Getting gcode file.
Jun 29, 2015 8:28:19 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:19 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G21 G91 G0  Y1
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G91 G0  Y1
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 2
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 2
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 2
Jun 29, 2015 8:28:20 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 2
Jun 29, 2015 8:28:28 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:28 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G91 G0  Y1
Jun 29, 2015 8:28:28 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 3
Jun 29, 2015 8:28:28 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 3
Jun 29, 2015 8:28:30 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:30 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G91 G0  Y1
Jun 29, 2015 8:28:30 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 4
Jun 29, 2015 8:28:30 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 4
Jun 29, 2015 8:28:32 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:32 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G91 G0  Y1
Jun 29, 2015 8:28:32 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 5
Jun 29, 2015 8:28:32 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 5
Jun 29, 2015 8:28:34 PM com.willwinder.universalgcodesender.model.GUIBackend adjustManualLocation
INFO: Adjusting manual location.
Jun 29, 2015 8:28:34 PM com.willwinder.universalgcodesender.model.GUIBackend sendGcodeCommand
INFO: Sending gcode command: G91 G0  Y1
Jun 29, 2015 8:28:34 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 6
Jun 29, 2015 8:28:34 PM com.willwinder.universalgcodesender.GrblSmoothieController rawResponseHandler
INFO: Size of Commands not yet completed = 6
Jun 29, 2015 8:28:37 PM com.willwinder.universalgcodesender.model.GUIBackend disconnect
INFO: Disconnecting.
Jun 29, 2015 8:28:37 PM com.willwinder.universalgcodesender.model.GUIBackend sendControlStateEvent
INFO: Sending control state change.
Jun 29, 2015 8:28:37 PM com.willwinder.universalgcodesender.model.GUIBackend getFile
INFO: Getting gcode file.
Jun 29, 2015 8:28:37 PM com.willwinder.universalgcodesender.model.GUIBackend getControlState
INFO: Getting control state.

It looks like the commands are never being checked off as complete, even though the rawResponseHandler is getting all the OK messages. I'm not getting any "Skipped" responses from abstractController though.

@winder
Owner
winder commented Jun 30, 2015

Maybe try setting a breakpoint in your "rawResponseHandler", is the response "ok" ? Does isOkErrorResponse return true?

@morrowsend

isOkErrorResponse returns false.

@winder
Owner
winder commented Jun 30, 2015

JSSCConnection calls "responseMessage" each time it gets the line terminator ("\r\n" or "\n"). "responseMessage" is in BufferedCommunicator which calls "rawResponseListener" in the controller.

I'm not sure why JSSCConnection is not sending "ok", but you need to either figure that out, or make a new "isOkErrorResponse" type function which only returns true at the correct time.

@morrowsend

When I look at the response variable in the debugger, it shows "ok\r" I'll keep playing with it.

@winder
Owner
winder commented Jun 30, 2015

Nice, sounds like you're really close.

@morrowsend

I should have just started from scratch debugging stuff since your last update, all I had to do was set GrblController's isReady true and everything works as expected. The only issue is that I'm getting that nullok error again when I manually move (of course, since I'm getting the two OKs) but everything works more or less. I killed cancelled a job, but it continued to move the steppers until the job was finished, then when I manually jogged it started throwing this kinda thing


[verbose][Error] Error while processing response <ok>: Index: 115, Size: 114ok
[verbose][Error] Error while processing response <ok>: Index: 116, Size: 114ok
[verbose][Error] Error while processing response <ok>: Index: 117, Size: 114ok
>>> G91 G0  Y1
[verbose][Error] Error while processing response <ok>: Index: 118, Size: 115ok
[verbose][Error] Error while processing response <ok>: Index: 119, Size: 115ok
>>> G91 G0  Y1
[verbose][Error] Error while processing response <ok>: Index: 120, Size: 116ok
[verbose][Error] Error while processing response <ok>: Index: 121, Size: 116ok
>>> G91 G0  X1
[verbose][Error] Error while processing response <ok>: Index: 122, Size: 117ok
[verbose][Error] Error while processing response <ok>: Index: 123, Size: 117ok
>>> G91 G0  Y-1
[verbose][Error] Error while processing response <ok>: Index: 124, Size: 118ok
[verbose][Error] Error while processing response <ok>: Index: 125, Size: 118ok

But it kept responding correctly.

@winder
Owner
winder commented Jun 30, 2015

Nice work. You've finally hit the point where you need to figure out a way to deal with the multiple ok messages, you're getting exceptions from completing commands that haven't been sent:

    @Override
    protected void rawResponseHandler(String response) {
        if (GcodeCommand.isOkErrorResponse(response)) {    
            try {
                this.commandComplete(response);
            } catch (Exception e) {
                this.errorMessageForConsole(Localization.getString("controller.error.response")
                        + " <" + response + ">: " + e.getMessage());
            }

            this.messageForConsole(response + "\n");
        }
        ...
    }
@soundstorm
@morrowsend

Sorry for the long delay, I've been traveling and working on my machine's hardware.
So I'm looking at the code, the GcodePreprocessorUtils returns the correct number of G codes in a string. But for the life of me I can't follow the logic through the layers to see where I might be able to use it. Where is it keeping track of how many "ok" messages it receives? Is the list size of "commands" in GcodePreprocessorUtils different from the list size of "commands" in AbstractController? If so, why?

@winder
Owner
winder commented Jul 27, 2015

UGS doesne't keep track of "ok" messages have been received. The GRBL implementation knows that when an "ok" is received it can send more commands. Counting the ok and G commands is something new for Smoothie.

I made some changes to the Communicator code so that sent commands can be tracked. Take a look at XLCDCommunicator.java where I added something like this recently (in this example extra "ok" messages could be sent that needed to be ignored). A nice thing about this is that if Smoothie is the same as Grbl other than this you don't even need a controller: FirmwareUtils.java line 63

@arthurwolf

On Mon, Jul 27, 2015 at 5:00 PM, Will Winder notifications@github.com
wrote:

UGS doesne't keep track of "ok" messages have been received. The GRBL
implementation knows that when an "ok" is received it can send more
commands. Counting the ok and G commands is something new for Smoothie.

Smoothie works exactly the same, as long as you send only one G-code at a
time. This is what it is recommended to do.

I made some changes to the Communicator code so that sent commands can be
tracked. Take a look at XLCDCommunicator.java
https://github.com/winder/Universal-G-Code-Sender/blob/master/src/com/willwinder/universalgcodesender/XLCDCommunicator.java
where I added something like this recently (in this example extra "ok"
messages could be sent that needed to be ignored). A nice thing about this
is that if Smoothie is the same as Grbl other than this you don't even need
a controller: FirmwareUtils.java line 63
https://github.com/winder/Universal-G-Code-Sender/blob/4f326e2830b0f6a2e9b26d5ca0b07d77d287c6cb/src/com/willwinder/universalgcodesender/utils/FirmwareUtils.java#L63


Reply to this email directly or view it on GitHub
#204 (comment)
.

Courage et bonne humeur.

@winder
Owner
winder commented Jul 27, 2015

UGS doesn't send one G-code at a time, which is causing the problem. Most generated gcode files aren't formatted that way either.

Grbl sends an "ok" for each buffer received while Smoothie sends an "ok" for each G-code command within the buffer. That difference seems to be the only problem to get UGS working with Smoothie.

@winder
Owner
winder commented Jul 27, 2015

I don't keep track of the number of ok messages, this is new for Smoothie.

Take a look at how I implemented "XLCDCommunicator", I think you can do
something similar for Smoothie.

On Sunday, July 26, 2015, morrowsend notifications@github.com wrote:

Sorry for the long delay, I've been traveling and working on my machine's
hardware.
So I'm looking at the code, the GcodePreprocessorUtils returns the correct
number of G codes in a string. But for the life of me I can't follow the
logic through the layers to see where I might be able to use it. Where is
it keeping track of how many "ok" messages it receives? Is the list size of
commands in GcodePreprocessorUtils different from the list size of
"commands" in AbstractController? If so, why?


Reply to this email directly or view it on GitHub
#204 (comment)
.

@arthurwolf

I really think it's much simpler to implement to just split lines that
contain several G-codes into several lines, and send each separately.

On Tue, Jul 28, 2015 at 1:42 AM, Will Winder notifications@github.com
wrote:

I don't keep track of the number of ok messages, this is new for Smoothie.

Take a look at how I implemented "XLCDCommunicator", I think you can do
something similar for Smoothie.

On Sunday, July 26, 2015, morrowsend notifications@github.com wrote:

Sorry for the long delay, I've been traveling and working on my machine's
hardware.
So I'm looking at the code, the GcodePreprocessorUtils returns the
correct
number of G codes in a string. But for the life of me I can't follow the
logic through the layers to see where I might be able to use it. Where is
it keeping track of how many "ok" messages it receives? Is the list size
of
commands in GcodePreprocessorUtils different from the list size of
"commands" in AbstractController? If so, why?


Reply to this email directly or view it on GitHub
<
#204 (comment)

.


Reply to this email directly or view it on GitHub
#204 (comment)
.

Courage et bonne humeur.

@winder
Owner
winder commented Jul 28, 2015

I'll consider an option like that for the future.

You might consider updating the reference sender implementation to do this: https://github.com/Smoothieware/Smoothieware/blob/edge/smoothie-stream.py

@arthurwolf

Hey everybody ! Does anybody know the status of this, and if Smoothie is now supported by UGS ?

@wolfmanjm

FYI the https://github.com/Smoothieware/Smoothieware/blob/edge/smoothie-stream.py is for streaming over TCP/IP NOT for USB, it is important because TCP/IP handles the flow control whereas Serial/USB does not.
It is important with Smoothie over serial to only send a new G code when the previous one has sent ok, unlike GRBL you must not presume there is buffer space and send a bunch of gcodes and then count ok. The rule is one G/M code one ok, do not send another until the previous has been ok'd.

Sending Ok on each gcode/mcode is actually part of the gcode standard AFAIK so I am surprised GRBL does not comply with that. (if someone can show me where it says one ok per line vs one ok per G/M code I'll try to fix it in Smoothie).

@chamnit
chamnit commented Sep 1, 2015

@wolfmanjm : Could you point me to where the g-code standard says to respond with an ok on each gcode/mcode? AFAIK, it's undefined. IMHO, it's more important that the g-code block is read and error checked in the whole context of the block, rather than single commands.

@winder
Owner
winder commented Sep 1, 2015

@arthurwolf I thought this was a simple exercise to add Smoothie support, so I was leaving it to @morrowsend since he had done a lot of the legwork.

@wolfmanjm what is Smoothies buffer size? UGS does manage flow control to ensure that queued commands remain under a configurable byte threshold. For GRBL multiple commands need to be sent in order to maximize whats available for path optimization.

@wolfmanjm

@winder You cannot presume any buffer size for smoothie thus the rule that every other sender uses (printerface, octoprint etc) is you must not send another gcode until the previous one has sent ok.
Violating that will likely cause severe errors.

@chamnit looking.... ;)

@chamnit
chamnit commented Sep 1, 2015

@winder : FYI, I'm pondering on whether or not to eliminate the character-counting protocol. While much more efficient by better utilizing the bi-directional serial RX/TX, it has some problems. One of which cropped up yesterday when sending data during an EEPROM write (g10). While rare, the GUI should monitor these types of commands and make exceptions for full robustness. Not great, but i'm working on another solution.

You may want to have UGS have an option to use the simple send-and-wait-for-response when using Grbl. You'll run into performance issues only when streaming lots of small line segments very fast. It's not common.

@winder
Owner
winder commented Sep 1, 2015

@chamnit I do have a send-and-wait mode that can be enabled - I actually added it originally for the EEPROM issue. I don't chop up lines with multiple G/M codes though.

@chamnit
chamnit commented Sep 1, 2015

@winder : Excellent! Nevermind then. :)

@splitn2
splitn2 commented Sep 1, 2015

I might be a bit naive here guys, so please excuse me , but as I am evaluating GRBL and UGS on my bench in testing and also as I develop an understanding of your plans to develop GRBL it does make me wonder why there is so much effort going into the serial / USB streaming and still we are dealing the risks that this serial streaming of GCODE apparently introduces.

I have read that one future development is to incorporate a flash memory SD card as a repository for GCODE, so effectively the Arduino GRBL can execute the gcode file straight out of local memory. No running out of serial stream no worrying about any loss of chars in real time cnc operation surely is a priority.

This seems to me the natural way to go. Is this only awaiting further GRBL tweaking so that it can fit into an Uno or does it need a Mega so we have IO lines to talk to a flash shield?

My point is that if efforts were focused on getting the flash based storage for gcode built in to the GRBL then you could collaboratively focus other effort on a monitoring system that used the serial USB stream upwards to a program more like GRBL Monitor , that is informed command by command what is being executed in GCODE and also is updated far more often about the true position of the XYZ.

There will be many reasons why I am wrong I am sure but I am just putting my thoughts out there as I see so much discussion on serial streaming but is that worth the effort in the long term?
@chamnit @winder your thoughts? cheers, Rich

@chamnit
chamnit commented Sep 1, 2015

@splitn2 : Not adding an SD card capability has kept Grbl simple during its development, which is nearing the end of its first phase. A serial interface is also universal. It can talk with computers via USB-serial in just about every programming language and talk with other ICs through direct serial connections. This lends to a proliferation of interesting applications like browser-based solutions. It also keeps the Grbl microcontroller having to do too much, so it can do what it's supposed to do robustly and efficiently.

That said, more on-board storage does make sense in the near future, but you still have to get that data onto the SD-card somehow. Either by streaming data to it (same problem), or sneaker-net, which isn't ideal either.

@splitn2
splitn2 commented Sep 1, 2015

I guess my point is streaming to the Arduino and into SD ram can be "out of band" and not so time critical and not impacting real time CNC gcode parsing and movement. Streaming a file to the GRBL can end with a checksum so we know all the data has been precisely received by the Arduino into SD ram, then it can be executed with full memory speed bandwidth allowing GRBL to look ahead as many instructions as it wants to and let the planner work most efficiently? Flow control and error checking should be all part of file transfer natively.

I agree with you it sounds like both have their benefits depending on what you want to do, browser based interaction with the GRBL sounds like it needs to be driven from the browser / pc end whereas for headless and time critical operations perhaps local SD ram based gcode might be more reliable?

Great work anyway guys and I know you are far more versed on this than me I am just very interested in what you are doing. I do wish I could program well but my mind does not process code well these days, In a former life as a Telecommunications and Electronics technician I managed several large repair centres, in one company I coded some quite badly written assembler on 8051 and an enhanced version of Z80 processor that was used to control a retail POS system (cash register) but this is so long ago and I never took it to next level in C it was always in assembler. This helped me understand microcontrollers a lot better and in fact consolidated my electronics training and microprocessor fundamentals nicely - I could directly see the electronics and computing working. Using data analysers I could see my bits and bytes, reads and writes to io or memory etc, it was fun and I understood it to the nuts and bolts level so to speak. These days my patience and also my ability to focus on relatively simple bits of code is surprisingly poor I suspect that comes from too much beer and bad eyesight and poor memory but I do find this extremely interesting none the less!

cheers
Rich
@chamnit @winder

@AlexHolden

@chamnit I've found in testing with my own GUI that the streaming protocol greatly speeds up checking a program. Sending a roughly 14,000 line test file in check mode with the streaming protocol takes 17 seconds; with the call-response protocol it takes 1 minute 11 seconds. Scale that up to a really long program and the wait could get frustrating.

I'm considering implementing an option where I normally send using call-response but automatically switch to streaming if grbl is in check mode.

P.S. I implemented a feature where I automatically pause streaming and wait for an OK if the block I just sent contained a one of the commands in the list I put in grbl ticket #779.

@winder
Owner
winder commented Jul 1, 2016

I spent some time refactoring to the gcode parser in UGS so that I can reformat gcode more easily to support different controllers. In this case making sure G/M codes are split up if the CAM software decides to put more than one of them on the same line.

Could someone with a smoothie board get in contact with me (see my github profile) to help test out a prototype solution?
Alternatively add gcp.addCommandProcessor(new CommandSplitter()); to this line.

Thanks!

@GeorgeIoak
GeorgeIoak commented Jul 1, 2016 edited

I’ve got some time and could test some code for you. I haven’t messed with the smoothie board in a while so I’ll have to dust off some cob webs (both in my brain and on the board!)

@winder
Owner
winder commented Jul 31, 2016

The UGS nightly build now has a smoothie firmware option which configures the gcode parser according to smoothies requirements. Could someone with a smoothie could give it a try and let me know how it works?

@jahnj0584

There was someone in the OXbuilds google+ group who JUST posted about their smoothie not working. Post there?

@wolfmanjm

FWIW smoothie was changed many months ago to send one ok per line regardless of how many gcodes are on that line. (it used to send an ok per gcode, it no longer does that).

Also note that unlike for grbl you must NOT send any lines until the previous line has replied ok, we do not have a serial buffer like grbl does, we only have a planner queue, and you must not send a line before the previous one has replied ok otherwise all hell will break loose :)

@tigerpolis

I tried both nightly builds but i just get this:
**** Connected to /dev/tty.usbmodem14111 @ 57600 baud ****
Smoothie
Error while processing response : nullok
HALTED, M999 or $X to exit HALT state

@arthurwolf

This sounds like an error triggered smoothie-side, this might be unrelated
to UGC. Do things work if you use Pronterface ? What type of machine is
this ?

On Thu, Aug 25, 2016 at 10:07 AM, tigerpolis notifications@github.com
wrote:

I tried both nightly builds but i just get this:
**** Connected to /dev/tty.usbmodem14111 @ 57600 baud ****
Smoothie
Error while processing response : nullok
HALTED, M999 or $X to exit HALT state


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#204 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpFcerj4jLRVjyzdHXozi-41qrcC1lks5qjU1GgaJpZM4C8M00
.

Courage et bonne humeur.

@tigerpolis

Yes things work with pronterface! It's a cnc mill!

@tigerpolis

Although I'm having some issues with my VFD+Spindle and usb connection. But this is only when i turn on the spindle, so i don't think thats related to the UGC error!

@arthurwolf

If it works in pronterface, you need to use pronterface, and get the error
to happen there, as that will show you the full error message, and you will
know what the error is then. Are limit switches enabled ?

On Thu, Aug 25, 2016 at 11:20 AM, tigerpolis notifications@github.com
wrote:

Yes things work with pronterface! It's a cnc mill!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#204 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpFZFJ4gvtlrL6no0ZwhK93n7tevMxks5qjV5wgaJpZM4C8M00
.

Courage et bonne humeur.

@tigerpolis

The error never happens in pronterface, just with UGC when i start the connection. Yes i have limit/home for x and y min, works in pronterface as well.

@winder
Owner
winder commented Aug 25, 2016

Looking back in this thread it looks like there might have been a couple other changes @morrowsend had made. It seems like there might be a little more work to get UGS to interface with Smoothie.

One change is to remove the 0x18 byte which is normally sent to reset GRBL, the other is changing line endings from \r\n to \n.

@wolfmanjm

@winder Control X is the problem here, it does not reset smoothie (that would be reset and is not needed). Control X puts the sysem into Alarm state. Also as Smoothie has many GRBL features now it needs to be put into grbl mode by adding grbl_mode true to the config. However it certainly is not 100% grbl compatible, I just added things like $G etc

@wolfmanjm

\r\n is fine too, although\n is less to send :)

@winder
Owner
winder commented Aug 25, 2016

@wolfmanjm Thanks for the feedback

@tigerpolis if you could try the nightly build, I removed the Ctrl-C and added a call to version. Also setting grbl_mode true in smoothie should help as well, UGS does use $G (this could be modified in SmoothieController to use the smoothie native calls for this operation.

@tigerpolis
tigerpolis commented Aug 25, 2016 edited

I will try it tomorrow! I can download the new build from this link ↓ right? (I'm quite new to github)
ugs

@winder
Owner
winder commented Aug 25, 2016

Yep, thanks

On Thursday, August 25, 2016, tigerpolis notifications@github.com wrote:

I will try it tomorrow! I can download the new build from this link right?
[image: ugs]
https://cloud.githubusercontent.com/assets/21237130/17985943/9a4bc048-6b18-11e6-95de-3221d9f1a3c1.PNG


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#204 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHqRRx6wzDs5bQi6JjXZhpIFRm_sVKFks5qjgP9gaJpZM4C8M00
.

@tigerpolis

Not working :/ just getting this now:
screen shot 2016-08-26 at 09 43 58

@winder
Owner
winder commented Aug 26, 2016

@tigerpolis I fixed these two errors. Looking back in this issue the nullok issue was happening because of \r\n - I'm thinking maybe Smoothie responded twice (once for each line terminator) which would confuse UGS. The other error was because I sent the version request too early (I also added a new error message so it will say Smoothie has not finished booting.

@wolfmanjm

@winder smoothie ignores \r, so would not send ok twice.

@winder
Owner
winder commented Aug 26, 2016

@wolfmanjm I was basing that off of a comment from last year:

So changing the line terminator to "/n" only in GrblCommunicator removed the weird "nullok"

@tigerpolis

I will see if i can check the new build this weekend, otherwise on Monday! Thanks!

@tigerpolis

Ok so there is some progress, i can now connect and move the machine, but only 9 steps then it becomes unresponsive in all directions. Also i get some weird message:
screen shot 2016-08-29 at 08 47 41

@winder
Owner
winder commented Aug 29, 2016

@tigerpolis I just made another change to make sure single-step mode is enabled for Smoothie.

@tigerpolis

Now i can only move one time then when i click again nothing happens, no error, nothing! Have to disconnect then connect again to move one step again!

@winder
Owner
winder commented Sep 7, 2016

It seems like there is more to this than I expected. I'm not sure I'll be able to trouble shoot this remotely.

@cheton cheton referenced this issue in cheton/cnc Nov 23, 2016
Open

Smoothieware support #94

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment