bCNC chokes with huge memory leak on small .nc file.

[paulvdhoeven]

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:

(/home/paul/projects/cnc/000_AAA_Python.nc)
G17 G21 G40 G49 G54 G90 G94 (End of init code.)
M03 S6000(rpm, cw.)
G04 P 125.0
F300
G0   X123456787.3 Y0
(Cylinder X0 Y0 Zbot: -2 rad: -123456787.3 step: 1)
G02 X123456787.3 Y0 Z-1 I-123456787.3 J0
G02 X123456787.3 Y0 Z-2 I-123456787.3 J0
G02 X123456787.3 Y0 Z-2 I-123456787.3 J0
G0   X0 Y0
G0  Z3
F1200
G0   X-123456797 Y0
G0  Z1
(Cylinder X0 Y0 Zbot: -3 rad: 123456797 step: 999)
G02 X-123456797 Y0 Z-3 I123456797 J0
G02 X-123456797 Y0 Z-3 I123456797 J0
G0  Z3
G0  Z10

( End of Program: cleanup )
M05 ( Spindle off )

M30 ( End of program.)

The title bar has the text: bCNC 0.9.14-dev(linux py3.8.5)

[Harvie]

Ok, happens to me as well. We need to figure this out.

[MARIOBASZ]

number or value too large?

[truglodite]

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

[paulvdhoeven]

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

[truglodite]

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.