What happens if the screws lose a step or many steps?
How are the two screws homed?
How are the screws typically synchronized (espeically at
startup) to be homed?
What is the consequence of being out of sync? (Do they rip
themselves apart, bind, jam, or otherwise get stuck?)
What does a typical electrical wiring diagram look like, and
how does it behave? (Limit switches? Can open-loop steppers
be used? Home switches?) I assume you can't just connect
the outputs of one PC pulse generator to 2 drives...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The mechanical connection is not only the hobby solution
but also the professional one. The full "electric" axis
connection is only possible if a)one axis is allowed to slip
if the torque produced on the gantry (by mis-alignment)
exceeds a certain level, or b) an absolute measurement
system for feedback is used. The slip in option a can be
mechanical or electrical in the servo drive. Steppers are
pretty much excluded here.
In more general terms it is only possible to build a
succesfull gantry system if one designs both the mechanical
construction and the drive system in one concept.
Retrofitting is not so easy.
In professional sulutions I only see solutions in the drive
electronics and not in the higher level control like the
CNC. The conclusion is that this request is not very
suitable for EMC in my opinion. If you supply some data
about your configuration I can help with some suggestions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a sidenote I am doing this with my config by slaving two
axis, see dallur-thc sample config in HEAD. It can be done
without problems, the only tricky bit is the homing which at
the moment has to be done manually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A "gantry kinematics" module is available here: http://axis.unpy.net/01162326817
This kinematics simply makes multiple copies of the same
axis value on multiple joints. This allows the two motors
on the gantry axis to have their own home and limit
switches, as well as their own motor offsets. In the GUI,
the joints can be jogged independently, so if they have
become misaligned but are still movable under motor power,
they can be moved into "good enough" alignment by the
operator before performing the homing operation. (however,
there are problems with having more joints than axes -- it
may be necessary to define a dummy "A" axis for a 3-axis
XXYZ or XYYZ machine, particularly to get access to the 4th
joint in the GUIs)
In emc2.1, there is a "homing sequence". When two joints
are given the same homing sequence number, they will begin
the homing sequence at the same time--If the joints have the
same velocity and acceleration settings, they will move in
unison. However, subsequent steps of the homing sequence
are not performed in unison, so for instance in the second
step of homing if one joint takes longer to clear the home
switch than the other, alignment will be lost. I think that
some simple modifications of the homing sequence may fix
this. I assume that the homing type being used is the
second type (4 moves) or maybe the fourth type (4 moves, to
index pulse), and that the home switch locations for the
first and third moves are dependable enough.
The first move is the same as now. The beginning of the
second move is delayed until both of the joints have reached
the home switch. If the joints were already in a position
that allows them to move, they will move together and stay
in the same relative alignment +- following error during
this time, but at the end of the move alignment will be
improved because they each stopped on reaching the joint
home switch.
The second move continues until both of the joints have left
the home switch. As before, they will stay in the same
relative alignment +- following error, and stop at the same
time.
Like the first move, the third move ends when each joint
reaches its switch, and the fourth step begins when both
have reached their switches.
The fourth move is exactly as now.
If you are interested in gantry systems, please comment on
this proposal. It may be possible to implement these homing
features in time for EMC version 2.1, but that depends on
the reaction from those familiar with such systems. I'd
prefer to do such discussions on the emc-developers list (or
on the developers channel) but followups to this bug are
fine too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this still needs some minimal amount of documentation. users shouldnt have to dig around in the sample config files to understand how the module is supposed to work. also, it's not clear to me whether in 2.2.x one should use A as the twin axis or something else. has homing been tested on a real machine yet? what is sim-xyyz.hal for?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1003939
using one servo or stepper for each screw.
Logged In: YES
user_id=866695
I'm curious about some details of this concept;
What happens if the screws lose a step or many steps?
How are the two screws homed?
How are the screws typically synchronized (espeically at
startup) to be homed?
What is the consequence of being out of sync? (Do they rip
themselves apart, bind, jam, or otherwise get stuck?)
What does a typical electrical wiring diagram look like, and
how does it behave? (Limit switches? Can open-loop steppers
be used? Home switches?) I assume you can't just connect
the outputs of one PC pulse generator to 2 drives...
Logged In: YES
user_id=1211556
The mechanical connection is not only the hobby solution
but also the professional one. The full "electric" axis
connection is only possible if a)one axis is allowed to slip
if the torque produced on the gantry (by mis-alignment)
exceeds a certain level, or b) an absolute measurement
system for feedback is used. The slip in option a can be
mechanical or electrical in the servo drive. Steppers are
pretty much excluded here.
In more general terms it is only possible to build a
succesfull gantry system if one designs both the mechanical
construction and the drive system in one concept.
Retrofitting is not so easy.
In professional sulutions I only see solutions in the drive
electronics and not in the higher level control like the
CNC. The conclusion is that this request is not very
suitable for EMC in my opinion. If you supply some data
about your configuration I can help with some suggestions.
Logged In: YES
user_id=1378478
As a sidenote I am doing this with my config by slaving two
axis, see dallur-thc sample config in HEAD. It can be done
without problems, the only tricky bit is the homing which at
the moment has to be done manually.
Logged In: YES
user_id=2772
A "gantry kinematics" module is available here:
http://axis.unpy.net/01162326817
This kinematics simply makes multiple copies of the same
axis value on multiple joints. This allows the two motors
on the gantry axis to have their own home and limit
switches, as well as their own motor offsets. In the GUI,
the joints can be jogged independently, so if they have
become misaligned but are still movable under motor power,
they can be moved into "good enough" alignment by the
operator before performing the homing operation. (however,
there are problems with having more joints than axes -- it
may be necessary to define a dummy "A" axis for a 3-axis
XXYZ or XYYZ machine, particularly to get access to the 4th
joint in the GUIs)
In emc2.1, there is a "homing sequence". When two joints
are given the same homing sequence number, they will begin
the homing sequence at the same time--If the joints have the
same velocity and acceleration settings, they will move in
unison. However, subsequent steps of the homing sequence
are not performed in unison, so for instance in the second
step of homing if one joint takes longer to clear the home
switch than the other, alignment will be lost. I think that
some simple modifications of the homing sequence may fix
this. I assume that the homing type being used is the
second type (4 moves) or maybe the fourth type (4 moves, to
index pulse), and that the home switch locations for the
first and third moves are dependable enough.
The first move is the same as now. The beginning of the
second move is delayed until both of the joints have reached
the home switch. If the joints were already in a position
that allows them to move, they will move together and stay
in the same relative alignment +- following error during
this time, but at the end of the move alignment will be
improved because they each stopped on reaching the joint
home switch.
The second move continues until both of the joints have left
the home switch. As before, they will stay in the same
relative alignment +- following error, and stop at the same
time.
Like the first move, the third move ends when each joint
reaches its switch, and the fourth step begins when both
have reached their switches.
The fourth move is exactly as now.
If you are interested in gantry systems, please comment on
this proposal. It may be possible to implement these homing
features in time for EMC version 2.1, but that depends on
the reaction from those familiar with such systems. I'd
prefer to do such discussions on the emc-developers list (or
on the developers channel) but followups to this bug are
fine too.
Logged In: YES
user_id=97658
Originator: NO
this still needs some minimal amount of documentation. users shouldnt have to dig around in the sample config files to understand how the module is supposed to work. also, it's not clear to me whether in 2.2.x one should use A as the twin axis or something else. has homing been tested on a real machine yet? what is sim-xyyz.hal for?
Logged In: YES
user_id=1343557
Originator: NO
Has this actually been tested? in reality, not just simulation?
Also, can this be combined with '5axiskins'?
Large 5 axes gantrys exist. 6 motors. XYZ BC U (and a virtual W, as in 5axiskins.