GUI

[ivaring]

Hi there, would it be possible to make changes on GUI interface GRBL software by using Visual Studio for example?. If yes, how should I do in order to get actual GUI as first reference?.

Thanks.

[MeJasonT]

https://github.com/gerritv/Grbl-Panel/releases its already done for you. If you are good at coding i would be interested in working with you to make changes with this GUI. My friend Gerit is no longer supporting it unfortunately. Where Grbl has limitations with the command set (G codes it can use) it would be nice to change Gerits parser to accept G codes for Drilling/pecking and tool changes. A GUI should be able to receive additional commands and change the gcode to suit the command set accepted by GRBL. effectively have hard written macros within the GUI.

[ivaring]

Hi Jeason,

thanks for your kindly reply, I downloaded your software and opened with Visual Studio, thanks 4 that. I usually use C#, so let me please take a look to your solution file and let you know about it,

thank you very much again,

We keep in touch.

[terjeio]

@ivaring : I am working on a new sender written in C# that uses WPF and MVVM coding patterns. The code is structured in a layered manner (it comprises several projects) and it should thus be fairly easy to change/expand for the UI parts.

[MeJasonT]

OK i butchered Gerits code https://drive.google.com/file/d/1yYWKrgaLPk8jkk3r5QPpiQuL9TLLOcBk/view?usp=sharing you really shouldn't let mechanical engineers write (sorry copy and paste code).

[MeJasonT]

If, Canned cycles for drilling were added and the spare analogue pin used to receive a done signal when an external tool change was done then they would make grbl unbelievably fantastic. I am working on hardware/mechanicals for a 10 position umbrella styled tool changer which seems feasible - i would sniff the serial coms to get T and M6 commands and use a second arduino to run the tool changer. or at least that's where my heads at.

Probing zero locations is a must and zeroing based on circle centre would be desirable A CMM (computer machine measurement) probing facility would be out of this world like grblgru.

The restriction i have is i don't really understand the structure of Gerits code, the switch from VB6 to .net confuses the pants off me. How the Gcode commands are parsed in order to load the file into the listbox has me baffled. Foolishly i have the idea that if i can intercept Canned cycle codes and T/M6 codes then i can create code nested in the program that will produce those functions. It would require pausing the sender until effectively a macro had been run then jump back and continue with the rest of the job file.

[ivaring]

OK i butchered Gerits code https://drive.google.com/file/d/1yYWKrgaLPk8jkk3r5QPpiQuL9TLLOcBk/view?usp=sharing you really shouldn't let mechanical engineers write (sorry copy and paste code).

Thanks 4 that!, not even from stackoverflow?

[ivaring]

@ivaring : I am working on a new sender written in C# that uses WPF and MVVM coding patterns. The code is structured in a layered manner (it comprises several projects) and it should thus be fairly easy to change/expand for the UI parts.

Gr8 job!, thanks 4 sharing that information with me!.

[MeJasonT]

LinuxCnc guys are so inflexible about writing a driver to support grbl which is a shame as it has all the functionality everyone is looking for from a GUI. Tormach Pathpilot has to be the ultimate goal. The new professional controllers coming to the market are more graphical and have a much better menu structure than that of the old ones. Mach3 unless you spend more money on a GUI template (in some cases an extra £100+) you get the basic control window which in my opinion looks like a child drew it. The graphics don.t have the graphics/sharp edges one typically associates with a windows app - they look like they were drawn with crayon. Haas has a new controller out which is more windows app looking and has a more intuitive menu structure, I think Fadal is similar. At the end of the day its just graphics and all the heavy work is being done in the code behind it but it would be nice to have a GUI which looks and feels like a Pro machine controller. As GRBL has been structured to behave like a Pro machine control with the functionality and discipline that goes with it then having the same from the GUI would be a nice conclusion to the GRBL package. The limited memory size of the Atmega 328 is what has been holding GRBL back but it doesnt need to be as the GUI should be more than capable of producing G0 &G1 moves by interpreting G83 and rewriting the output for example. Fusion 360 has already helped us by having a GRBL post processor which will create 2D and 3D adaptive tool paths which out surpasses Cambams point to point paths. Im sure it will become a feature of Cambam in the not to distant future.

[MeJasonT]

I was wondering how easy it would be to incorporate an optical sensor for a plasma table torch height control and have the gui update the height. I'm sure its not viable as the next Z command would over right any previous adjustment. possibly it would be impossible to jog whilst under planned job moves anyways but wouldn't it be cool.

[MeJasonT]

@ivaring, How are you my friend, I hope you and your family are safe and well. I was wondering have you taken the oportunity to progress this project. all the best Jason

[MARIOBASZ]

Like so many other times, I don't know if I say nonsense or something with any meaning. I use bcnc as a guide: from there you can carry out canned cycles for drilling, and also different policies for changing tools ( M6 ignore, or manual change) with a subsequent height compensation probe. I am advancing in my own ATC project, I have added the automatic tool change option with all its movements, also advancing in the hardware part, even without deciding whether to use a second exclusive arduino for the tool change itself (I think that better option ) or add everything on the same arduino (mega). I hope to reach a good port in a short time.

[MeJasonT]

The mega will have spare I/O but the timers are pretty well utilised so it may be difficult to get the additional controls required for an ATC not to mention a stepper motor output for a carrosel as all the PWM outputs are used up ? When i started to accumulate parts for putting one together (my style of project management, see what you have and see what you can make without spending money - to think companies spend thousands on project software). basically you need to decide on the style of tool changer, wine rack, carrosel etc. We are probably all thinking about a carrosel and a horizontal one not a verticle as we dont want to flip tools as well as locate.
So there will be the carrosel which needs to rotate to the required tool positions (stepper motor) a homing switch so the carrosel knows its starting point, possibly an id mark to tell the ATC the tool is correctly located for a change or that the holder space is not blank (can be same sensor with some code buggery). How will we confirm the tool number ?. The carrosel will require extending and retracting from the load location angain 2 sensors to make sure its in or out, a solenoid for pneumatic cylinder or another method of extending the carossel out. A pressure sensor to make sure there is air 1. to make the operation and 2. to make sure the machine doesnt thing it can run if there is a sudden loss of air with the carossel in the load position. A command to say run a change and a command to say change complete. As i pondered this i suddenly discovered id forgotten the power draw bar so share the same presure loss sensor an acctuator to release the spindle and a sensor to check the tool has cleared once the spindle retracts - otherwis we will drag the tool out of the carrosel causing a wee bit of damarge. a control signal required to check the spindle is stopped/locked prior to a change. I came to the conclusion that a seperate controller was the best course of action - however the Uno does not have enough I/O.