You cannot download Mastercam. You should contact your reseller, see http://www.mastercam.com/ResellerLocator/Int.asp

Most recent vira include their own SMTP engine, so the response to an undeliverable e-mail would be received by the virus' SMTP engine, not the user's mail client, and the virus' SMTP engine will ignore failures, it will just keep sending to all the addresses it has collected. And it is not just sending to the addresses in the address book, it is sending to all addresses it can find on the infected machine, in a lot of different types of files. These files include the HTML cache, which is why addresses that are posted on the web, such as the sales@ addresses of companies, receive a large number of virus e-mails. That trick may have worked a long time ago, but it is useless now. Sorry to be a spoilsport, but useless countermeasures are worse than no countermeasures.

No Hardmill, it is not the same link. And it does not work, there is no picture. The first link you used contained this: /sessions/793371483418/ The second link contained this: /sessions/259721483418/ So it is not the same link. The 'session' part of the link suggest that it might be a temporary page, created by scripting. That would explain why it seems to work when you create the post (you have just created the temporary page, and might still be viewing it), and when you view you post after posting it (the temporary page has not been deleted yet). However, the temporary page has a relatively short TTL (time to live), so a short time after the last request for it from the server, the temporary page is deleted. I have no idea what he TTL is, my guess is anywhere between 5 minutes and 1 hour.

That picture looks OK, Toolfab. But then, the two links look different in the source code, too. Hardmill's link is: code: http://www.hpphoto.com/sessions/793371483418/33243920sm.jpg Your link is: code: http://www.hpphoto.com/servlet/LinkPhoto?G...72b&size=lg I think the conclusion must be, that the method you describe ('Create link for auction') is necessary, and that Hardmill did not use that method.

Hmm, when I look at the source code of Hardmill's post, there is an image link, but when I paste the URI to the browser I hit a redirect to a members login page. It looks like those pictures might only be viewable by people who are users of that HP thing (and presumably have a cookie set to reflect that)

The post is supposed to use the text file with the same file name (but the .txt extension), e.i. the post Mpmaster.pst is supposed to use Mpmaster.txt. However, the .txt file is not loaded if you change post from post dialog in the Operation Manager. If you need to change post while a file is open, you should do it from the menu, at Main Menu -> NC Utils -> Post Process -> Change. Then the .txt file is also loaded.

There is another shortcut to the desktop that should be right at the tips of your fingers. Windows key and M will minimize all windows. Except that it won't minimize Mastercam if you have a dialog open inside Mastercam

I think the variable you are looking for is tosz. That defines the top of stock Z level as set in the drilling page.

When seeing a Mastercam seat for sale on ebay, you should inform [email protected] of the fact (I have already done so in this case). They will then take it from there.

Looking at that, here is what I can work out: fg1014 must specify whether NCI code 1014 was found (1014 = tool plane matrix, in v9 it is always there). A check to see if the Y axis is in the XY plane (an error is output if it is not). The tool vector is set to the Z axis vector (that seems correct). caxis is set according to the direction of the Y axis of the tool plane. baxis is set according to some calculations I cannot work out what does right now. I think the post must be remapping the coordinates at some later point, and that arcs have to be linearized because they would not be in the XZ or YZ plane after the remapping. It is difficult to say for certain, though, as I cannot see what else is happening in the post.

The condition " if m4<>0 | m5<>1 | m6<>0 | m7<>0 | m8<>0 | m9<>1" reference the tool plane matrix as Roger suggested. To be specific, it checks whether the tool plane Y axis is unequal to the world coordinate Y axis (m4<>0 | m5<>1 | m6<>0) or the tool plane Z axis is unequal to the world coordinate Z axis (m7<>0 | m8<>0 | m9<>1), so in any plane other than the unrotated top plane, linarc is set to 1 linearizing arc. This is followed by a check of the variable fg1014, and if that variable is zero, then linarc is reset to zero, allowing arcs in any main plane. I do not know the variable fg1014, I assume that variable is specific to your post. It is probably a flag, set and explained near the top of the post, could you look for the relevant line? It will be something like this: fg1014 : 1 # Some explanation Where "Some explanation" explains what the flag specifies. We have made post processors for a couple of Thermwoods and AFAIR they did not have trouble with arcs in other planes, so fg1014 might specify whether the control is a type that can handle arcs in any main plane. If you set the post to output arcs in other planes, and the control does not support arcs in other planes, then the two most likely results are: 1. An alarm on the control, and the machine stops. That is the best result. 2. The machine executes the arc, but in the XY plane. With the tool going off in an unintended direction, what then happens depends on what gets in the way of the tool. As Roger suggested, it is probably best to talk to whoever wrote the post, or Thermwood, in order to find out if it is necessary to linearize arcs that are not in the top plane.

Mastercam won't crash if a license server goes down. It will tell the user that connection with the NetHASP server has been lost, and the user has one chance to save the file, before Mastercam closes down.

MachineSMMC, The HSM Performance Pack will filter to XY, YZ and XZ arcs now.

Adajun, there is one detail you may not have considered. While you can set up more than one NetHASP server, you will need a NetHASP for each server for that to work. Assuming you want 6 licenses to be available even if one server goes down, that means two NetHASPs with 6 licenses on each if you use two servers, or three NetHASPs with 3 licenses on each if you use 3 servers. Perhaps it would be easier if it was possible for the users to reboot the NetHASP server without your assistance? If you do use two NetHASP servers, then my understanding of the system is this: Then the clients will grab a license from the first NetHASP server they connect to that has an available license of the needed type. If there is no available license on that NetHASP server, then the client looks for another NetHASP server, and tries to get a license from that NetHASP server. And so on... I think there is a timeout for how long the client will search, before it gives up. I have not actually tested how the system behaves when there is more than one NetHASP server, though, so I do not know for certain. The closest I have come to testing the situation is to have NetHASP server software installed and running on more than one PC on the network, where only one of those PCs had a NetHASP attached.

Welcome to the forum. The rapid feedrate and toolchange time used for the calculation is set in the .set file. To adjust the cycle time calculations, you need to find this section: code: # Specific setting to allow tuning the cycle time calculations -> # Set the time it takes for machine to do a toolchange -> tlchgtime : .1 # Tool Change Time (* in Minutes *) # Set the Rapid Traverse Rate of the machine 38. Rapid feedrate (Inches per Minute)? 300.0 1538. Rapid feedrate (MM per Minute)? 10000.0 #These values are loaded into the pre-defined post variable -> pst_rpd_fr (v9) The two rapid feedrates are for inch mode (q. 38.) and metric mode (q. 1538.).

Use a check on the opcode variable. Opcode = 3 is drilling, opcode = 16 is drill5ax, any other value is milling. If you also want to check on the previous value (prv_opcode) to see if the prior operation was drilling, then you will need to update the variable with !opcode at the end of the psof, ptlchg0 and ptlchg postblocks. The above is for a milling post, if it is a lathe post, then there are more values that should be checked for. I don't remember them off the top of my head, but I can easily find out what values that is.

The newest HASP driver can be downloaded from AKS, that one might work better. You can find it here: http://www.aks.com/support/hasp/enduser.asp. You might also be able to find information about what is new on AKS' homepage. If you can't find it there, then I don't know where you should look for it.

Mp.dll belongs in the C-Hooks directory, though it isn't a C-Hook, so you have probably made the C-Hook file path point to the wrong directory. Go to Screen -> Configure -> Files and set the C-Hook path to C:Mcam9CHooks (assuming you have Mastercam installed in C:Mcam9).

The Mc?rs.dll contains the layout and text for all the dialogs in Mastercam. It can be modified to change the layout if desired, and it has to be modified to translate the dialogs to another language. The Mc9rs.dll is the same for Mastercam version 9.1, 9.1 sp1 and 9.1 sp2.

Google is also a very good search engine. With any search engine, you have to keep in mind how the search words are interpreted, here are three examples: Search term: medieval art Result: Pages containing the word 'medieval' AND/OR the word 'art' Search term: "medieval art" Result: Pages containing the text string 'medieval art' Dearch term: +medieval +art Result: Pages containing both the word 'medieval' AND the word 'art'

Jody, what do you mean by quote: ... and the WCS is fixed. I have not heard of any problems with the WCS in the current release version of the HSM Performance Pack.

Perhaps the control briefly used a value of zero? Just a suggestion, I really have no idea why that would happen.

If you are using AVG, Grisoft has an update to detect that one now. You can also find information about it on Symantec's site at http://securityresponse.symantec.com/[email protected]

Another possibility is the number of decimals in the NCI file. Eric, if you go to Screen -> Configure -> NC Settings, what have you set as 'Number of decimal places for NCI'? The angle is calculated from the tool plane matrix, and the tool plane matrix is a unitary matrix (i.e. each row or column is a vector with the length one). To get accurate output in multiaxis, the 'Number of decimal places for NCI' should be set to 6 or more.

I would like to add my comments on two details here. The 3+2 toolpaths (including boundaries) looks like they are working correctly in the latest "experimental" build of the Mastercam HSM Peformance Pack, so they should be in the next public release build, which should be out very soon. We are aware of the arc problem, and we are looking to solve that problem.