How do I do I document a possible problem in the latest edge?

How do I do I document a possible problem in the latest edge?
I attempted to do a G32 on a Rostock mini pro using the JhonSL fsr board and 3 FSR’s under the bed.

There was no override file present on the SD card at the time of the initial run.

The board is an Azteeg x5 v2
Commands were issued via USB serial from a Windows ten machine

The command would run through several iterations then become unresponsive, the log froze with a program exception and thread ended error. Then disconnected. This happened repeatedly.

I then tried:
G32 E0 and it was successful
M500
G32 R0 and it was successful
M500

After this G32 doing full radius and endstop calibration will iterate and succeed without crashing.

I have my config and terminal logs of the sessions on the machine in question

It’s possible you were very close to running out of ram, and because latest edge uses a tiny bit more RAM, you are now out of ram. can you try disabling a switch module and changing your queue from 32 to 16 ( just for testing ), and try to reproduce the error ?

Sure, my switch module is only configured for fan though. Is that enough? Just # it our or set to false?

Do you want me to delete the override file and try it that way or leave it in place?

As I said it did become successful after the overrides file was in place having calibrated endstops and radius separately. Btw the radius is not large on this machine. (Testing 60mm R)

Not sure if that’s a factor.

I can test the Rostock today if you like. Just want to know how to best document it for your analysis.

I also have a bunch of other boards I could try it on on different bots, but that would have to wait for me to finish taxes (ugg, being an adult sucks lol) I have pretty much all the Azteeg versions including the latest with the Bigfoot drivers. And a lot of different machine geometries. I may be a good resource in the future. Converting everything to smoothie.

Just set the switch to false, don’t change anything else ( in particular don’t change the override or anything, we want to change as little as possible to isolate the issue ).

Yup, one variable at a time… I can test with switch false, then true, and queue 16 then both if you like.

Just try one, and if it still crashed, try both together.

Failed with switch disabled and no other changes
Now going to change queue

Success with queue @16 and switch off
M500 save

Now turning switch for fan to true.

Failed with switch set to true and queue set to 16

Going to set queue back to 32. And run G32 E0 and G32 R0

Nope. So just set switch to false and plan ahead queue to 16 when I need to calibrate. Then back to 32 and true to run normally in the meantime? And do you need the config and the logs or this is enough for now? If it matters I am running the Azteeg with stepping set to max I believe.

I can also evaluate any other builds if/when they are available.
Running mar 23 22:12:46

what did the leds do? what host program are you using? the error is from the host not smoothie. FWIW I have never actually run out of memory on a delta with the standard config and a few switches set. issue the mem command at a prompt and see what you get I’ll bet you are nowhere near running out of memory.

I’ve been having some issues along the same line with my X5 V2 using Simplify3D. I upgraded to the latest edge build and now the printer seems to lag. It will print a few lines of code, freeze for a short while, and then resume. Would this be due to a ram shortage as well? I don’t run an LCD.

S3D cannot be used as a host to smoothjie it does not support the protocol smoothie uses, try pronterface or octoprint or a plain temnial. Any proiblems with S3D host are their problems not ours :slight_smile:

and no it would have nothing to do with RAM as I said there is usually plenty of RAM once it boots. to check issue the mem command if you have more than 2k free memory you are ok.

Had the same issue with pronterface, and no terminal at all with a custom.menu set up to do G32.
However I was able to get G32 E0, M500, G32 R0, M500 to work on both.

I don’t have visual on the leds, they are under the delta, but I can put it up on books and try again if that is a critical piece of data.

I managed to fix my problem. I disabled retract while wiping and that seems to have fixed my intermittent pausing I was getting. I don’t know why you can’t use smoothie as a host, I’ve been using it for a few years now.

It is odd that runni g with E and R works as it does exactly the same thing. Did yo u monitor the log for any error messages? did you set initial height correctly as per the wiki instructions?

If you use FSRs they tend to be overly sensitive and can sometimes trigger prematurely which would cause the calibration to cancel. I had that just happen to me with my FSR setup. I also run with far less memory than you would have available and routinely run G32 with NO issues whatsoever. So I can pretty much guarantee you are not running out of memory.
My best bet is you need to increase the initial_height setting.