Re: [Emc-users] synchronized axes.
Dave Engvall wrote: Think long arm sewing machine for quilting. The rotational axes are the needle and the bobbin. The tracking give constant stitch length. Two are X and Y and the other pair need to track (rotationally) with in a few degrees or better. Rotational speeds are from zero to 1800 rpm for one axis and either 1:1 or 2:1 for the other. The speed of rotation and the vectorized X and Y velocity need to track each other. you could do it a few different ways option 1) write a kinematics module and treat the needle/bobbin as rotational axes within emc option 2) use the hypot component to calculate distance traveled by x and y and feed that to your needle axis as a position command option 3) differentiate the output from above with ddt and feed it to the needle spindle as a velocity command. might be slightly less accurate than 2 but you won't need to do silly hacks to prevent counter overflow. option 4) synchronized motion like for lathe threading. this would be better if your needle is not very responsive compared to X and Y, but harder to write g-code for. (?) for example you couldn't do any arcs. however you could easily turn the spindle off and move around without stitching anything. options 23 would require using an M-code to disconnect the spindle from x-y motion. also the K parameter to G33 allows you to easily change the stitch length right in your g-code. There are two modes of motion. (1) is driven by an operator moving the carriage(s) in X and Y and (2) X and Y will be under G-code control. this should work fine using teleop mode under option 1 or just regular jogging under 234. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] synchronized axes.
Hi Ben, Thanks for the ideas, option 3 makes the most sense to me and I guess the best approach is to rig up a couple of servo motors and start experimenting. Dave On Aug 24, 2007, at 3:38 AM, ben lipkowitz wrote: Dave Engvall wrote: Think long arm sewing machine for quilting. The rotational axes are the needle and the bobbin. The tracking give constant stitch length. Two are X and Y and the other pair need to track (rotationally) with in a few degrees or better. Rotational speeds are from zero to 1800 rpm for one axis and either 1:1 or 2:1 for the other. The speed of rotation and the vectorized X and Y velocity need to track each other. you could do it a few different ways option 1) write a kinematics module and treat the needle/bobbin as rotational axes within emc option 2) use the hypot component to calculate distance traveled by x and y and feed that to your needle axis as a position command option 3) differentiate the output from above with ddt and feed it to the needle spindle as a velocity command. might be slightly less accurate than 2 but you won't need to do silly hacks to prevent counter overflow. option 4) synchronized motion like for lathe threading. this would be better if your needle is not very responsive compared to X and Y, but harder to write g-code for. (?) for example you couldn't do any arcs. however you could easily turn the spindle off and move around without stitching anything. options 23 would require using an M-code to disconnect the spindle from x-y motion. also the K parameter to G33 allows you to easily change the stitch length right in your g-code. There are two modes of motion. (1) is driven by an operator moving the carriage(s) in X and Y and (2) X and Y will be under G-code control. this should work fine using teleop mode under option 1 or just regular jogging under 234. -- --- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Max speed too fast
Cecil Thomas wrote: Thanks Stephen and Manfredi for the help. For those with similar setups this might be helpful: Here is my latest (I hesitate to say final) .ini data This is for a 1.7 GHz pentium 3 with a 400 MHz bus Hopefully it's final :) 2000 steps/rev servo, 5 rev/inch lead screw, 4:1 gear down motor to screw 40,000 input scale it seems to run at 48 ipm (.8 ips) with no problem and there are no RTErrors or Following Errors (yet) Base Period 12000 Servo Period 2,400,000 Traj Period 2,400,000 Trajectory Section default vel .2 (12 ipm) maxvel .9 (54 ipm) acc 2.5 maxacc 4.0 AXIS Section maxvel .8 stepgenmaxvel 1 maxacc 3 stepgenmaxacc 4.4 Is there any particular reason why you chose 2,400,000 for the servo and traj periods? I'm sure it will work for these speeds (and it does reduce the CPU load marginally), but it shouldn't be necessary to lengthen these. Can you share your reason for changing them? I ask for two reasons: 1) if you found that something didn't work at 1,000,000 but it did at 2,400,000, I'd like to know. 2) I think it's usually best to keep changes to the INI to a minimum - it makes upgrades easier if you only change things that are specific to your machine and leave the rest at default. - Steve Thanks, Cecil - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How Fast Are Pythons
On Thu, 2007-08-23 at 18:13 -0400, Stephen Wille Padnos wrote:
... snip
Just using wsum made a big difference in the shell script. I was
consistently just one tool position off with the rotate direct to
station routine, and it only gets better from here.
If the
turret can't move in both directions, then you can do the whole thing
with HAL components - no classicladder needed. You'll have to write a
simple component to compare two s32 numbers (strange but true - there's
an 8-bit pattern match with cascade input component, but no integer
comparison :) ) Look at something like xor2.comp for an example of a
simple .comp component.
Like this?
~ s32equal.comp ~
component s32equal Check if two s32's are equal;
pin in s32 in0;
pin in s32 in1;
pin out bit out;
function _ nofp;
license GPL;
;;
FUNCTION(_) {
if (in0 == in1)
out = 0;
else
out = 1;
}
~ s32equal.comp ~
then recompile EMC or just the component?
use debounce / weighted_sum to get a stable position reading (current_tool)
use tool_change AND NOT (requested_tool == current_tool) to enable the
turret to index
(AND and NOT are both HAL components already, and there are other logic
components)
I think that's about it. Another option is to just write a .comp to do
it all - take in 4 bits, the requested tool number, and the
tool-prep/tool-change signals, output tool_prepped/tool_changed and
turret controls.
Then forget the M101 and tie into the pins used by M6, as nature had
intended.
The comp preprocessor really helps make this kind of
HAL component easy to write.
- Steve
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
