Connecting with GRBL 4 axis driver problem.

[rainharvester]

Hello Experts,

I can't connect with the GRBL driver (4 axis at https://github.com/openpnp/grbl)

After pressing the green power button icon, I get "Timeout waiting for response to G21; Set millimeters mode".

I can type $ into openPNP and get a response from GRBL.  So my baud/com is good. (But if I do this before clicking the green power Icon, I don't get a response.  Interesting but probably not relevant.) I can also issue commands with UniversalGCodeSender (so baud/ port is good).

I read a lot of posts and followed the recommendations:

1) I recompiled GRBL to a modified version : changed the GRBL version from 0.9g  to 0.91.

2) I tried changing the COMMAND_CONFIRM_REGEX from  "^ok.*" to "ok.*".

G21 ; Set millimeters mode

G90 ; Set absolute positioning mode

M82 ; Set absolute mode for extruder

If I remove all the above from the "CONNECT_COMMAND",then click the power button, the power button icon turns RED.  But then pressing the "Jog /Arrow keys", gives another "timeout waiting for response".

Here is my Debug log.  Any ideas?

2017-09-02 21:13:30 Main DEBUG: Bienvenue, Willkommen, Hello, Namaskar, Welkom to OpenPnP version 2017-08-29_16-42-37.ca7141e.

2017-09-02 21:13:30 Scripting TRACE: Scripting.on Startup

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_POS_MSEC = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_POS_FRAMES = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_POS_AVI_RATIO = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FRAME_WIDTH = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FRAME_HEIGHT = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FPS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FOURCC = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FRAME_COUNT = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FORMAT = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_MODE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_BRIGHTNESS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_CONTRAST = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_SATURATION = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_HUE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_GAIN = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_EXPOSURE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_CONVERT_RGB = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_WHITE_BALANCE_BLUE_U = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_RECTIFICATION = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_MONOCHROME = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_SHARPNESS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_AUTO_EXPOSURE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_GAMMA = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_TEMPERATURE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_TRIGGER = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_TRIGGER_DELAY = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_WHITE_BALANCE_RED_V = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_ZOOM = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_FOCUS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_GUID = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_ISO_SPEED = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_BACKLIGHT = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_PAN = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_TILT = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_ROLL = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_IRIS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_SETTINGS = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_BUFFERSIZE = 0.0

2017-09-02 21:13:31 OpenCvCamera TRACE: OpenCvCamera CAP_PROP_AUTOFOCUS = 0.0

2017-09-02 21:14:27 GcodeDriver DEBUG: sendCommand($, 5000)...

2017-09-02 21:14:27 GcodeDriver TRACE: [COM6] >> $

2017-09-02 21:14:27 GcodeDriverConsole DEBUG: Gcode console error: java.lang.NullPointerException

2017-09-02 21:14:43 GcodeDriver DEBUG: sendCommand($, 5000)...

2017-09-02 21:14:43 GcodeDriver TRACE: [COM6] >> $

2017-09-02 21:14:43 GcodeDriverConsole DEBUG: Gcode console error: java.lang.NullPointerException

2017-09-02 21:14:45 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:14:46 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:14:46 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:14:46 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...

2017-09-02 21:14:46 GcodeDriver TRACE: [COM6] >> G21 ; Set millimeters mode

2017-09-02 21:14:46 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:14:51 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; Set millimeters mode

2017-09-02 21:14:54 GcodeDriver DEBUG: sendCommand($, 5000)...

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] >> $

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $$ (view Grbl settings)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $# (view # parameters)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $G (view parser state)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $I (view build info)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $N (view startup blocks)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $x=value (save Grbl setting)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $Nx=line (save startup block)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $C (check gcode mode)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $X (kill alarm lock)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << $H (run homing cycle)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << ~ (cycle start)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << ! (feed hold)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << ? (current status)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << ctrl-x (reset Grbl)

2017-09-02 21:14:54 GcodeDriver TRACE: [COM6] << ok

2017-09-02 21:14:54 GcodeDriver DEBUG: sendCommand(COM6 $, 5000) => [$$ (view Grbl settings), $# (view # parameters), $G (view parser state), $I (view build info), $N (view startup blocks), $x=value (save Grbl setting), $Nx=line (save startup block), $C (check gcode mode), $X (kill alarm lock), $H (run homing cycle), ~ (cycle start), ! (feed hold), ? (current status), ctrl-x (reset Grbl), ok]

2017-09-02 21:15:28 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:15:29 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:15:29 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:15:29 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...

2017-09-02 21:15:29 GcodeDriver TRACE: [COM6] >> G21 ; Set millimeters mode

2017-09-02 21:15:29 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:15:34 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; Set millimeters mode

2017-09-02 21:16:21 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:16:22 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:16:23 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:16:23 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...

2017-09-02 21:16:23 GcodeDriver TRACE: [COM6] >> G21 ; Set millimeters mode

2017-09-02 21:16:23 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:16:28 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; Set millimeters mode

[rainharvester]

PS, here is my machine.xml file

[rainharvester]

The weird thing is that I can type a "G21" into the openPNP command window and I get an "ok" response,

"    GcodeDriver DEBUG: sendCommand(COM6 G21, 5000) => [ok]"

But, if I hit the power button icon, I get,

"    GcodeDriver TRACE: [COM6] << error: Expected command letter"

Complete log below:

2017-09-02 21:53:57 Main DEBUG: Bienvenue, Willkommen, Hello, Namaskar, Welkom to OpenPnP version 2017-08-29_16-42-37.ca7141e.

2017-09-02 21:53:57 Scripting TRACE: Scripting.on Startup

2017-09-02 21:54:06 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:54:07 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:54:08 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:54:08 GcodeDriver DEBUG: sendCommand(G21 ; Set millimeters mode, 5000)...

2017-09-02 21:54:08 GcodeDriver TRACE: [COM6] >> G21 ; Set millimeters mode

2017-09-02 21:54:08 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:54:13 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21 ; Set millimeters mode

2017-09-02 21:56:08 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:56:09 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:56:10 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:56:10 GcodeDriver DEBUG: sendCommand(G21, 5000)...

2017-09-02 21:56:10 GcodeDriver TRACE: [COM6] >> G21

2017-09-02 21:56:10 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:56:15 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to G21

2017-09-02 21:56:34 ReferenceMachine DEBUG: setEnabled(true)

2017-09-02 21:56:36 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-02 21:56:36 GcodeDriver DEBUG: sendCommand(COM6 null, 250) => []

2017-09-02 21:56:36 GcodeDriver DEBUG: sendCommand(g21, 5000)...

2017-09-02 21:56:36 GcodeDriver TRACE: [COM6] >> g21

2017-09-02 21:56:36 GcodeDriver TRACE: [COM6] << error: Expected command letter

2017-09-02 21:56:41 MessageBoxes DEBUG: Enable Failure: Timeout waiting for response to g21

2017-09-02 21:56:54 GcodeDriver DEBUG: sendCommand(G21, 5000)...

2017-09-02 21:56:54 GcodeDriver TRACE: [COM6] >> G21

2017-09-02 21:56:54 GcodeDriver TRACE: [COM6] << ok

2017-09-02 21:56:54 GcodeDriver DEBUG: sendCommand(COM6 G21, 5000) => [ok]

[Jason von Nieda]

Try removing the comments from the Gcodes. e.g. change "G21 ; Set millimeters mode" to "G21". I don't remember offhand if Grbl supports comments, but that's the only thing that really jumps out to me.

I also recommend not messing around in the console before clicking the power on button as the state of the driver can get a bit confused.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7caa97a6-da6a-48ec-b463-009afedfb391%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[rainharvester]

Thanks Jason,

That was the first thing I tried but it didn't help. I also tried lower case.

The 2 commands shown in the debug log are structured differently, but I don't know if that should matter.

[Jason von Nieda]

Okay, going to test this locally real quick. Stand by.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/20876667-c043-4f9d-bf77-64462ee84fd2%40googlegroups.com.

[Jason von Nieda]

Okay, I just ran a quick test with a fresh copy of Grbl-Mega using the attached machine.xml and it connects fine.

What I'd suggest is:

1. Try the machine.xml attached and see if it just works. If so, great.

2. If not, try getting a fresh (non OpenPnP) copy of Grbl or Grbl-Mega, depending on what board you are using, and try with that. It could be something in the OpenPnP fork causing problems.

3. If that works but the OpenPnP fork doesn't, we probably need to consider trying to merge in the changes that have been made since the fork. That fork has seen no updates in like 3 years. 

Jason

[Cri S]

Grbl don't support the semicolon type comments, only the standard ( bracket ) type comments.

Il domenica 3 settembre 2017, Jason von Nieda <ja...@vonnieda.org> ha scritto:

Okay, I just ran a quick test with a fresh copy of Grbl-Mega using the attached machine.xml and it connects fine.

What I'd suggest is:

1. Try the machine.xml attached and see if it just works. If so, great.

2. If not, try getting a fresh (non OpenPnP) copy of Grbl or Grbl-Mega, depending on what board you are using, and try with that. It could be something in the OpenPnP fork causing problems.

3. If that works but the OpenPnP fork doesn't, we probably need to consider trying to merge in the changes that have been made since the fork. That fork has seen no updates in like 3 years. 

Jason

On Sat, Sep 2, 2017 at 11:40 PM Jason von Nieda <ja...@vonnieda.org> wrote:

Okay, going to test this locally real quick. Stand by.

On Sat, Sep 2, 2017 at 10:41 PM rainharvester <rainha...@gmail.com> wrote:

Thanks Jason,

That was the first thing I tried but it didn't help.  I also tried lower case.

The 2 commands shown in the debug log are structured differently, but I don't know if that should matter.


--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/20876667-c043-4f9d-bf77-64462ee84fd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyPepTXfDj-L9AABpqxAP7WO-TeQHiR40R9EeM64vH4Lw%40mail.gmail.com.

[rainharvester]

Thanks experts!

Here is a verbose reply for others to benefit too:

1) Using your .xml didn't affect the bug.

2) I loaded official (3axis), grbl-mega-1.1f.20170802 from "https://github.com/gnea/grbl-Mega/releases"

     and it worked (ie pressing the powerButton icon worked.)

    I still removed the ";" and rest of the comment from MachineSetup->Driver->GcodeDriver->Gcode(TAB)->Setting->CONNECT_COMMAND.  

    The bad comments, don't matter because I think the error returned from GRBL is ignored.  I removed it anyway to avoid future problems.

    

    Also, I had to remove the 3rd line, "M85", from the save CONNECT_COMMAND.

Other:

It looks like the"^" in the  "^ok.*" COMMAND_CONFIRM_REGEX is fine to keep.

I tried jogging and got, "Timeout waiting for response to M400".  M400 is in the MOVE_TO_COMMAND which presumably needs to be setup (along with a lot of other GRBL specific commands).

So now, I have 3 axis connected.  But still need the 4th axis.

Did I use the lastest 4axis grbl (address given in 1st post)?  I looked for a more recent version through this forum but didn't see anything but an old 6-axis grbl which I avoided because electrokean said it "will slightly limit your maximum pulse rate", and I got the feeling it was untested / unsupported.  Also, it is as old as this 4-axis grbl so might have the same connection bug.

Is anyone else using 4-axis GRBL-mega?  If so, how?

[Cri S]

instead of m400 you must use G4P0 and COMMAND_ERROR_REGEX is missing.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to openpnp+u...@googlegroups.com.

> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/cee8e1fe-deb0-4c7c-92e4-52dcc7e3d325%40googlegroups.com.

[Jason von Nieda]

Thanks for the update. Yes, you used the latest version. Unfortunately the latest is extremely out of date. It was created when there were no better options, but now we typically don't recommend using Grbl for pick and place.

So, here is what I'd suggest at this point:

1. Switch to Smoothie if possible. Grbl just isn't really suited for PnP and IMHO it's more trouble than it's worth. More information about that at https://github.com/openpnp/openpnp/wiki/Motion-Controllers.

2. If you really need to use Grbl for some reason, we're going to need to figure out what the difference is between the commands being sent from the console and the driver. It should be the same, but clearly we're missing something.

3. Another avenue to explore is how hard it would be to port the 4th axis changes in the OpenPnP fork to the current latest Grbl code. The original changes were not extensive, so it might be a day or two of work.

So, let me know your thoughts on dumping Grbl and in the meantime I will try to get that old fork up and running and see if anything jumps out to me as to why it's not working. It could be something as silly as a line ending difference, or just a buffer that needs to be cleared. 

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cee8e1fe-deb0-4c7c-92e4-52dcc7e3d325%40googlegroups.com.

[Cri S]

This "old" version is more stable as the newest grbl for pnp operation
as the newest have
several issues that affect pnp operation.
As no modification was made to configuration, probably the M400 instead of G4P0
and E axis instead of C axis .and the OK and ERROR regex need to be modified,
and for the GCODE driver the reset character in order that it can be send down.

In contrast, the newest version could run on smoothie hardware..

>> <https://groups.google.com/d/msgid/openpnp/cee8e1fe-deb0-4c7c-92e4-52dcc7e3d325%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

>> For more options, visit https://groups.google.com/d/optout.
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyWOf3gbQN%3DSt2FB_HMdxLjwvUsx4vPi9R8jK1jUty-nw%40mail.gmail.com.

[rainharvester]

Thank you Jason.

Here is a head start. 

I found 4 extra mystery characters being sent from OpenPNP to 4-axis-GRBL before the G21, "????G21".

If I echo them back to openPNP (so I can debug/see them),  these ???? show up in the openPNP log as squares, but when I copy the log to this post, they aren't printed (not even whitespace).

So I typed the ???? in the following line, which I pasted from openPNP's log window:

     2017-09-03 15:49:02 GcodeDriver TRACE: [COM6] << ????G90 error: Expected command letter

I diffed the GRBL sources and found some jog related stuff to skip 3 characters, '$J='.

I did an if-check in the GRBL code to see if the 1st char was a '$', and it was not.

So not sure how the new GRBL is skipping those 4 characters.

FYI - you can print stuff from GRBL to openPNP log file by doing something like this near line 133:

    

printString("start:");

   if (line[0] == '$')

   {

       printString("dollarSign:"); // Just to make sure the $ wasn't there, although it should print.

   }

   

   ss = line;

   //ss = line[4];

   printString(ss);

[rainharvester]

This is a total *hack* but might give a clue as to where the true problem lies:

In 4-axis grbl's gcode.c at line 129ish, I put this code:

  uint8_t mantissa = 0; // NOTE: For mantissa values > 255, variable type must be changed to uint16_t.

#if 1// rainharvester

  static int firstTime = 1;

  if (firstTime)

  {

    char_counter = 4;

    firstTime = 0;

    printString("FIRST TIME EVER\r\n");

  }

#endif

Then, remove all the semicolons and comments in the openPNP settings:

        MachineSetup->Driver->GcodeDriver->Gcode(TAB)->Setting->CONNECT_COMMAND. 

        MachineSetup->Driver->GcodeDriver->Gcode(TAB)->Setting->MOVE_TO_COMMAND.  

Also, remove the 3rd line, "M85", from the save CONNECT_COMMAND.  G4P0 seems to be ignored ( by GRBL?)

This lets the GRBL connect, and jogs work (except for rotate. Rotate still uses E as Cri S noted.

*note: since GRBL runs while plugged in, and the hack keeps track of the "static int firstTime", it is necessary to unplug /plug-in the Mega and start the OpenPNP.  

Its a total hack, but it shows that only the first time ever that GRBL is invoked, do the 1st 4 bad/unicode characters get sent from openPNP to GRBL.  The bad characters also get sent if the command doesn't succeed, that is why hitting the power button twice did not work...hmm....

[Cri S]

2017-09-04 1:03 GMT+02:00, rainharvester <rainha...@gmail.com>:
> This is a total *hack* but might give a clue as to where the true problem
> lies:
>
> In 4-axis grbl's gcode.c at line 129ish, I put this code:
>
> uint8_t mantissa = 0; // NOTE: For mantissa values > 255, variable type
> must be changed to uint16_t.
>

> *#if 1// rainharvester*
>
> * static int firstTime = 1;*
> * if (firstTime)*
> * {*
> * char_counter = 4;*
> * firstTime = 0;*
> * printString("FIRST TIME EVER\r\n");*
> * }*
> *#endif*

>
>
> Then, remove all the semicolons and comments in the openPNP settings:
>
> MachineSetup->Driver->GcodeDriver->Gcode(TAB)->Setting->CONNECT_COMMAND.
>
> MachineSetup->Driver->GcodeDriver->Gcode(TAB)->Setting->MOVE_TO_COMMAND.
> Also, remove the 3rd line, "M85", from the save CONNECT_COMMAND. G4P0
> seems to be ignored ( by GRBL?)
>
> This lets the GRBL connect, and jogs work (except for rotate. Rotate still
> uses E as Cri S noted.
>
> *note: since GRBL runs while plugged in, and the hack keeps track of the

> "static int *firstTime"*, it is necessary to unplug /plug-in the Mega and

> start the OpenPNP.
>
> Its a total hack, but it shows that only the first time ever that GRBL is
> invoked, do the 1st 4 bad/unicode characters get sent from openPNP to GRBL.
>
> The bad characters also get sent if the command doesn't succeed, that is
> why hitting the power button twice did not work...hmm....
>

> --
> You received this message because you are subscribed to the Google Groups
> "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/1fdd65e2-53ac-47f0-81bd-9921ad9864f5%40googlegroups.com.

[Cri S]

You must change the CMD_RESET 0x18 inside config.h in order to map it
to printable character in order gcode-driver can send it down.
The 4 characters are probably the UNICODE BOM, but that don't matter,
it is important to send several soft-reset commands down on connect/disconnect.
And important, you must include the CONNECT string to the OK connect
regex, otherwise
the driver cannot work correctly during homing.

[Jason von Nieda]

The question marks are characters that can't be mapped to the String encoding being used, and it's possible that that is where the issue is. We may have an encoding problem somewhere. Here are some things to try:

1. Zip your machine.xml and send it to me. I'll open it in a hex editor and make sure there's nothing hiding in there that we don't expect.

2. In your Grbl code, for each character received, print the decimal value of it. This will let us determine what actual characters are being sent. You should be able to replace line 135 with something like this:

    if((letter < 'A') || (letter > 'Z')) { 

      for (int i = 0; i < 4; i++) {

        printInteger(line[i]);

      }

      FAIL(STATUS_EXPECTED_COMMAND_LETTER); 

    } // [Expected word letter]

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b40ec8a4-8728-4a79-ae27-a64a92f25903%40googlegroups.com.

[Jason von Nieda]

I was finally able to get this version of Grbl built and running here, so I'm digging in to see if I can see what's up.

Jason

[Jason von Nieda]

Alright, believe I've got this sorted. In your GcodeDriver settings under the General Settings tab, change Connect Wait Time from 1000 to 3000 and make sure that none of your Gcode commands contain the semicolon comments.

Here is what is happening, and how I found it:

I added this code at line 135:

    if((letter < 'A') || (letter > 'Z')) { 

      for (i = 0; i < 4; i++) {

        print_uint8_base10(line[char_counter + i]);

        printString("\n");

      }

      FAIL(STATUS_EXPECTED_COMMAND_LETTER); 

    } // [Expected word letter]

When I ran this and attempted to connect I got:

59

83

69

85

Which corresponds to ";SET" in ASCII. This told me that Grbl was seeing the comment rather than the start of the command, and that it is stripping spaces and changing the input to upper case.

With it missing the start of the command, I suspected that something was out of sync, and I noticed that when I connect there is a > 1 second delay before I would see the welcome message. OpenPnP was only waiting 1 second before sending the connect command, so part of the command was getting lost in the buffer before Grbl was awake. 

Changing the startup wait time to 3 seconds resolved it and here is the log:

2017-09-03 22:10:57 Main DEBUG: Bienvenue, Willkommen, Hello, Namaskar, Welkom to OpenPnP version INTERNAL BUILD.

2017-09-03 22:10:57 Scripting TRACE: Scripting.on Startup

2017-09-03 22:10:57 Scripting TRACE: Scripting.on found Startup.js

2017-09-03 22:11:02 ReferenceMachine DEBUG: setEnabled(true)

2017-09-03 22:11:03 GcodeDriver TRACE: [/dev/tty.usbmodem1421] << Grbl 0.9g ['$' for help]

2017-09-03 22:11:05 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-03 22:11:05 GcodeDriver DEBUG: sendCommand(/dev/tty.usbmodem1421 null, 250) => [Grbl 0.9g ['$' for help]]

2017-09-03 22:11:05 GcodeDriver DEBUG: sendCommand(null, 250)...

2017-09-03 22:11:06 GcodeDriver DEBUG: sendCommand(/dev/tty.usbmodem1421 null, 250) => []

2017-09-03 22:11:06 GcodeDriver DEBUG: sendCommand(G21, 5000)...

2017-09-03 22:11:06 GcodeDriver TRACE: [/dev/tty.usbmodem1421] >> G21

2017-09-03 22:11:06 GcodeDriver TRACE: [/dev/tty.usbmodem1421] << ok

2017-09-03 22:11:06 GcodeDriver DEBUG: sendCommand(/dev/tty.usbmodem1421 G21, 5000) => [ok]

2017-09-03 22:11:06 GcodeDriver DEBUG: sendCommand(G90, 5000)...

2017-09-03 22:11:06 GcodeDriver TRACE: [/dev/tty.usbmodem1421] >> G90

2017-09-03 22:11:06 GcodeDriver TRACE: [/dev/tty.usbmodem1421] << ok

2017-09-03 22:11:06 GcodeDriver DEBUG: sendCommand(/dev/tty.usbmodem1421 G90, 5000) => [ok]

So, give that a shot and let me know how it goes!

Jason

[Jason von Nieda]

Oh, forgot to mention: I had to remove the semicolon comments because even with the timeout set correctly I would get the same response. Looks like this old version of Grbl doesn't handle the semicolon comments, although the current code (from Grbl, not OpenPnP) does.

Jason

[rainharvester]

Increasing from 1000 ms to 3000 ms (and removing all semicolon and comments) did not work for me.

In my case, I get all the characters, and 4 extra characters at the beginning (I'm not missing the "G21" characters, which the 3000 ms seems to have solved for you.).

I printed out the decimal for the 4 extra characters and they are all 240:

2017-09-04 07:35:05 GcodeDriver DEBUG: sendCommand(G21, 5000)...

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] >> G21

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 240

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 240

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 240

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 240

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 71

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 50

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 49

2017-09-04 07:35:05 GcodeDriver TRACE: [COM6] << 0

I'm using openPNP # 2017-08-29.

[rainharvester]

Also, it seems like increasing the Connect Wait Time from 1000ms to 3000ms would allow more characters at the end of the string of characters to get sent ( not skip the beginning 4 extra characters).

So I'm confused how that worked for you.

I did an experiment and changed my Connect Wait Time to 100ms.  It still connected (with my hack to drop the 4 extra characters, and no semicolon comments).

fyi - the decimal 240 characters = hex 0xF0, if that rings a bell.

[Jason von Nieda]

Okay, that does appear to be some kind of encoding issue. Can you zip and send your machine.xml please? It would also help me to know what country/language your computer is set up to use.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b28e188a-65e3-4b90-b299-8ec6faf0ded7%40googlegroups.com.

[Jason von Nieda]

Just found https://stackoverflow.com/questions/25615359/extra-bytes-sent-when-communicating-at-115200-baud-over-usb-serial-winapi which sounds an awful lot like what we're seeing. Can you rebuild Grbl for 19200 and try that? Don't forget to remove your 4 byte workaround, make sure flow control is off, and make sure you restart OpenPnP each time you try to connect. It will only connect once during a session.

Jason

[rainharvester]

I think I found it.

The 3-axis GRBL has extra code to skip chars > 0x7F.

When I add that code to the old 4-axis-GRBL, I can connect (still removed semicolon and comments).

Serial.C Around line 182:

    default: // Write character to buffer    

 #if 1// rainharvester

       if (data > 0x7F) { // Real-time control characters are extended ACSII only.

        // Throw away any unfound extended-ASCII character by not passing it to the serial buffer.

      } else { // Write character to buffer

 #endif

      next_head = serial_rx_buffer_head + 1;

      if (next_head == RX_BUFFER_SIZE) { next_head = 0; }

    

      // Write data to buffer unless it is full.

      if (next_head != serial_rx_buffer_tail) {

        serial_rx_buffer[serial_rx_buffer_head] = data;

        serial_rx_buffer_head = next_head;    

        

        #ifdef ENABLE_XONXOFF

          if ((serial_get_rx_buffer_count() >= RX_BUFFER_FULL) && flow_ctrl == XON_SENT) {

            flow_ctrl = SEND_XOFF;

            UCSR0B |=  (1 << UDRIE0); // Force TX

          } 

        #endif

        

      }

      //TODO: else alarm on overflow?

#if 1// rainharvester

      } //else { // Write character to buffer

#endif

[rainharvester]

Hi Jason, Just saw your 2 preceeding posts.  And, yes, I found a lot web-talk of 0xF0 being mysteriously recieved by Arduino upon init of the its serial.

So it looks like the latest 3-axis GRBL compensated for it (on accident?).

Still not sure how that delay solved your problem.  Maybe you never got the extra 4 chars on your system.

My computer is setup for USA / english.

(had some spelling mistakes in the deleted post)

[Jason von Nieda]

Nice work! That explains why the new worked when the old didn't, but I'm still very curious as to where those characters are coming from. Glad to hear it's working, though!

The reason the delay solved my problem was that it was a different problem :) I'm on Mac and Mac + Arduino causes a reset of the Arduino when the port is opened, so when I would connect I was sending the commands while the Arduino was still resetting and it was only getting part of the command.

Jason

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b2e93eb4-b5b8-4ecb-8246-e96782ec52a9%40googlegroups.com.

[rainharvester]

Hey Thanks!  And thanks for helping too.  Can't wait to get openPNP going!

I'm on a PC.  9600 baud works!  No bad extra 4 characters.  

============================================

So for all who read this thread, you could possibly just recompile to use 9600 on the old 4-axis GRBL  (4 axis at https://github.com/openpnp/grbl).  (Config.h line 42, "#define BAUD_RATE 19200").

Also remove all the semicolon comments in the openPNP (see above).

==============================================

It might be good practice to actually skip bad data instead of just changing to 9600.  I thought I read that others have variable amount of garbage, 0xF0, on different serial rates.

So Jason, how can we fix these for other people for the long-term?  

    1) There is your Apple bug.  (The apple bug might be fixable in openPNP defaults?)

    2) And this, Initial 0xF0 Serial Garbage bug.  (hey, just realized you own that branch!  Cool!)

    3) Semicolon Comments (maybe just a wiki? hmmm...)

[rainharvester]

for #2, thinking...maybe this could be fixed in both:
- openPNP (send some extra init data, and disregard the initial response),
- and in grbl (skip garbage commands).

(that way we keep the amount of merging with old grbls down, if someone uses an unpatched grbl).

[Jason von Nieda]

1. Yea, I think increasing the default timeout to 3000 is a good change. This has bitten people on several different motion controllers.

2. It seems like changing the baud rate fixes this pretty definitively, so unless I see evidence otherwise I think it would be reasonable to just change the branch to default to 9600. It's been "common wisdom" not to use Arduino at 115k for a long time due to the bit slew error and low speed of the processor and really, 9600 is more than fast enough for OpenPnP.

3. Yea, I think Wiki will do the trick. We already have a Grbl Wiki, so it can be added there: https://github.com/openpnp/openpnp/wiki/Grbl. I think it would also be good to add a short section in the GcodeDriver wiki ( https://github.com/openpnp/openpnp/wiki/GcodeDriver ) that links out to the Grbl wiki and has room for others. These pages can be used to talk about the controller specific Gcodes that can be used with the GcodeDriver.

If you'd like to take on any of these changes, let me know. Otherwise I'll probably knock them out this evening.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/24c8216d-09ac-4329-9737-0da26e961caf%40googlegroups.com.

[Jason von Nieda]

These changes have been made:

* https://github.com/openpnp/openpnp/commit/0b136cfb975ae4118027eb6010fe44685672d6b1

* https://github.com/openpnp/grbl/commit/c7dc952f52b40f294e2f598212f5c88cec4f9fcd

* https://github.com/openpnp/openpnp/wiki/GcodeDriver#controller-specific

* https://github.com/openpnp/openpnp/wiki/Grbl

Jason

[Jason Wei Han Lee]

Hi Jason von Nieda,

Does Arduino Uno work with OpenPNP? My current setup is an Arduino Uno+ CNC shield that is loaded with a servo-grbl file from https://github.com/robottini/grbl-servo. 

After pressing the green power button icon, I get "Timeout waiting for response to G21; Set millimeters mode", whch is the same as your problem. What should I do? After reading through this forum, it seems like GRBL is not the best for OpenPNP? 

Regards,

Jason