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. Recovering from a power failure is not possible. I can't start the sampler from an external input. The high end ones often have a completely independent PLC for I/O as well. The problem with the inexpensive CNC controllers is that G-code does motion well but is very poor at user and I/O interfacing. Works quite well except all programming is G-code only. 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. 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. It also controls printer bed temperature and extruder head temperature.Ī couple of weeks back I bought a Chinese 3020 router and built a test tube rack for it. A DL06 handles all the button functions, switches between the R8 spindle, router spindle, lathe spindle and 3D printer extruder. I built my own 4 axis CNC in my garage running on Mach 3 with a motion card. 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 think I have a little experience at this level of discussion. Quote from: BobO on December 25, 2016, 05:06:03 PM Let's see if I can stir up some discussion. If this doesn't sound viable, what would make it so? Are codes G0-3 adequate for most applications?Ĥ. 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.ģ.
#Cambam 4th axis generator#
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. So we need a multi-axis path instruction that can optimize for slave axis constraints. 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). Those that have played with it like what we have area of weakness is in multi-axis paths. We have already implemented electronic gearing, axis following, and camming. We are looking to add some coordinated motion to a future product.
0 kommentar(er)
