Accessing Tool members

[Jure Klemencic from Camincam]

Please, help me to get to Tool members (properties) in NetHook 1.0 API in Mastercam X2 MR2.

 

I thought:

code:

---

opRef.operationTool.<Tool Member>

---

should work, but it doesn't.

 

Thank you.

[Mike Crivello CNC Software Inc.]

Jure,

 

That should definitely work, so long as there is actually a tool loaded into the operation. It's entirely possible that an operation may not have a tool associated with it yet or may have been just created and wouldn't have a tool loaded into it yet. If either of those things happen to be the case, then what you'll get when you access "opRef.operationTool" is a default tool.

 

If you're seeing something completely different, feel free to let us know...

[Jure Klemencic from Camincam]

Mike,

 

thank you for your answer. According to it the .operationTool doesn't work as it should. This is my (shortened) code:

code:

---

public override MC_RETURN Run(int param)

{

(int[] opList = all selected operations)

 

foreach (int opID in opList)

{

if (opID > 0)

{

COperationRef opRef = new COperationRef(0);

opRef.operationID = opID;

GUI.ShowString("comment " + opRef.comment);

GUI.ShowString("operationTool.toolComment " + opRef.operationTool.toolComment);

}

}

return (MC_RETURN.MC_UNLOADAPP);

}

---

When testing this code I always use a MCX file with clean Mill operations, all with regular tools. In this code the line opRef.comment works whereas the line opRef.operationTool.toolComment doesn't work. It results in this error window:

 

 

That's it. Thank you again for your help.

[Mike Crivello CNC Software Inc.]

Jure,

 

I'll take a look at it and see if I can come up with something for you. In the meantime, if you can answer this question for me it may help to shorten the debug time... is the 'operationTool' member null at the point where you reference the 'operationTool.toolComment'? Do you do any checking for it? Can you access anything else in the 'operationTool' member (slot, diameter values, etc.)?

 

 

I'll get back to you as soon as I can scrounge something up,

[Jure Klemencic from Camincam]

Mike,

 

I will try to answer you, but I can't debug my code so I don't see the values of my variables in every moment.

 

1. I don't know what the value of 'operationTool' is because whenever I try to reference it or ANY of its members, I get an error. If I say for example:

code:

---

opRef.operationTool.ToString()

---

I get an error.

 

2. I am not checking if operationTool is null.

 

3. I can't access anything in the 'operationTool' (slot, diameter values, etc.), even not the 'operationTool' itself.

 

Thanks for your help.

[rm_titus]

Hello guys,

 

I just did the same test and it appears the 'opRef.operationTool' member is always null.

Wrapping this in a try/catch block will return the reason of the exception.

 

On the other hand, I did notice that using

code:

---

	COperationRef opRef = new COperationRef(opID);

---

this will return a non null member.

 

Could this be a workaround in the meantime ?

 

--Titus

[Roger Martin from CNC Software]

A couple observations I noticed while looking into this...

 

This Test() will work – If the are Operations in the Op Mgr. with these Op IDs.

If you do this -> opRef = new COperationRef(opID);

And there is no operation with the passed opID, opRef will get created using ‘default’ operation data, but... the member opRef.operationTool will be null.

As you already know... So you must check for that situation.

 

code:

---

public void Test()

{

int[] opList = { 1, 2 }; // We assume that we have these Op ID's

 

COperationRef opRef = null;

foreach (int opID in opList)

{

opRef = new COperationRef(opID);

if (opRef != null) // just in case

{

GUI.ShowString("comment =" + opRef.comment);

if (opRef.operationTool != null) // it could happen!

{

GUI.ShowString("operationTool.toolComment =" + opRef.operationTool.toolComment);

}

}

}

}

---

If you want to find data by using the COperationRef(string name) constructor,

Even if an operation with this “name” does exist, the opRef.operationTool member will be null.

But... now you have an OpID (in the operationID member) you can use to ‘re-construct’ opRef using a call to the COperationRef(int number) constructor.

Note that opRef.operationTool could still be null after all of this, so you’d need to check for that situation – before trying to use it.

code:

---

         /// <summary>

/// Find an operation by 'name' and return the tool info for that operation

/// </summary>

/// <param name="name"></param>

/// <returns></returns>

public Mastercam.CToolRef GetToolData(string name)

{

Mastercam.COperationRef opRef = null;

Mastercam.CToolRef toolRef = null;

try

{

opRef = new Mastercam.COperationRef(name);

}

catch

{

return null;

}

 

if (opRef != null)// this should never be null, but...

{

opRef = new Mastercam.COperationRef(opRef.operationID);

if (opRef != null)

{

toolRef = opRef.operationTool;

}

}

return toolRef; // this could be null !!!

}

 

 

 

// --- NETHook Entry ---

//-----------------------

public override MC_RETURN Run(int param)

{

try

{

Class1 class1 = new Class1();

Mastercam.CToolRef toolRef = class1.GetToolData("test");

if (toolRef != null)

{

Mastercam.GUI.ShowString(toolRef.toolComment;);

Mastercam.Toolpath.EditTool(toolRef);

}

}

catch (Exception ex)

{

Mastercam.GUI.ShowString(ex.Message);

}

return MC_RETURN.MC_NOERROR

} // class NETHOOK

---

[Mike Crivello CNC Software Inc.]

Jure,

 

I think I may have an idea as to why this is happening for you. The 'name' field in a COperationRef class is a bit of a misnomer... what's displayed in the Operations Manager as the 'name' of an operation is actually a dynamically built string based upon the the operation's parameters and / or creation number. In that sense, what you see there isn't really a name so much as it is an identifier. The 'name' field in the COperationRef constructor is actually comparing against the operation's comments field, which used to be used as a way for user's to name and identify their operations from one another.

 

So in order to find a matching operation by name, it has to match whatever string is in the comments field of that operation. That would explain why the operation ref object you're getting back isn't what you expect. Now, that said you should still be getting back a default CToolRef object, so I'll take a look at that as well.

 

I'll get back to you...

[Mike Crivello CNC Software Inc.]

Jure,

 

Roger was dead on with the rest of it in his post above. Thanks Roger.

[Jure Klemencic from Camincam]

Thank you guys.

 

I used this code:

code:

---

COperationRef opRef = new COperationRef(0);

opRef.operationID = opID;

opRef = new COperationRef(opRef.operationID);

---

and now the .operationTool works fine.

 

BUT it works only with mill operations. In fact I am interested in lathe operations. I guess I will have to combine my managed code with some unmanaged C++ code in order to reach lathe tools. I will try that in future.

 

Now, I have questions concerning working with MS Excel. I find it easy to write strings to Excel, but I don't fully understand opening and closing XLS files. I used this code:

code:

---

Excel.OpenExcelFile("C:Test.XLS");

Excel.WriteExcelString("A1", "test");

Excel.SaveExcelFile("C:Test.XLS");

Excel.CloseExcelFile();

---

1. Why don't I see any Excel window open?

2. Why is there still an Excel process in computer's memory after this code finishes.

3. How to start a new Excel file instead of opening the existing one?

4. How to start a macro in Excel?

 

Thank you for your great help.

[Mike Crivello CNC Software Inc.]

Jure,

 

Let me see if I can tackle some of those questions for you...

 

1) The reason you don't see the Excel window open is because the API opens it as a process, sans any sort of UI.

 

2) That's a good question... in theory, when you call the Close method it SHOULD kill the process. There may be a problem there worth investigating...

 

3) I'm not sure if we've exposed enough functionality for you to be able to create a New file as opposed to opening an existing one. I can look into this for you. I suppose a good work-around in the interimn would be to save off a blank excel file and use it as a template for starting up Excel.

 

4) That is another case of functionality we simply haven't exposed through the API. That's a little more advanced, and I can't say for sure one way or another if that's ever something we would expose. However, if that's a must-have for you I'm sure .NET exposes a way for you to get more out of Excel from within your own app instead of accessing it via our API. Perhaps that would be a better solution for you in the interimn... ?

 

 

Hope that helps,