Sorry to be the guy with all the new questions. But I have my build up and running. I seem to have left side drift problem. As you can see in the picture the left side of the art is pulling to the right. The right side is straight as an arrow.
The frame under the table is square (or really close), in any case it is not that far off or the right side would be off as well.
It must have something to do with the belt?
I have the mm per step set at 80 on X and Y, using a SRK Pro controller (TMC2209) and NEMA 17 steppers. I homed Y and then X before starting.
Ok, solved it - I heard it skipping/snagging - bumped the current from 100ma to 300ma and it now moves smoothly in all directions. Adding the sand must have caused the need for more current to pull the ball.
I used to have problems like that with my first one. Turning up the current masked the problem, until it started eating cores.
On my old table, thatās the sort of thing that would happen closer to the Y max side where it would start to skip steps. In my case, I caught it trying to pinch the belt between the rail and the roller bearings on the side. I made āskatesā to replace the spacers between the bearings to keep the belt away from the bearings, which helped quite a bit, but didnāt stop it entirely.
This is the V2 assembly and parts.
The sand is pretty deep so that was likely it. Without the sand I ran a couple test patterns and all was good at 100ma.
Now my only issue is I get a āError Unknown command M140ā at the end of each print, and there is no M140 command in the Gcode created by Sandify?
My V2 builds are dead solid on 150mA, but the baking soda in mine is not very deep.
What are you using to send the code to the table? Iāll bet something is sending code at the end of the āprintā to do things like turn off heaters. Some Gcode senders append gcode to the end of print jobs in case you forget to add it to the slicer.
Edit: M140 ā set bed temperature, Almost certain thatās your gcode sender.
No M140 in sandify. Dan is right, it is repetier host or pronterface or whatever making sure the heated bed is off at the end. It wonāt hurt anything if you canāt find out how to turn it off.
Thanks Guys and please work with me as I catch up on terms
What you guys are saying makes sense, it is not in the gcode file I have verified that as stated before it must be in the setting of the SRK.
You asked what I am using to send code to the table? I am using the display SD slot that is connected to the SRK Pro. I guess that is what you would call me gcode sender?
I have briefly looked around in the SRK setting and donāt see anything about ābed tempā but I will keep looking.
This is a great project and I plan to go bigger now - Thanks to all of you as I am sure I will have more questions. I am an IT guy, so most of this I can figure out but it is nice to have people to bounce ideaās off. I also build build golf cart and GEM car AC motor kits and use Tesla batteries to power them if anyone needs a 60mph (100 mile range) golf cart - happy to help
So yeah. In this case, Iād say that it looks like the firmware on your touchscreen is sending code to turn off your (nonexistent) heated bed when the file is done. This is a little trickier to get to, but thatās where Iād be looking.
the SRK does think there is a bed attached, but the temp is set to zero. I am using the ZenXY SRK firmware from this site (which is untested) so there is one item that could be looked at some day. Turning off the BED feature.
I have installed and played with VCODE a little, just not up to speed yet. I have not been able to get all the plug-in installed needed to compile.
It is the screen firmware, not the skr itself. If it is able to be turned off, then it is in the config.ini file that gets put on the sd card when you flash it. Otherwise, it will be some software work to get it changed in the screen firmware.
