[3.4b3] Homing to negative Y doesn't work
-
@diamondback all looks valid.
out of curiosity could you try a split M208 command? i.e.M208 X-150 Y{global.minY} C0 Z0 S1 M208 X160 Y{global.maxY} C250 Z270I home with an 0,0 at the centre at the same way you do.
The only other thing I can think of is its not carrying over the global variable correctly.
If the above doesn't work, can you try removing the variable from your M208?
This should help pin down the error -
Good morning @diamondback
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC#reprapfirmware-340beta2
Where a GCode parameter accepts multiple values, you can no longer use a mixture of literals and expressions (which was previously supported in standalone mode only). However, the whole parameter can now be an array expression. For example, M92 E{var.e1}:400:{var.e3} will no longer work and must be replaced by M92 E{var.e1,400,var.e3}.In your case this is how it should be:
M208 X-150:160 Y{global.minY,global.maxY} C0:250 Z0:270 ; set axis minima & maximaCheck if you have any more
I don't know if this will be the solution for your problem.
Best regards
-
Thanks for the ideas, will test as soon as the current print (on 3.3) finishes
-
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
Thanks for the ideas, will test as soon as the current print (on 3.3) finishes
Just out of curiosity why are you using a global var in that way?
Those values are already part of the Object Model so if you set them using constants in config.g you can read them from the Object Model if you need to use the current values.
Thanks.
Frederick
-
@fcwilt I need to change these values at runtime (during mesh probing). I don't want to have to define the actual value in multiple places, so I just store it as a global.
I wasn't aware I can read this from the OM, that would open further possibilities of achieving the same goal. -
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
@fcwilt I need to change these values at runtime (during mesh probing). I don't want to have to define the actual value in multiple places, so I just store it as a global.
I wasn't aware I can read this from the OM, that would open further possibilities of achieving the same goal.If the normal M208 limits prevent you from probing the desired locations you can temporarily removing the restrictions set by those limits by using a pair of M564 commands, one to disable the limits before you probe, one to restore the limits after you probe.
As long as the locations you wish to probe are accessible temporarily disabling the limits will cause no problems.
Frederick
-
@fcwilt said in [3.4b3] Homing to negative Y doesn't work:
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
@fcwilt I need to change these values at runtime (during mesh probing). I don't want to have to define the actual value in multiple places, so I just store it as a global.
I wasn't aware I can read this from the OM, that would open further possibilities of achieving the same goal.If the normal M208 limits prevent you from probing the desired locations you can temporarily removing the restrictions set by those limits by using a pair of M564 commands, one to disable the limits before you probe, one to restore the limits after you probe.
As long as the locations you wish to probe are accessible temporarily disabling the limits will cause no problems.
Frederick
That didn't work for me when I originally set up this system. RRF will just report that it can't reach those points.
-
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
That didn't work for me when I originally set up this system. RRF will just report that it can't reach those points.
Well it does work because it is the approach I use.
Frederick
-
@fcwilt said in [3.4b3] Homing to negative Y doesn't work:
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
That didn't work for me when I originally set up this system. RRF will just report that it can't reach those points.
Well it does work because it is the approach I use.
Frederick
Maybe something changed then, because that was the first thing I tried back then:
https://forum.duet3d.com/topic/23474/probing-outside-allowed-area -
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
@fcwilt said in [3.4b3] Homing to negative Y doesn't work:
@diamondback said in [3.4b3] Homing to negative Y doesn't work:
That didn't work for me when I originally set up this system. RRF will just report that it can't reach those points.
Well it does work because it is the approach I use.
Frederick
Maybe something changed then, because that was the first thing I tried back then:
https://forum.duet3d.com/topic/23474/probing-outside-allowed-areaPerhaps something has changed. I will have to run a test.
Thanks for the feedback.
Frederick
-
@aitor said in [3.4b3] Homing to negative Y doesn't work:
Good morning @diamondback
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC#reprapfirmware-340beta2
Where a GCode parameter accepts multiple values, you can no longer use a mixture of literals and expressions (which was previously supported in standalone mode only). However, the whole parameter can now be an array expression. For example, M92 E{var.e1}:400:{var.e3} will no longer work and must be replaced by M92 E{var.e1,400,var.e3}.In your case this is how it should be:
M208 X-150:160 Y{global.minY,global.maxY} C0:250 Z0:270 ; set axis minima & maximaCheck if you have any more
I don't know if this will be the solution for your problem.
Best regards
Thanks again for this hint, it was indeed the issue. I've read about that specific change in the changelog, but since I wasn't using a mix of variables and literals, I didn't pay any attention.
@dc42 maybe worth mentioning that my use case is also changed now (ie using multiple variables)
