little jogging problems

[S2000Stefan]

Hello Martin,

actually it is not a real problem with your program but maybe you can help me anyway.
I use an STM32 Blue Pill to control my 4 axis milling machine which also works wonderfully.
Depending on the milled part, I use GRBL Panel or your program OCP as a g-code sender.
Now to my problem, when I move the machine in jog mode, GRBL sometimes no longer accepts jog commands.
Assume it is due to the STM32 and the GRBL implementation. Unfortunately, everything works fine with the original
Arduino but no 4 axes.
In GRBL Panel I can briefly press one of the arrow keys, then the jogging works again perfectly.
Unfortunately, there are no such control buttons in your program to reactivate jogging.
Maybe you can give me a tip on how I can reactivate jogging in your program?

Greetings Stefan

[martin2250]

Hi Stefan,

does the buffer meter (green progress bar in the machine tab) show something other than zero when this happens? In that case, try clearing the buffer (click the progress bar) and if that doesn't help, soft reset the machine. Apart from the G92 work offset, you won't loose the machine position. This happens to me sometimes as well, though only very infrequently.

Cheers,
Martin

[S2000Stefan]

Hi Martin,

yes the green progress bar show any number other than zero. By click the progress bar nothing happens.
After soft reset the machine, the progress bar show short zero than three and no jogging command is accepted even if I type it in by hand. G0 and G1 commands are accept?
BTW why does your program know no G93 G94 commands? ;)

Cheers Stefan

[martin2250]

Hi Stefan,

ok, that's strange. I usually get it to work again after a bit of fiddling...
so you're saying that you can get OCP into a state where

1. it accepts regular G-Code from the console
2. it doesn't accept the same command when prepended with a $J= ?

this is interesting... Can you send me a link to your firmware (as long as it runs on a blue pill)? I don't know when I'll have time for debugging, but I'll try to look into it when I can. Is this a show stopper for you or can you work around it for the time being?

As for G93-95: I never used it and since I don't know of any post processors which can't be made to output pure G93 code, I don't see the need to implement this.

Cheers!

[S2000Stefan]

Hi Martin,

sorry, my mistake, something went wrong earlier, of course your program accepts g-code and jogging commands like G0/G1 and $J=G91...
I don't know what I did wrong earlier.
I tested something today and found out if I set the status report $ 10 = 10 and the machine is no longer jogging the green progress bar got to minus value, can be reached by loading the grbl settings, one two times or change a value at short notice. If the value is minus jogging is possible.
Hope you understand what i mean.
After i found out i can live with the little problem. :)
Deskproto outputs g93 code. Can calm you down G93 G94 commands are processed by your program there is only an error message. ;)
Cheers
Stefan

[martin2250]

Hope you understand what i mean.

I'm afraid I don't think I do, can you try to explain it in German maybe?

Cheers

[S2000Stefan]

Hi Martin,

sorry für die späte Antwort. Also dann versuche ich mal das ganze in deutsch zu erklären. ;)
Wenn ich den status report in GRBL $10, normalerweis 1, auf 10 setze und ich nach einem Programmdurchlauf einen soft reset ausführe muss, warum auch immer, steht die grüne progress bar meist auf einem positiven Wert und die Maschine lässt sich nicht mehr mit dem Keyboard Joggen.
(Fehler erzeugt)
Linksklick auf besagte progress bar und nullen des Puffers? joggt die Maschine noch immer nicht. Nach aufrufen der GRBL Settings mit dem button unter der progress bar geht die Anzeige meist auf einen minus Wert und die Maschine lässt sich wieder mit dem Keyboard Joggen. Muss man manchmal wiederholen da nach eins, zwei Tasten der Wert ins Positive läuft und das Joggen ist wieder gesperrt. Nicht vergessen vorher die progress bar zu klicken.
Danach joggt meine Maschine wieder wie nach einem Neustart.

Bezieht sich alles nur auf meine Steuerung mit dem STM32 (BluePill) ist also vielleicht nicht aussagekräftig bei anderen Steuerungen.

Hoffe war nun verständlicher :)

Gruß
Stefan

[martin2250]

Hallo Stefan,

ok, das ist wirklich merkwürdig... Eigentlich sollte der Pufferstand niemals negativ werden können. Vermutlich hat es etwas mit der grbl-Version zu tun. Ich verwende bei mir den Port von https://github.com/usbcnc/grbl, der hatte allerdings in der Version im verlinkten Repo auch noch Probleme mit der USB-Verbindung (Ist in einem der Issues beschrieben). Wenn sonst nichts hilft, kannst du den mal probieren.

Grüße
Martin

[S2000Stefan]

Hallo Martin,
der Pufferstand wird ja nur negativ wenn ich $10=10 setze, bei $10=1 bleibt der Wert immer null oder positiv. Bei eins kann ich den Puffer aber nicht nullen um wieder Joggen zu können. Wie gesagt komme ja mit meinem Lösungsweg einigermaßen zurecht. Dachte nur du hättest vielleicht eine bessere Lösung.
Die Version benutze ich auch, ist aber die abgewandelte stm32grbl11_11122018.zip von robomechs, wobei ich noch das Softlimit der A-Achse ausgeschaltet habe, da ich meine Drehachse immer weiter in eine Richtung drehen lasse (>360 Grad), beim Figurenfräsen gibt das eine schönere Fläche.
Das habe ich irgendwo bei einem anderen Port gefunden und kopiert, ich kann nämlich gar nicht net Programmieren. ;-)
Kennst du vielleicht einen G-Code Sender für GRBL der vier Achsen anzeigen kann? Keine Grafiken, die Digitale Weganzeigen würden mir schon reichen?

Grüße
Stefan

[martin2250]

Hallo Stefan,

Ein Readout für die A-Achse hatte ich sogar mal in OpenCNCPilot eingebaut: #63 (comment) Ich frage mich bloß warum der Branch nicht mehr existiert. Ansonsten kenne ich nicht viele GRBL-GUIs, da musst du dich ein bisschen umschauen ;D

Grüße
Martin

Edit: nevermind, laut einem anderen Kommentar von mir hat dieser Release auch kein Readout, sondern ignoriert nur den entsprechenden Eintrag in den Statusnachrichten.