Obsolete use of S parameter on G1 command...
-
; homez.g
; called to home the Z axis
;; ============= PRE-HOMING =====================
; Ignore Machine boundaries
M564 H0 S0; Turn off bed leveling during homing
G29 S2 ; Does the same as M561!
G29 S2 ; Do it twice because once just isn't enough; Switch to Origin Tool
T0; Relative positioning
G91; Provide Z height clearance
G1 Z10 F750 H1; ============ HOME Z ==============
; Rapid Z until limit switch triggers
G0 Z450 F1500 H1; Back off to release limit switch
G0 Z-15 F1500; Slow advance to trigger limit switch
G0 Z20 F120 H1M98 Pmachine_zendstop.g ; Set Z Endstop height
M98 Pmachine_zprobe.g ; Set Z Probe distance; ============ Post-Homing ==============
; Revert to absolute coordinates
G90; Re-enable mesh leveling
G29 S1M98 Pmachine_axisdimension.g ; Set Axes Limits
; Stop movement across limits, enable boundaries, homing requirement
M564 H1 S1 -
; homey.g
; called to home the Y axis
;; Same as homex.g because of coreXY
; Front left is (0,0)M98 Phomex.g
-
; homeall.g
; called to home all axes
;; Front left corner is (0,0)
; ============ HOME X & HOME Y ==============
M98 Phomex.g ; Run the homex.g file, also homes the Y axis
; ============ HOME Z ==============
M98 Phomez.g ; Run the homez.g file
-
@dc42 Stephenbright 20 Jan 2020, 20:53
Part one: The obsolete S and H parameters warning is now gone so I think I have that fixed...
Right now I had manually put the core XY and the bed in to the home positioning and then restarted the machine. I am NOW getting movement, however its grinding all over the place as I'm sure nothing is aligned and needs to be set up, however how do I do that when its freaking out like that??
Below is the config file. Do you need ALL of the homing files to look at? And is it okay to post it like the config file below?
Thank you BOTH for all of your help !
-
@Stephenbright said in Obsolete use of S parameter on G1 command...:
; Provide Z height clearance
G1 Z10 F750 H1Is the intention here to seek an endstop, or to move the axis before it's been homed? H1 would seek the endstop, H2 would allow movement before homing. Failing to reach the endstop could cause you issues.
-
@Phaedrux I think I need to set the end stops first in the homed position. Right now it seems confused like its trying to home and move the axis in a different direction at the same time...
-
I think I initially did the same thing, but yes, if you remove the H1 it should still not crash as long Z is homed before running homex as the soft limit would stop the axis at the limits defined by M208 (280?)
And if z is not homed before running homex it should fail saying insufficient axis homed when you try to move z.
-
I'm thinking I may go back to the last 2.06 firmware. Is that straight forward? Can I just install the older firmware or do I have to erase the board and start over?
-
You should be able to just upload the older firmware and it will detect and install it.
-
Is the H/S swap also in the later bugfix versions of RepRapFirmware 1?
Should the following line in the wiki be tweaked from:
Rn Return to the coordinates stored in restore point #n (see G60). Any X, Y, Z and other axis parameters in the command are used as offsets from the stored position. Axes not mentioned are not moved, so use offset 0 for axes you want to restore to the stored value. For example, G1 X0 Y0 Z2 will move to 2mm above the position stored in the restore point.
...to:
Rn Return to the coordinates stored in restore point #n (see G60). Any X, Y, Z and other axis parameters in the command are used as offsets from the stored position. Axes not mentioned are not moved, so use offset 0 for axes you want to restore to the stored value. For example, G1 R0 X0 Y0 Z2 will move to 2mm above the position stored in the restore point.
The use of R0 is also not covered in the usage summary.
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
@DocTrucker said in Obsolete use of S parameter on G1 command...:
Is the H/S swap also in the later bugfix versions of RepRapFirmware 1?
Yes, recent versions of RRF 2.x (or 1.x for Duet 06/085) support both S and H. The warning if you use S for this purpose is only in RRF3.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@DocTrucker said in Obsolete use of S parameter on G1 command...:
Should the following line in the wiki be tweaked from:
Rn Return to the coordinates stored in restore point #n (see G60). Any X, Y, Z and other axis parameters in the command are used as offsets from the stored position. Axes not mentioned are not moved, so use offset 0 for axes you want to restore to the stored value. For example, G1 X0 Y0 Z2 will move to 2mm above the position stored in the restore point.
...to:
Rn Return to the coordinates stored in restore point #n (see G60). Any X, Y, Z and other axis parameters in the command are used as offsets from the stored position. Axes not mentioned are not moved, so use offset 0 for axes you want to restore to the stored value. For example, G1 R0 X0 Y0 Z2 will move to 2mm above the position stored in the restore point.
Yes. I've made that change.
-
@dc42 Thanks. I've got to get back to getting the Cortex dev board running with RepRapFirmware & RADDS so thought I may as well use the H on all if it causes no harm.
