Open paulvdhoeven opened 3 years ago
Ok, happens to me as well. We need to figure this out.
number or value too large?
I don't know if it would not matter numerically in the code, but those G2 commands are non-standard. G2 and G3 commands require that the radius at the start and end are equal. Your G2 moves have start and end points that are basically 1mm away on the z axis, centered at the origin. This implies a radius that is a hair longer than the X start and end positions. This could dissapear numerically, but maybe not. I'm still processing coffee ATM, but I think adding K-0.5 and K-1.5 would be correct?
A quick test would be sending it an invalid arc command that is not on the edge of dropping out numerically, like:
G1 X5.0Y5.0
G02 X1.0Y0.0I1.1J1.1
If that throws a different error or no error, then I'd say there is some buffer overflowing somewhere with those huge numbers. I mean, this is machine with 1km of X and Y travel, correct? This would not be fix that ever gets used for actual cutting. :P
Maybe I should have mentioned it in the first post, but I thought it obvious enough that the 123456797 coordinates are bogus. My immediate concern is not with bogus code, but with bCNC not being able to load the code and trying to allocate infinite memory.
I do not understand why my G02 and G03 codes would be non standard. How could a G02 arc have two different radii??? As I understand the G-code, then G02 and G03 are always 2D circles (normally in (X, Y) and adding Z does change nothing about the radius, but only turns the arc (circle) into a spiral.
As I said in my first post, I'm still experimenting with this stuff and both my G-code and Python knowledge is quite limited. The G-Code posted before was generated from a python script, and the big bogus coordinates come from a tool radius that was set incorrectly (to: 123456789 in the library, forgot to set it to some proper value.)
For the curious, I'll attach the library that generated the code. The G02 G-code was generated by the "cylinder( )" function. 2021-03-27_cnc.py.zip
G02/03 codes can be 2d or 3D… here is a fairly thorough description of how they work:
https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/
There is only one radius per arc command. What makes an arc command invalid is when it’s start/end points and pivot point are implausible (ie different radius at start vs stop).
I am also not proficient with python or really any of the code underlying g bcnc. I just was pointing out that this issue may be caused by a numerical error… in this case the z moves almost zero per unit of xy travel. Depending on how the arc command is processed it could cause problems (for example if the planner takes an incremental change those changes may all be numerically zero). To visualize this… imagine a tiny change in z at that angle results in a huge change in r. Can also see this as near zero change in z wrt xy position. This is an area to focus on when looking for a numerical cause.
Maybe it is not related to this at all… maybe some buffer overflow not handled correctly? I am of little help wrt these kinds of programming bugs.
I am experimenting with a bit of python script to generate G-Code files. Upon loading one of those files bCNC got unresponsive and I had to kill it. When looking at bCNC in the system monitor it keeps on allocating memory at a pretty steep rate. It got to over 2GB in a minute or so.
Here is the code that I used:
The title bar has the text: bCNC 0.9.14-dev(linux py3.8.5)