Re-arm, connection drops after G31

Hi,

I recently had a little hiccup after flashing the newer edge version of smoothieware, but I fiexed it and it worked normally.

After I switched nozzle I wanted to redo the calibration and noticed that the connection drops as soon as the first 2-3 points are probed both with G32 and G31.
I reflashed the firmware, checked the config, and did a print from the sd card while being connected to my pc to make sure the connection was stable.

Panucatt support recently started talking to me about my earlier issues, so I already opened a ticket on this issue.

Are you re-arm people already on edge? According to Arthur Wolf master is "old and shouldnt be used" but im not sure how flexible the re-arm is with the different firmwares.


My zprobe config looks like this btw:


# optional Z probe [smoothieware.org]
zprobe.enable true # set to true to enable a zprobe
zprobe.probe_pin 1.29^ # pin probe is attached to if NC remove the !
zprobe.slow_feedrate 5 # mm/sec probe feed rate
#zprobe.debounce_count 100 # set if noisy
zprobe.fast_feedrate 100 # move feedrate
zprobe.probe_height 30 # how much above bed to start probe

#leveling-strategy.delta-grid.probe_offsets 0,0,0 # Optional probe offsets from the nozzle or tool head

# Example for the delta calibration strategy
leveling-strategy.delta-calibration.enable true # Enable basic delta calibration
leveling-strategy.delta-calibration.radius 100 # the probe radius

# Example for the delta grid leveling strategy
leveling-strategy.delta-grid.enable true # Enable grid leveling
leveling-strategy.delta-grid.radius 100 # Grid radius in millimeters
leveling-strategy.delta-grid.size 7 # Grid size, must be an odd number
leveling-strategy.delta-grid.do_home true # Whether to home before calibration
leveling-strategy.delta-grid.save true # Whether to automatically save the grid
leveling-strategy.delta-grid.initial_height 30 # Height at which to start probling

Edited 1 time(s). Last edit at 04/03/2017 04:29PM by sungod3k.

I had the same thing happen to me last night, with a compiled version of edge that I'd put some of my own slight changes in.

Changing back to master (from a month or two ago) made it all start working again.


I'm not sure what happens, it seems to just lock up completely, everything becomes unresponsive and the motors turn off.


Try using the master branch.

I hope this helps.

Aha good to know that is definitely version related.
Seems like a real bug.

Do you by any chance use a shielded cable? Thats at least the suggestion im getting from the google smoothie support group. I cant really imagine that interference is an issue because the same interference would happen over a longer print and also with the old master firmware, but stranger things have happened.

A shielded cable for what? The USB connection? I think all USB cables are shielded aren't they?

I must admit that I didn't sacrifice a chicken, or say a prayer to the 3D printer gods before my experiments. The result seemed quite repeatable so I didn't see the need to invoke a placebo.

im not following the placebo is what exactly in your religous metaphor?

i went back to master and voila it worked.

Quote
sungod3k
im not following the placebo is what exactly in your religous metaphor?

Shielded cable.

With a username like yours you should be familiar with religious rites!

I've submitted an issue for this:

[github.com]

Great,

[groups.google.com] this is the same issue on the smoothie support google group.

You mentioning the watchdog is interesting because in the very beginning I had to relax the settings already a bit and over the last 3 days I had 2 "random"
"halted, use M999" error, not sure how that fits in the overall picture.

Edited 1 time(s). Last edit at 04/06/2017 10:48AM by sungod3k.

Gosh. 3 hours after being submitted, the issue was closed because "This cannot be duplicated". Interesting, especially considering that you were able to duplicate it, and the person who closed my issue was aware of your problem as well.

Not a good introduction to the Smoothie development process. *sigh*

It would be great if you could post on the github issue, saying that you had the same problem.

Yup, I already have the text ready, I just wasnt at my printer today to copy my config and console log.
Ill post a something right away.

Quote
nebbian
I've submitted an issue for this:

[github.com]

Your so called "bogus" config (sorry, but I had to laugh when I read that) has currentcontrol_module_enable defined twice, the 2nd one is right at the bottom of the file is incorrectly set to true. Not sure why they didn't just point it out. There is also 2 entries for leds_disable, although the 2nd one is commented out, so not sure if that counts as bogus or not?

It's probably worth checking if it does it when the LCD is disconnected and also with panel disabled in config? It probably wont make a difference, but always good to show you've tried all the usual sources of problems, especially when it comes to 3rd party addons.

I also notice you have a kill button defined in the config, i assume is connected to button on LCD? I would also disable that during debugging in the config just to rule out some weird accidental triggering from noise/faulty button/etc.

Does it always fail in the same way? i.e. always immediately after a probe? Or randomly during a move etc?

Yeah I had to laugh as well. He certainly seems a bit bothered by it all. I don't know why he closed the issue straight away, I don't think that it's standard practice to do so on any of the other github repos that I've worked on.

I carefully went through my config this morning, and saw that I had exactly one duplicated setting: currentcontrol_module_enable (as you pointed out).

I'm not sure why he's so adamant that I need to disable the tower correction angles either, I've used them with good effect in Repetier. DC42's delta calculator certainly uses them as well.
If they're not supposed to be used, then why are they on this page?
[smoothieware.org]


The errors were happening without the kill button set up, but I'll try disabling it again just to confirm. The issue seems very repeatable. It doesn't always happen at the same spot, but it does happen during the calibration process with newer builds. With older builds it doesn't happen at all.

Yes, its strange to close so quickly. At the very least you'd expect them to wait to see the logs they requested.

I never had any luck with tower correction angles in smoothie, as soon as I used them it would make things a lot worse.

Out of interest, I just downloaded the latest firmware to put on my Azteeg X5 mini. The calibration ran though without a hitch, M500 no problems, M501 prints current settings to screen .... and then that's it, motors off, unresponsive, LEDs no longer flashing. Reset everything, and just ran M501 to see it that was the culprit and again unresponsive. While I cant replicate your issue, I have some new issue which also results in a crash. Seems like there is something odd with the latest firmware.

EDIT: Further investigation, if i have leveling-strategy.delta-grid.enable set to true, I can get the crash when loading config with M501. When set to false, no crash. Not sure if it helps with your issue, but can try it and see if G32 works with delta grid disabled.

Edited 1 time(s). Last edit at 04/07/2017 04:44AM by sdavi.

Sdavi,

Thanks for trying it out on the Azteeg X5 mini, that's a good data point. I'll try M501 next. It certainly sounds like a similar symptom.

Regarding tower correction angles, I've looked through the code, and it seems to be implemented properly -- I can't see how they would hurt to specify them properly. Did you set them based on a calculator like this one? [www.escher3d.com]

That's why I don't want to deal with smoothiware:
There is often this you_are_a_stupid_user subtone between the lines.
Something I haven't seen on other 32bit firmware hubs.

Oooh just saw your edit. That's some fine detective work right there! What a wonderful test. I'll try it asap.

Sounds to me like it could be a memory leak / out of bounds error.

Quote
o_lampe
That's why I don't want to deal with smoothiware:
There is often this you_are_a_stupid_user subtone between the lines.
Something I haven't seen on other 32bit firmware hubs.

I'm rapidly coming to the same conclusion

If only RRF supported normal LCD panels, and the Re-Arm.

Sdavi,

We have success! They uploaded some edits to the probe code, and now it seems to be working pretty reliably for me. Try the attached firmware.

Somehow this seems oddly appropriate:

Good to hear its all working now

Just read through those comments on github, interesting they say the angle corrections are incompatible with delta-grid. I don't recall seeing that anywhere in the documentation.

Yeah go figure. That'll teach me to believe the documentation.

btw grid levelling works, at least it's good once the print is well inside the mesh. On the edges it's a bit flakey.

My calibration at the moment is woeful, with all the bed taking off and putting back on, moving the printer, new firmware etc, it's all over the place. After doing the grid levelling routines the prints are nice and flat on the build plate. This isn't the end of it though, I'm not happy with how far out it was before grid levelling, so will have to turn it off again and do the full manual calibration properly. ie calipers, set square, the works.

When you do the mesh levelling, remember to send M374 (not M500 as the documentation suggests) to save the mesh.

Is your setup now working perfectly? I still have some freezes when i preheat from the display and also the occasional freeze midprint.

All working fine for me, have done at most a 1 hr print but no freezes since the code fix was posted (a week or so ago).

I ran some more prints, and I still have issues.

I ran G32/G31 combo with 9 points and it dropped the connection like before. When I changed to 7 points it worked. I have to repeat that some more times but its not encouraging.

and secondly almost on every first print of the day. When I just turn on the printer for the first time, select a file from the micro sd, the bed starts heating up and after a few seconds the display and the whole machine freezes. When I reset the board and do the same thing again the heat up goes normal and the prints starts just fine.