Manual programming helpers #105
Comments
|
Oh, and user messages (useful for tool changes for long programs with many tools). It would make those programs more self contained. |
|
@mkaluza those are good points which you gave, but current goal of the app is to support only grbl supported features. Typed command history is one think i can think of in next version. |
|
I'm writing all this because I've seen you saying you have no experience
with professional cnc machines, so you may even not realize that there are
some very useful features to have. All those I've written about (except
variables) should be fairly easy to implement (I would not all for things
requiring a lot of work)
Those are either already supported features or features that no version of
grbl will ever support, arm or not arm (lack of permanent storage, to
little memory) and actually completely independent from grbl
- right now you have shortcuts to zero X, Y and Z axes and they in the
background generate G10 L20 P0 X/Y/Z0. What I would like is the ability to
enter arbitrary value by clicking on the coordinates (see image) so you
don't have to write write G10 L20 P0 Xxxx every time. And it's something I
do A LOT of times.
- command history is obvious and an absolute minimum. It would be nice to
have a multiline edit window that does not clear on execute so you can
write more complex ad hoc programs without external text editor.
- Messages to the user. Grbl has no way to support them (and will never
have), but it should be easy inside the UI. If while sending gcodes you
encounter a comment like "(!drillbit hss 6)" (one simple regexp in a
function that is reading gcodes from a file), grbl will ignore it, but the
app should hold sending further g codes and display a message "drillbit hss
6" and wait for user to click OK (or Abort). This would make tool changes
very easy and robust (especially if it is later implemented in
postprocessor that could generate toolchange "macros" with those messages
automatically). Otherwise if you use 5 different tools in one program (I
do), you either need to have 5 separate programs (which is a pain), or use
M0 and have a list somewhere, which tool to change to now (error prone,
because you need to keep track of where you are by hand)
As for those gcode features, I'll write some examples when I get to some
PC, because from phone is not very convenient. They are very useful and
very needed if you do any kind of gcode programming and not only run files
from cad/cam.
…On Thu, 2 May 2019, 11:01 zeevy, ***@***.***> wrote:
@mkaluza <https://github.com/mkaluza> those are good points which you
gave, but current goal of the app is to support only grbl supported
features.
I think many more features will be possible to add once official grbl arm
firmware is out.
Typed command history is one think i can think of in next version.
Subprograms i am not sure about them, how much they will be helpful
Labels, forward jumps, Variables (can you explain them a little)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHSF5YTRKP2JGRBXC7URUDPTKUYFANCNFSM4HJ4KI5A>
.
|
|
Just realized that email attachments don't get displayed, so here is the image |
|
@mkaluza Thanks for the image. You are correct i don't have any knowledge of professional cnc machines, I developed this app only with grbl in mind. I did not get clarity on waiting for the user to press ok if some line like "(!drillbit hss 6)" is found. If user has to do a tool change after this message then its little complicated (not impossible). Supporting M6 with user macro is in my todo list, when it is done it may address this issue. It would be great help for me, if you can provide some gcode samples. The image looks wired to me, why the text "Step Size | Jog Feed" in two lines? App is supposed to be open in full screen, mobile status bar should not be visible. |
Let's assume the following code to change the tool (just example not meant to be working for real or very correct) Right now on grbl this code would go to X100 Y300 in absolute machine coordinates (tool change place, tool probe location) with spindle and coolant off and a little above it (N4), and hold the program so that I can remove the endmill and insert another. After that it would go down and wait again so that I can tighten the endmill at a reference level (I don't have a tool probe yet so it's the way I deal with tool length setting). After that it goes up and on with the milling. But right now each time the machine waits I need to look into the code to find the comment containing the tool that the machine is expecting. The modification I'm proposing would allow me to see on the screen the message permanently so that I know that now I should insert 6mm endmill and either click 'OK' when I've found it or abort if there's a problem (but it isn't strictly nevessary as I could abort when the machine is waiting on M0, so just "OK" button is enough for a start, but it would be good to have it). By the way, you've given me the idea on how to implement M6 in grbl easily and flexibly :) I'm not sure if the UI should do it... I think it's more a grbl job... Besides - that kind of message would be universal - user could get all kinds of messages, like for example about stock and initial setup: "Stock 100x150, zero in the center", some safety checks or some other messages/info the operator should get in the middle of the operation, like "Close the cover".
Ok, lets assume we have 20 holes to drill (that is the immediate problem I have right now). Right now I would need to have such gcode: That's a very long, ugly code to edit on a cell phone... But if I have subprograms, I could do this: This already looks better, because by looking at the main program you can easily figure out what it does (drill, advance 10mm, drill, advance etc...) Now let's add a loop here. drill_5.sub stays the same, only the main program changes the last line instructs the UI to repeat the gcode from there to "drill_label" 19 times (it's been already executed once, so there'll be 20 holes in total). After that it continues further with the program. Subprograms are the simplest thing - when parsing gcode, if you encounter L_(filename), you should just send the contents of subprograms/filename.sub opened from folder relative to the main script. It doesn't require keeping any state and should not be complicated. Think of it as an "include". REPEAT is more complicated because you have to keep track of the labels and the number of repeats already done, but still should be quite doable. It doesn't change any syntax and doesn't create confusion (label could be detected with a regexp: alnum characters without parentheses (we ignore comments) ending with a colon. And REPEAT is well... repeat :D also parseable with a regular expression. It also doesn't require any preprocessing since REPEAT always goes backwards, so you have either already encountered the label in the code or it is an error. A forward jump is just a GOTOF label with the difference being that the label is after the goto, not before as in repeat. It's very useful if you had to abort a program at some point and you want to restart it at the same point. Then you just add a label there and a GOTOF at the beginning and don't need to delete all the lines. The difficulty here is that at that point you have to scan the file forward to find the label. Or maybe it isn't - you just skip all the lines until you find the label or the program ends (in which case it is an error, but it would stop the program nevertheless). I'll skip the variables for now as it becomes more complicated then. I hope you get the point. No version of grbl will ever implement those features because it doesn't have access to the entire gcode at once, so it cannot 'remember' the labels for REPEAT (besides, the repeated code block could be too large to fit in uP memory anyway) or look for them for GOTOF (ok, it could just skip the lines until the label is found). It also won't have any way to show messages to the user without gui support.
It is fullscreen - status bar being visible is the side effect of taking a screenshot
LG K7 2017
Yes, I had large font size set. I didn't even notice it :) |
|
Thanks for the great explanation.
Desktop sender like UGS and BCNC supports M6 macro, where M6 command is replaced with the user defined gcode block.
For simple repeatable gcode blocks, i think we can use custom buttons where we place the repeatable code in the custom button and press the button for n number of times. Or even we can have an option of "Repeat n times" in button configuration. Actually I wanted to have a simple cam tool in the app it self where i can do drilling, profiling and cutting basic shapes but due to lack of time i am unable implement it. Supporting "L_", "labels" and "REPEAT" will only be good idea if those are the standard practice in CNC world. (I doubt may people have different labels/letter to indicate them) When i do rewrite the core of the app i will keep these points in mind. |
Not that I know of. It's as good as any other. That was my first idea. In fact instead of hardcoding it you could add a config option to enter a regular expression that would match the messages that should be displayed as dialog boxes - then anyone could set anything they like/want with the default being for example /^!(?P<message>[\w ]+)/
Yes, I know, but it's because grbl's author refused to implement it... I still think it's the machine controller responsibility - this way it's implemented once and independent of the higher level application
You're missing the point. I can do that already - I write a script to drill one hole and execute it 20 times - this way I'm not limited by any buttons. I want to be able to quickly and conveniently write scripts that will do it all at once and more - can repeat many things many times. Just fire and forget. By the way - can the app remember last file location and start the "open file" dialog there? Every time I want to open a script I must click from the top level something down to my one - always the same - directory with my scripts...
There's no such thing as "simple cam tool" - cam is complicated almost "by definition". Or there is - it's called gcode :) And loops and jumps is everything you need to do "basic shapes" like helix, pocket, planning etc... And it will be way easier to implement ... and use - I can't really image using any graphical design software on a cell phone, or any other touch screen for that matter.
You do realize "label" can be any name... I suggested using L_xxx instead of Lxxx to avoid collisions. That's what Sinumerik uses and thats what I know. But I think Fanuc is more popular and a kind of "standard" and there is an M98/M99 call to subprograms. (https://www.cnccookbook.com/m98-m99-g-code-cnc-subprograms/). Mach 3 also appears to be using Fanuc syntax. As long as you implement anything that is used in the industry, you're good - there's no "standard" way probably because at some point every vendor introduced their own extensions, but I think Fanuc is a good template.
Ok, so that's a problem - I haven't looked into the code hoping that I won't have to, but I will at some point (that is when I have all the environment set up, because right now I have nothing...)
No - REPEAT and subprograms are two separate things and one doesn't depend on the other. And while I could live without REPEAT/GOTO, subprograms are essential.
Great. If you need anything, just ask. And you can have a look into this cnccookbook page - it has many good info on how professional cnc machines work. |
|
Sure i will have look at cnccookbook |
|
I've tried to look into your code but no - I still don't like java in general and java for Android in particular :P, so I won't be able to help you directly. But... If you know python, or at least can read it and understand it more or less, I could write a proof of concept (fully working) gcode preprocessor for REPEATs, GOTOs and subprograms. I would of course make the code as readable as possible. Because I've been thinking - implementation of loops, jumps and includes is fuly static. It means all we need is one function - preprocessGCode() - that will take the main input file, go through it, replace REPEATs with multiple instances of the repeated block, remove lines that are jumped over and include subprograms' code (also with preprocessing, so it has to be recursive, but that shouldn't be a problem), and generate a temporary file with "vanilla" gcode for grbl. Then your code could send that file instead of the original one! Therefore it won't require any modifications to your current code. This function would also handle M6 macro expansion. Also if you could show/explain to me in your code where file reading is initiated, where it is done and where the gcode is sent, maybe I could help you figure out how to easily insert those user messages from comments in there, or at least we could think about it together. And if you won't be able to read python, maybe I'll be able to translate that code later into vanilla java, and all you would have to do is include it and do all the android stuff like file reading etc. It'll probably be ugly, but hopefully it'll work. |
|
I know python a little, File streaming process in app is handled in FileStreamerIntentService.java |
Ok, that's great, because writing it in java would take me ages. Here it is: https://github.com/mkaluza/gcode_preprocessor One difference from what I suggested is that it doesn't handle subprograms (separate files), but only subroutines (in the same file). It's an "official" syntax that Fanuc and Mach3 use. I also added Sinumerik-like label, because I think verbose labels are way better than numeric-only. And when I thought about it more, subroutines in one file are better (simpler) for 99% of cases than multiple files. And if someone requests multiple files, they could be added easily. It's far from perfect, but if I wanted to make it perfect, I would've probably never finished it. I'm for as-needed improvements and good-enough code. One obvious missing thing is the recursion limit for subroutines to avoid endless loops, but again - it's in author's best interest not to fuck up his gcode to that extent so I wouldn't worry about it too much from the start;) If you have any questions, feel free to ask.
Ok, as for those user messages - I think it's very simple with your current code:
Also in this function you would call the preprocessor and instead of opening a stream for the original file, you would read the temporary file created by the preprocessor. Or the preprocessor function could also return a stream and could be a generator and produce code on demand instead of processing the whole file, but that would complicate things a bit (error checking would be deferred and besides it needs to read whole file at least once anyway to scan for labels) - I think reading whole files will be easier to begin with. Having thought about it - I don't know how android handles intents and if |
|
I will go with the preprocessor option as it would be much faster solution and does not need any major changes in the current structure. it might take a couple of weeks for me to start with this. |
|
I've been thinking... If you could do the android part (with which I definitely won't be able to help you), I could probably take a shot at the processor itself during the weekend. For now just use a stub class with one entry point that receives a filename and returns a stream. |
Hi,
I'm using grbl mostly manually and I'm missing few features very much compared to a professional cnc (mine is with Sinumeric control), which grbl doesn't support (and even cannot support due to Arduino limitations), but that could easily be supported by the controller app
UI:
GCODE:
Those features would require a bit of gcode preprocessing, but maybe they would be possible (in order from the easiest and most wanted):
Tell me what you think. Although I don't like java and don't program in java too much, maybe I could help with coding.
The text was updated successfully, but these errors were encountered: