2. serial for Joystick, proposal: debug feature

[deHarro]

Hi Sven, I'm more or less sure that my Joystick issues commands to the serial port. Only there is no visible reaction in GRBL-Plotter. The stylus doesn't move, the coordinates do not change.

Can you please implement some sort of debug feature which allows the visualisation of the strings (or whatever is received on the serial port), perhaps easiest just into the listbox of the DIY control pad? Would be fine. Thanks! Harald

[svenhb]

Hi Harald, each received command will be shown in the window. I just used a 2nd arduino with grbl and received the known reset-startup message, which was then forwarded to grbl - which causes an error (because it was not a regular gcode). Perhaps I need to offer settings for stop-bits? Or can you try to use grbl - com settings? (8 data bits, 1 stop-bit, no parity )

[deHarro]

Hi Sven, my Joystick uses "115200, 8, 1, n, no handshake", just the settings GRBL uses.

This is what I set on "Termite":

And this is the communication between joystick and GRBL:

COM14 ist the joystick, COM13 is GRBL (V1.1f).

Just got an idea... To keep GRBL satisfied when debugging with Termite I issue "?" commands on the joystick. This perhaps garbles the communication between GRBL-Ploter and GRBL. I will stop the "?" in joystick since those "?" are issued by GRBL-Plotter. I will report...

Harald

[svenhb]

Hello Harald, in your screenshot I read "$J=G91X 1F1000" -> to be regular gcode, there must be no space between character and number: "X 1" is not a correct gcode - as I know. To be on the save site I would use spaces between commands, like "$J=G91 X1 F1000" Sven

[deHarro]

Hi Sven, as far as I know, GRBL discards whitespaces in gcode strings. But I can change that as you proposed. This will last some time since I fiddle around with pointers to the resulting string to keep runtime fast.

One argument against your idea is, when stepping in negative direction this space is occupied by a minus sign and this string is not forwarded to GRBL, too (or at least it is not shown in GRBL-Plotter). Harald

[edit] Just looked it up... "- Spaces and comments are allowed in the command. These are removed by the pre-parser." (from https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging)

So I will keep those spaces, make no changes on that in joystick. Please verify, that GRBL-Plotter does not discard jogging commands which consist of spaces in between command and parameter. Thanks! [\edit]

[svenhb]

You may should use "CR anhängen"

[deHarro]

G-code with or without "CR" are treated similar. I have different implementation (by chance, not deliberately :) for X- and Y-axis, respectively, and both are not shown in GRBL-Plotter.

[deHarro]

In the meanwhile I discarded sending the "?" on my own in joystick, but no change in GRBL-Plotter. Still no visible reaction in GRBL-Plotter.

[svenhb]

Did you try just to connect another grbl - as I did? At least this should work...

[deHarro]

Not yet... I will do and report

[edit] GRBL reports as expected, so what now? Whats the difference?

Ok, new test with joystick: I activate COM14 (the joystick port) -> nothing reported (that's ok, I didn't move the stick) I move the stick in X direction -> nothing reported (that's not ok, I expect "$J=G91X-1F1000") I reset the joystick arduino (by clicking the reset switch an the arduino) -> (see picture)

Explanation of the list box content:

• I closed and reopened the port to clear the listbox ->this results in line "Open COM14"
• next I get "< $J=G91X 1F1000" and two more $J=G91X 1F1000 $J=G91X 1F1000
• then two lines with ?$X < G4 P0.01

This is the output I issued by touching the joystick to minus X direction a very short time --before the reset-- of joystick, followed by two gcode commands to reset GRBL.

Then I show a loop of joystick values to get the middle position of each: < 508; 520; 505 ... < 507; 519; 522

I think I have to discard those two reset codes a well... I will report [\edit]

[deHarro]

ok, nothing changed (despite the now omitted reset codes). Again I get nothing until I reset the joystick arduino.

I try to append something (a "CR" or "LF" or both?) after the jog command, but that should not be neccesary following the jogging tutorial I linked above.

[edit] ...and I think, I already do append those:

// konstruiere die Strings fuer die Jog-Befehle
//                  0.........1.........2.........3.........4.........5.........6.........7.........80  Abschaetzung HilfeBuf
//                  012345678901234567890123456789012345678901234567890123456789012345678901234567890
//                  |         |         |         |         |         |         |         |         |
// jogXChar[20] = {"$J=G91X-1F1000"};

// jogXChar[7]                                  // Vorzeichen
jogXChar[8]  = '1';                             // immer einen kurzen Step angeben
jogXChar[9]  = 'F';
jogXChar[10] = '1';
jogXChar[11] = '0';
jogXChar[12] = '0';
jogXChar[13] = '0';                         
jogXChar[14] = '\r';                            // Stringende Kennung
jogXChar[15] = '\0';                            // statisch -> hier einfuegen

see jogXChar[14] = '\r'; // Stringende Kennung jogXChar[15] = '\0'; // statisch -> hier einfuegen [\edit]

[deHarro]

Ok, one step beyond... :-)

I appended "0x0D, 0x0A" (that is CR LF) and the commands appear in the list box of the DIYcontrolPad.

So what should happen next? The coordinates in GRBL-Plotter do not change.

[svenhb]

Ok, at least GRBL-Plotter received something. I will check the serialport configuration this evening - perhaps rx-buffer is different compared to grbl-comport.

[svenhb]

This two functions handles the data revceived (same as for grbl com-port). A command line should end with \r\n (CR LF) to be recognized as one command.

    private void serialPort_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
    {   while ((serialPort.IsOpen) && (serialPort.BytesToRead > 0))
        {   rxString = string.Empty;
            try
            {   rxString = serialPort.ReadTo("\r\n");              //read line from grbl, discard CR LF
                this.Invoke(new EventHandler(handleRxData));        //tigger rx process 
                while ((serialPort.IsOpen) && (isDataProcessing)) ;  //wait previous data line processed done
            }
            catch (Exception errort)
            {   serialPort.Close();
                logError("Error reading line from serial port", errort);
            }
        }
    }

    private void handleRxData(object sender, EventArgs e)
    {
        rtbLog.AppendText(string.Format("< {0} \r\n", rxString));
        OnRaiseCommandEvent(new CommandEventArgs(rxString));
        isDataProcessing = false;
    }

[deHarro]

Update: Not sure what was the reason, but now I can jog with my joystick.

I issued a "Reset" and now the communication to GRBL seems to function properly.

Now I can start to adjust step size and speed to fit the deviation of the sticks. Thank you very much so far!!!

[svenhb]

Very good! I'm happy too!

[deHarro]

One more question: Do you mirror the "ok" responses of GRBL to the DIYControl port? (didn't examine that on my own yet) That is essential for keeping the jog queue filled as much as possible.

[deHarro]

If I encounter issues when dealing with the joystick port, should I raise a new issue? (or report them here in this topic?)

[svenhb]

All send messages will be shown in the DIY-control window - each grbl message in brackets "[ ]", but no 'ok'. I would prefer to open a new issue and close this one - because communication is working now - right?

[deHarro]

By the way... How do you handle the immediate commands from the joystick? When issuing a jog-abort command, then there is nothing like CR and/or LF, just the 0x85 on its own. ... Ok, I see what you do (or better what you do not do). Just as with my commands before the changes, the abort command is held in the input queue (of GRBL-Plotter, i assume) and is then forwarded to the listbox (and GRBL?) just in front of the next jog command (see the red circles):

To get jogging working as expected, you have to implement a means of handling those immediate commands as well. Side effect: If you get that done, there will be no need to finalize the jog commands with CR LF any more.

[deHarro]

Hi Sven, my question aims not on the listing, but on whether the "ok" is forwarded to my joystick arduino.

This is essential for me, when it comes to holding the jog queue stuffed. When jogging continuously, it can happen, that the machine cannot keep up with the jog commands. To prevent sending commands when the queue of GRBL is full, I have to stop sending commands.

Or is that problem handled by GRBL-Plotter for the joystick?

[deHarro]

Hi again! You stated elsewhere (see https://github.com/svenhb/GRBL-Plotter/issues/34#issuecomment-419643553), I should recon how fast I can send additional jog commands. That would be possible but complicated and time consuming for the Arduino, I fear.

On the other hand they mention, one has to wait for the "ok" from GRBL before the next jog command is issued:

Basic Implementation Overview:

• Create a loop to read the joystick signal and translate it to a desired jog motion vector.
• Send Grbl a very short G91 incremental distance jog command with a feed rate based on the joystick throw.
• Wait for an 'ok' acknowledgement before restarting the loop.
• Continually read the joystick input and send Grbl short jog motions to keep Grbl's planner buffer full.

I think at the moment you do not forward the "ok" from GRBL to the DIY port.

[svenhb]

I don't want to pass through the 'ok' - it's information overkill in my eyes... Check https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1208_test.zip

[deHarro]

Ok, please close this issue then. Thanks anyway so far!! :)