Shop OBEX P1 Docs P2 Docs Learn Events
CNC - I may be crazy, but.... — Parallax Forums

CNC - I may be crazy, but....

idbruceidbruce Posts: 6,197
in Propeller 1
Hello Everyone

In a recent thread that I started, I mentioned that I would be switching to an Arduino, as a CNC controller, because of it's ability to run GRBL CNC software, and use the Propeller for a user interface. From a tired persons point of view, this is probably a good route to go, BUT there is one main limitation. GRBL is currently limited to three axes, which is perfect for three axis machines, but what about a fourth?

In the thread mentioned above, which is located here: forums.parallax.com/discussion/166284/cnc-the-new-plan-any-feedback/p1

Ken Said:
There's a very functional CNC controller (all Propeller) recently made by a customer of ours that runs G code.

If you're interested in being connected to him please drop me an e-mail kgracey@parallax.com. We should consider rallying behind his product if it's suitable for a number of our customers. At my first look, it certainly is.

My Response:
The controller really is not the issue, because the Propeller can easily be used as a controller. The problem is reliable, understandable, and configurable software, which has community support. This particular issue has been my stumbling block for years.

In another thread, I present and describe a CNC controller, which should work well for a 3D printer or a four axes CNC machine. However, there currently is no completed software available to utilize this controller. And of course, this is always somewhere in the back of my mind. This thread can be found here: forums.parallax.com/discussion/160739/new-attempt-3d-printer-controller-and-firmware/p1

The new machine that I am building, will have a total of six steppers motors, for various tasks, and of course, all of these motors will need to be controlled, and as of yet, I still have no perfect plan for controlling these motors. I believe my best option at this point, is to move forward with the Propeller + Arduino + GRBL plan, but I still know with all my heart that the Propeller chip would make a nice controller without Arduino, so once again, I have been searching for and looking at various documents pertaining to interpolation, multi-axes syncronization, and CNC control.

A while back, during some previous research, I came across a document titled "Multi-Axis Synchronization", which was authored by John Rathkey, from Parker-Hannifin, Compumotor Division. This document can be found here: parkermotion.com/whitepages/Multi-axis.pdf

Now I must admit that my reading comprehension is not the greatest, so I have studied this document several times. And as I study other control schemes and software, I am always drawn back to this specific document. Over time, I have weeded out and sorted what I believed were the key aspects of the document, but then always returned to the original, for a fresh look. After reading it again this morning, I believe I had an epiphany, which should have been obvious from the first time I read it. In this document, John Rathkey discusses the mechanical approach to synchronization and the electrical approach to synchronization. Even though I was reading the document over and over, I always just glazed over the mechanical approach to synchronization and analogies thereof, but this time it hit me.....

To achieve multi-axis synchronization, the software must run just like a set of gears!!!!
And this software gear set, must support gears of different ratios!!!!
The master gear sets the pace, and the following gears remain synced at their specific ratio!!!!

Now what would be the perfect microcontroller for creating this software gearing? The Propeller of course, because it already has cogs :)

I hereby present the idea of Propeller Gear CNC software:) Am I crazy?

Comments

  • jmgjmg Posts: 15,173
    idbruce wrote: »
    In a recent thread that I started, I mentioned that I would be switching to an Arduino, as a CNC controller, because of it's ability to run GRBL CNC software, and use the Propeller for a user interface. From a tired persons point of view, this is probably a good route to go, BUT there is one main limitation. GRBL is currently limited to three axes, which is perfect for three axis machines, but what about a fourth?

    Yes, seems to have hit design saturation. Was started years ago, but now maxes out the smaller AVRs
    idbruce wrote: »
    The new machine that I am building, will have a total of six steppers motors, for various tasks, and of course, all of these motors will need to be controlled, and as of yet, I still have no perfect plan for controlling these motors. I believe my best option at this point, is to move forward with the Propeller + Arduino + GRBL plan, but I still know with all my heart that the Propeller chip would make a nice controller without Arduino, so once again, I have been searching for and looking at various documents pertaining to interpolation, multi-axes syncronization, and CNC control.
    ... not to mention, that six steppers is likely going to need some means to split at the front end, to what the Ardunio can manage....

    idbruce wrote: »
    A while back, during some previous research, I came across a document titled "Multi-Axis Synchronization", which was authored by John Rathkey, from Parker-Hannifin, Compumotor Division. This document can be found here: parkermotion.com/whitepages/Multi-axis.pdf

    Now I must admit that my reading comprehension is not the greatest, so I have studied this document several times. And as I study other control schemes and software, I am always drawn back to this specific document. Over time, I have weeded out and sorted what I believed were the key aspects of the document, but then always returned to the original, for a fresh look. After reading it again this morning, I believe I had an epiphany, which should have been obvious from the first time I read it. In this document, John Rathkey discusses the mechanical approach to synchronization and the electrical approach to synchronization. Even though I was reading the document over and over, I always just glazed over the mechanical approach to synchronization and analogies thereof, but this time it hit me.....

    To achieve multi-axis synchronization, the software must run just like a set of gears!!!!
    And this software gear set, must support gears of different ratios!!!!
    The master gear sets the pace, and the following gears remain synced at their specific ratio!!!!

    Now what would be the perfect microcontroller for creating this software gearing? The Propeller of course, because it already has cogs :)

    I hereby present the idea of Propeller Gear CNC software:) Am I crazy?

    No, you may be onto something. It does make sense to use a gear metaphor.

    The way I would tackle this, to avoid 'future choke points' , would be to have a master CPU engine manage the axes, and dispatch instructions in the form of way points.

    These would have both time, and location.

    That allows any number of slaves to co-operate, on a multi-axis system, and allows any mix of processor on the slaves.

    A simple link would include a means to SYNC time, which should be possible on a Prop to 12.5ns
    UARTs are universal, but most hosts lack the useful 9-bit mode, (only EXAR manage this), so drawing on KISS, a simple packet that uses sub byte indexing, self-extracts without complex message parsing.

    Possible payloads in this scheme are :
    FragmentID.Data    BytesInPacket    Data (D*BIP)
0.8                1                8b 
1.7                2               14b 
2.6                4               24b 
3.5                8               40b 
4.4               16               64b 
5.3               32               96b 
6.2               64              128b 
7.1              128              128b

    Picking one of those, 3.5 sounds useful, as it supports 40b in 8 bytes, giving a payload of 32b data, 1b for Time/Distance select, and 7 bits for Axis ID.
    A few of the possible 128 Axis ID would be used for global commands like ZeroTime and ZeroAxes.
    Host sends a stream of 8 byte payloads to each axis, as dD,dT pairs (distance to move, and time to take, or time/step)
    eg 6 axis machine, a 1MBd link, could update all axes in 950us, 2~3 MBd would be practical ?

    One COG manages the link, leaving 7, maybe 6 axes, and one 'watchdog' ?
    Multiple Props can be added, or even a mix of ARM/Prop/Smaller MCU as needed, all drawing on the same link info.

  • idbruceidbruce Posts: 6,197
    edited 2017-03-20 01:10
    jmg

    First off, thanks for responding, and secondly, thanks for letting me know that I am not crazy :)

    As mentioned in my previous post, my reading comprehension is a bit on the poor side, and I believe a lot of what you said is way above my pay grade :) Please forgive me, but I only grasped a portion of what you were trying to tell me. :)

    However I can already tell that we are thinking a bit differently, which is okay, because the discussion of different ideas, has led to many great discoveries and advances.

    As I see it, there will always be a master of any given process or cycle, and the master sets the pace or timing of events or advancement of the other so called gears. Instead of doing a bunch of timing calculations for each slave, each slave or follower simply monitors the outputting pin state of the master and accumulates a counter. When the counter reaches a value which coincides with the required ratio of the slave or follower, it then advances.

    EDIT: After reading your post another time, I see that you want the slaves to be able to cooperate. For the sake of discussion, let's just assume that a slave gear can also be a master gear, which other slave gears base their movement upon. In which case those slaves would monitor the outputting pin of their master.
  • jmgjmg Posts: 15,173
    idbruce wrote: »
    ...
    EDIT: After reading your post another time, I see that you want the slaves to be able to cooperate. For the sake of discussion, let's just assume that a slave gear can also be a master gear, which other slave gears base their movement upon. In which case those slaves would monitor the outputting pin of their master.

    Close, but I would word it a little differently.
    The slaves do not strictly co-operate, as no slave knows of the existence of others, but they certainly do synchronize, and you would commonly send a series of queued command way points to each Axis slave, and then issue a common 'GO' - from there, the slaves issue varying dD rates, to complete their movements in (exactly) the allocated dT.
    idbruce wrote: »
    ...
    As I see it, there will always be a master of any given process or cycle, and the master sets the pace or timing of events or advancement of the other so called gears. Instead of doing a bunch of timing calculations for each slave...
    Almost, the slaves are certainly simpler than a 3-axis Ardunio, and they do less calculations, but they still do some, as they manage a Count (dD) and a step rate or speed (dT)
    The slaves do not manage acceleration - effectively they manage straight line, single velocity movement vectors.
    The master manages acceleration by stringing many small movements together.
    Complex curves in 3D space come about by way of the Time-Sync 'smarts' in the slaves. (all axes move together, as needed)

    A high level OS host (like Windows or Linux) may not be able to 'fine tune' the data delivery, in which case a shared 'done' handshake line would allow common serial port buffers to manage that.
    We have used 'NOP' type serial port packers in the past, to get finer control over actual delivery rates, which OS delays and USB quanta conspire to prevent.
    As an example, if you want to pause a 1MBd serial link for 550us, you cannot do that from the OS, but you can send 55 NOPs.
    idbruce wrote: »
    ...
    Instead of doing a bunch of timing calculations for each slave, each slave or follower simply monitors the outputting pin state of the master and accumulates a counter. When the counter reaches a value which coincides with the required ratio of the slave or follower, it then advances.
    Whilst you could, in theory generate a cluster of Step and Direction outputs, to achieve a similar outcome, the master hardware needed for that would likely include a FPGA (or a P2?).
    My idea is to allow RaspPi type masters, which more limits your choice of data transport layer to Serial.
  • JasonDorieJasonDorie Posts: 1,930
    For any linear move, Bresenham can coordinate multiple axis moves in a single thread with very simple math. The tricky part is handling acceleration and deceleration, but even that can be done relatively simply with a trapezoidal motion curve. Then it's Bresenham for the interpolation, with the trapezoidal motion plan for the step timing.

    GRBL and others compute in advance a series of segments, and use acceleration / deceleration limits to figure out how fast you should be going when you start and end a given segment. As you figure out segments, they get pushed into a queue which gets processed by an interrupt handler. On the Prop that'd just be another cog, so I'd expect the overall code to actually be simpler.

    If you haven't seen these, both might help you:
    http://www.eetimes.com/document.asp?doc_id=1276928
    http://www.embedded.com/design/mcus-processors-and-socs/4006438/Generate-stepper-motor-speed-profiles-in-real-time

    I've implemented the above on the Prop - This is C++, on a single cog:

  • idbruceidbruce Posts: 6,197
    jmg

    After thinking on a bit more, I realize my analogy was a bit too over-simplified. The output of a slave gear will not always be limited to a whole number of the master, but it will definitely be somewhere between the two output points, in which case a delay would be added to the slave, based on the ratio. I believe figuring out the delay would be the hardest part of implementation.

    I just thought of something, but I will have to put more thought into it.

    jason

    I am just trying to think outside the box and open up possible ideas. One way or another, Bresenhams algorithms will definitely have to play a role.

  • MJBMJB Posts: 1,235
    idbruce wrote: »
    jmg

    After thinking on a bit more, I realize my analogy was a bit too over-simplified. The output of a slave gear will not always be limited to a whole number of the master, but it will definitely be somewhere between the two output points, in which case a delay would be added to the slave, based on the ratio. I believe figuring out the delay would be the hardest part of implementation.

    I just thought of something, but I will have to put more thought into it.

    jason

    I am just trying to think outside the box and open up possible ideas. One way or another, Bresenhams algorithms will definitely have to play a role.
    the gear analogy holds for linear movements in 3D space.
    As soon as the direction vector changes the gear ratios change as well.
    So as a metapher it might help visualize, but in reality it is a bit more complex.


  • ErNaErNa Posts: 1,752
    edited 2017-03-20 10:32
    IdBruce, you touched a very important point. The problem to be solved in creating movement in space is not solvable exactly, it needs alway compromises. Maybe, Trump knows a way. The point is: whenever you move "around" a sharp edge, you can not do this at a given constant speed, because this would require infinite acceleration. Idealy you describe a minimal circle. If you do not take such provisions, the limitations of the mechanics (motor torque, inertia, stiffness) will determine what happens. You will then see jitter, vibration... as an outcome. The question is: what errors are acceptable. So: you will find a lot of research related to this topic and as different tasks urge for different compromises, there will be discussion.
    To come around this: you have to decide, what is needed. Surely, the propeller can do this best, but noone brought it to the end.
  • kwinnkwinn Posts: 8,697
    The gear ratio is a pretty good analogy for synchronizing several axis of motion, except as MJB points out only for linear motion. For nonlinear motions it would be more like a number of Continuously Variable Transmissions connected to a single motor. To overcome the problems ErNa points out the “motor” would need to adjust it’s “RPM” based on feedback from all of the “CVT’s”. Generally one of the axis will limit how fast the system can go, and that will not always be the same axis, so the “motor” (code that determines overall speed) would looks at how fast each axis needs to move and adjusts the “gear ratios” of the “CVT’s” and it’s own “RPM”
  • idbruceidbruce Posts: 6,197
    Yes, it is all very complicated. UGH

    So what do you folks think about hooking up two of these ICs to a Propeller? novaelec.co.jp/eng/MCX514_e.html
  • jmgjmg Posts: 15,173
    JasonDorie wrote: »
    For any linear move, Bresenham can coordinate multiple axis moves in a single thread with very simple math. The tricky part is handling acceleration and deceleration, but even that can be done relatively simply with a trapezoidal motion curve. Then it's Bresenham for the interpolation, with the trapezoidal motion plan for the step timing.

    GRBL and others compute in advance a series of segments, and use acceleration / deceleration limits to figure out how fast you should be going when you start and end a given segment. As you figure out segments, they get pushed into a queue which gets processed by an interrupt handler.
    Yup, the system I describe splits the design, so those segments (sent as dD,dT 'waypoints') go over the serial link.
    That allows flexibility of the host processor, by decoupling the maths from the movement details.
    The dT info, adds tolerance of serial link delays, and allows more decoupled axis slaves to still move in unison.
    (adding more axis slaves does not affect the timing)


    idbruce wrote: »
    So what do you folks think about hooking up two of these ICs to a Propeller? novaelec.co.jp/eng/MCX514_e.html

    You could do that, but their English is not looking the best, which could make managing the details a challenge.
  • MicksterMickster Posts: 2,693
    Actually, gearing is totally different to interpolation. With gearing, the master becomes the commander of the slave. A good example of a master is a handwheel, whichever way you spin it, the slave axis will follow....at the specified ratio.
  • JasonDorieJasonDorie Posts: 1,930
    That's true, but things get weird when you're doing something like a circular arc that needs acceleration & deceleration. During the arc the ratio between axes changes, so you need to figure out in advance which axis will be the limiting one, and base the accel rate off that, driving the other axis off the interpolation of the driver axis.
  • MicksterMickster Posts: 2,693
    JasonDorie wrote: »
    That's true, but things get weird when you're doing something like a circular arc that needs acceleration & deceleration. During the arc the ratio between axes changes, so you need to figure out in advance which axis will be the limiting one, and base the accel rate off that, driving the other axis off the interpolation of the driver axis.

    That's my point; with master/slaving, NOTHING is figured out in advance. If the slave is commanded to do something that it's not capable of, its following error increases and appropriate action is taken. Linear and circular interpolation are pre-calculated commands, dished out in a time-sliced fashion.

  • MicksterMickster Posts: 2,693
    idbruce wrote: »
    Yes, it is all very complicated. UGH

    So what do you folks think about hooking up two of these ICs to a Propeller? novaelec.co.jp/eng/MCX514_e.html

    I recommend jrkerr.com

  • idbruceidbruce Posts: 6,197
    Mickster
    I recommend jrkerr.com

    I think I may just actually take a gamble on this IC, just to see what it is actually capable of doing, at least with my simple projects. It sounds like it can do some fairly serious stuff, much more than I need, but I figure it will be a learning experience for a possible motion control solutions, and perhaps I may find a solution to many of my problems along the way.

    In my opinion or guess, the Propeller chip could probably perform many of the functions and computations that this chip does, but alas, we need a motion control genius/programmer in our corner, which we do not have, or at least not one that is willing to share their code.

    After doing a currency conversion, the MCX514 Evalution Board comes in at $133.15. I have certainly taken bigger gambles. Additionally, the datasheet contains an example C program, which should easily paste into SimpleIDE, to enable fast testing, providing the Propeller has enough pins to run the chip and drivers.
  • MJBMJB Posts: 1,235
    idbruce wrote: »
    jmg

    After thinking on a bit more, I realize my analogy was a bit too over-simplified. The output of a slave gear will not always be limited to a whole number of the master, but it will definitely be somewhere between the two output points, in which case a delay would be added to the slave, based on the ratio. I believe figuring out the delay would be the hardest part of implementation.

    I just thought of something, but I will have to put more thought into it.

    jason

    I am just trying to think outside the box and open up possible ideas. One way or another, Bresenhams algorithms will definitely have to play a role.
    the gear analogy holds for linear movements in 3D space.
    As soon as the direction vector changes the gear ratios change as well.
    So as a metapher it might help visualize, but in reality it is a bit more complex.

    idbruce wrote: »
    Mickster
    I recommend jrkerr.com

    I think I may just actually take a gamble on this IC, just to see what it is actually capable of doing, at least with my simple projects. It sounds like it can do some fairly serious stuff, much more than I need, but I figure it will be a learning experience for a possible motion control solutions, and perhaps I may find a solution to many of my problems along the way.

    In my opinion or guess, the Propeller chip could probably perform many of the functions and computations that this chip does, but alas, we need a motion control genius/programmer in our corner, which we do not have, or at least not one that is willing to share their code.

    After doing a currency conversion, the MCX514 Evalution Board comes in at $133.15. I have certainly taken bigger gambles. Additionally, the datasheet contains an example C program, which should easily paste into SimpleIDE, to enable fast testing, providing the Propeller has enough pins to run the chip and drivers.

    IIRC @manatwork - regular poster here - (search the forums for him) uses the propeller to build (and sell) professional motor control and CNC systems.
  • MicksterMickster Posts: 2,693
    MJB wrote: »

    IIRC @manatwork - regular poster here - (search the forums for him) uses the propeller to build (and sell) professional motor control and CNC systems.

    I haven't been able to contact him in months and his website is down. was thinking about trying to page him on this forum.

    @idbruce: Dunno, man. Sounds like getting back to reinventing the wheel. What's up with LinuxCNC on Beagleboard/RPi?
  • idbruceidbruce Posts: 6,197
    edited 2017-03-21 11:12
    Mickster
    Dunno, man. Sounds like getting back to reinventing the wheel.

    :D Yea, but I need a nice, inexpensive solution, that suits my needs and wallet. Just so you know, I do look at the info you provide and some of it is very good and interesting. Just haven't found the perfect fit just yet.

    I browsed through LinuxCNC yesterday, but turned away, because Linux just isn't my thing, although it probably should be. As for Beagleboard, I have not looked at it since ErNa mentioned it several years ago. I will take another look.

    As for now, I can easily run the new machine I am building off a Propeller, Arduino, and GRBL, but I am always looking for that final solution, which does not cost the big bucks. If I can get these chips to work for me, I believe it might fit the bill and wallet for prototypes.

    Once I get something seriously off the ground, then I can play a much bigger and better game, until then, I suppose I must struggle. I am hoping that my furnaces and metal melting tools will be an income earner this year, but now I need to rush to get my videos made, a website built, etc... I had blocked it all out of mind until yesterday, which was the first day of Spring. Now it has to be rush, rush, rush, before I get behind again.
  • MicksterMickster Posts: 2,693
    edited 2017-03-22 08:47
    idbruce wrote: »

    :D Yea, but I need a nice, inexpensive solution

    Linux just isn't my thing

    I hear ya!

    A Micromite Plus (or the new Extreme) + Prop makes a nice marriage.

    I have a couple of "Explore 100s" sitting here that I am currently working with. Doesn't get easier than this.
    One of these units will be coupled with Cluso's P8XBlade2 (recently received....VERY nice!)

    There is also the "Explore 64"

  • idbruceidbruce Posts: 6,197
    edited 2017-03-22 10:16
    Mickster
    A Micromite Plus (or the new Extreme)

    I just watched this video: https://youtube.com/watch?v=j12LidkzG2A

    All I can say is WOW! Now that is very impressive! You definitely got my attention with that one!

    It was a little unclear to me, because firsth he starts describing the chips and their abilities, but then he starts showing of this wonderful interface. Can it all be purchased just like he is showing it with the screen?

    EDIT: DUH I just clicked your links... Sorry
  • idbruceidbruce Posts: 6,197
    Mickster

    I will definitely be getting one of the MicroMite Explore 100 kits. Thanks for the heads up on that wonderful find!!!
  • MicksterMickster Posts: 2,693
    My project is paid-for and time is short. I needed a ready-made professional-looking product and this was it.

    The two Mikrobus sockets are perfect because I need BT comms (tablet is the HMI) and the ability to read an incremental encoder (7366 Counter Click)

    Digital outs via SSRs and digital ins via standard wiring terminals with built-in opto-couplers.

    All I have to do is program which can be done directly on the Explore 100 but I prefer "MM-Edit" (nice!) on the PC.

    I'm only interested in the real-time capabilities of the Prop1 so most future changes should be purely parametric. Actual machine sequencing, etc., to be handled by the MM Explore.

    Yer gonna like it! :-)


  • idbruceidbruce Posts: 6,197
    Mickster
    I needed a ready-made professional-looking product and this was it.

    Yes, it looked very professional indeed and very inexpensive. No doubt about it, I am certain that I will have a lot of fun toying around with it.

    Many years ago, when I was really into programming with C++ and MFC, I really enjoyed putting together practical and nice looking user interfaces for various software. Since moving onto making machinery and various prototypes, I was briefly exposed to LabVIEW from National Instruments, which I really liked a lot also, but their products are way out of my league.

    Putting together a practical and nice looking user interface for machinery is no cake walk as you know, but the Explore 100 is just the ticket for a very professional looking and inexpensive HMI.

    Words cannot express my gratitude for your sharing of this information, so I will simply say Thank You Mic.
  • MicksterMickster Posts: 2,693
    edited 2017-03-22 15:14
    idbruce wrote: »

    Putting together a practical and nice looking user interface for machinery is no cake walk as you know,

    Oh I put quite a bit of effort in my GUI designs and Android makes it easy. I even include machine schematics so that the maintenance guys can detach the tablet from the pedestal and take the entire set of prints to the point of interest on the machine. A few screenshots..



    Screenshot_2013-08-31-15-35-33.png
    1280 x 752 - 270K
    Screenshot_2013-08-31-15-38-24.png
    1280 x 752 - 348K
    Screenshot_2013-09-03-08-15-19.png
    1280 x 752 - 873K
    Screenshot_2013-08-31-13-46-40.png
    1280 x 752 - 714K
    Screenshot_2013-08-31-14-26-19.png
    1280 x 752 - 410K
    Screenshot_2013-08-31-17-30-16.png
    1280 x 752 - 535K
    Screenshot_2013-08-31-14-28-34.png
    1280 x 752 - 649K
    Screenshot_2013-08-31-15-33-46.png
    1280 x 752 - 247K
    Screenshot_2013-08-31-13-41-04.png
    1280 x 752 - 693K
    Screenshot_2013-08-31-13-40-54.png
    1280 x 752 - 275K
  • idbruceidbruce Posts: 6,197
    Mickster

    Very nice work and interesting. Did you design that tubing bender? Is the 2500 max length for the tubing? How much does the machine weigh? It looks rigid and heavy :) Built to last
  • MicksterMickster Posts: 2,693
    Thanks, yeah it's my design. I was the founder/owner of the company. We built hundreds of the EB76 (Electra-Bend 76mm) and dominated the US muffler industry throughout the 90's.

    It was the first large(ish) exhaust bender with an electric bending axis (as opposed to hydraulics). The exhaust industry had recently switched from cold-rolled steel to 409 stainless and existing machines began to struggle. I beefed my design up and fitted a closed-loop 40HP AC Vector-drive/motor and 55:1 helical-bevel gear-reducer to the bend-head. They can bend 3" diameter, 2mm wall-thickness, 409 SS at 180 degrees/sec. Made a few people jump...LOL.

    Standard length over mandrel is 3000mm but we have some 6000mm versions for non-automotive industries.

    The Corvette chassis actually starts out as round, 6" diameter tube and is formed, entirely on our EB150 (150mm). Even that bends at 90 degrees/sec.

    Can't for the life of me remember the weight but yeah, beef was the order of the day.

    For the Polaris RZR, we went 100% electric (that company is loaded) and 17 CNC axes.


  • idbruceidbruce Posts: 6,197
    Mickster
    Thanks, yeah it's my design. I was the founder/owner of the company. We built hundreds of the EB76 (Electra-Bend 76mm) and dominated the US muffler industry throughout the 90's.

    It was the first large(ish) exhaust bender with an electric bending axis (as opposed to hydraulics). The exhaust industry had recently switched from cold-rolled steel to 409 stainless and existing machines began to struggle. I beefed my design up and fitted a closed-loop 40HP AC Vector-drive/motor and 55:1 helical-bevel gear-reducer to the bend-head. They can bend 3" diameter, 2mm wall-thickness, 409 SS at 180 degrees/sec. Made a few people jump...LOL.

    Standard length over mandrel is 3000mm but we have some 6000mm versions for non-automotive industries.

    The Corvette chassis actually starts out as round, 6" diameter tube and is formed, entirely on our EB150 (150mm). Even that bends at 90 degrees/sec.

    Can't for the life of me remember the weight but yeah, beef was the order of the day.

    For the Polaris RZR, we went 100% electric (that company is loaded) and 17 CNC axes.

    Cool Stuff!

    I have been thinking about a tubing bender for my next project, so naturally, upon seeing the pics, it peeked my interest :) However, I am thinking of a much smaller machine, for much smaller tubing, and I will probably go hydraulic.
  • PublisonPublison Posts: 12,366
    idbruce wrote: »
    Mickster
    A Micromite Plus (or the new Extreme)

    I just watched this video: https://youtube.com/watch?v=j12LidkzG2A

    All I can say is WOW! Now that is very impressive! You definitely got my attention with that one!

    It was a little unclear to me, because firsth he starts describing the chips and their abilities, but then he starts showing of this wonderful interface. Can it all be purchased just like he is showing it with the screen?

    EDIT: DUH I just clicked your links... Sorry

    Bruce,

    Do a search on Micromite in the forum search box. Jeff (Oldbitcollector) did some work with the chip and Propeller.

  • idbruceidbruce Posts: 6,197
    Publison

    I hope all is well with you.
    Do a search on Micromite in the forum search box. Jeff (Oldbitcollector) did some work with the chip and Propeller.

    Yea, I would imagine he does. He also has a video on youtube, which I started to watch, but got distracted.
Sign In or Register to comment.