I've done too many to list (over 50) but some highlights. Multiple file merge. Mastercam only allows you to merge one file at a time. A real pain when you have to merge 40 or 50 plus files in a directory. Automatic toolpathing. Mainly drilling but some hole contouring. Custom multiposting. A chook to show all (relevant) parameters for all operations displayed on one page. A html file actually. Also performs a bunch of sanity check on the ops and highlights the areas that need looking at. Like drilling past z0.0 when its the bottom of the steel / top of the table. a whole crap load of chooks dealing with view creating, display and manipulation. One example is a drop down menu with each submenu a user define filter (regexp) for named planes. Which then sets the tool/const/gview planes. Simplier than going in view manager all the time. 2 clicks and t/c/g planes are set. Designer and Toolpather created name planes can exist in the same file without cluttering each other. Several for prepping a file before toolpathing. Automating the couple of dozen procedures done after a design is released and before its ready to toolpath. Orientation, creating toolplanes, insert patterns, setting up rawblocks, creating some empty op groups, etc. A insert pattern library (with user created drop down menus) with overrides for stuff like color and level. a template system that pulls data from a database and can be used to create notes. Or copied to the clipboard, which than can be pasted into setup sheets or other files. (We input most data about a part once and it's pulled many times. Cutting down on costly human error mistakes. ) Again presented in a drop down menu for easy access. A few for entity copy and move. 1. copy selected ents from one point to many points. 2. Rotate around two points. The two points define the axis to rotate about. Simpler than the rigmarole to creating a new cplane and then rotating entities. Select ents, select 2pts, enter angle, copy/move, done. 3. xform between (2 sets of) 3 points. Compresses xform translate between points, xform rotate, xform between views into one chook. 1-3 points are used to define views to translate between. 1pt current view, 2pts current view with a rotation, 3pts defines a new view. Again saves the hassle of defining new views to translate between. select ents, select points, copy/move, done. Bryan

Just to clarify a bit. Parsing an NCI file is extremely easy. But what I think Roger means by a lot of work is there's a lot of raw data in the NCI. Much of which needs to be processed, calculated, and format. Ekke, If your minz doesn't have to be totally accurate you can just scan through the file and pull the z values from the G0, G1 and drill lines for each operation yourself. Bryan

You also might look into taking a beginning c/c++ programming class at a local community college. Community college's are pretty cheep and have night classes. It'll get you over the initial 'hump' of learning the language. Also, if you're lucky and it's job related, you can talk the boss into paying for it. Bryan

We've been using it as a simplified flat file database for years. Each piece of the die goes on its own level. Information about the detail is stored in the levelset. When it's ready for toolpathing the level is saved off and the information automatically goes with it. Surprisingly, you can store a lot of information in the approx. 200 characters. This is all done via chooks of course. Bryan

Zerren Gedeon, I've used your code as basis for a chook and I wish to put my chook and code up on the ftp site but I didn't see any kind of licensing stated in your files. Since my code is partially derived from your code do you have any problems with me putting this up? Are there any licensing statements you wish me to include? (ie GPL?) Or can I put a general 'public domain' 'do what you want' on it? Bryan

quote: How automated can all of this stuff really make Mastercam?a lot. I've seen chooks eliminate hours off of individual steels and days off of entire designs. On both the toolpathing and design side of things. quote: If there is such a time savings why does it appear that it is a major minority of users who are using them?Well for one writing a chook requires a knowledgeable programmer. Also Mastercams sdk, while getting better, is still a mess. The full api is missing and the documentation is spotty or outright missing is places. Also given the variation in industries, individuals, and companies it is nearly impossible to write a general 'program' that would be effective for everybody or even a small subset. Each program or chook has to be customized for each customer's need. Think custom postprocessor but a hundred times worse. quote: What can you do, what are people doing with them? Tweaking mastercam. Automatic toolpathing is a biggie. Automatically generating 'parts' from a variable list is another. Since a chook is just a program it can combined with any other kind of software. Scripting languages, web servers, data bases, tracking software, accounting software, simulation, etc. It's just data it can be exported, imported, created, processed, formated, saved, loaded, modified, etc. Just limited by your needs, mastecams api, and the programmers ability. Bryan

To get you started, from the file GrVars_CH.h in the c-hook sdk: code: /** * @defgroup gr_grp9 Graphics Background Gradient Defines * @{*/ #define GRADIENT_NONE 0 ///< None (use Graphics background color) #define GRADIENT_HORIZONTAL 1 ///< Horizontal #define GRADIENT_VERTICAL 2 ///< Vertical #define GRADIENT_DIAGONAL 3 ///< Diagonal /** @}*/ extern DllImpExp MC_BYTE gr_back_color; ///< graphics view background color extern DllImpExp MC_BYTE gr_gradient_start_color; ///< graphics view gradient start color extern DllImpExp MC_BYTE gr_gradient_end_color; ///< graphics view gradient end color extern DllImpExp short gradient_direction; ///< graphics view gradient direction You may need to call repaint_graphics(); or rebuild_graphics(); after changing the values. Bryan

James, sorry if I over-reacted. a bit of a touchy subject. quote: So....... Bryan. WHat kid of C-Hooks are you cooking up for X/X2??? Inquiring monds want to know!!! Right now I'm just trying to get a bunch of our 'internal' 9 chooks converted over to X. Luckily many of the 9 'regular' chooks are redundent in X so I can just ignore them. Ie right-click-mouse. As for new ones, haven't put much thought into yet. Our engineers are doing more with solids and had a few requests but seeing accessing or modifying a solid via a chook is NA those are now kaput. Bryan

James, I know you're joking. And that you're not insinuating anything. But please, even jokingly, don't associate me or my chooks with cracking. I too have taken enough heat over that-which-you-speak-of. It is a bug in mastercam. (a very very big bug) My chook has nothing to do with that. The same result can be accomplished through mastercam without my chook. It just makes the bug that much more visible. Bryan

ok, thanks Pete. Parasolids licensing issue, not yet implemented, or don't want Bryan to write a doing-something-kick-xxxx-with-solids chook? Bryan

Anybody got any idea how to edit an existing solid? I'm trying to familiarize myself with the solids portion of the sdk. I see the routines for creating (sld_new_primitive) and boolean operations (sld_new_boolean). But after they created I don't see anyway to go back and edit them. The entity structure (ent --> mc_solid_ent) only seems to refer to a parasolid id number. I can't find any functions for retrieving the info by referencing the id number. I don't see any way to go from selecting a solid ent, ie via select_ent, to editing and resaving it back. any help would be appreciated. Bryan

something like this will set all unselected operations to selected. I don't have my notes but for some reason I had to call operation_manager to force update something in the operation manager. code: op_list *opl; opl = op_list_ptr; while (opl != NULL) { if (opl->op.db.select_flag == FALSE) { MC_BOOL succf = FALSE; DB_LIST_ENT_PTR eptr; opl->op.db.select_flag = TRUE; operation_manager( &opl->op, OPMGR_REWRITE, &eptr, &succf); } /* next operation */ opl = opl->next_ptr; } bryan

select_ent will allow your user to select an entity. which you can then get the level information from. The other function probably prompts the user to select a level from the level manager. 2) just rename m_main to m_open. It's called the first time the chook is run. m_enter is called every time the chook is called after that. m_close is called when mastercam exits. When I use them my code is structured sorta like this: m_open -> initialization stuff; ie allocate memory. Call main chook code. m_enter -> call main chook code. m_close -> clean up. ie release memory bryan

Try setting select_color to red before calling select_ent with s_color TRUE. I'd backup/restore select_color's current value so not to have everything selected afterwards be red. In V9 s_color was described as a TRUE/FALSE setting and the description was changed (looks like incorrectly) to a 'color' description in X. Bryan

But you did pictures Bryan

I think it's time value. A quick and dirty (and probably wrong) explanation. Imagine one end of a line is 0.0 and the other end is 1.0. The t value is the point along that line the user selected. It's more usefull for splines where you get funky curves and such. Bryan

Sorry, I don't. I tried looking at the Mastercam.ft file but didn't see anything promising. Bryan

I'm seeing the following in MCX SP2. 1) create an entity. Line, point, arc, whatever. 2) turn the entity's level off. 3) undo 4) turn level back on. 5) the entity is still there. You now have to 'redo' and then 'undo' to get ride of it. I searched the forum didn't see anyone else with this problems. Is this a bug or 'feature' of Mastercam X. If it's a bug does anybody with MR2 see it also? Bryan

menu bar across the top of Mastercam. file edit view . . . Machine Type -> submenu --> Mill ->-> sub-sub menu --> default sorry for the confusion Bryan

If the function is successful the eptr just points to the memory mastercam allocates for the operation. It's short for entity pointer. Your op variable is just a copy of eptr->eptr.u.op check out the structures: db_list_ent_type (eptr) ent (eptr->eptr) operation (eptr->eptr.u.op) in 3dvars_ch.h Don't do any manipulations on the eptr directly unless you know what your doing (or even if you know) since it's a really quick and easy way to crash mastercam if you're not careful. Bryan

Groups_CH.H lists several different group functions list_grp_add_empty being one. Creating regular groups with these fucntions are quite simple. But creating a machine group this way will probably be a pain in the a**. There's probably a hidden "create group" function that you just feed a machine/control name into and it does all the correct initializations. One of the Mastercam guys can probably help with this. Or a way to set the default machine name and call post_FT_command with the function called by menu [mahchine type -> mill -> default] Bryan

quote: #why it is not declared??? What? A needed function not declared in the header files. Never. I don't believe it. 10 20 goto 10 C'mon Mastercam guys. It was one thing 5 years ago when there was only 3 big companies doing chooks (like moldpluss) but now there's dozens of us chook programmers. How about releasing the full header files to the sdk. What reason is there to keeping these hidden? Bryan

Never used the function myself. I'm assuming you already tried calling with 0 or 2 instead of one. 0=drive & check looks like you can designate a surf as check or drive. So shooting in the dark try flipping other sel bits. I'd try #define TEMP_BIT 0x40 /* bit 6 */ first.

You probably can just delete the entry in the registry using regedit. HKEY_CURRENT_USERSoftwareCNC Software, Inc.Mastercam XEditors Bryan

Now that MR2 is out when(if?) are we going to see a SP3 for non-maintenance for Bugs fixed since MR1/SP2? The bug fixes that where rolled up in MR2? And plese don't make me dig up the various comment by MC stating they wouldn't withhold bug fixes just because you did't buy maintenance. Bryan