Design Concepts - Page 9

Page 9 of 9 FirstFirst ... 6789
Results 161 to 175 of 175

Thread: Design Concepts

  1. #161
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi,

    but they do not provide velocity ramping info for instance.
    Rubbish! Of course they do...they have to. Mach (or UCCNC) plans the trajectory so that an axis accelerates up to speed and the decelerates to a stop. The trajectory is
    issued by position data in 1 ms time slices.

    Sure they provide the motion controller with velocity & accel limits (which are user set)
    NO!!! The motion controller does not calculate velocity or acceleration, nor is this data even included in the motion controller. The motion controller executes the discrete motion steps as planned by
    Mach. If Mach wants to accelerate then each position of the stream of position commands is a little further apart. Once the axis has achieved its required speed, as determined by
    Mach, in response to a Gcode command or the axis maximum velocity, whichever is the greater, the position of each time slice will increment uniformly.

    X position:

    t0=0
    t1=.5
    t2=1.5
    t3=3
    t4=6
    t5=9
    t6=12

    This would be a typical stream of motion commands. The time interval is approx 1ms. The position is the number of steps of the axis motor.
    The (vastly simplified) string of data is for the X axis to accelerate from its original position, assumed 0 here for clarity, then accelerate up to 3 steps/time slice
    and continue at 3 step/time slice thereafter.

    The motion controller just generates the signals that cause the motor to move....it does not calculate the trajectory.

    Craig



  2. #162
    Member peteeng's Avatar
    Join Date
    Jul 2018
    Location
    dum dum
    Posts
    6257
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hello Craig - I'll have to go away and do some reading. But your implying that the motion controller does not plan the motion and that the machine controller does. I believe this is incorrect. The machine controller provides a stream of positions (and the feed speed/accel limits), and the motion controller figures out how to achieve those positions within the configuration settings. But I'll do some reading up on mach... Peter



  3. #163
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi peteeng,

    But your implying that the motion controller does not plan the motion and that the machine controller does. I believe this is incorrect.
    The motion controller does not plan the trajectory, the trajectory planner is Mach, and is a very substantial part of what Mach is. Just so we are clear, a UC100 motion controller
    can be used with Mach OR UCCNC, so Mach and UCCNC are very similar, while not identical ie they operate the same way. Just as another matter of interes LinuxCNC operates similairly,
    ie a stream of position points. Those positions reflects the accel or decel or constant speed or stop of the axis.

    The CNC software plans the trajectory and plots if you like a series of position points the the axes have to meet along the way. Lets say at time interval 12345ms the the X axis
    position is 7896543 counts. Mach determines that at 12346ms, ie 1 ms later the X axis needs to be at 7896533 counts in order to be in synch with all the other axes. The motion controller
    knows then that over the next 1ms it must issue 10 Step pulses while the Dir pulse is held low ie the axis count is decreasing. It divides the 1000uS by ten and issues 10 pulses
    of 100us duration, ie 10 Steps in 1 ms...and then awaits a new count target for the next time slice. The motion controller generates the pulses and that requires very good timing
    and that is what motion controllers specialise in as PCs are poor at it.

    To my knowledge ALL CNC software solutions operate on this basis, the software plans the trajectory and the motion controller issues the pulse to do it.

    The machine controller provides a stream of positions (and the feed speed/accel limits), and the motion controller figures out how to achieve those positions within the configuration settings.
    The machine controller does indeed provide a steam of positions, but it takes into account the acceleration and speed settings that the user has told the controller that the machine is capable of.
    The motion controller just issues pules......at best it calculates the duration of each pulse to occupy the time it has available, but it does not do any calculation as to what velocity or acceleration
    that would result in.

    Craig



  4. #164
    Member peteeng's Avatar
    Join Date
    Jul 2018
    Location
    dum dum
    Posts
    6257
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi Craig - This is my understanding of the chain of events:
    1) Use a CAM system to generate a g-code stream that defines the ideal toolpath. It only contains positional data no motion attributes except target feed speeds and target rapid speeds are included. These are modal.
    2) Import this into the machine controller or trajectory planner - The machine controller (MC - uccnc mach 4 etc etc) takes the ideal G-code stream and modifies it according to the machine specific configuration settings. Especially in constant velocity mode this means the MC may change the actual ideal g-code co-ords to maintain a path inside the tolerance settings, it may decimate code to make it shorter etc etc. But it does not use any velocity or acceleration calculations to achieve this. The trajectory planner (M3-4 uccnc etc) is purely concerned with positions. Just like asking Google to get you somewhere, you can drive around potholes and stay on the same road side etc but the roadway is the Google path and you stay inside that tolerance. Speed is another matter... The MC does not consider speed or accelerations
    3) This new pathway is sent to the motion planner or motion controller (MP) The MP (UC100 ESS etc) picks up velocity and accel limits from the config. When the position stream starts the MP calculates the velocity ramp from the max accel settings in the config. Once it knows the vel ramp it can attach time to the position data and create timed steps. It issues these timed steps to the motor controllers. Once the axis velocity gets to the max set velocity it stops accelerating or if the path is curved or a 90deg is about to happen it slows down and then speeds up according to the machine configuration rules. Or if the motion can happen in theory but for instance the machine is not stiff enough then it chatters or digs in or breaks... This means the MC config does not match or suit the machine in realty. **** happens slow down accels or vels until this sort of thing does not happen...
    4) When all of this comes together you get a clean toolpath and good parts. When something goes wrong (timings, config, various linking motions, interference, poor power supply stability, etc etc etc you've been there) it goes really wrong. Its a complex 3D eco system and we are both about to go down the 5 axis path and its even worse!! Inflections, indeterminate positions, multi rotational acceleration time and space, sounds like fun... Peter



  5. #165
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi peteng,
    1) is OK

    2) is shaky. The machine controller accepts Gcode, one of Machs job is a Gcode interpreter. It plans the trajectory, which includes recognising the acceleration and velocity limits of the hardware.
    It also accommodates the constant velocity calculation.

    Especially in constant velocity mode this means the MC may change the actual ideal g-code co-ords to maintain a path inside the tolerance settings, it may decimate code to make it shorter etc etc. But it does not use any velocity or acceleration calculations to achieve this.
    BS. It is the machine controllers job to plan the trajectory, which includes any shortcuts it might take to achieve it. It relies on the velocity and acceleration settings declared to it by the user as to the capability
    of the machine. Note that when you try to tweak the constant velocity algorithm that you input data into the machine controller....not the motion controller which lends weight to the idea that the constant velocity
    algorithm is in the machine controller/trajectory planner not the motion control.

    Speed is another matter... The MC does not consider speed or accelerations
    This is just plain wrong....it is the machine controller (Mach, UCCNC or whatever) that calculates speeds and accelerations. It conveys this to the motipon controller by producing
    a set of waypoints for the axis motors. If two waypoints are a short distance apart over several milliseconds that indicates a low velocity. If they are a significant distance apart over the same
    several milliseconds then that indicates a high velocity.

    Given that your understanding of 2) is faulty then 3) is just plain rubbish. The motion controller gets frames of numeric data, maybe a block of sixteen 32 bit integers,with each 32 bit integer being the
    expected axis position of an axis at the end of the time slice, 1 ms. The motion controller has a running total or count of its current position(per axis) and it compares this to the number that is supplied to it
    by the planner. It then executes the number of steps to achieve that target position in the next 1ms. Should it be that the number of steps is such that no motor could keep up, the motion controller
    neither knows or cares it just issues the number of pulses its told to. Its the trajectory planners job to ensure that the movement commands it issues are actually achievable. Have you noticed that
    the max velocity, max acceleration and steps per unit are ALL entered into the machine controller (Mach, UCCNC etc) not the motion controller? It is because the trajectory planner uses this data....
    not the motion controller. The trajectory planner will know for instance that it cannot issue a movement increment of more than 314 to the X axis in one time slice because it knows that would
    exceed the max velocity of the X axis.

    Have you wondered how a CNC machine coordinates two or more axes?

    The trajectory planner issues an X movement increment of 20 and a Y movement increment of 40 and therefor the Y axis will move twice as far (in 1ms) as the X axis. The next time slice might
    have a Y movement increment of 38 while the X movement increment is 22, ie the toolpath is curved with the Y axis slowing a little and the X axis going a little faster. The point is that during
    any one time slice the X axis is moving its required 20 steps while the Y axis is moving 40, but the X and Y axes are not coordinating during that period, they are just moving the commanded number
    of steps. Presumably the trajectory planner knows that all will be well if the X axis indeed does its 20 and the Y axis its 40....but the motion controller has no idea.

    Also have you wondered why, given that you seem to think that the UC100 is so smart, that its so small and has but one small FPGA inside while you drive it with a PC with VASTLY more computing power?
    The truth is the UC100 can't really calculate to save itself, it can do pulse timing......but not much else, while the PC can do the intricate calculations to coordinate multiple axes including acceleration,
    deceleration, constant speed, and manipulate the toolpath for Constant Velocity.

    Craig



  6. #166
    Member peteeng's Avatar
    Join Date
    Jul 2018
    Location
    dum dum
    Posts
    6257
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Sorry Craig - We shall differ until otherwise figured out... The maths for the vel and accel stuff any high school kid can do its not intensive. The vectoring again is easy for a basic machine. M3 was doing it 20 years ago with very little resources... I shall continue reading. Peter

    You say that the machine config is entered into the machine controller not the motion controller so it must be doing the math. Not so.... thats just the way the industry has divided the duties historically... it can be different. intricate calculations??? very basic calculations and co-ordination is simple... I've not done it but I expect many people do...



  7. #167
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi petteng,
    even 20 years ago Mach3 had a PC, and even a 20 year old PC has way more computing power than a UC100.

    You say that the machine config is entered into the machine controller not the motion controller so it must be doing the math. Not so.... thats just the way the industry has divided the duties historically... it can be different. intricate calculations??? very basic calculations and co-ordination is simple... I've not done it but I expect many people do...
    BS. Data that the motion controller needs and uses is put into the motion controller plugin. That data is flashed to the motion controller on start up as firmware.
    Data which is put into the machine control software is consumed and used by the machine control software.

    very basic calculations and co-ordination is simple... I've not done it but I expect many people do...
    I call them intricate because up to six axes (in Mach) are coordinated, with each potentially having different max accelerations, max velocities and steps per unit values.
    Perhaps you'd like to try that calculation by hand. Three axes all different accelerations starting from zero to some cutting speed for a given length and decelerate so that all
    axes arrive at the same moment and also ensuring that all axes stay within some small error on the same toolpath. Thats what I call intricate, maybe not hard but certainly
    voluminous.

    That is called trajectory planning and its done by Mach. Whereon Mach issues movement instructions (stepwise) by issuing a terminating position or axis count to each axis in 1ms intervals.

    Thats How Mach has operated for years, as has UCCNC, LinuxCNC, Planet CNC and on, and on ,and on.

    Craig



  8. #168

    Default Re: Design Concepts

    I won't pretend I understand any of it, but I was only planning to use axbb with uccnc for the initial 3 axis only, just to get it going. For more I'm looking at acorns big brother oak or edings industrial controller, which has the advantage of having a guy that worked on the UI(kabaalstra) a part of this forum, equal to having somewhat of a more direct access and to hopefully better tech support than any other vendors.

    there's also that guy from swissmak that used duet3d for 9 axis...

    I hope to stay within the more reasonably priced motion controllers but if all fails siemens has a basic entry level package under 10g's, not ideal but nothing that 10 years of future saving up cant handle



  9. #169

    Default Re: Design Concepts

    some further work with internal structure, trying to minimize local sheer issues. bed target length around 1800mm, cross section around 320x320mm, weight is ~400kg across all 3 versions.

    third one seems the most promising as it can be cast with sand cores, so makes it cheaper, it's also how modig designed their hhv bed and its integrated with bolt holes. the problem is I want all the components to be designed with the same approach and this approach doesn't work well for the column due to local sheer.

    I'm probably overthinking it because the column on the hhv is designed with the same approach as the bed. though I'm not sure how the carriage area is handled, couldn't find any renderings of it beside the main structure inside the column

    Attached Thumbnails Attached Thumbnails Design Concepts-2023-09-09-13_27_22-microsoft-word-prospect   Design Concepts-2023-09-09-13_14_16-nx-modeling-jpg   Design Concepts-2023-09-09-13_29_17-modig-hhv-duo  


  10. #170
    Member peteeng's Avatar
    Join Date
    Jul 2018
    Location
    dum dum
    Posts
    6257
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Morning Ard - If you added a central web on the bottom design it would be a classic isogrid design. But the design has a redundant triangle grid anyway that creates the square centre cell. The technical term for one side is "zig" the other side is called "zag" The grillage spacing when optimised is dependent on the buckling strain of the webs ie the web length and thickness is the design criteria based on it not buckling. In the case of casting, the web thickness will be a manufacturing limit. Maybe a single zig or zag is all that's needed?

    NASA developed the isogrid for their structures with the node and small hole as a standard feature and spacing. They then made all bolt on parts have the same spacing so they could be moved or attached as needed. I don't know if they bonded the accessories on or they threaded extra holes in space if needed. Maybe that's how the Russians got their hole in the Space station trying to bottom tap a hole The node was not needed structurally but they wanted a feature that allowed them to attach unforeseen things to the shell in the future without modifying the shell.

    The open back design is poor in torsion but if you use the holes for instance in the lower image and bolt two of these back to back they form a nearly closed symmetric part which is good in torsion.... So have a go at bolting two together and see how that goes. Can you model a separating joint with friction? or an adhesive joint? By bolting two parts back to back you may not need the internal webs. Like two head covers back to back... The internal webs function is to stop the "shell" from warping under torsion. Once you "close" the structure webs are not needed. Plus if you use hollow dowels or a couple of dowels it becomes a very firm mechanical fit vs relying on friction 100% If no internal access is needed then you could bolt and epoxy the halves together...

    Even a back cover bolted on would help if it was mechanically sound enough. ie hollow dowels, dowels adhesive...Peter

    Attached Thumbnails Attached Thumbnails Design Concepts-ard-jpg  
    Last edited by peteeng; 09-09-2023 at 04:51 PM.


  11. #171
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi Ardenum,
    those deigns all look like they could be very stiff relative to weight, but none of them is easily made.

    The top one is almost certainly a lost foam or investment cast, I suspect either will prove too expensive.

    The middle one requires one sand core and one greensand mold. The sand core is approximately rectangular with indentations on is surface matching the ribs.
    Such a core is made of sand with a binder that is chemically or thermally hardened. They have a similar weight and mechanical properties as a low strength building brick.
    That core would then be put inside a greensand mold and then poured. The cost of a sand core is intermediate to lost foam and a plain greensand mold. My experience with casting is that
    even plain greensand molds are entirely expensive enough without trying to use a sand core. Your call, but I would shy away from it on cost grounds alone.

    The last pic could be done in a single greensand mold. I think you are trying to make the walls too thin. As a rule of thumb make the width of the section no less than 1/8 its depth, otherwise
    you'll have problems pouring it. With die casing (under pressure....think Telsa Giga Press) you can achieve ratios of 15:1, but pouring cast iron about 10:1 is the limit, and less for SG, and less again for
    steel.

    Craig



  12. #172
    Member
    Join Date
    Nov 2013
    Posts
    4283
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi Ardenum,

    It occurs to me that if you are going to the trouble of a sand core you might as well make it worthwhile and end up with a genuine closed tubular shape and thereby
    secure max torsional rigidity.

    If the outer profile of the tube is symmetrical, say a rectangle or a square, then you need one pattern from which would do both greensand drag and cope, and a split mold
    to make a hard sand core.

    Craig



  13. #173

    Default Re: Design Concepts

    Quote Originally Posted by joeavaerage View Post
    Hi Ardenum,

    It occurs to me that if you are going to the trouble of a sand core you might as well make it worthwhile and end up with a genuine closed tubular shape and thereby
    secure max torsional rigidity.

    If the outer profile of the tube is symmetrical, say a rectangle or a square, then you need one pattern from which would do both greensand drag and cope, and a split mold
    to make a hard sand core.

    Craig
    if you mean to have the ends completely closed off, that only increases stiffness when there's no internal ribs, with ribs that doesn't matter as much. or do you mean to have an inner circular(tubular) profile inside the outer square profile? I tried that and it actually had the worst torsional stiffness from all of them. if its neither I'm gonna need some drawings...



  14. #174

    Default Re: Design Concepts

    Quote Originally Posted by peteeng View Post
    The technical term for one side is "zig" the other side is called "zag" The grillage spacing when optimised is dependent on the buckling strain of the webs ie the web length and thickness is the design criteria based on it not buckling. In the case of casting, the web thickness will be a manufacturing limit. Maybe a single zig or zag is all that's needed?
    I was thinking of a single zag but in a different orientation, will see what simsolid has to say about it, it would definitely be good for weight reduction.


    Quote Originally Posted by peteeng View Post
    The open back design is poor in torsion but if you use the holes for instance in the lower image and bolt two of these back to back they form a nearly closed symmetric part which is good in torsion.... So have a go at bolting two together and see how that goes. Can you model a separating joint with friction? or an adhesive joint? By bolting two parts back to back you may not need the internal webs. Like two head covers back to back... The internal webs function is to stop the "shell" from warping under torsion. Once you "close" the structure webs are not needed. Plus if you use hollow dowels or a couple of dowels it becomes a very firm mechanical fit vs relying on friction 100% If no internal access is needed then you could bolt and epoxy the halves together...

    Even a back cover bolted on would help if it was mechanically sound enough. ie hollow dowels, dowels adhesive...Peter
    do you mean the first two pictures? those aren't open actually, I just cut through them to show what's inside, is that what you meant?

    the third picture is open on the bottom side, modig hhv bed is like this, I assume once its bolted down the open structure doesn't matter as much



  15. #175
    Member peteeng's Avatar
    Join Date
    Jul 2018
    Location
    dum dum
    Posts
    6257
    Downloads
    0
    Uploads
    0

    Default Re: Design Concepts

    Hi Ard - One issue I have with basic Simsolid is that it does not do linear buckling. So its difficult to determine when thin is too thin. I have spoken to the product manager a couple of times about this and he agrees with me on this issue and he has spoken to the developers to bring buckling into the basic version. For instance I have supplied models of columns to them in simsolid and strand7 and hand calcs to show that basic SS can load up a column past its buckling load even though they say that the non linear solver should pick this up. It clearly does not.

    I did not realise that the images were sections of hollow parts. Keep at it, I think you understand the basics to get to a good answer. Peter



Page 9 of 9 FirstFirst ... 6789

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Design Concepts

Design Concepts