-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
end user probing testing #41
Comments
I have to look at your video again, not sure I picked up everything... A few comments: G92 option will be axed. Not sure about (how to) add(ing) tool length offset option for Tool length and Height map tabs, at least for vanilla grbl as it does not survive a soft reset (from checking the code, I may be wrong - will test later). I assume you are testing in a single axis test jig? If so then IMO the only axis that can be tested in a meaningful way is Z. Ref. "Move the probe to above the position indicated by green dot before start." in the Tool length tab (I have added the italics). The Edge finder graphics needs to be updated, IMO not good. I wrote "Inspired by probing plugin for LinuxCNC (IMO a good reference)." - in the release notes did you check out that link? It may explain some of your issues. Profile pop-up menu: Add - add profile to drop down and saves the data to to a file, Update - updates the file. No need to update unless you want to save your changes. Perhaps a tooltip or better wording of the menu options should be used. Note that a profile does not contain data from the probing tabs. Maybe I will add some later. Crashing - I have had a couple of crashes recently too, always when interacting with the program and I have not been able to replicate. Hopefully I will be able to track this down. Probing puts the machine temporarily in G90 mode (relative distance), this is a problem if probing fails the approach as grbl then enter alarm mode. This means the G90/G91 mode cannot easily be reverted to its original state when exiting the Probing tab. I will have to find a way around that. A tip, to see the current parser state in the sender check the Parser state option for $10 (available for grblHAL only). Note the Center finder does not pull off (#32) before retracting in outside mode, I will fix that. I'll dig into this more later, I have some paid business to take care of first. |
I am not against G92 but I don't think it should be the default and it shouldn't sneak in. Somehow I think your probe page states are getting reset without your view updating. I have no other explaination for getting a g92 when G56 was ticked. I've reviewed the recording and it snuck in but not because I had the wrong checkbox active. This may be a more serious problem with states in your UI. G92 should be an options since some folks will not be using end stops.
The documentation is very dense but there is a ton of room in the probe screen so why not use it!! I'm also wondering if the 3d viewer can be used to dynamically display the current parameters in a 3d model. For instance the detail on the vers documentation has a great illustration of the edge moves and just seeing it tells you which param you need to pay attention to.
i don't understand the quoted text, where is that from? Seems like edge finder tab is ok to use for any axis. I was testing Y.
Add is greyed out, only update is available unless you type in a new name (i just discovered this). maybe more obvious is you enable the Add button which creates a modal input prompt for the new name? Another fairly typical way to do this is to put a item in the dropdown list under the existing list and for a new install like [ ,[user's profiles], ]. Finally user provided names really shouldn't be your lookup key (in my opinion) so maybe just let the user click add and create another default labeled profile. This feature really seems to have potential though!
G90 isn't relative so I don't understand this. I see a G91 down below is that what you mean? I think you can code around that. here's what I see when the edge finder runs and fails due to the motors not powered.
I see some things in there i'm not sure about, like: G49. I don't think you want to cancel your tool offset when edge or corner finding. G98 and G50: is this for lathe mode? Maybe good to omit machine type gcodes when not being used.
This is getting long, no rush on this. The main thing i'm interested in is a 2d 3d model showing the moves in scale so I'll poke around with that and see if I can come up with something helpful. |
Ok, I'll leave it in then, but not as the default mode.
Yes, but it requires work - IMO it is better to get something out for discussion that trying to make it perfect on the first go, and then perhaps have to rip everything apart again. Eg. on my todo list is adding internal corner probing to the edge finder.
It may be easier to use static bitmaps, but of course not possible to rotate/scale as a 3D rendering.
The information I have added under the probing tabs could be better/more precise, english is not my first language and I am not very familiar with the nomenclature used by machinists either...
My bad, sorry for the confusion - probing may leave the controller in G91 (incremental distance) if probing results in an alarm. I save the current G90/G91 state when entering the probing tab and try to restore it when exiting, this may fail if an alarm has been triggered. I am not sure I like the soft reset behaviour of vanilla grbl - something I need to explore further before deciding how to handle this.
It is the current parser state, indicating no tool offset is active.
G98 is retract mode for canned cycles. G50 is scaling off, G51 is scaling on, this is a Mach3 extension I find useful when drilling and milling PCBs. Perhaps I should add a
Yes, this is how I do it - eg. G7/G8 is not shown unless lathe mode is active. |
I was poking around the rendering code last night to try to use the gcode parser to show the probing moves. How would I get the G38 to render? I couldn't quite figure out how start and end are calculated. |
Sorry, I am not sure I understand. Do you mean you subscribe to position updates and that fails? I switch off polling for the real time status when probing, could that be the reason? |
I wanted to render the gcode for the probe moves in the 3d viewer. G38 does not render, and it seems to need a start and end for the 3dviewer to show it but I couldn't figure out how to get that set correctly. The idea is to setup a new instance of 3dviewer and put it to the right of the probe config screen. Then add a preview button which would generate the gcode and send it to the probing 3dviewer so you can see what moves will be made. If it works well I could add some labels to show the steps (like the static vers probe docs). |
Ok, I think I get it now. Generation of rendering moves is done in GCodeEmulator.cs, by the Execute() method, moves for G38 has not been added there. |
yes, i tried to add it but i wasn't able to get the start and end set correctly. |
Try:
|
this worked. I am poking at adding labels. One issue is that the "!" commands are not parsed and the point at which it moves after the probe will not be a single line. I may try to show a triangle of moves possible to represent the range of motion which might be made based on the current settings. this for example where i've moved things to G90 so I can know where to pull the probe back to after the G38 is mocked in: This example is what is spit out from the corner probing:
Also, the renderer does not seem to reload correctly, you have to change tabs. Do you think I should try to re-use the existing rendering gcode or make a new class? Also Machine.StartPosition seems to be the machine home position, is that correct? Does the animation work? This would make it very slick. Finally, there is an example in the helix toolkit demo app that allows you to see X,Y,Z mouse coords and it does fact detection to show where the mouse is on the model. This would be really handy. I can take a pass at integrating that if you are ok with it. |
You mean the ! prefix on G38 I use to skip the previous probed point if latch distance is > 0?
A minor bug - I do not want the 3D tab to render before it is visible. Fixed.
I do not know. Start with a new or subclass if possible?
It is the current controlled point (tool tip). It is where the green lines intersect.
Yes, but not in the main 3D View as it is not possible to open that while a program is running.
Could be cool, but I guess that would require correct coordinate system handling in the emulator/renderer. Coordinate system handling and improving grid rendering is on my todo list, but currently way down. |
Hello, Another question while I was looking at e.g. Estlcam that you can make a edge finding and measure the angle of the workpiece, so that the G-Code will be „rotated“ to match the workpiece. This would be much easier when you could mount the Workpiece on the surface without the high accuracy you would normally need... Do you see any chances for these points ? Thank you in Advance |
@einencool Your questions are valid and it should be possible to implement these features. Rotation is perhaps best implemented by expanding G10L2 to recognize the R parameter in grblHAL? I have been busy with maintenance work in my home lately - and I am not yet finished. It may take a little while before I am able to restart coding for the sender. |
No hurry, take your time, these projects are more for the winter time :-) |
One question about the Probing Tab. Today I made exactly one test, and in this way I won‘t use it, because it fires the whole machine with G0 Codes, and with 5m/min I don‘t want to destroy my new 3D-Finder... |
The probing tab is work in progress so changes will happen. I have some in the pipeline but I need to revisit the code before making any new commits. I use this document as a reference and this stipulates RAPID_SPEED for the initial movements. In grbl terms this is the maximum rate for a given axis. So perhaps we need an additional setting for the speed of initial movements then? |
Yes, I think that makes sense. Edit. |
Hello @terjeio One question. Today I set the Speed in the GRBL Settings to max 750mm/min So I could make a little test for the 3D-Finder with better speeds. Is it possible to while in Center Finding Mode to view the measured diameter from the Hole or Pin? This could also be helpful to set the Origins of a Workpiece with manual measurement methods |
It should be, but perhaps after running two or more passes to ensure that the measurements are from the exact center? My plan is do some grblHAL coding before I restart coding for the sender so it could be a little while before it get done. |
Sounds good, I‘ve seen some Center Finding Macros, where the Position will be measured in this direction: X- It would be great to get the possibility to measure a workpiece and get the „real“ dimensions from the touch points. |
Please, Please add the possibility to slow down the RAPID feedrate while Probing. That would make things much easier. |
@terjeio Here is a little summary from the last points.
Maybe you find some time in the next weeks :-) |
I hope so, currently I am busy with maintenance work on my house. Rainy days might give me more time for coding... My plan is to get a stable grblHAL version out first (moving test to master), then I will restart "serious" coding on the sender. Recent changes has been relatively minor: bug fixes and for testing of new features in grblHAL. |
Hello @terjeio Is it possible to add a offset for the Touch probe, which is not mounted in the spindle? Second question is about the possibility in center finding only to measure one direction, maybe only X or only Y Axis. I think the Rotation off the part is much more work, and the other two parts can be implemented much more easier. Thank you in advance. |
This should be part of a probe profile? Add a button for advanced settings?
This could be done by unlocking and setting the distance for axis not to probe to 0?
It is as the gcode has to be transformed. I wonder if it will be possible to do that in the controller by implementing the |
Yes, I think that would be a very good idea.
When you think this would be ok, then I would also recommend it :-)
|
This is now available in the beta 8 release, by unlocking XY sync and setting the direction not to probe to 0. |
Nice to hear, I‘ll give it a try in the next days :-) |
Since beta 8 makes some problems on my machine, I‘ve seen in Beta 7.3 that when probing „only the right outer wall side“ the probe touches the workpiece and after that drives directly die Z-Axis up, it doesn‘t clear the tip from the workpiece. |
Does this happens with beta 8 too? I would rather fix problems with this than reverting to beta 7.3 for bug fixing. |
@einencool I have added some initial code for probe offset, currently only for setting G5x offsets. Do you want to test it to see if I am on the right track? If so I can upload to the edge version. Note that the probe XY offsets are not visible with the default window size, the height has to be extended a bit first. Due to that I have added a new configuration for the sender in Settings: App for restoring the last screen size on startup. |
Good Evening @terjeio Then I can test if all sides are handled correctly. One point from my side for testing, but I don‘t know if it is possible. When in Probing tab, I can configure the feeds & speeds for probing, and also there are F&S in the Config part for the tool Change. I have configured the speed in the Toolchange Config relatively slow, because I don‘t want the Touchprobe „Search“ speed to high (50mm/min Search and 25 for Probing) But when doing the Reference Tool Length Measurement, it will use the Speed given from the Probing Tab. And for sideway probing, I would like to use the 200mm/min, but for Z-Probing only 50mm/min. Would it be possible to separate X/Y and Z Speeds? And while using the $TPW Command, the Tool probes two times, thats all Ok, but it drives the Z-Axis really high between the two probes, is there also a way to change this separately? Only some points, and when it‘s not possible, it‘s ok, but when I don‘t ask, then I don‘t know :-) Thank you :-) |
@einencool ok, I'll upload tomorrow.
A lot is possible but I am a bit conservative in not adding too many options to the user interface, probing is quite confusing already. Maybe an appsetting for advanced users could be a solution to that dilemma?
This is currently hardcoded in the controller in grbl/tool_change.c by It can be mentioned that I have now completed an overhaul of the controller settings system making it easier to add new ones, and this is a candidate for joining the settings list. A remaining issue is that adding new settings will often trigger a settings reset - more work is required to fix that. Part of the overhaul is that ioSender now gets setting information from the controller and groups settings in the UI - making it easier to navigate for the end user. This also eliminates the need to update the sender when settings are added. |
Perfect, thank you very much, and also for the travel distance, that‘s no Problem for me, to change it in this file. You are absolutely right, that not to much settings should be added to confuse the users. Then I think, I‘ll change the search speed to 100mm/min and go this way. Or another question. |
No, the extra 2mm is for setting the target of the second probe motion 2mm below the first probed z-position to ensure the probe is triggered again. |
Ah, alright that sounds good :-) |
It seems to be 2mm when I am testing - do you see a larger distance? The edge sender for probe offset testing has just been uploaded. Be careful when testing, do not damage your probe! |
The distance looks so big, but I think you are right and it is only 2mm, I have 0.5mm in my Macro for probing. One open point. Will try in the evening or maybe tomorrow your new version, now I'm not at home, and don't know how much time I get today :-) |
Yes, use Also note that |
You'll have to try, I am not 100% sure about what you want to achieve.
The only way to clear that light is to use red Reset button or issue
This could well be so since an error may be raised if the probe triggers when not expected, e.g when retracting. This is enabled in the controller by the Thanks for testing, I am happy that it works as expected. |
What do i have to do, that i can see the “tlo” light? and the question for the probe macro I’ll answer myself tomorrow 👍 |
You have to set a tool length offset with The tool length reference offset is only used by the tool change extension to calculate and set |
Now I have tested a simple GCode with two tool changes.
After TLR Measurement and also when Programm is finished: Clear button appears after new tool is measured, I think in the past it was also there after the Reference was set: This is the little test file This is the output from the console |
I have to thank you 👍 |
This is due to I can be noted that legacy grbl does not support these status lights at all. |
Ah ok, For me the Probing is now working really good. One point could be also interesting. |
See issue #94 for edge version with gcode rotation. |
here is a long winded video of me bumbling through some testing. I didn't test edge finding prior to today. Corner finding works well, as does center finding. I'm guessing you didn't put much time into edge finding and there are some easy fixes.
https://youtu.be/NthS9aIBZzg
It seems that for edge probing it uses some of the corner parameters in unclear ways, for instance the x/y offset seems to control the pull off distance. It is also unclear if the probing distance in the 2nd from the top box controls the probe distance or if the offset in the bottom box controls the distance for edge probing.
Here is an example where g92 was set somehow but not by the settings I had configure and I had a "crash"
Here g92 gets set again but not based on my input
Here I forgot to reset the diameter since the settings need a few click to persist and get lost when you switch tabs (or maybe I restarted?)
Here I am not sure what coordinates are being used and the dro values are not helping. Maybe a feature request: can you track the coordinate system and other things like absolute vs relative mode and have them display in all tabs? I would also like to see the DRO in the probing tab, if the DRO could display the current WCS that would be great!
Here is an example of the GUI crashing. It did this many times in a row while I was attempting to record this and the crashing is what motivated me to record it in the first place. Once I finally got the recording setup decent it stopped crashing. The audio is very bad because I had the wrong mic setup.
The text was updated successfully, but these errors were encountered: