-
Notifications
You must be signed in to change notification settings - Fork 37
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
Documentation problem #52
Comments
can you describe what steps are you doing and what output you get from CNCjs? Normally when autolevel process is finished, a new modified gcode file is automatically loaded into CNCjs |
Yes, the Z coordinates modified. The save function can't use. if i use before the auto level the file is 0 byte long, after use 0 to. Somehow in one time, i'm succesfully saved the data, but never again. I try this macro:
later i'm deleted the probeopen, probeclose commands. the console output on end of the autoleveling:
the modified grbl after the autolevel:
I would note it: All of comments is gone. I not sure what make the mistake. Maybe z axis inaccurate? (the cnc is in my closet almost 2 years) slow controller board? (the modern board burned down due to an inaccurate heightmap -Candle- i'm don't understand the protectionless electronics ) If i can suggest a speedup trick... on scanning i give a smaller height if this height relative, to last touch point so i give 0.5mm to scan height, if this 0.5 counted from the last touched height. the touch rarely change 0.5mm in 10mm distance, but the scanning speed is significant faster. Thanks to the asistance, and your work |
Hi! i'm testing a little with touch probe... if i'm used a higher feed rate, the result is inaccurate. F20 +/- 0.2 mm i created an own probe macro. with this macro the touching error always betveen +/- 0.003mm to 0.006mm (by the cncjs report)
maybe an another suggestion. the autoleveler probe's it could be like this:
This is may create a better result. i try an autoleveling some specific feed rate. and (if) i can save the result compared to this. of course this problem maybe exists only in hobby cnc machines. |
It looks to me like you are doing everything correctly regarding the software use. It could be then that the problem is mechanical. If you do get good probing repeatability then it could be that machine is accurate when there are no forces involved, but not so much when it as actually milling. Also for PCB milling, backlash should be minimal (i.e. less than 50 um) in order to get good results - either by using ball screws or some sort of anti-backlash nut |
ok definitely hardware problem. If your code has a little bit more comment, maybe i'm understand it. I'm not programmed js before. But if i see right, i need an average auto leveling. minimum 3 but preferably 5 touch average. Then maybe i can modify the leveler. Until that i trying. If i see right the probe process not writed in function. It is more safe to DIY to an incompetent geek. :) Thank you very mutch! |
Sorry again! i found a problem. Your code not analyze the movement if i see it right. I created a 20X20mm square, with isolation routing, so this is two square. an inner and an outer. The flatcam generate a wrong code, that an anoter bug report. The outer square has 4 movement. X19.9Y-19.9 then move X19.9Y-0.1 then X0.1X-19.9 then X0.1Y-0.1 then X0.1Y-19.9. your code that modified this 4 lines. But the heightmap shows differences in height in this 20 mm. Normally this movement needs to chop multiple pieces. Minimum so mutch as the heightmap probes in that distance. Here has one 20mm step, but i have 10 pieces 2mm height probe. So this movement needs to divide to 10 parts, then apply the Z axis movement. So unfortunately my hardwer is not the best on market, but this problem can cause my problems one part. What you think? This is the modified grbl as you see the flatcam make a mistake too. The inner square is 4 movement the outer is 67. That is not a square maybe a diamond? i'm not created a visual image. But the modified GRBL has some duplicates.
The original grbl: ` G01 X19.9000 Y-19.9000
I need that PCB for now so i'm search my iron-chlorid and the laser printer, thats enough to an one sided PCB |
this funcion splitToSegments(p1, p2, units) does the chopping Line 343 in e5bb26d
so far it all worked fine for me i.e. this is the last PCB I milled few months ago, the size is quite large 100x150 mm and it came out ok: also I usually plot the silkscreen layer with the white marker for glass (POSCA 0.7mm) mounted on the CNC (though have to set larger fonts for silkscreen layer and adjust it a little because pen is not thin enough for fine details) |
Hi! Nice work, what programs are you use? i created the PCB in Kicad then convert in Flatcam to grbl then use cncjs. I use the candle before but that always dropped the connection. And what you think, in my case why not segmentated the movement? |
An another question. The autoleveler set the initial Z height, or use the current z settings? So if i set the Z lower a few mikrometer... i se the first is not the best, but i'm not create a new grbl to deeper cut only i set the z to a bit lower (G10 L20 P1 Z-0.05)... Can work? |
thx, I also use kicad + flatcam + grbl + cncjs + a small script to generate grbl gcode from gerber file for silkscreeen plotting. however I am using some very old version of this autolevel script, I was accepting the pull requests in order for other people to use new features, but I didn't upgrade on the CNC machine it for a long time because the original version worked just ok for me . But now I see that in this current version it may be a problem here Line 471 in e5bb26d
it looks like it is missing the units parameter ... So I will need to test this new version and correct it Edit: this missing units parameter is also like this in the version I am using, so It may be work ok like that ... anyway I will test the last version today |
This should work after autoleveling is performed - you can adjust machine work offset to get deeper cuts |
Hi, yes, after testing I see that the splitToSegments didn't seem to work correctly in the recent versions. Thanks for noticing this! It is fixed now, here is the output example with new version using your gcode file: hopefully this also solves the problem for your PCB |
Hi! Thank you! I'm testing. |
Hi! It's perfect. The PCB is almost perfect in first try! Thank you! |
Happy that it works for you. will close the issue |
Hi!
Sorry my english, and the bothering...
The documentation is a bit incomprehensible. The probeopen needs to run before autolevel, or after autolevel? What happened if i use probeopen and the file is exists? The exists file is applied to gcode, or the exists file overtwritten by the new autolevel datas?
In my opinion this needs to clear. Maybe need a probesave command, or a overwrite parameter to the probeopen command.
What if the gcode has an applied autolevel. the new autolevel owervrites that or modify the previous autolevel datas?
How to stop the autoleveling?
The autoleveler can work in:
(probeopen)
(#autolevel)
(probeclose)
the autolevel reapply working from previously saved file? How? need a probeopen before?
The text was updated successfully, but these errors were encountered: