Unanswered CHOOK SDK questions

[Robert Brower]

Greetings,

 

We're developing a CHOOK that automates the generation of NC using mastercam for a completely new machine equipment and we have made some progress, but we are struggling with a few things.

 

There are roughly 6 issues that i need to resolve in order for this new kind of machining tool to work.

 

1. Although I have obtained the chaining word document from the ftp site, it is missing a function or 2 so although we can easily navigate through our geometry, selecting, or coloring entities automatically, we cannot get proper chains using the source code provided in that document. The document is incomplete, we're looking for the missing function.

 

Additionally, we need to be able to import 5 axs curve operation, and through our geometry walking algorithm, we need to be able to automatically select and add curves and surfaces to the operation. I have been working with the SDK surface_manager() function but I haven't gotten the results I need in order to proceed.

 

2. We need to be able to automate the setting of the CPlane and TPlane. Currently our software executes a PushKey command in the places where we haven't been able to figure out the SDK. We can select an entity, we want to be able to set the CPlane and TPlane to an arc for example, using the SDK, with no clicking.

 

3. We're importing operations from our library. One of them is a horizontal milling operation that was created with the CPlane and TPlane set to a specific arc. By clicking T/CPlane button in the operations parameters dialog we're able to set the operations view to the appropriate one, but we need to be able to automate this using the SDK.

 

4. I have not found a SDK function which will allow us to close mastercam.

 

I know this probably sounds like a lot, but in actually it is a small ammount of unanswered questions which are keeping us from using mastercam to the extent that we had hoped for.

 

We're looking for C++ examples for these issues, or more SDK examples, as there are some we could not find, e.g. surface_manager().

 

I took a cursory look at ATP and i was somewhat dissappointed in that it will not help us.

 

Our main problem in general is that we want to use the SDK to automate a proprietary process and we cannot allow user interaction. We're struggling. Could anyone offer any support with these CHOOK SDK questions please.

 

Thank you,

 

Robert Brower

[Fig sign]

Out of topic - have you tried ATP vbscript

for automatic toolpath generation ?

[Günther Massimo - GMCCS]

quote:

---

4. I have not found a SDK function which will allow us to close mastercam.

---

Try to send a WM_CLOSE message to the main window.

[bryan314]

quote:

---

We're struggling.

---

Join the club. I have a nice dent in the concrete wall next to my desk from banging my head in frustration.

 

1. The chaining example is incomplete. If you want to use it 'as is' you'll have to write the functions yourself. The better options is to use it to understand the chaining itself and write your own function to fit your application.

 

1.b. Don't know, I stay as far away from surfaces as I can.

 

2. look in m_math.h a lot of view stuff is in there. find_view_from_ent, find_view_m, find_view_k, get_view_matrix, make_view_k, etc

 

m_vars.h: constr_view_n, gr_view_n, tool_view_n, cur_cview_ent, cur_tview_ent, cur_gview_ent, WCS

 

m_assoc.h: named_view_manager

 

There's more but you'll have to poke around.

 

3. set the op_view structures in your operation. op.tpln and op.cpln. Also look into operation_manager specifically OPMGR_INIT. You can init a 'dummy' op and it'll set a lot stuff for you. Like initializing t/c planes to current t/c planes.

 

4. No 'nice' way that I know of from inside mastercam. I don't even see a file-exit function you could call with execute_func. I like Gismo's idea of sending WM_CLOSE.

 

Hope that helps.

 

Bryan

[Robert Brower]

Nice, thanks for the responses.

 

Iskander, Thanks for the suggestion about ATP. I looked closely at it but it doesn't perform the automation to the extent that we need. We don't want to even see mastercam if at all possible. We want ~everything~ to be automatic. It's a bit unautomated... for an automation tool. it introduces yet another GUI to the user, this is unacceptable to us.

 

Gismo, sending WM_CLOSE to mastercam makes mastercam really unhappy, causes a access violation. Perhaps it was the way that i was getting the mastercam window, AfxGetmainWnd(). FindWindow(), a dated WIN32 function would get it, but it is not guarunteed. I appreciate your advice though, and I will try that again in some different ways.

 

I attempted to fill in the blanks for the chaining example but would it be too much to ask for the person who posted that document to the FTP site to also post the missing function? My function isn't doing what I thought it should do and chaining is not working.

 

As for solids... ... really at a loss here... in an extreme pinch and desperate, i could send key strokes to mastercam, for adding surfaces to the 5 axis curve, but that would defeat the whole purpose of what we're doing. Additionally, many of the dialog boxes in mastercam do not seem to use the idea of tab order in the dlg resource and although I can send a TAB TAB TAB, etc. to the dialog, it tends to be extremely unreliable, especially from machine to machine. In other words, even through sending key strokes to the 5 axis curve dialog, it doesn't work.

 

We bought mastercam after reading about its automation capability, and I have to admit that the things that we have working really help but without complete unattended automation, we'll have ~less~ use for mastercam as part of this OEM machine solution.

 

Thanks for the feedback... I am going back to the big dented thing in the corner, that thing I call my desk.

 

have a good one!

 

Robert

[bryan314]

...but would it be too much to ask for the person who posted that document to the FTP site to also post the missing function?

 

Sometimes it's like trying to get blood from a stone to get MC to provide example for the SDK.

 

If you want a 'dirty' way to close mastercam call the C exit() function.

code:

---

exit(EXIT_SUCCESS);  

---

This is a rather abrupt way to close mastecam and may cause problems. For example: if there is a chook using m_open instead if m_main as the chook entry point, so the chook can run continuously in the background, Mastercam doesn't have the chance to call m_close for the chook and allow for any clean up. Like releasing allocated memory and causing a memory leak.

 

Bryan

[Robert Brower]

Bryan, you said: This is a rather abrupt way to close mastecam and may cause problems. For example: if there is a chook using m_open instead if m_main as the chook entry point

 

This is the case for me bryan. My chook comes in 2 parts.

 

1. a modeless, invisible dialog CHook that is configured to start when mastercam starts.

 

2. an activex control for which my VB and c++ apps can speak to the chook via shmem.

 

Would be slick if I can address all of my problems. Back to the grind.

 

Thanks again.

 

Robert

[Günther Massimo - GMCCS]

quote:

---

Gismo, sending WM_CLOSE to mastercam makes mastercam really unhappy, causes a access violation. Perhaps it was the way that i was getting the mastercam window, AfxGetmainWnd(). FindWindow(), a dated WIN32 function would get it, but it is not guarunteed. I appreciate your advice though, and I will try that again in some different ways.

---

Use PostMessage instead of SendMessage and make sure you return immediately from your chook.

BTW you can access the Mastercam main window with MainWnd.

You have to declare MainWnd as extern in your header file. It's an undocumented variable

 

I can mail you a little chook that closes MC.

[bryan314]

Based on Gismo's comments, this works as a 'safe' exit for me. This allows MC to call m_close when m_open is used. Since you seem to be using MFC/C++ it'll probably need be changed slightly.

 

Bryan

 

 

code:

---

 void your_function(void)

{

HWND mc_handle = (HWND)dbm_get_mainwnd_id();

if(mc_handle != NULL)

{

/* remove 'MC9 file has changed. Save it?' dialog box.

changes since last file save are lost */

set_db_unchanged();

 

/* send exit command */

PostMessage( mc_handle, WM_CLOSE, 0,0);

 

/* answer yes to 'Do you really want to exit Mastercam' dialog box */

#ifndef VK_Y

#define VK_Y 0x59 /* not always defined */

#endif

keybd_event( VK_Y, 0, 0, 0 );

return;

}

 

/* debug */

cleartextall();

mprintf("can't find MC EXE handle.n");

wait_for_space();

cleartextall();

/* debug */

 

}

---

[Bullines]

quote:

---

Since you seem to be using MFC/C++ it'll probably need be changed slightly.

---

Very few changes. AfxGetMainWnd()->PostMessage() instead of PostMessage(). mprintf() call could be substituted with AfxMessageBox() but no biggie.

 

Kewl stuff, bryan

[bryan314]

Thanks. mprintf is just for debugging, enter your error handling of choice.

 

+1 post count

Bryan

[Robert Brower]

Thanks men. I appreciate it. I will probably have more questions later. Do either of you know of any forums, usergroups, or IRC where people who are developing chooks can network about chooks specifically?

 

Robert

[Bullines]

quote:

---

Do either of you know of any forums, usergroups, or IRC where people who are developing chooks can network about chooks specifically?

---

Here

[bryan314]

Here The best responses I've got from other members and MC employees is just asking specific questions like you did.

 

Bryan

[Robert Brower]

Excellent & thank you,

 

I have a few more:

 

1. In the absence of automatic chaining via the SDK (don't have it working), I would like to be able to hide all entities of a given type, surfaces for example. This will make it easier for the user to click on the splines and arcs that I am turning different colors that comprise my chains. With all the surfaces visible it is extremely likely that mis-clicks will happen.

 

I tried to call set_sel_bit_on() and set_sel_bit_off() using BLANK_BIT and rewriting the entity to the db, but it seems to have very strange behavior and doesn't work to show or hide anything.

 

2. I'm using nci_manager to post all the operations that I am creating dynamically. Even though I have my screen | configure settings such that it should overwrite and not ask, it still pops up bothersome dialog boxes for save, overwrite, and delete previous.

 

I tried setting post_dlg_settings structure members but this structure has no impact on posting through nci_manager() function.

 

Is there a way to suppress all these dialogs when usign nci_manager() function to post all operations? If not, is there a slick workaround?

 

I appreciate your time and hope to return the favor.

 

Robert

[Bullines]

quote:

---

2. I'm using nci_manager to post all the operations that I am creating dynamically. Even though I have my screen | configure settings such that it should overwrite and not ask, it still pops up bothersome dialog boxes for save, overwrite, and delete previous.

---

If you're posting each op individually using postOps(), you can use a post_dlg_settings structure to define how you'd like to post. For example:

 

code:

---

post_dlg_settings compnci_post_settings;  // post settings

 

// configure posting settings

compnci_post_settings.save_nci_file = TRUE;

compnci_post_settings.overwrite_nci = TRUE;

compnci_post_settings.save_nc_file = FALSE;

compnci_post_settings.overwrite_nc = TRUE;

compnci_post_settings.send_to_machine = FALSE;

compnci_post_settings.editNCI = FALSE;

compnci_post_settings.editNC = FALSE;

compnci_post_settings.export_oplist = TRUE;

compnci_post_settings.export_prm = TRUE;

compnci_post_settings.wcs_1014 = FALSE;

compnci_post_settings.descriptor = FALSE;

 

// post an op

postOps(&compnci_post_settings, szYourPST, nc_prefix, FALSE, FALSE);

---

HTH

[bryan314]

1. Setting the blank bit is probably equivalent to screen-blank, probably not good. I don't remember any function for directly manipulating screen-hide equivalent but you can probably manipulate the display_list structure in m_vars.h. I can email you some code that might get you started if you're interested.

 

2. I use a combination of postOps and run_post_exe_dll to bypass those annoying boxes for a custom multipost chook. postOps to generate the nci file. run_post_exe_dll to run that file through multiple post processors. I found if you want to use postOps multiple times on one op it regenerates the nci code each and every time. doh. A real pain if you're posting a crap load of surface operations. The only gotcha I had with postOps was to backup the current post_settings variable and then restore them when I was done or postOps overwrote the current users posting settings for that session.

 

Bryan

[Robert Brower]

Bryan,

 

'I can email you some code that might get you started if you're interested.'

 

Oh yeah, thank you! [email protected]

 

Thanks for the tip on postOps and run_post_exe_dll. I will have to look into this on monday.

 

Robert

[Robert Brower]

So far so good. MC is closing when I tell it to, and i've eliminated a lot of user interactions. postOps() is delicious automation sweetness.

 

I have initially one operation, a horizontal milling op. I make several copies and change the depth parameter for each copy to cut a slot to some width. In regards to postOps(). Does this function post one or all operations in the operation manager?

 

In regards to setting the CPLANE and TPLANE of an operation, it seems that the operation is being rewritten, because I can see the comment I set in the operation structure taking effect, but setting the tpln and cpln view_n member does not want to stick. I am missing something here?

 

When I created my op lib, I used CPLANE = TPLANE = named view #9. This is the what I would like my operation to use, before I copy it into new operations.

 

Thanks again for your valuable time!

 

Robert

[Bullines]

quote:

---

In regards to postOps(). Does this function post one or all operations in the operation manager?

---

postOps() posts one operation at a time like this:

 

code:

---

op_list *op_ptr;

db_ptr_type ent_ptr;

 

 

// go to beginning of the operations linked list

list_manager(OP_ID, "", LSTMGR_GET, &op_ptr);

 

// loop through all available operations in the linked list

while(op_ptr)

{

// get the operation

operation_manager(&(op_ptr->op), OPMGR_GET, &ent_ptr, &bSuccf);

 

// post the operation

postOps(&your_post_settings, szYourPostPath, nc_prefix, FALSE, FALSE);

 

// next operation

op_ptr = op_ptr->next_ptr;

}

---

To post all selected operations, you can use run_post_exe_dll().

[Robert Brower]

Thanks Bullines! Exactly what I was after. Any idea why the operation's tpln and cpln view_n member doesn't take when I rewrite the operation?

 

Does the list manager supercede the operation manager function? Seems there is more than one way to skin this cat lol

 

Thanks,

 

Robert

[Robert Brower]

Still making decent progress.

 

I noticed with postOps() that I must re-specify the ~full~ path to the .PST file in the while loop, otherwise it's shortened automatically to just the filename and not the full path, and MC asks for the name of the post file in a popup on subsequent loops.

 

I'm not sure about run_post_exe_dll(). Specifically not sure about what I would pass in as an exe or dll name.

 

The advantage to using run_post_exe_dll(), I am guessing is that you get one NC file as opposed to one NC file per operation. I'm not completely opposed to getting an NC file per operation since we will be doing some special post processing of these files anyways. But it would be cool to at least see how that function works.

 

I do not understand why if I have specified edit NC and edit NCI = FALSE why the silly text editor is ~still~ popping up.

 

And if I can figure out why my op.tpln.view_n and op.cpln.view_n are not being updated when I rewrite the operation then we will be laughing.

 

All good stuff. Thanks for your inputs!

 

Robert

[Bullines]

quote:

---

I'm not sure about run_post_exe_dll(). Specifically not sure about what I would pass in as an exe or dll name.

---

There's a Mastercam variable declared in m_ncvars.h, called post_exe_filename, that holds the name of the Post Processor executable (mp.dll, mpl.dll, etc...). So if you want to use the default post executable, you can call run_post_exe_dll() like this:

 

code:

---

char szYourNCI[_MAX_FNAME];

char szYourNC[_MAX_FNAME];

char szYourPost[_MAX_FNAME];

 

/* Assign your paths to szYourNCI, szYourNC and szYourPost.

Yes, those are FULL paths, like you discovered

*/

 

run_post_exe_dll(post_exe_filename, szYourNCI, szYourPost, szYourNC);

---

quote:

---

I do not understand why if I have specified edit NC and edit NCI = FALSE why the silly text editor is ~still~ popping up.

---

Make sure you have the "overwrite" members of the struct set to TRUE:

 

code:

---

post_dlg_settings your_post_settings;

 

 

your_post_settings.save_nci_file = TRUE;

your_post_settings.overwrite_nci = TRUE;

your_post_settings.save_nc_file = TRUE;

your_post_settings.overwrite_nc = TRUE;

your_post_settings.send_to_machine = FALSE;

your_post_settings.editNCI = FALSE;

your_post_settings.editNC = FALSE;

your_post_settings.export_oplist = TRUE;

your_post_settings.export_prm = TRUE;

your_post_settings.wcs_1014 = FALSE;

your_post_settings.descriptor = FALSE;

---

Keep in mind that post_dlg_settings structure does not apply to run_post_exe_dll(); only postOps().

 

Does that work?

[Robert Brower]

llines,

 

No, it doesn't work. The post_dlg_settings structure is set exactly as you said. The programmer's editor is still popping up. I'll try the run_post_exe_dll() and see if that gives me what I want.

 

Robert

 

[EDIT]okay I think I know what is going on here. First I must postOps with save NC = false, one time for each operation. After I call postOps() I have to rename the NCI file it creates, then run_post_exe_dll() on that NCI file.

 

either that or.. It's saving T.NCI by default. I must find out where "T" is set as the default NCI base filename and change it as needed for each postOps().

 

[ 12-14-2004, 01:38 PM: Message edited by: Robert Brower ]

[Robert Brower]

no, now post_run_exe_dll() is causing the programmer's editor to open. good grief. I went in a full circle. great to be alive!