Hi I was looking at Vectric Aspire 8 to get my gcode, but can't find the OX in the Post Processor list. If the correct one is there then whats it called. No good getting the FULL software (I'm messing around with the free version at present) and finding out later that the software doesn't include the OX in the list. Maybe it comes under a different name. Anyway, if someone has used this product to go from clipart to finished piece then could they give me some info on it before I take the plunge (scuse the pun). Michael. (centurian)
The post processor creates code that your BOB can interpret. So it's not necessarily the machine, but the machine controller. I would look for a generic Fanuc or Haas mill. You might be able to find a post processor for your controller from Vectric, your control supplier, or a third party online. If not then choose a generic mill and try it out. Joe
Thanks Joe Then that would be GRBL for me and I looked again at the list in Vectric and low and behold, there it was very small I almost missed it. Thanks for the help. Michael.
Cool. Thanks for asking the question. I'm sure others will ask it and find this post. Btw, post processors can be edited and updated. I've never done it and don't really understand what's happening on the back end myself. @David the swarfer could probably better explain this wizardry. Just keep in mind that anyone can run into machining problems that are post processor related. It can be easy to think that your machine isn't working right or you just suck at assigning automated tool paths. lol. Though problems are rare, the important point is that you know it's there and can be a variable when difficulties arise. One hypothetical is if the controller firmware gets upgraded and the post processor hasn't been. If you try an operation that utilizes new firmware functionality then it might not be in the post processor yet to take advantage of. In this case you might try other developed PPs and have success. GRBL is NIST based so you shouldn't have too much troubles with other post processors. One reason for all the options(aside from machine type) is that some manufactures have little variations in the way their machine tools operate. Another possibility is that the GRBL PP isn't fully developed to match the current firmware functionality....I know..basically the samething as above. Chances are good that if an advanced function is added to GRBL another well established processor can interpret the operation or functionality. Ranting again. Here is a nice article surrounding post processors and all of the intricacies and nuances surrounding them: www.cnccookbook.com/CCCNCGCodeDialects.htm Have fun. Joe
postprocessors, a possibly murky area (-: The idea is to separate the Gcode that suites a particular machine from the geometry in the CAD/CAM model. Since there is a standard for G-code, which allows for extensions to the language, many controller makers include many special features in the machine that need special custom G-codes to activate. On the other hand, simple controllers like GRBL only support the most basic codes so we cannot send GRBL any of the more complicated codes. For example HAAS VMC's have a tool length measuring device that can be used to check that the tool has not broken, in the middle of a job! This needs a special set of instructions included in the Gcode file to tell it to check and what to do if it fails (load a different tool, abort with alarm, etc) This poses difficulties for software that writes G-code. The complicated way is to cater for everything and then have options that the user can turn on and off as needed. LOTS of options! (SketchUcam uses this method, there are 'feature options' that change the way G-code is generated. For example holes can be bored using a depth first or a diameter first strategy.) The simpler way (for the user) is to have an intermediate 'language', halfway between the geometry and the G-code. This intermediate language contains all the primitives for tool changing, cutting, rapid moves, plunge,retract and so on. The postprocessor takes these primitives and translates them into G-code. This means that converting the geometry in the CAD to the intermediate language never changes, but the code used in the postprocessor can be changed easily to accommodate differences in tool changers, mill/laser/lathe etc. For example, in the drawing is a hole, the user has selected the correct drill as 'tool 14', and certain pecking depths and speeds etc. The intermediate language generates a sequence like this (in pseudocode, ie code I just invented now) fetchtool(14) retract(safeheight) startspindle(1200rpm) moveto(123,345) (an x,y position) drillhere(depth,peckdepth, safeheight, peckheight) stopspindle() The postprocessor language has a function for each of those words that translates those primitives into G-code to suite a particular machine. so, the fetchtool(14) for a HAAS could be just M5 T14 M6but for GRBL, which does not support tool change, you would need, something like; M5 ;stop spindle G49 ; cancel old tool length offset G53 X100 Y200 Z0 ; go to an absolute position where user can change tool M0 ; pause until resume and pray user inserts tool 14 G43.1 Z23 ; set length offset for this tool drillhere() for the HAAS might output one of the several flavours of G81/G82/G83 canned drill cycles while for GRBL we need to translate it into separate movements, here is an example from SketchUcam for a 10.5mm deep hole, 2mm per layer, quickpeck is active so only retract 0.5mm between layers. (plungebore DEPTH=10.500 DIAM=3.000) G00 Z0.500 G01 Z-2.000 F1000 G00 Z-1.500 G01 Z-4.000 G00 Z-3.500 G01 Z-6.000 G00 Z-5.500 G01 Z-8.000 G00 Z-7.500 G01 Z-10.000 G00 Z-9.500 G01 Z-10.500 G00 Z0.500 G00 Y42.055 Z5.000 (plungebore end) So, in short, the postprocessor translates the general cut commands into specific G-code that suites a particular controller. (aside: SketchUcam *can* output G81/G83 codes but so few 'hobby' controllers support this that it is still a hidden option that still needs a lot of testing). confused yet?
