Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on December 25, 2016, 05:06:03 PM
-
Let's see if I can stir up some discussion...
We are looking to add some coordinated motion to a future product. We have already implemented electronic gearing, axis following, and camming. Those that have played with it like what we have done...however...one area of weakness is in multi-axis paths. It can be done with multiple cams tied to a single virtual axis, but there is no good way to control the master axis in such a way as to optimize the slave execution time and/or tangental velocity (tool speed). So we need a multi-axis path instruction that can optimize for slave axis constraints.
We don't envision this being a G-code interpreter per se, but we do like the idea of taking G-code output from your favorite CNC path generator and post processing G0/1/2/3 to produce a time-based cam output that we can feed into our existing cam solver. The basic workflow we envision is a) make some G0-3 toolpath code, b) run through a DmD-based utility to produce a file we speak, and c) point a Do-more instruction to that file and 2 or 3 axes to do a coordinated path.
Questions:
1. Does that sound useful?
2. Is G-code the preferred source?
3. Are codes G0-3 adequate for most applications?
4. If this doesn't sound viable, what would make it so?
-
You really are bored.
I had to go look up the G-codes just to recall that, yes, those are the ones I used when I was playing with CNC. I really need to finish those (personal) projects.
I have customers that run CNC machines every day, but they have industrial machine tool controls. I am drawing a blank at where I would need this capability in my day job type work. I reckon that means I won't be much help to you.
-
In discussions we've had with a few users, we feel that there is a middle ground between simple single axis stepper control and full multi-axis CNC where a PLC with a decent X/Y path control could play. So that's what we're trying to determine: if a PLC could do 2 or 3 axis coordinated path control, is that useful, and does our approach sound viable?
We don't want to waste time creating stuff folks don't want, nor do we want to miss the mark enough to render the feature unusable. We feel it is viable to implement though, and would love to do it if some of our resident motion experts tell us it is useful.
So sound off!
-
that would really be helpful if you did the x/y coordinated motion. We do it all the time, but we us IAI actuators to do this. This can be very expensive. I certainly would be interested if Hosteng developed such a system.
-
Let's see if I can stir up some discussion...
We are looking to add some coordinated motion to a future product. We have already implemented electronic gearing, axis following, and camming. Those that have played with it like what we have done...however...one area of weakness is in multi-axis paths. It can be done with multiple cams tied to a single virtual axis, but there is no good way to control the master axis in such a way as to optimize the slave execution time and/or tangental velocity (tool speed). So we need a multi-axis path instruction that can optimize for slave axis constraints.
We don't envision this being a G-code interpreter per se, but we do like the idea of taking G-code output from your favorite CNC path generator and post processing G0/1/2/3 to produce a time-based cam output that we can feed into our existing cam solver. The basic workflow we envision is a) make some G0-3 toolpath code, b) run through a DmD-based utility to produce a file we speak, and c) point a Do-more instruction to that file and 2 or 3 axes to do a coordinated path.
Questions:
1. Does that sound useful?
2. Is G-code the preferred source?
3. Are codes G0-3 adequate for most applications?
4. If this doesn't sound viable, what would make it so?
I haven't run into any of these apps myself, but I do see people doing things that, if I were doing them, I'd use a Do-More with this capability, so my guess is there is a market. No idea of the size of the niche between independent or simply-cammed axes and full CNC.
-
I have customers that run CNC machines every day, but they have industrial machine tool controls. I am drawing a blank at where I would need this capability in my day job type work. I reckon that means I won't be much help to you.
The first thing that occurred to me were machining-like operations in applications that don't demand the precision or robustness of an actual CNC machine. Carving big letters out of styrofoam with a hot wire and two axes of motion for example. Possibly CNC plasma cutting sheet metal for HVAC shops. I'm sure they're using something proprietary for this now, but it looks like something where you could use a path-controlling Do-More if you're the OEM or want to build one in-house.
-
The first thing that occurred to me were machining-like operations in applications that don't demand the precision or robustness of an actual CNC machine. Carving big letters out of styrofoam with a hot wire and two axes of motion for example. Possibly CNC plasma cutting sheet metal for HVAC shops. I'm sure they're using something proprietary for this now, but it looks like something where you could use a path-controlling Do-More if you're the OEM or want to build one in-house.
Plasma cutting was one of the specific requests mentioned. Fairly crunchy operations that don't require the precision of true CNC, but do require multi-axis path control. My gut tells me there are a bunch of apps like this that are being handled by much more expensive equipment than required.
-
Ginormous 3D printer! :)
-
I think I have a little experience at this level of discussion. I am currently active on the Practical Machinist, Mach 3, Home Shop Machinist, CamBam, and Reprap forums, worked as CNC programmer, bought the CNC in our shop.
I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. It also controls printer bed temperature and extruder head temperature.
A couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. I moddled the rack in SolidWorks, programmed the shop CNC using CamBam to cut out the 144 holes and then imported the same geometry into a cheap TopCNC TC55H CNC controller. 3 axis of control to move from a drain port to each tube and a 4th axis running a peristaltic pump to pull the sample and accurately dispense into the test tubes. Works quite well except all programming is G-code only.
The problem with the inexpensive CNC controllers is that G-code does motion well but is very poor at user and I/O interfacing. The high end ones often have a completely independent PLC for I/O as well. I can't start the sampler from an external input. Recovering from a power failure is not possible. The only timing function is a pause. Things like tool changers need logic that G-code is poorly suited to and an axis or two of motion control makes the task much easier.
So I think if you offered some basic multi-axis motion commands there could be jobs I'd use it for. We built the sampler for inhouse use, but a number of people have already asked if we would consider selling them. We'd need better controller for that. It has to be standalone, can't run on a PC.
-
Gary, I think you are going to have to bring a little more to the table than that...
;D
-
I think I have a little experience at this level of discussion. I am currently active on the Practical Machinist, Mach 3, Home Shop Machinist, CamBam, and Reprap forums, worked as CNC programmer, bought the CNC in our shop.
I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. It also controls printer bed temperature and extruder head temperature.
A couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. I moddled the rack in SolidWorks, programmed the shop CNC using CamBam to cut out the 144 holes and then imported the same geometry into a cheap TopCNC TC55H CNC controller. 3 axis of control to move from a drain port to each tube and a 4th axis running a peristaltic pump to pull the sample and accurately dispense into the test tubes. Works quite well except all programming is G-code only.
The problem with the inexpensive CNC controllers is that G-code does motion well but is very poor at user and I/O interfacing. The high end ones often have a completely independent PLC for I/O as well. I can't start the sampler from an external input. Recovering from a power failure is not possible. The only timing function is a pause. Things like tool changers need logic that G-code is poorly suited to and an axis or two of motion control makes the task much easier.
So I think if you offered some basic multi-axis motion commands there could be jobs I'd use it for. We built the sampler for inhouse use, but a number of people have already asked if we would consider selling them. We'd need better controller for that. It has to be standalone, can't run on a PC.
So, yeah, I'd put you in the 'expert' class. ;)
We have already implemented a few basic coordinated functions for the new platform, but we don't have a great approach for multi-axis path control, hence the query.
Currently support three physical axes and one virtual. Three coordinated instructions:
1. AXGEAR - simple electronic gearing with live variable ratio.
2. AXFOLLOW - slave follows master at a fixed ratio, and can do dynamic relative adjustments on the fly.
3. AXCAM - slave follows master as defined by a position cam. Up to 64 points on the cam, with cubic interpolation. Linear or rotary mode.
I want to add AXPATH, which is essentially G0, G1, G2, G3, and perhaps even G4...assuming that's enough to do what we need. Probably support feed rate code as well, so it can be changed on the fly.
-
I am a little confused about F code, though. I've seen some CAM software that generates F code on a per axis basis, i.e., F100XY or F30Z. I would think F would be defining tangential velocity (absolute velocity of the tool relative to the material), and not the velocity of a particular axis. Although I guess that could be describing tangential velocity of the XY plane, and then treating the Z tool plunge independently. Just trying to wrap my head around this, and hopefully come up with a useful expression on the PLC. Any feedback from our local experts welcome.
-
I think I have a little experience at this level of discussion. I am currently active on the Practical Machinist, Mach 3, Home Shop Machinist, CamBam, and Reprap forums, worked as CNC programmer, bought the CNC in our shop.
I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. It also controls printer bed temperature and extruder head temperature.
A couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. I modeled the rack in SolidWorks, programmed the shop CNC using CamBam to cut out the 144 holes and then imported the same geometry into a cheap TopCNC TC55H CNC controller. 3 axis of control to move from a drain port to each tube and a 4th axis running a peristaltic pump to pull the sample and accurately dispense into the test tubes. Works quite well except all programming is G-code only.
That's it?? :D
-
I am a little confused about F code, though. I've seen some CAM software that generates F code on a per axis basis, i.e., F100XY or F30Z. I would think F would be defining tangential velocity (absolute velocity of the tool relative to the material), and not the velocity of a particular axis. Although I guess that could be describing tangential velocity of the XY plane, and then treating the Z tool plunge independently. Just trying to wrap my head around this, and hopefully come up with a useful expression on the PLC. Any feedback from our local experts welcome.
F is just feed rate along a path whether it be 1,2, or 3 axis interpolated. An F5 G1 X1 Y1 Z1 move would be a path the diagonal of a cube at a rate of 5 along that line. Ussually if there is a separate feed rate for the Z axis it is a convenience thing for canned drill cycles so you don't have to keep changing a single feed rate.
-
Feed rate is a must for g-code motion. Also G0 rapid would be nice. Multiaxis rapid motion is ussually a dog leg. Each axis runs at the same high rate, so an axis with a shorter move will finish first, and the others will continue moving. A G4 on most system is a pause time not a move.
Someone mentioned 3D printers. The g-code for that far exceeds the memory of almost any PLC. I've cut some simple 3D shapes that took 80,000 lines of G-code, but a 3D printer program can easily run to millions of lines.
-
I think I have a little experience at this level of discussion. I am currently active on the Practical Machinist, Mach 3, Home Shop Machinist, CamBam, and Reprap forums, worked as CNC programmer, bought the CNC in our shop.
I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. It also controls printer bed temperature and extruder head temperature.
A couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. I modeled the rack in SolidWorks, programmed the shop CNC using CamBam to cut out the 144 holes and then imported the same geometry into a cheap TopCNC TC55H CNC controller. 3 axis of control to move from a drain port to each tube and a 4th axis running a peristaltic pump to pull the sample and accurately dispense into the test tubes. Works quite well except all programming is G-code only.
That's it?? :D
No. But real work interferes at times.
-
Someone mentioned 3D printers. The g-code for that far exceeds the memory of almost any PLC. I've cut some simple 3D shapes that took 80,000 lines of G-code, but a 3D printer program can easily run to millions of lines.
One option will be streaming from files on the SDCard. Quite sure that you'll be able to fit what is needed. That certainly isn't our market target though.
-
A couple other thoughts. G0 and G1 are modal, once called all motion occurs at rapid for G0 or feed rate for G1 until you call the other. G90 and G91 are important, G90 is absolute motion from a defined origin, while G91 is incremental from the last location. This also concerns G2 and G3 and how the arc center point is defined. Typically using I,J,and K respective to X,Y, and Z. Then various systems use either incremental or absolute referencing for I,J, and K. You don't need both but you have define one or the other.
Just had a great thought. Download the full version of CamBam and use it to create some G-code using any of the post processors supplied. Then you can see exactly how a drawing gets processed into G-code. It costs $150 but you can install it and run it free for 40 sessions that last all day before it reverts to a limited demo mode. I think you'll learn what is needed and what is not much quicker that way. It'll also generate test code if you decide to move forward.
-
Another Hostie is a full blown machine tool guy, and he has one or more packages. Not sure which, but I'm sure I can get what I need. Will definitely look into CamBam as well.
It's probably an irrelevant implementation detail, but we won't be running G-code at the PLC. My current plan is to have a conversion utility that will read G-code and convert to what amounts to a time-based multi-axis position cam; the master axis 'position' will be microseconds, which will drive up to three slave position cams which are utility-generated to give you coordinated motion at the specified feed rates. As far as you are aware, you are running G-code, but this approach allows me to use the existing cam solver to do very complex stuff with almost no computational hit.
That also gives me the luxury of continuing to enhance the conversion utility over time, with no changes to the firmware. We'll be able to add as many codes as makes sense. PLC won't know or care in the slightest.
-
Modality is interesting. The files I've been playing with use a G1 or G0 on every line, but I have seen others that did G0 or G1 with axes on one line, then just axes on subsequent lines. That isn't hard to parse, but it implies that each line is a single command and must be well-formed within the line. That's a different parsing approach to languages like C where line breaks really don't matter, but of course there is no modality concept in C.
And all of this is made ever more fun given how 'standardized' G-code is. ::) I'll probably pattern after a well known and well supported open source target like grbl. If I can see the parser code I stand a better chance of not messing my implementation up. In the end, I don't guess it matters as long as most CAM packages have post processors for whatever we choose.
-
Lots of G-code stuff comes from the old paper tape days, and then really underpowered CNC controllers. Modality saves memory, lots of CNCs work fine without line numbers too. I used to program a Bandit controller. 4 digital numeric displays, X,Y,Z and G-code or M-Code number and some red lights indicating G, M, F etc. Really user friendly.
The other space and programmer saving things were canned cycles, like G80,G81,G82, which were drilling cycles that did depth,peck, chip break and such. Then there were G70-G79 range cycles for things like circular pockets, rectangular pockets, mirroring, rotation about an axis and such. When writing code by hand these things kept you from going completely mad as the code that would replace them would be thousands of lines. The G40, G41, G42 codes do tool radius offsetting. That was nice because you could program a 2" square pocket and cut it to size by calling up a tool number and radius, and the toolpath would move over to compensate. Subroutine calls were useful too. No standardization on that at all! One machine I worked on, a Fadal actually used MBasic for macros!