Check for homing?

[bcsteeve]

I don't know if this is possible, but I just had a crappy moment where I hit "center" when the unit wasn't homed (timed out) and it assumed it was at 0,0 when it was actually at something like 200, 200 and it went bashing into the side of the frame.

So... if possible... can a check be done to see if homing is required? I don't know how the system knows, but on the LCD it will have flashing figures for X and Y and I think that means it isn't sure where it is (so proceed with caution).

If this isn't possible... then sure, proceed with caution :) I should have anyway.

[bcsteeve]

You know what... I think this is important because I just did it again. Need to somehow check that the printer knows where it is before heading off to la la land. Good luck.

[electr0sheep]

I can confirm that this is an issue. I've been working on extensibility, but I'm going to switch over to fixing this. Obviously I don't want to damage anyone's equipment.

[nean-and-i]

if possible, pls send a G28 ; Home X/Y/Z axis before starting with the first move.

and after calibration extruder reset and some other stuff might be useful, like: G28 ; Home X/Y/Z axis G92 E0 ; Set extruder to [0] zero M107 ; turn off layer fan M84 ; disable motors G90 ; absolute positioning

[bcsteeve]

Yeah, but how do we determine what is "the first move"? I wouldn't want a G28 before every move, certainly. And if too much time has passed (I guess?) and it loses its position then how do we know that?

Come to think of it... it would be great if Marlin itself would make the G28 a little smarter. By default, a G28 should do nothing if there is an expectation that it already knows where it is. A parameter could be used to force (or other way around. Force unless a parameter is sent). Off topic.

[nean-and-i]

in no case the plug know the position of the noozle.

@electr0sheep , can you probably implement a new switch that must be enabled first, before even being able to press a button? -> 0/1 switch like on a phone, after switching it on, then controls becomes visible or un-greyed, and on that switch-on action a G28 is being triggered,...

Result: after switching-on the plug (causing a single home),it knows the first position ;-) User might need to switch it off manually or automatically via timeout, that needs to be sorted,...

Instead of G28 you can do a fast move to eg. G1 X-500 Y-500 F10000 .... G1 Z-600 F40 .... that is a fast move to negative position, but that triggers the end stops fastest possible way

[bcsteeve]

"after enabling control, the plug knows the first position"

But that isn't true, unfortunately. Otherwise I wouldn't have run into trouble (twice) already. I did a G28 but then let some time pass and pressed "center" (while it was already in the G28 position, which is center + probe offsets for me) and it started to move to the back right. So we also can't depend on the control's own status.

Safest: G28 before every movement (crazy). Next safest: G28 before every movement AFTER some time has passed. Does the plug-in know time?

Best: If the plugin can get the status from the device or Octoprint. I have no idea if that's possible.

[nean-and-i]

sorry you misunderstood my posting,... I meant after implementation my new idea, this would then be the case,... I've edited it, hope its clear now?

[electr0sheep]

What I was working on is having a "Safety Home" button that you must press first (which homes the x and y axis, I don't want to mess with the z axis and knock printed stuff over). I actually assumed that @bcsteeve turned the printer on and then used the plugin before homing it. I didn't think it could become "out of sync" due to time. But at any rate, yes you can keep track of time, as the plugin uses JavaScript, but that's easier said than done.

[electr0sheep]

I think this is a very important issue, we don't want to damage people's expensive machines if we can help it. I have started work on this on the add-safety-home branch, with the idea that after the button is pressed, the normal controls become visible. Any help would be welcome.

[bcsteeve]

I can confirm that I did not use the plugin before homing. The reason it was where it was (offset from center by the probe offsets) was because the last thing I did was home it. Some time passed... not sure how long. Then I clicked "center" and it crashed into the side before I could reach the power switch. Then I did the same thing later (but that time I got to the switch).

Damage isn't a huge concern, though it is possible. It makes a heck of an ugly noise, but the steppers aren't really powerful enough to do much more than skip the belt and throw things out of alignment a little.

I tried looking into the available commands and methods and I'm not sure there's much you can do. On my end, I'll use M84 to lengthen the stepper timeouts, which may be the issue? They default to 1 minute. I'll do more testing.

[electr0sheep]

If I add a button that issues an M84, will that cause all the motors to stop? Maybe I could add a button like that as an emergency stop.

[bcsteeve]

M84 sets the timeout is all. There is an emergency stop, but it requires a firmware change. I can look up the details of you want. I would LOVE an emergency stop! I'm kind of surprised it isn't a native feature.

[electr0sheep]

It looks like M112 might do the trick. What firmware does the CR-10 use? Is it Marlin? According to the link, Marlin should support M112?

[bcsteeve]

M112 is a little harsh, but yeah it works most of the time. I'll look up the method I meant

[bcsteeve]

M108 is the one. Requires EMERGENCY_PARSER but doesn't require system restart like M112 does. And M112 can be delayed depending on what is currently executing.

[bcsteeve]

I'm sure stock CR10 uses some form of Marlin, but who knows what version and what they may have changed. I recommend every cr-10 owner should glass latest vanilla Marlin for sure.

[electr0sheep]

Oh I see. I guess I was looking at the wrong firmware's wiki. Geez that's confusing. M108 seems like it just breaks out of commands that cause the printer to "wait". Don't really know what I'm doing with Gcode though, so I'll give it a whirl.

Suppose I forget to home my machine and its ramming against an edge, would M108 stop that?

[bcsteeve]

Indirectly. Let me test and I'll get you the right gcode tomorrow. Use m112 for now because it doesn't require a firmware change and it is more straightforward. The problem with m112 is it requires the user to physically power cycle the printer and sometimes octopi also needs resetting. And rarely... it doesn't work fast enough (I've had problems during G29)

[bcsteeve]

OK, it looks like I was reading out-dated discussions that also included typos lol. M108 isn't what you want. M108 (as it was implemented) is what you said, a break from loops. It might still be a helpful button, but it isn't what I was thinking. I still don't like M112, but that might be the way to go. M18 (not M108) is what they meant. I see that's now analogous to M84, which I thought was just timeouts but it looks like if you pass it with no arguments that it disables all steppers (so what you asked above). So you were on the right track, I think, and I was steering you wrong. Sorry.

Let's try m18 (or 84) and see if that does the trick! If not, M112. I have my doubts, but the docs do say "immediately" so hopefully M18 doesn't have to wait for the queue to clear. If it does, ironically M108 might be the answer - send that and then M18.

[b-morgan]

There should be a Start Gcode as part of the printer settings in any slicer that has support for the CR-10. These Gcode commands begin with the commands necessary to take the printer from an unknown state to a known state which includes homing the axes. If the printer is already "homed" (and the bed is clear), these commands can safely be sent to the printer multiple times.

I believe a subset of this "Start Gcode" is what this plugin needs to implement.

[bcsteeve]

Except that start code executes immediately before a job... no possibility for a timeout. This plugin could be left on for hours without activity. Months even. There's no guarantee that the hooking is valid at any given time. Right? Maybe I've misinterpreted what I observed.

[b-morgan]

I'm not sure all printers "timeout" and forget where home is. How much time are you talking about?

I believe an additional "Home" button is necessary. When pressed it issues (at least) G28 and enables all the other buttons. There could be a setting associated with this button that was a timeout value with 0 meaning never timeout and positive values being how many minutes(?) before the other buttons disable and you have to press the "Home" button again to get started. The other buttons might also disable when a print is started.

[bcsteeve]

Minutes. Not long. It has happened several times now.

Don't your steppers shut down after a minute? I think one minute is the default in Marlin. I assumed (could be very wrong) that is why/when the system seems to "forget" its position.

Haven't you ever run into... for example... trying to run G29 and the system complains that you have to do a G28 first? This can happen just a few minutes (or, presumably, exactly one minute) after running a G28.

I dunno... maybe its my system?

[b-morgan]

@bcsteeve : You are correct. The Marlin default is set in configuration_adv.h (for my printer, #define DEFAULT_STEPPER_DEACTIVE_TIME 120) and can be changed with M18 and M84 (http://marlinfw.org/docs/gcode/M018.html)

[nean-and-i]

for something like an emergency stop please install another plugin, afaik there are at least 2 plugs that does this already, so no need to get this addressed here. I've installed one and it works fine.

@electr0sheep I guess any kind of "homing first" mechanism is sufficient, however that will look like, its up to you, but we're in line that it is essential..

It seems this gets a bit off-topic, from homing to interrupting.

@bcsteeve "sometimes octopi also needs resetting" -> I doubt that, reconnecting is what you mean. The M112 in no case can cause raspbian linux underneath octoprint to freeze, if so you'd need to replace your pi/sd-card/ and reinstall the whole OS. I have no Idea what you like to achieve, actually M112 is the only way that works in our case, everything else only works to interrupt a series of gcode commands, to be specific-> only between 2 commands, so whatever you try to do, be aware that, what we have here, a single move command eg. "G1 X300 Y300 F1000" can only be interrupted by a M112 !

Pls. stay away from changing default firmware settings, such as timeouts, e-steps, etc., this is in users/customers responsibilities, and can cause unwanted side effects, and angry users. To my experience this not required for bed calibration, so lets focus on core functionality of the plug!

[bcsteeve]

@nean-and-i "I've installed one and it works fine"... consider sharing?

And yes, M112 has several times necessitated a full reboot of Octopi before I can get it to reconnect. Perhaps "in no case [it SHOULD] cause rasbian [...]". And I didn't say Raspbian froze. I said I had to reboot it before it would connect. I tried the connect button. I tried the restart Octoprint button. It wasn't until I rebooted that I could reconnect with the printer. Why? I have no idea. But even if that's something wrong with my particular system... it still necessitates physically powering down the printer, right? That is a bit harsh when we're just wanting to stop runaway motors.

Core functionality of the plug-in (yes, it is plug-in, not plug) is to assist with leveling by moving the steppers to specific locations. It needs to do that reliably. That's all.

[bcsteeve]

I just tried it now (and know that last night I reinstalled Octopi from the beginning).

I started a job and it was in the middle of heating. I entered M112 and it shut down. I tried "connect" but of course it won't work because the printer itself says it has to be reset. I shut down the printer, waited some 30s. I turned it back on. I click "connect"... nothing. I wait 2 minutes and click connect. Nothing. I do "restart Octoprint" and have to wait some 8 minutes for the interface to come back. I click connect... NOTHING. I have to reboot Pi before I can reconnect. Why? Beats me... but it often happens with M112, which is why I hoped it could be avoided.

[bcsteeve]

@electr0sheep I don't know if you figured this out yourself, but I've confirmed the documentation for M18, M84 is poorly worded. It does NOT "immediately" disable the steppers and therefore can't be used as an emergency stop for them.

I personally think I'm going to try enabling the EMERGENCY_PARSER and then use M410 - Quickstop. This seems like a better alternative to M112. I'm not sure why EMERGENCY_PARSER isn't enabled by default. Even the documentation for M112 says that it should be fore more effective/reliable stops.

[nean-and-i]

@bcsteeve sounds like usb is not recognized, sometimes it helps just unplug and replug the usb, so the kernel reinitiates the usb port, after that you should be able to reconnect. Else you might need to debug it on linux level, like with dmesg and lsusb to see if usb is re-detected after the reset.

[electr0sheep]

Okay, so I'm still working on a fix, but interestingly enough, after some experimentation, the default OctoPrint controls suffer from this same issue. If you don't home the printer first, you can use the controls to go out-of-bounds as well. I had an idea to see if OctoPrint has some custom functions that do some out-of-bounds checking, but I guess not.

[electr0sheep]

For version 2.0.0, I added a warning message next to the controls. This doesn't resolve the issue, but hopefully works as a temporary solution. I also considered adding an M28 to each control, but this ruins the plugin for me. I anticipate that I won't have as much time to work on this plugin the next couple of days, and I wanted to get the plugin in as good a state as I could today.

So, I'm still working on this issue, but hopefully this will be a decent band-aid fix. I think @b-morgan is on to something with the start Gcode idea.

One of the things that sketches me out is that you can also use the default OctoPrint controls to move out-of-bounds, they just don't move the bed by 270mm at a time.

Also, I need to know what causes this issue. As far as I can tell, the only way to trigger this is by turning off the printer and then not homing it. I haven't been able to reproduce the "timeout" successfully.

[Havenwar]

I hope I'm not stepping on anyones foot here but I'm not sure I understand this detail.

I can confirm that I did not use the plugin before homing. The reason it was where it was (offset from center by the probe offsets) was because the last thing I did was home it.

@bcsteeve Did you really mean center here? Home is front left corner on the cr10, so if the last thing you did was home it then your printhead should have been at the front left corner, right? Did the head move away from the front left corner after homing, or is your home not the front left corner?

[bcsteeve]

I have safe homing enabled in the firmware with a fix mount z probe defined... so for me, homing is with the sensor at the middle. Due to offsets, that means the print head is at x195, y160.

[Havenwar]

Hey cool, I haven't heard of that before! Learn something new every day. I feel like that's the likely problem in this case though: your printhead is at x195, y160 when the plugin (as all cr10 related things) expects it at x0, y0.

[bcsteeve]

I don't think so. If I home and then center (it any other plugin button) it works fine. Center takes me from home to x150y150 as it should. It is after the "timeout" where the problem lies. However, you bring up a point. The stock firmware, perhaps, doesn't timeout. The CR-10 uses an old and modified version of Marlin. I use the current version. I recommend everyone so the same, as it prints much better... but yes, perhaps it introduces a feature that this plugin doesn't account for. I'm not sure.

[Havenwar]

Ah okay! Sorry for the confusion.

Good point though about the firmware, I guess most people are on stock or simply go through the leveling quickly enough that they don't hit this issue much. I'm planning to upgrade the firmware myself but I just feel I gotta get everything else working right first. :D

[bcsteeve]

And really, you should be taking everything I say with a grain of salt. I didn't really think about it before, but I guess I'm a bit of an edge-use case. I have auto-bed-leveling hardware and firmware, and most people that go that route would have no use for your plugin (afterall, the whole point of ABL is just that, right?). But I'm developing a new bed leveling system, so it is important for me to get a good baseline and your plugin helps with that.

Regardless, it shouldn't matter if I have stock (outdated Marlin) or "custom" (current Marlin) firmware because your plugin should work for any. Afterall, Creality could choose to update the firmware they ship with at any point.

I do strongly recommend updating your firmware, whether or not you use ABL. It just prints better.

[bcsteeve]

Incidentally... I hadn't been using this plugin for awhile. I just re-installed it today and I have to say... you've done a great job. The improvements you've made since the first release are really good.

I'd even say you can probably close this issue, as I think the warning is good enough and the issue is probably only relevant to those that have modified as I have. I've been using it with a stock CR-10 and haven't yet run into the issues I originally reported.

[electr0sheep]

I am marking this issue as will not fix. I have added warnings, and that should be sufficient. I don't see a way to fix this, especially considering the octoprint core will allow you to move out-of-bounds as well.