My machine is an MPCNC, running a full Rambo board with dual firmware installed by Ryan. I’m controlling it with Repetier Host.
So far it’s been flawless, it’s been drawing and cutting test patterns extremely well. It also homes perfectly. With one exception. I’m not sure what causes it, but if it has to home in the x-axis (I don’t think y is affected, but I’m at work now and I can’t actually remember checking it) and it travels somewhere around 150mm, it tells me there has been a fatal error on the printer side.
I disconnect and reconnect in Repetier, then it functions normally again. I can jog the machine out and back manually and so long as it’s not further out than around 150mm, it homes just fine.
Does my board just get nervous blindly running backwards for too long?
The default work area in the firmware is set to be smaller than what you have so the soft stops kill the system. You need to move the axes closer to the endstops when you home X and Y or redefine it in the firmware. Not quite sure of all the ramifications other than this is what is going on and it is expected.
Tried to find another topic on this, but will post this now.
Not trying to be pedantic, but I don’t think it is the soft stops. Those just keep you from going negative when you are moving around. The homing procedure also uses the bed size and errors when it travels longer than the bed length or width. If you have a 500mm bed, and it travels 510mm and doesn’t trigger and endstop, something is wrong. Or at least, that’s what Marlin thinks.
Well I did think that it was a bit weird that it would let me jog all around the table and would stop me at exactly 600mm, which is what I have my table set to in Repetier.
By the way…
I haven’t messed with arduinos and firmware in years, and I’ve been trying to read up on it.
How do I go about changing the settings on my particular board? Do I have to download an IDE for the board, get a copy of the firmware, change it, then reflash it?
I’m sure I read somewhere that there was a super easy way to change a setting like that.
Here’s Ryan’s write up about flashing the firmware. There’s a few more steps to get set up for a rambo vs a standard arduino but still pretty easy. https://www.v1engineering.com/marlin-firmware/
[EDIT] Wait no, the soft MAX stop is disabled, the soft MIN is enabled.
Yeah, I read over that one again for sure. As easy as it might appear to be, I’m not messing with resetting the firmware. Not unless this issue causes a large project to fail.
It works perfectly fine, and the last thing I need is to screw up the board. I really don’t want to go through the inevitable mess of “you didn’t download the library of esoteric functions? It should have been obvious you needed that to compile” etc.
What’s going on is Marlin will only search for your x and y endstops for a distance of X_BED_SIZE and Y_BED_SIZE respectively and if it doesn’t find it it will throw an error (or at least some factor of those variables, can’t remember). Those are defined just above the line I linked to in my last reply. The default is 200mm x 200mm and if you change those to your actual bed size it might fix your issue.
Or if you remember to send it back at least close to home before you’re done with a job so it never has to search very far for home you should be okay. I wouldn’t move it around literally by hand too much, I understand the feedback can damage the drivers. But maybe I’m wrong about that. You should still be able to jog it back before homing.
Everytime you disconnect and then reconnect repetier you’re closing and opening the serial port which is also sending a signal to the rambo to reboot. The rambo reboots and thinks it’s at 0,0 but will let you try homing again up to those distances.
Does it stop you if you use gcode commands, or just the manual buttons in repetier? RH has it’s own coordinate systems and limits.
The dual endstop firmware has the min soft endstops enabled by default, so you don’t crash into the endstops. The serial firmware has them off. This is separate from the issue during homing.
That has been converted to new docs, which has had a couple of updates:
Good idea. The firmware is pretty robust. The nice thing is, you really can’t brick an arduino by flashing it, and uploading only happens when you get the rest right. It is nice to have the ability to change it. The biggest risk is that Ryan has changed something or Marlin has changed something, and you can’t really get it back to how it was before.
Hi there!. I had exactly the same problem and to just leave it registered for somebody else, effectively by changing in the config.h file the BED_SIZE dimensions solves the problem:
// The size of the print bed #define X_BED_SIZE [X_SIZE] #define Y_BED_SIZE [Y_SIZE]
