Crash in OpenOffice processing Gcode data

[HjC]

Edit: New person/situation needs new topic. Split from Calc keeps crashing, lots of lost work

I do not use Calc much but have recently tried to use it work on a Gcode file for 3D printing. The system was repeatedly crashing when I tried to enter equations to check the data. At first I thought this was due to the size of the file 532000 lines of text so tried to set up some Macros to do the checks one line at a time. Still crashed when trying to use or even edit a macro.
Went through this and related posts to see what was recommended and then did the following several times and in various combinations:
a) reset user profiles,
b) reinstall Open Office,
c) reinstall Java to suit Open Office,
d) update Windows.
and
e) use only ODS file format
Probably about 10 or 12 combinations but the end result every time was, crash, crash, crash.
So did the obvious;
Uninstalled Open Office,
Installed LibreOffice 6.3 with the relevant Java.
Result everything works perfectly, no need for macros the LibreOffice Calc has no problem with the file size and all the related formulas and works with all my other ODS historic files, no problem.
So answer seems to be don't use Open Office with Windows use LibreOffice instead.
(EDIT - changed incorrect ref Libra Office to correct name LibreOffice)

[RusselB]

FYI: The reference in the above post uses "Libra Office".
This is incorrect, as the office suite that closest matches in name is "LibreOffice"

[RoryOF]

Start Windows in Safe Mode (Google for how). Run LibreOffice while Windows is in that mode; if LibreOffice runs stable while Windows is in Safe Mode, the problem is caused by some other program or driver that runs in Windows normal mode. Then detective work is needed.

[HjC]

OOPS!! my typo.
Yes it is LibreOffice I have used to replace Open Office.

[HjC]

Not sure if RoryOF » Mon Dec 30, 2019 6:11 pm is in response to my post.

But LibreOffice works with no problem at all under Windows 10, it is only Open Office which crashes all the time. I solved my problem by removing Open Office and am now using only LibreOffice.

Over and Out.

[RoryOF]

Then Windows Safe Mode and try OpenOffice in that mode.

[HjC]

Although not mentioned in my first post Windows Safe Mode with Open Office was one of the many combinations I tried and it still crashed hence my conversion to a stable alternative, LibreOffice.

[John_Ha]

Auto saving has been set to every minute in the hopes of mitigating lost work.

How long does it take to save your 532,000 row file as 1 minute may be too short.

"Read-Error. Unknown or unsupported Excel file."

That suggests you are using .xls files. Use .odt files. See [Tutorial] Differences between Writer and MS Word files for a description of differences and for why you should always work in, and save files as, .odt.

Your LO setup may be different from your AOO setup (eg macros disabled or a problem macro not present) so your conclusion "I solved my problem by removing Open Office and am now using only LibreOffice" seems highly suspect to me.

Without sight of the file there is little else we can advise.

[RusselB]

Please change the .odt references in John_Ha's reply to .ods, as that is the extension for Open Document Spreadsheets. The .odt is for Open Document Document Text.

[John_Ha]

Russel

The tutorial explains it is for spreadsheet .ods too ...

I will update my AutoHotKey to "See [Tutorial] Differences between Writer and MS Word files for a description of differences and for why you should always work in, and save Writer files as, .odt, Calc files as .ods, Impress files as .odp etc."

[HjC]

Regarding John_Ha » Mon Dec 30, 2019 9:33 pm

File takes 40 seconds to save. When I was testing it on the AOO set up I only used a file with 50 lines to develop the macros in the hope that a small file would not generate the crash but it made no difference.

Do not understand the XLS ref which is not relevant to my situation, I use ODS. Your ref to ODT is in error.

My LO set up has macros etc fully enabled including the record option.
I also tested the same macros I had produced under the AOO set up and these ran flawlessly on the LO but constantly crash in the AOO.
The main difference between the LO and AOO is that under Windows the AOO and the supporting Java are 32 bit but LO is 64 bit.

I am satisfied that in my case the error lies with Open Office and that LibreOffice is the more stable option for me.

[RoryOF]

There are by now differences in the underlying code bases and macro capabilities of OpenOffice and LibreOffice.

Is it possible that at some stage you tweaked the macros on LibreOffice, thereby introducing some LibreOffice specific construct? I doubt that the Java comes into play.

[HjC]

The macros used in the LO were a direct cut and paste from those developed in the AOO, no tweaking done.

As LO ran these with no problem it seems to strengthen the case for LO being a more stable package.

[John_Ha]

I downloaded 1,000,000 sales records in a 119 MByte .csv file from Downloads 18 - Sample CSV Files / Data Sets for Testing (till 1.5 Million Records) - Sales, opened the file with AOO 4.1.7 and saved it as 1000000 Sales Records.ods. Each row had fourteen columns as shown below.

Code: Select all

Region	Country	Item Type	Sales Channel	Order Priority	Order Date	Order ID	Ship Date	Units Sold	Unit Price	Unit Cost	Total Revenue	Total Cost	Total Profit
Sub-Saharan Africa	South Africa	Fruits	Offline	M	7/27/2012	443368995	7/28/2012	1593	9.33	6.92	14862.69	11023.56	3839.13
Middle East and North Africa	Morocco	Clothes	Online	M	9/14/2013	667593514	10/19/2013	4611	109.28	35.84	503890.08	165258.24	338631.84
Australia and Oceania	Papua New Guinea	Meat	Offline	M	5/15/2015	940995585	6/4/2015	360	421.89	364.69	151880.4	131288.4	20592
Sub-Saharan Africa	Djibouti	Clothes	Offline	H	5/17/2017	880811536	7/2/2017	562	109.28	35.84	61415.36	20142.08	41273.28
Europe	Slovakia	Beverages	Offline	L	10/26/2016	174590194	12/4/2016	3973	47.45	31.79	188518.85	126301.67	62217.18

The .ods file was 77 MBytes. This is so small because there was a lot of repetition of country names, product categories etc (and XML tags), all of which compress excellently. When decompressed content.xml was almost 1.5 GBytes. The .ods file took over three minutes to save and the CPU continued to be consumed for many seconds after the blue dotted line had crossed the bottom of the screen.

content.xml is 1,455 MBytes

This file is probably 8x or 10x larger than your file (I have twice the rows and 14 columns compared with your probable 3 columns) but AOO was completely responsive and I had no crashes or hangs. For example I sorted the entire 1,000,000 records on the Total Profit column and it took about six minutes without any problems. Centralising 4,000,000 items in four columns took three or four seconds. soffice.bin was using 877 MBytes of memory in my 4 GB PC. File > Properties > Statistics ..., shows I have 14,000,000 cells and nearly 57,000 pages. Scrolling or dragging a view bar was instantaneous.

1,000,000 row file sorted on the right-most column

I therefore suggest that there is something wrong with your much smaller file of only 500,000 rows, your setup or the way in which you are working. It is probably your setting the AutoSave time to only 1 minute as the save probably takes longer than that.

Also you are probably mistaking AOO "not responding while it is working" with "hanging". A hang is where the program is permanently unresponsive. You also may incorrectly be calling "not responding" or "hanging" a "crash" but they are not the same think. A "crash" is when the program terminates, the program window disappears and the program disappears from TaskManager.

[HjC]

Thanks for the comments.

All my crashes were just that the programme terminates.
This includes any attempt to use the macro editor, just trying to delete one line generates a crash.

I have made no reference to my auto save setting, but the test file with only 50 records only takes a second or so to save and still crashed.

Perhaps you should try using Windows 10 with the most recent Open Office to see what happens.

For me I have fixed the problem and will only be using LibreOffice from now on.

[John_Ha]

Perhaps you should try using Windows 10 with the most recent Open Office to see what happens.

My file works fine on W10. It is a different PC so not immediately comparable.

Loading the file seems to take a little longer but sorting the 1,000,000 records is much faster - only about one minute. Saving the file took about 2 1/2 minutes where the green bar stopped after 1 1/2 minutes but the save was not completed for a further 1 minute.

As an aside why are you using a spreadsheet for a 3D Printer file? I would have thought a flat TXT file would be much better as the data is presumably just flat text and the spreadsheet carries an unnecessary overhead compared with a text file editor. NotePad ++ opens the 120 MByte .csv file in about one second ...

I downloaded a .3mf file, extracted ...\3d\3dmodel.model and renamed to 3dmodel.xml. NotePad++ opened and laid out the 28 MByte .xml file in seconds. It has 530,000 lines.

[HjC]

Hi.

I am using a spreed sheet because I need to interrogate the Gcode file to see if I can correct some geometry errors which Cura is producing.
The spreed sheet has 4 sheets, (1) imported Gcode text, (2) look up table to turn Gcode commands into plain English, (3) formulas to read the Gcode, put it into plain English so that I can understand before I modify some paths, (4) Graph to show the path as I change it so that I can also get the print head return path correct.

Basically I need to force Cura to print wall thickness from the core of the section towards the outer surface but Cura seems to do it the other way which leaves parts unsupported. Have not found any Cura setting which reverses this behaviour.

I am sure there must be some high end professional 3D printing software / editor which allows you to drag and drop geometry corrections like this but I have not found it.

Thanks for the interest.

[John_Ha]

Basically I need to force Cura to print wall thickness from the core of the section towards the outer surface but Cura seems to do it the other way which leaves parts unsupported. Have not found any Cura setting which reverses this behaviour.

I am now well out of my depth but a quick glance at the Cura tutorial shows a section "Turn on auto-generated support structures for unstable models in Cura".

Have you tried asking on the Cura Forum

[HjC]

Hi again.

I am trying to avoid using the general support structure option as most of the model is fine without this, it uses extra time and material and can spoil the final look due to need for removal after printing. Unfortunately the option is all or nothing. Cura does have a system for setting up special case slicing geometries but I have not yet mastered this.

I will give the Cura forum a look, did not think of that.