Showing results for 
Search instead for 
Do you mean 
Reply
Solved! Go to solution

Generate Material Removal Rate with NXOpen

Hi everyone,

 

I want to export the material removal rate to a file in excel. I found this thread that talks about the mrr : https://community.plm.automation.siemens.com/t5/Discussion-Forum-NX-Manufacturing/Metal-removal-rate...

My problem is that i don't know where I have to write these lines : 

# Save material removal rate to file
# UGII_CAM_WRITE_MRR="d:\users\rief\nx10\mrr.csv"

I tried to write it in the ugii_env.dat but when I ran the regeneration of the tool path with the Optimize Feed Rate command it didn't write anything in the file I specified.

 

The second question that I have is how do I use it with the journal ?

I would like to have a journal that change an operation (to use the Optimize feed rate command), generate the mrr data (by generating the tool path ?) to store it and undo the changes.

 

Can you help me ?

 

Regards,

18 REPLIES

Re: Generate Material Removal Rate with NXOpen

The variable needs to be defined before you start NX. There are may ways to do this, including the ugii_env.dat file. Start NX, and look at the syslog to be sure it has been defined. 

It's possible the variable only works with the RMB > Tool Path > Optimize Feed Rate command from the operation navigator, and not the toggle in the feeds and speeds dialog. Try the command from the navigator to be sure the text file is being written out. 

The journal should behave exactly as the UI. 

Mark Rief
Retired Siemens

Re: Generate Material Removal Rate with NXOpen

Thanks Mark for your help, indeed the variable only works with the optimize feed rate command from the op navigator.

 

I managed to get the data that I needed but I have several questions remaining. How is the file structured ? I attached a file genereted with the command. We can see in the second column the MRR but the numbers seems ... strange. I looked up in the NX help and in the NX API for a description of the file produced but I found nothing.

 

I recorded a journal in order to see how the command is used but I never saw a mention of the file location. Can we change the file location/name for the data to be send ?

 

Thank again for your time

Solution
Solution
Accepted by topic author MFrancois
‎05-07-2017 09:21 AM

Re: Generate Material Removal Rate with NXOpen

The data in your file does not look right. It should look something like this:

Length Material Removal Rate Volume Length Feedrate Optimized Feedrate
0.5 198169.235 495.4230874 0.5 200 161.4781427
1 202567.3609 506.4184023 0.5 200 161.4781427
1.5 220931.7737 552.3294342 0.5 200 144.8410949
2 200954.8682 502.3871705 0.5 200 144.8410949

 

The file location is part of the path in the variable. This is an unsupported debugging function, so there is no documentation or support.

 

Mark Rief
Retired Siemens

Re: Generate Material Removal Rate with NXOpen

Hello Mark,

 

Thanks for the quick reply.

I looked at the file produced in detail and I found that the weird numbers was the result of my windows configuration. I changed that and all is normal now.

 

I'm not a native english speaker so I'm not sure to fully understand this statement "The file location is part of the path in the variable."

Wich variable ? The one we declared in the UGII_env.dat ? So it is not possible to change the location of the file produced with journaling ?

 

Thanks again for your help

Re: Generate Material Removal Rate with NXOpen

[ Edited ]

I'm testing on the command and I have an issue with the file produced. The length doesn't change when I change the length interval. What am I doing wrong ?

See the 2 files attached for more information. Using NX 10.0.3

Re: Generate Material Removal Rate with NXOpen

The file location is part of the complet path in the variable UGII_CAM_WRITE_MRR. For example 

UGII_CAM_WRITE_MRR="d:\users\rief\mrr.csv"

My guess is that you are not writing to the file. I would set the variable BEFORE NX starts, sheck the syslog to see where it is pointing, generate the operation, RMB > Optimize, change length, and OK. Now lcheck the file and see if the date and time have changed.

Mark Rief
Retired Siemens

Re: Generate Material Removal Rate with NXOpen

[ Edited ]

I checked the syslog, I am writing in the correct file, the date and time change at each time I optimize the feed.

 

I did some more testing and I managed to have the length change for one operation. I tried many operation from different parts and there is only one operation that behaves like it should be. When I tried with other operations in the same part the length did not change. I am using a student license, does it have an impact on what I am able to do with this function ?

 

I attached the part that I used for testing, 2 xlsx files produced (I can't post CSV file on the forum) (first with data wich make sense, second with data that doesn't make sense) and the syslog file. If you need more detail/file to help me i will gladly give them to you.

 

I don't understand what is wrong in the way I'm doing these things. Why am I able to have the correct data for one operation but not for others ?

 

 

Thanks for the help, it's much appreciated

Re: Generate Material Removal Rate with NXOpen

I just tested with NX 11 and it worked without problem. Is this function bugged in NX10 or in my version of NX10? I have to use it with NX 10.0.3 is it possible to do so ?

 

Another question about the data produced : In NX11 I tried to optimize the feed with different options. In each data the total length changed and did not matched each other. For example, in the first test the length at the last line of the file was 135.96... In the second test the final length was 110.96... And when i check in the part, the cutting length is 170.8 .

So my question is : what does the length represent ?

Re: Generate Material Removal Rate with NXOpen

I can't answer your questions about what might have been fixed or why you are seeing different results. As I said, it is an unsupported variable that is used internally. 

FYI another thing that can affect optimize feed is the IPW resolution. Try a fine resolution, just in case that helps. 

Mark Rief
Retired Siemens

Learn online





Solution Information