Large files issue random straight lines

[massiveradiation]

Hey folks,
I've been using bCNC for years now on an RPi and it has been awesome! Seriously, I love this software and I want to thank everyone involved in its development.

Over the years I've been having one persistent issue with random straight line movement in large files. I've ruled out Fusion 360 and post processing for grbl. I've ruled out the hardware. It boils down to bCNC randomly inserting straight line movements.

You can see in the image, below and parallel to the green line, how the machine simply stopped executing gcode and moved in a straight random line, and then continued with the gcode as if nothing happened. I repeat, this is not in the gcode. I've analyzed and plotted the gcode at ncviewer.com (if you haven't used this, you're missing out!) and it's perfect. Sometimes several of these random straight lines are cut over the course of the job. The file size is almost 15MB, almost 600K lines of gcode. It's simply a repeating pattern, so I wish there were a way to simply repeat the same bit of gcode over and over, but from different start points. In this case, it would reduce the number of gcode lines to less than 7K! Anyway, a man can dream.

I'm using the latest Beta 9.14 version. Perhaps I should step back to 9.11?

I know that there hasn't been any movement on the bCNC github for quite some time now, but I'm hoping someone may have some insight since I love this software and want to continue using it, but damage is occurring randomly to my work pieces. The autolevel feature is something I can't live without for my purposes. I've looked at other possible gcode senders, but none have as easy and repeatable autolevel setup as bCNC.

I'm going to try breaking the large gcode files into pieces to see if that will have any effect. This is not ideal, as I can't just walk away and let this job run in its entirety, but perhaps it's better than losing work, time and material.

Any input or suggestions to help solve this perplexing riddle, are welcome.

Cheers,
Tyler

[JipeB]

Hello,
You have 6 workspaces (G54..G59) therefore the possibility of repeating the same code 6 times, and of dividing the file size by 6.
The offset between workspaces must be a multiple of the pattern group.
J.P.

[massiveradiation]

J.P.
Great idea for lowering the file size! Using the different work spaces! I'm not exactly sure how this would work since I've only ever used G54. I use Fusion 360 for CAM. If I create 6 different setups, then the file size would be about the same. I could create 6 separate gcode files, but that would be a bit of a hassle. Can you explain how I can make this happen.
Also, is there anyone actively working on bCNC improvement? Seem like people are indicating that it's working with grblHal. I'm currently using it with FluidNC.
Thanks for answering.
Cheers,
Tyler

[Harvie]

Also, is there anyone actively working on bCNC improvement?

There is no dedicated developer right now, but when random people submit PRs that looks sensible to me i try to review it and merge it if don't find any issues. But there are some caveats in bCNC that need to be adressed (most notably #591 ) which i haven't looked into for a while...

[JipeB]

Create the program to cover 1/6th of the surface to be machined with Fusion 360. The Gcode will be edited in G54 by default.

Create with bCNC 6 workspaces which will be stored in grbl. The offsets of each workspace must be in phase with the pitch of the patterns to obtain a good connection.

Run program in G54.

When the program is finished, open the bCNC code editor and modify Fixture to G55.

Launch the program, it will run on G55.

Same procedure for the other workspaces.
The same code is repeated 6 times. In fact the volume of the code is divided by 6

JP

[massiveradiation]

I thought I'd give an update here. This was happening when running bCNC from a RPi4 with Ubuntu, which was fairly sluggish with larger files. I upgraded to a PC with 16GB RAM, faster CPU, etc and running the latest version of Linux and the problem went away. At least so far. So, while I don't know exactly what was causing it, it seems to have been some sort of resources issue. Thanks for the suggestions!

[JipeB]

To make any suggestion you would need to know how bCNC stores the file being executed. It could be in RAM for small files, but for files of around ten G0 I only see a temporary file on the hard drive to do the job.
@Harvie could probably tell us more on the subject.

My version of bCNC is installed on an RPI4 with 8 GB of RAM which boots on a 250 MB disk. So far I haven't had this kind of problem, but my files rarely exceed 1 GB.

To reduce the size of files including repetitive machining, it would be necessary to be able to use the subprograms as on professional computers; but as bCNC does not recognize the M98 and M99 functions, a developer would need to take an interest in them.
JP