Feature Request - custom command buttons

[Scott216]

I'd like to see a couple buttons that are linked to custom gcode. They would work just like Go To Spcl Posn1 and Posn2 buttons. For example, I have a command that I use all the time for my touch plate: G20 G38.2 Z-2 F0.118
It would be nice if in addition to storing the command, the user could also name the button, so you'd have two text fields, one for the button name, one for the Gcode

[gerritv]

Thank you for the suggestions:
I will look at adding something like this by summer. As mentioned in #24, my ability to code features is limited for a few months.
the challenge with this one is to find room on the GUI :-) I think likely location will be in the Status panel with a new section there.

[thoralt]

Hi Gerrit, Scott,

I implemented something similar during the last days because I also was typing G38.2... a few times too often. I came up with probing support for grbl-panel. Right now I'm extending it for the X and Y axis, the Z axis is already working. Placing an additional button for probing was easy: I moved the "0" button of the Z axis a bit up und added a "P" button below. Clicking it starts a probe cycle using probe distance, feed rate, plate thickness and back off distance from a few new text boxes on the settings page.

@gerritv: I'm still testing it - would you be interested in the code once its stable? If you do, how would you like to integrate my changes?

Best regards
Thoralt

[gerritv]

I would love to get the code and merge it in. I am not a fan of Git nor GitHub so I prefer to merge the file myself. You can send the changed files to my (masked) email address listed under my member name.
thank you for this most useful addition. I hope to get my shop up and running near the end of Sept, its been a long time, almost a year, without one. I really need to get my own machine finished :-)

[thoralt]

Okay, I'll send you the code as soon as I'm done with testing. Until then, the (not fully tested) code is available in my fork of your project. I plan to finish it at the weekend.

[thoralt]

Gerrit,

while testing my additions, I'm observing some strange behaviour. Whenever grblreplies with a [PRB:...] line while I'm probing, I immediately send back two commands using gcode.sendGCodeLine(). When singlestepping in debug mode, every command (namely G90G10L20P0X3 and G0X8) is being executed by grbl. Whenever I let the program run without breakpoints, grblsimply ignores the G0X8 command while grbl-panel still displays it in the command history.

Did something equal ever occur during your development, are there timing constraints I need to observe? Is there some waiting for ACKs going on? How would I need to adapt to your protocol handling best? At the moment I'm clueless why grblignores the second call to gcode.sendGCodeLine().

[gerritv]

sendGCodeLine doesn't wait for an Ack/OK but for such short commands I would think it doesn't matter because the buffer doesn't fill up.
In the command history at full speed do both have an Ok status or is the second one for G0X8 missing? That would be the clue.

Do you run the Probe sequence with a Gcode program already loaded or is this manual stage work?

[thoralt]

There's only one OK in the list, in front of the second command G0X8. The previous G90G10... doesn't have an OK, but according to the position display the X axis does get set to 3, so maybe the OK in the list is the reply to the first G90G10..., but not to the G0X8. It seems grbl does not process the command. Should I fire a timer and send the second command a few milliseconds later? Sounds odd to me.

Another one: When I start the probe cycle, I first reset the corresponding axis to zero using G90G10L20P0X0 and then start the probe cycle with G38.2.... Strange thing is, I get only one OK here, too, but grbl clearly does set the axis to 0 and starts probing, so nothing gets dropped here although the situation is similar to above. I'm confused.

[thoralt]

I forgot to answer your second question: No, I didn't load a program, this is all manual work.

[gerritv]

I think it is then because 2 MDI commands were sent in a row, specifically the second command was sent before the first Ok was received. I never considered that would happen :-( aka I never tested that situation.
I think the best 'quick' solution is to fake loading a file by 'reading' the 2 lines you need to send into the gcode list and then faking a Start event. This should be in gcode.vb if memory serves me. I think the code is modular enough that it shouldn't require too much modification, maybe adding a flag parameter to some routines.
Alternative is to add a delay before sending the second command but this might make the problem go into hiding only to pop up when you least want it to show up.

Unfortunately I am in the midst of renovations and even if I could find my Arduino, there is no realistic way for me to code up a proper queue. I had started that but when we sold our condo last year and went homeless for 8 months (travelling etc) the code was parked.

[gerritv]

Some of the symptoms/sequence might be a bit clearer if you can turn off polling? Or turn it off soon after the second command goes out?

[thoralt]

Just a quick update: I've had an interesting discussion over here:
grbl/grbl#792

This explains most of the issues I was experiencing the last days. I've implemented a GrblQueue class which handles all the byte counting and contains its own queue list which can be filled using simple calls. It is working, well, almost. I'm able to fill it with gcode commands and it stuffs everything into grbl's receive buffer until it is full, always trying to keep buffer utilization high.

The only thing I did not expect was that some commands write to the internal EEPROM and this stalls grbl's RX handling for several milliseconds which leads to lost characters. I will implement some detection to find gcode commands which write to EEPROM. If they occur, I need to wait until grbl's buffer has drained and the EEPROM write is complete, then the next commands can be written. I will report back as soon as progress is made.

[gerritv]

mn, read the thread, difficult troubleshooting. Excellent work!
It is still Grbl's problem but due to hw platform there is no sw solution at that end so the gUI gets to work around it :-)
Might I suggest adding a 'wait for ok before feeding more' to the gcode lines that contain eeprom affecting commands? Maybe add an indicator in the Queue during load from file/MDI/macro button? Then during write to Grbl, if flag is set then wait for Ok for the command before resuming the stuffing. That seems better/smoother than waiting for the buffer to empty. A hybrid solution as it were of send/ok and stuffing.

[chamnit]

@thoralt @gerritv : I've thought about this overnight. The character-counting protocol has issues such as this EEPROM one inherently. There isn't a robust way to change this protocol to keep from sending data when it is in the middle of an EEPROM write, other than tracking what commands you've sent, waiting until the buffer clears, sending it, and waiting for an 'ok' for that particular command.

While the character counting does provide improved performance by eliminating some latency between messages, its implementation is more difficult and has a few catches. The simple send and wait for response is robust and will eliminate all such issues.

I'll think about it some more on how to improve the streaming interface to Grbl for the next version. If you all have any suggestions, I'd love to hear them.

[gerritv]

Hi Sonny,
I think that waiting for an Ok for the EEPROM writing command will solve the problem, for all others can just push it out to fill the buffer.
The problem with the send, wait for Ok is that many small segments will slow down the machine. For many this is a 'who cares' but it seems that for laser type devices it matters.

The real solution IMHO is a protocol along the lines of SDLC where you send one or more packets and look for matching Acks.(Acks included the frame number being acknowledged) If you get a Nak, then resend that packet. If you get a RNR (receiver not ready e.g. if about to do an EEPROM command) then the sender tries again after some delay. If you timeout waiting for an Ack, then resend.

I have never understood the penchant for using only gnd, Rx and Tx without Rts/Cts flow control or even checking for parity errors in most of the FOSS sw being used. It is not a reliable medium when used this way.

[gerritv]

Do we know which commands write to EEPROM? I forget what is says on the wiki, is it documented there?

[thoralt]

I had a look at grbl's code and as far as I can tell, there's only G10, G38.1 and G38.2. Additionally, all $ commands should be taken into account. Although some of them ($X, $H, ...) do not cause EEPROM writes, it should be safe to drain the queue after each of these.

[chamnit]

@gerritv : Agreed, waiting for a response will fix the issue, but only if the GUI ceases streaming after it detects and sends one of the EEPROM commands in a line. Grbl can't control the data coming in and there may be a case where the EEPROM write still gets executed, while the GUI is still streaming or a USB packet gets delivered late.

As for a new streaming interface, I've been thinking about something similar to what you suggested. Given that both a Mega and ARM chip will have much more memory, the streaming interface can have larger buffers that can do more complicated things like packet-type data transfers, error-checking via checksums, among a lot of other things. A major goal for the next version of Grbl is to fix a lot of these outstanding issues with the streaming protocol and do it once and right.

I've updated the Interface wiki on Grbl's website and it has a list of the EEPROM command (here).

[gerritv]

@thoralt Are you still pursuing this probing code? I am finally back working on GrblPanel and my related hobbies. I checked your fork and nothing has changed for a while, much like my code :-)

[thoralt]

@gerritv Sorry for the delay, I've been busy with many other things :)

Last few month there was little progress due to business trips and things like that, but your message triggered my milling projects and I started looking into grbl-panel again. I will continue testing and report back during the next days.

[thoralt]

@gerritv I submitted some major updates to https://github.com/thoralt/Grbl-Panel to fully integrate the new command queue into the GUI. Most of the code in GrblGcode has changed because the old command routines are no longer necessary. GrblGcode now mainly exists to handle events fired by GrblQueue and connects GrblQueue to the GUI. Ideally, we should extract the embedded class GrblGcodeView and rename it to GrblQueueManager, but I don't mind.

Since grbl-panel now handles the command transmission completely different, we need some serious testing. The basic workflow like reset/unlock, load, send, pause, resume and stop already works as intended, but I also added a first issue to the list. The screenshot shows the slightly altered UI:

Could you please try to compile my fork and give it a test drive?

[gerritv]

Hi Thoralt
Super, I will compile and test on Sunday. That is a significant piece of work you did! I did a quick read, will have to ponder it some more to get my head wrapped around the whole picture.
Re: GrblGcode, perhaps renaming it to GrblGcodeView would be a meaningful solution?
Re: your Issue #1, perhaps labelling your inserted gcode from macro buttons/MDI as 'mdi' and then a flag to only execute those will be a solution?

I don't have a probe set up yet, will have to hack something together for that...

[joebananas10]

I don't know if you guys are still working on this or not but I've written something you might find interesting. Basically I've added user-defined macro buttons to the MDI group. I don't know how to share the code in Github but if you'd like to take a look you can get it from here,
https://drive.google.com/file/d/0BxSUzgJuH_MKaDZ2UkhkcHdpRkk/view?usp=sharing
my zip file only includes the files I've created and/or modified.

Here's the long and short of it. I added three new routines to the bottom of GrblGui, MacroButtonEditorToolStripMenuItem_Click
EnableMacroButtons
MacroButton_Click

I also added a call to EnableMacroButtons near the bottom of grblgui_Load and a new Menu Item under Tools.

There's a new form to allow the user to edit their macros, GrblMacroButtons. This form allows the user to add, edit, and delete macro buttons. The data is stored in the system registry under HKCU\Software\GrblPanel\Macros. Only five buttons can fit in the groupbox comfortably but there's no limit to the number of macros that can be added.

The buttons are dynamically added and removed to gbMDI based on the values found in the registry. When the user clicks one of the buttons the gcode associated with that button is sent using the same mechanism as the MDI Manual Command Send.

When the user enters the Macro Button Editor the first time or if there are no buttons defined at all the editor will load itself with a sample Probe macro. This sample is not saved in the system until the user commits the sample to the registry.

Please let me know your thoughts on this.

[gerritv]

@joebananas10 I will review your code additions on the weekend. Sounds like an excellent solution although I might prefer to use an xml file for the configuration. Otherwise the registry entries remain even if you no longer want to use GrblPanel.

[gerritv]

V1.0.7.0 implements the macro button code from @joebananas10

I am pondering a solution to Thoralts observations wrt probe etc.

[gerritv]

I am changing the Macro send code to use a Q for V1.1.0.0 (at last!) See Issue #61