Re: BeagleG homing
31 views
Skip to first unread message
Henner Zeller
Jan 4, 2020, 1:05:47 PM1/4/20
to Benjamin Menkuec, Leonardo Romor, beagleg-dev
[ + adding the mailing list ]
Hi Benjamin,
> we are using your beagleg software for our magnet field measuring robot
> (https://www.opensourceimaging.org/project/cosi-measure/).
Nice!
> The original
> version of COSI Measure was using BeBoPro, but this hardware is not
> available anymore and not open source. Therefore we were looking for
> some alternatives and found beagleg. So far everything is working fine.
> However, we noticed that beagleg only supports homing via the G28
> command. The G28 command only supports homing to min or max position.
Indeed, G28 moves to the 'machine origin'
(https://github.com/hzeller/beagleg/blob/master/G-code.md#machine-origin),
wherever that is defined min/max for that particular axis.
(Ideally, this would be separated out as a separated machine homing
command, which hits the switches, and the 'logical' homing G28 which
goes to machine origin after the machine has been started).
> We would like to do homing to min AND max (similar to the G161 and G162
> commands). Is there a way in beagleg to do that?
Not right now, but it can be added easily if needed and I understand
what it can be used for.
What do you use it for ? Is it to determine that the machine
end-switches are working, or would you like to use the resulting
relative coordinate where the switch hits in expressions within G-Code
later ?
The description in
https://reprap.org/wiki/G-code#G161:_Home_axes_to_minimum is not very
clear in which cases this would be used: if we hit the other end of
the machine, we can't really determine the origin from that, as that
switch might be a little bit off: there should only be one 'source of
truth'. So it is not quite clear to me in which context that can be
used.
Or is it that you would like to have the switches in one place
('machine origin'), but then the G-Code origin in some other place ?
For that, I suggest to establish a work coordinate system - you can
tell BeagleG that the (0, 0, 0) origin is at a different place than
the physical machine origin:
https://github.com/hzeller/beagleg/blob/master/G-code.md#work-coordinate-systems
.
From then on, G-Code coordinates are relative to that coordinate
system (e.g. G54). There are more coordinate systems to configure
actually; the BeagleG G-Code documentation is a bit sparse, but there
is great online documentation to be found on the web for general
CNC-ing. The configured coordinate system is also stored in the
parameter file later, so it will be at the same place when BeagleG
comes up again.
This is standard CNC machine functionality, so provided this is what
you'd like to achieve, this would be a preferred way to establish a
different coordinate system than the 'physical' one (this is often not
a feature of simple 3D printer machine controls, but it is certainly
supported by BeagleG).
Grüße aus San Francisco,
Henner.
>
> best regards,
> Benjamin
>
> --
> Prof. Dr. Benjamin Menkuec
> University of Applied Science and Arts Dortmund
> Laboratory for Electromagnetic Imaging
> Sonnenstr. 96
> 44139 Dortmund
> Germany
> DJ4LF 73
>
Hi Benjamin,
> we are using your beagleg software for our magnet field measuring robot
> (https://www.opensourceimaging.org/project/cosi-measure/).
Nice!
> The original
> version of COSI Measure was using BeBoPro, but this hardware is not
> available anymore and not open source. Therefore we were looking for
> some alternatives and found beagleg. So far everything is working fine.
> However, we noticed that beagleg only supports homing via the G28
> command. The G28 command only supports homing to min or max position.
Indeed, G28 moves to the 'machine origin'
(https://github.com/hzeller/beagleg/blob/master/G-code.md#machine-origin),
wherever that is defined min/max for that particular axis.
(Ideally, this would be separated out as a separated machine homing
command, which hits the switches, and the 'logical' homing G28 which
goes to machine origin after the machine has been started).
> We would like to do homing to min AND max (similar to the G161 and G162
> commands). Is there a way in beagleg to do that?
Not right now, but it can be added easily if needed and I understand
what it can be used for.
What do you use it for ? Is it to determine that the machine
end-switches are working, or would you like to use the resulting
relative coordinate where the switch hits in expressions within G-Code
later ?
The description in
https://reprap.org/wiki/G-code#G161:_Home_axes_to_minimum is not very
clear in which cases this would be used: if we hit the other end of
the machine, we can't really determine the origin from that, as that
switch might be a little bit off: there should only be one 'source of
truth'. So it is not quite clear to me in which context that can be
used.
Or is it that you would like to have the switches in one place
('machine origin'), but then the G-Code origin in some other place ?
For that, I suggest to establish a work coordinate system - you can
tell BeagleG that the (0, 0, 0) origin is at a different place than
the physical machine origin:
https://github.com/hzeller/beagleg/blob/master/G-code.md#work-coordinate-systems
.
From then on, G-Code coordinates are relative to that coordinate
system (e.g. G54). There are more coordinate systems to configure
actually; the BeagleG G-Code documentation is a bit sparse, but there
is great online documentation to be found on the web for general
CNC-ing. The configured coordinate system is also stored in the
parameter file later, so it will be at the same place when BeagleG
comes up again.
This is standard CNC machine functionality, so provided this is what
you'd like to achieve, this would be a preferred way to establish a
different coordinate system than the 'physical' one (this is often not
a feature of simple 3D printer machine controls, but it is certainly
supported by BeagleG).
Grüße aus San Francisco,
Henner.
>
> best regards,
> Benjamin
>
> --
> Prof. Dr. Benjamin Menkuec
> University of Applied Science and Arts Dortmund
> Laboratory for Electromagnetic Imaging
> Sonnenstr. 96
> 44139 Dortmund
> Germany
> DJ4LF 73
>
Henner Zeller
Jan 5, 2020, 2:58:55 PM1/5/20
to Benjamin Menkuec, Leonardo Romor, beagleg-dev, lukas....@ptb.de
On Sun, 5 Jan 2020 at 03:25, Benjamin Menkuec
<benjamin...@fh-dortmund.de> wrote:
>
> Hi Henner,
>
> thanks for the detailed answer.
>
> I think the purpose of the min and max homing is to prevent the machine
> to run over the physical limit even if the application software wants to
> do it.
So BeagleG automatically takes care of never moving outside the
bounds. As long as range-check
is configured in the configuration file and a range is defined in the
given axis, BeagleG will complain.
Example:
G1 X5000
// ERROR outside machine limit: Axis X = 5000.0 > 300.0mm. Ignoring move!
> I have added Lukas to this mail, he is the author of COSI Measure and
> also wants to use CRAMPS.
> @Lukas: Is there another reason why we want to do min and max homing for
> COSI Measure?
>
> Viele Grüße aus Dortmund,
> Benjamin
<benjamin...@fh-dortmund.de> wrote:
>
> Hi Henner,
>
> thanks for the detailed answer.
>
> I think the purpose of the min and max homing is to prevent the machine
> to run over the physical limit even if the application software wants to
> do it.
So BeagleG automatically takes care of never moving outside the
bounds. As long as range-check
is configured in the configuration file and a range is defined in the
given axis, BeagleG will complain.
Example:
G1 X5000
// ERROR outside machine limit: Axis X = 5000.0 > 300.0mm. Ignoring move!
> I have added Lukas to this mail, he is the author of COSI Measure and
> also wants to use CRAMPS.
> @Lukas: Is there another reason why we want to do min and max homing for
> COSI Measure?
>
> Viele Grüße aus Dortmund,
> Benjamin
Henner Zeller
Jan 8, 2020, 12:49:09 AM1/8/20
to lukas....@ptb.de, Benjamin Menkuec, Leonardo Romor, beagleg-dev
On Mon, 6 Jan 2020 at 17:41, <lukas....@ptb.de> wrote:
Hi and happy new year to all of you!thanks for the info around beagleG and thanks Benjamin for including me here. You are completely right, it is sufficient to have a single homing reference (either min or max) if the range check is set and complains accordingly. Nevertheless testing if the end switches work is definetly useful and needed since we are dealing with a bigger machine and measurement setups that might include sensitive equipment (both the sensors and the measured object).
You always can add more limit switches. The other limit switches are not used for homing, but they stop the machine if they are reached. So even if you have a home position at min, you can also add a limit switch on max and wire that up to a separate channel - then the machine will stop if that is tripped.
If you don't have enough channels for three extra limit switches, you can wire them up all together, so that if _any_ of them fires, the machine stops. See the documentation in the sample config.
You can query the endstop status with M119
Also, even though the limit switches are positioned at the axis in the orginial configuration, they could be also positioned within the measured object to prevent damage. I think what I had in mind originally for the min/max homing was to place limit switches directly at the sensor holder (or the CNC mill/drill to picture it with the CNC equivalent) of COSI Measure. While for CNC applications that would not make much sense, for automated measurements the advantage would be that I could place my sensor probe somewhere manually inside the object to be measured (e.g. an RF coil or an MR magnet) and then determine my measured space via homing.
So that is not a task for limit switches, but for 'probing'.
There is a concept of probing in BeagleG, but currently it only supports Z-probing (G30). This is for a typical use-case for CNC machines, but we could think of extending this further.
Also, another way would be to make the limit switch value accessible via a variable (The #-parameters as described in the GCode-doc), then you can write your own probing-routine with GCode itself.
Then I could calculate my pathfile automatically based on the min/max values (setting sampling resolution etc.) and the determined area/volume. This would be advantageous for reproducibility/speed since I would not need to make sure that my RF coil/magnet is in the exact same position with respect to the reference frame/ground truth based on the limit switches on each axis.
Yes, this sounds like something you want to write directly in GCode and having access to some value in a variable. But this is entirely different from end-stops; end-stops are a safety mechanism that makes sure the machine never runs out of bounds. Your application is probing.
But that would be sth optional and nice to have in the future. The limit switch test would be sth that I see more mandatory in order to have a reliable hardware protection (some steps might get lost for whatever reason) on top of software since it is related to safety. Hope that makes sense :)
Yes, the limit switch feature for the non-homing end is available, you just need to tell in the configuration file to which channel they are connected.
-h
Best wishes,Lukas----------------------------------
Dr. Lukas Winter
Physikalisch-Technische Bundesanstalt (PTB)
Department 8.1 - Biomedical Magnetic Resonance
Abbestr. 2 - 12, D-10587 Berlin, Germany
e-mail: lukas....@ptb.de
phone: (+49) 30-3481-7573
https://www.ptb.de/cms/en/ptb/fachabteilungen/abt8/fb-81.html-----"Benjamin Menkuec" <benjamin...@fh-dortmund.de> schrieb: -----An: "Henner Zeller" <h.ze...@acm.org>
Von: "Benjamin Menkuec" <benjamin...@fh-dortmund.de>
Datum: 06.01.2020 10:22
Kopie: "Leonardo Romor" <leonard...@gmail.com>, "beagleg-dev" <beagl...@googlegroups.com>, lukas....@ptb.de
Betreff: Re: BeagleG homingthat sounds reasonable. I think we dont need min and max homing then.
Lets see what Lukas says.
Henner Zeller
Jan 8, 2020, 12:51:06 AM1/8/20
to Benjamin Menkuec, lukas....@ptb.de, Leonardo Romor, beagleg-dev
On Tue, 7 Jan 2020 at 12:35, Benjamin Menkuec <benjamin...@fh-dortmund.de> wrote:
Hi,
I think placing the limit switch right at the magnet sensor could influence the measurement quite severely, but I can understand the advantage of some of the scenarios that you mention.
As of now, COSI measure does the homing only once at the beginning of a measurement. So if the step motor loses some steps it would not be detected. Or does the mendel software (BeBoPro) check the limit switches all the time, even if it is not doing a homing?
I think it would not be difficult to add a permanent limit switch monitoring functionality into BeagleG. What do you think Henner?
Yep, that feature already exists. Just add more limit switches in the configuration and it will stop the machine when it.
-h
regards,
Benjamin
Hi and happy new year to all of you!
thanks for the info around beagleG and thanks Benjamin for including me here. You are completely right, it is sufficient to have a single homing reference (either min or max) if the range check is set and complains accordingly. Nevertheless testing if the end switches work is definetly useful and needed since we are dealing with a bigger machine and measurement setups that might include sensitive equipment (both the sensors and the measured object). Also, even though the limit switches are positioned at the axis in the orginial configuration, they could be also positioned within the measured object to prevent damage. I think what I had in mind originally for the min/max homing was to place limit switches directly at the sensor holder (or the CNC mill/drill to picture it with the CNC equivalent) of COSI Measure. While for CNC applications that would not make much sense, for automated measurements the advantage would be that I could place my sensor probe somewhere manually inside the object to be measured (e.g. an RF coil or an MR magnet) and then determine my measured space via homing. Then I could calculate my pathfile automatically based on the min/max values (setting sampling resolution etc.) and the determined area/volume. This would be advantageous for reproducibility/speed since I would not need to make sure that my RF coil/magnet is in the exact same position with respect to the reference frame/ground truth based on the limit switches on each axis. But that would be sth optional and nice to have in the future. The limit switch test would be sth that I see more mandatory in order to have a reliable hardware protection (some steps might get lost for whatever reason) on top of software since it is related to safety. Hope that makes sense :)
Best wishes,Lukas----------------------------------
Dr. Lukas Winter
Physikalisch-Technische Bundesanstalt (PTB)
Department 8.1 - Biomedical Magnetic Resonance
Abbestr. 2 - 12, D-10587 Berlin, Germany
e-mail: lukas....@ptb.de
phone: (+49) 30-3481-7573
https://www.ptb.de/cms/en/ptb/fachabteilungen/abt8/fb-81.html
-----"Benjamin Menkuec" <benjamin...@fh-dortmund.de> schrieb: -----
An: "Henner Zeller" <h.ze...@acm.org>
Von: "Benjamin Menkuec" <benjamin...@fh-dortmund.de>
Datum: 06.01.2020 10:22
Kopie: "Leonardo Romor" <leonard...@gmail.com>, "beagleg-dev" <beagl...@googlegroups.com>, lukas....@ptb.de
Betreff: Re: BeagleG homing
that sounds reasonable. I think we dont need min and max homing then.
Lets see what Lukas says.
Am 05.01.2020 um 20:58 schrieb Henner Zeller:
Reply all
Reply to author
Forward
0 new messages