Skip to content
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

Warning in log and a question #71

Open
AuBeTeX opened this issue Sep 19, 2024 · 4 comments
Open

Warning in log and a question #71

AuBeTeX opened this issue Sep 19, 2024 · 4 comments

Comments

@AuBeTeX
Copy link

AuBeTeX commented Sep 19, 2024

Hi!

I guess you don't want to see me here, but unfortunately I'm still here and I use your program. Some time has passed again and I have time to deal with cnc again.

I made a panelized board and would work with it, but when I do the AL, it writes this warning in the log, which I haven't seen so far.

"WARNING: WCO Z offset drift detected!" what can this mean, do I have to do something with it, or can I just pass it?

I have another question, since I don't really understand js, but at least my CNC is crap, how complicated would it be to eliminate the problems arising from the crappy machine with a modification that tests every point at least 3x and averages from that? Maybe parameterizable? Unfortunately, I noticed that if I measure three times at the same point, the measurements always return slightly different results.

From the modest financial resources available in my small country, it only runs on Chinese garbage :)

Thank you for your divorce and patience.

Postscript: I wrote here because there is no discussion on the page, feel free to close the previous ones and this one as well. Thanks again!

@kreso-t
Copy link
Owner

kreso-t commented Sep 19, 2024

Hi,

The message "WCO Z offset drift detected!" should mean that AL script has detected the change in program zero/work coordinate offset for Z i.e. such as when you execute G10 L2 P1 Z0. If that happened during probing I guess that would cause a problem with the results later. If it has detected it before actual probing was started then probably would not be a problem.

About multiple probing and averaging for the same point, it could be done - it would take some time to do it and a lot of testing. But not sure if it would help significantly if machine is not mechanically precise enough, i.e. if it does not have positional repeatability later on, then getting more correct probing values would not matter that much.

Can you somehow check if the problem is machine positioning or is it really the probing? i.e. maybe with a tool like dial indicator (i.e. see link)
Maybe you can try to do probing at slower speed?

Could not get from you profile in which country do you live?

Br,
Kresimir

@AuBeTeX
Copy link
Author

AuBeTeX commented Sep 20, 2024

Hi!

Sorry i'm a bit long.

Thanks for the answer! And then comes "I don't understand this now then" :) The actions I perform:
I load grbl, then go to the lower left corner (that's what you wrote) and send the

G38.2 F50 Z-40
G91
g0 z1
G38.2 F10 Z-2
g0 z0.2
G38.2 F1 Z-0.5
G90
G92 Z0
g0 z2

Instructions as a macro. after that these instructions:

G38.2 F100 Z-40
G91
g0 z1
G38.2 F10 Z-2
g0 z0.2
G38.2 F1 Z-0.5
G90

as a macro. then the command "(#autolevel D5 H1 F10 M1)".
From now on, I won't touch anything until it's finished. The event log looks like this (first few lines):

 params: { PRB: { result: 1, x: '-144.000', y: '-98.000', z: '-27.128' } },
 Math: {},
 JSON: {},
 source: 'feeder'
}
Opened probe file __last_Z_probe.txt
STEP: 5 mm HEIGHT:1 mm FEED:10 MARGIN: 1 mm PROBE ONLY:0 Area: Not specified
WCO: { x: -144, y: -26, z: -27.145 }
probed 1/285> 1.000 -71.480 0.012
probed 2/285> 6.090 -71.480 -0.018
WARNING: WCO Z offset drift detected! wco.z is now: -27.148
probed 3/285> 11.180 -71.480 -0.025

according to cncjs, the test took place at point X0 Y-72. although as far as I can see, you are using machine coordinates, not work coordinates.
Where did I screw up?

Last night's fun was as follows: I loaded the grbl, went through the above, and then watched that the

probed 285/285> 92.630 -1.000 0.303
Closing probe file
applying compensation ...
progress info ... line: 0/321453
-cut-
progress info ... line: 321000/321453
AL: loading new gcode #AL:Panelized watchdog att-F_Cu.gbr_iso_combined_cnc.nc ...)
output file written to /root/cncout/#AL:Panelized watchdog att-F_Cu.gbr_iso_combined_cnc.nc
Leveling applied
Connected to ws://localhost:80?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MjY3Nzg3NDIsImV4cCI6MTcyOTM3MDc0Mn0.dDV5Hfoq7_k23nW34ud0PFYOFwYcaEhL7rSRetEL-X8
Connected to port "/dev/ttyUSB0" (Baud rate: 115200)
gcode loaded: Panelized watchdog att-F_Cu.gbr_iso_combined_cnc.nc
-cut-
point 285 X:92.63 Y:-1 Z:0.3030000000000008
Read 285 tested points from the previous session
Sentinel server running
Connected to ws://localhost:80?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MjY3ODIwOTYsImV4cCI6MTcyOTM3NDA5Nn0.O1nDi0_d1ARsnTDcijykKn8gFdO4Nt-qiwnRpn2wPKE
Connected to port "/dev/ttyUSB0" (Baud rate: 115200)
Loading previous probe from __last_Z_probe.txt
point 1 X:1 Y:-71.48 Z:0.012000000000000455

nothing changed in cncjs after that. (#autolevel_reapply) did nothing. The grbl remained the same. So I loaded the saved file. Why is this? This was no problem before. so much so that I installed a links browser on the pi

Also, from the logs, it seems to keep restarting.

I played with the instrument you suggested and it showed a small deviation from the horizontal one, but I don't trust it either because I didn't manage to attach it to the machine really effectively. I am afraid that the problem is not so much with the mechanics of the machine, but with the inaccurate setting of steppers due to the lack of description. I set it up as much as possible, but I have limitations. Here, there may be a problem with the precision settings of the stepper motors. Originally, when I assembled the device, a 5 cm milling was 5.5 cm. Currently, with my measuring capabilities, 5 cm seems to be 5 cm, although this does not mean that there is not a difference of a few tenths or hundredths of mm. But I set this up a long time ago and forgot how. maybe it should be recalibrated. Sometimes the milled holes seem to be not as big as on the plans. the part does not always go in. sometimes yes. which may indicate wobble.

But let's look at an example, the panel is curved, it's clear that if it were straight, there would be no need for AL. I zeroed the position at the x0y0 point with the above macro, then checked with the one below:

1 0.000
2 -0.002
3 +0.003

The difference is not great, but it is not zero either, and it is still noticeable with a copper thickness of 35 microns. If I do the measurement at one speed, let's say with F10, the differences are already in the order of 0.01-0.02. that is, the difference is about tenfold. I wrote the zeroing macro to make it more accurate. if I keep the speed of the AL F very low, the running time of the AL increases significantly due to the high altitude. I don't really dare to reduce it because there have been instances where the tool got stuck while on the move. If AL adjusts the height compared to the previous pot, the chance of this would be smaller, but I can see from the numbers that it adjusts it to the original zero. I would take it to 0.1, but there are points where the difference is greater than 0.1.
Check out this series:

probed 10/285> 46.815 -71.480 0.043
probed 11/285> 51.905 -71.480 0.068
probed 12/285> 56.995 -71.480 0.100
probed 13/285> 62.087 -71.480 0.125
probed 14/285> 67.177 -71.480 0.155
probed 15/285> 72.267 -71.480 0.183
probed 16/285> 77.357 -71.480 0.215
probed 17/285> 82.450 -71.480 0.240
probed 18/285> 87.540 -71.480 0.268
probed 19/285> 92.630 -71.480 0.300

The difference is 0.3 under ~5 cm.

Perhaps it would also be good to measure the AL at the speed F specified by the user, then reduce the speed significantly and make it more precise by raising it only a few tenths of a millimeter. I'll try the F1 one of these nights, although if it restarts it might not work because the current measurement takes about an hour, it will take about 10 hours. then I compare the result.

One more thing I noticed. I started AL, then cncjs crashed and the web interface didn't work, so I restarted the whole thing with a script. I uninstalled cncjs and AL and then started them. But until and after they were fired, the CNC continued the AL. Only a reset stopped it.

And my country is Hungary, A small, almost dictatorship, with a lot of poverty :) OK, I know there are a thousand places in the world where everything is worse, but here, in ~1 year, the country was destroyed, and people who lived modestly until now are now struggling.

@kreso-t
Copy link
Owner

kreso-t commented Sep 20, 2024

Hi,

Unfortunately I haven not done any PCB milling for quite some time ... so I will try to do some tests on my side and see if I can reproduce some of the issues you mentioned related to "WCO Z offset drift detected!" and repeatability of probing.

However it seems to me that if your deviations of measurement for the same x,y point are well below +-0.025 mm that should be very good result and the PCB should come up OK. As lead screws on my machine have accuracy of cca 25 um and the PCB usually comes out OK.

Relating the dynamically adjusting the initial probing height based on previous measurement - that could be a problem because the gcode for probing is actually generated in advance and not altered during probing. I will see what I can do about it... The approach with first faster probing then another slower probing could maybe be possible.

Related to problem with "nothing changed in cncjs" after AL - that looks like the issue with not enough memory on the PI. I see that your gocde file is quite large >300k lines. Most of my projects have less than 100K, i.e. 2-3MB of gcode per single file. Maybe you can split somehow the gcode to more smaller files? Also it could be that other problems with software stability are also related to not having enough RAM.

So then we live in neighboring countries :) - I live in Croatia. Sorry to hear about the situation in Hungary, in Croatia life is relatively OK for most of the people I guess, or maybe we just got used to not expecting too much :)

Br,
K.

@AuBeTeX
Copy link
Author

AuBeTeX commented Sep 20, 2024

Hi!

Ok, I'll reduce the size then. This is a job that connects 12 mini-panels, but then I don't insulate in 3 passes, but only in one, and not in several steps. The PI has 1GB of memory, of which 216MB is free. But according to them, my older problem is the cleaning milling (which removes the excess copper from the sheet), maybe that's why it failed? Unfortunately, I can't put a larger machine there at the moment, my milling machine is in an unheated "workshop" which would be difficult for a desktop machine. I'll try. I'll report the results as soon as I can.

Let me tell you, we didn't expect much either, but even we managed to fall short here :)

I've been ordering prototype boards for a while, but right now it's not worth my money, but I hope it will be better one day. By the way, now I have to put together several 5-part mini-boards, and even then it is not certain that the panel is perfect, it would cost a lot to order the PCB for it. I'm still in trouble because I have a micro-controller circuit which is good in principle, but it freezes regularly and I can't find the fault. Neither in the program nor on the circuit. The only thing left is the EMP. It's driving me crazy :) I need to make a watchdog for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants