Obsolete use of S parameter on G1 command...

Stephenbright

@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 !

Phaedrux

@Stephenbright said in Obsolete use of S parameter on G1 command...:

; Provide Z height clearance
G1 Z10 F750 H1

Is 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.

Stephenbright

@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...

A Former User

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.

Stephenbright

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?

Phaedrux

You should be able to just upload the older firmware and it will detect and install it.

DocTrucker

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.

dc42

@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.

dc42

@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.

DocTrucker

@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.