Long time no see!
Recently, I started using my LR3 again and decided to investigate the slack on the Z axis. Surprisingly, the slack is coming from the motors. When I manually lift the gantry, the Y motor shafts move by 0.5 to 1 mm and stay in that position until I push the gantry back down. This is a bit disappointing because it means I’ll either have to replace the motors or come up with a mechanism to stop the leadscrews from moving up and down…
I think there was something about stretching the couplers a bit when tightening the grub screws so that they don’t act as a spring but pull the leadscrew and the motor together.
It is not related to the coupler, the shafts are actually moving inside the motors when enough force is applied. Besides the slack issue, I love those motors - they can handle high current and never get hot. I might decide to just live with the slack… not sure yet.
Not a big problem for my surfboards, and when I mill plywood, I usually cut all the way through…
That should not be a huge deal as the weight of the gantry should push it down normally. Only way it would express itself is if you over drive and force the router to climb out of the cut.
Yes, that’s correct. I realized this after writing the post. During the final passes on the surfboards, the machine is only removing 1mm of foam, which shouldn’t lift the weight of the gantry. So there is some slack on the Z axis which I haven’t been able to find yet.
Are you certain the motor shafts are moving, or could it be the pulleys are shifting on the shafts? Grub/set screws loosening over time is a classic recurring problem.
How do I save the gcode on the card called “park” that are my start coordinates. I have learned to alter my gcode and do most of what you say, but I have been writing down my start coordinates because of any problems that might happen. I end my program with
G91
Z15.0
M00
I guess I would add something ,and is it something standard with gcode
You can use a text editor like notepad to make your file, then save it with the extension .gcode instead of .txt.
Yes, the shafts are moving, but this is probably not what’s causing the visible Z slack in my cuts. The weight of the gantry should be enough to pull it down.
Funny, I never came up with the idea of saving things like “park” in the card… Instead I made custom menu items in Marlin, such as “touchplate”, “Reset XYZ”, “Reset Z”, etc. Saving .gcode files would have been so much easier.
I know how to write gcode files, but where do I put the files and can they be called in another gcode file,
is it the sd card that is always stays in the SKR PRO main board ?
Does it just go on that card or in a config file on that card?
Someone else can confirm but I don’t believe you can can call other files from within a gcode file.
If you’re using an SKR Pro 1.2 you place the gcode files on the root of an SDCard and slot it into the LCD screen.
I meant were the shafts spinning inside the pulleys.
Ok, so I guess I’m not asking the question right. But after doing some research there is a way to do what I want with subroutines, sort of. A better way to ask would have been comparing it to coding in C where I can create my own libraries, then #Include them. That’s what I thought Ryan was doing with the “Park” gcode he saved to his card.I just misunderstood what he was saying. As of right now what I found is there is no way to call other gcode from within a gcode file.
Edit I guess they are called macros
You can have macros but almost anything you should want to do is best to add to your CAM as a start stop or toolchange subroutine.
You question is just sort of vague, exactly what are you trying to do.
As an example our toolchange CAM codes are very involved and include pauses and button presses. No macro’s needed.
What complicates this is that gcode is not as precise a standard as something like a strict programming language, where there’s a hard and fast set of included features and capabilities. There are a lot of gcode “dialects” with varying feature sets or optional parameters.
This is why lots of CAM packages include a post-processor feature. The CAM package will generate “generic” gcode (to an arbitrary standard selected by the package developer) and then the post-processor can massage this to be compliant with the syntax of a selected firmware/variant.
(edited to remove specific reference to C language)
Ha it gets even deeper, Fluid has enabled all sorts of programming features in the Gcode , last week, so technically you can run things from within a gcode file now, but it is best to stay way from this as I do not think that is the goal here.
I’m just learning and want to learn how the whole system works, mechanical, electrical and software. The reason I was interested in the “park” was the reasons you said in the comment that I replied to. you want it to go back to the start position in case there was a problem. So at the end of the gcode I put G00 x0.0 y0.0 z0.0, then I raise it up on the Z, but when the program stops the Gantry falls on the Z axis. Which is what the OP said his problem was and you commented about the Park gcode that you created. So I was wondering how you implemented that Park before the gantry collapsed. What I didn’t realize is that you parked it at ZMIN, so I will add that to my presets, while learning more about macros etc.
Also thanks for responding
Thanks, that helps a lot, I understand the basic structure better. But when we program in C we use different compilers for different operating systems to make and executable program, which really isn’t much different than what you said here.
But anyway I’m sure there are their differences. And I got a better grasp of whats going on.
As a C/C++ programmer, my heckles went up when I saw Tom’s comment about dialects. Because an absurd amount of C is undefined.
But gcode is still much more flexible and there is a lot of “proprietary” stuff that is in each firmware. The standard is pretty clear, but open source projects don’t have to closely follow the (very old) standard. It also defines nothing for the response from the firmware when sending gcode over a duplex serial connection. So those responses are ad hoc.