We have not managed to convert the videos to a format supported by Windows Media Player for XP / Windows Media Player 8 (two names for the same program ). We have placed instructions (and a link) for solving the problem along with the videos, it can be found here: http://www.cimco-hsm.com/index.php?page=do...ad#TargetVideos

I took a look at your file, and I agree with Peter and gcode. There are rapid moves in the toolpath that would cause crashes if your machine does dogleg rapids, and you are using shortest path or minimum retraction without mapping rapid moves to high feed cutting. You need to either use full retraction, or map to high feed rate.

We have investigated the problem further, and we have found the cause of the problem. The two videos about the Adaptive strategy are recorded using the Microsoft Windows Media Video 9 codec. That codec is supported by Windows Media Player 9 for Windows 2000, so we did not realize that that could cause problems. However, as can be seen here: http://support.microsoft.com/kb/291948 that codec is not supported by Windows Media Player for Windows XP. We will of course convert the videos to a supported codec as soon as possible.

We have looked at the matter, and the conclusion we have reached is, that the problem appears to be with Windows XP. On a PC with Windows XP, the files look bad, both when viewed streaming in IE and when downloaded to harddisk and played from there. On a PC with Windows 2000, the files look OK, both when viewed streaming in IE and when downloaded to harddisk and played from there. We will of course investiate the problem further, and try to come up with a solution.

If it is a SolidEdge file, then their free viewer might let you view it. The free viewer can be found here: http://www.solidedge.com/viewers/default.cfm

I would like to answer Peter Eigler's points. 1. No check surfaces. While check surfaces would of course be a nice thing to have, we are using a different approach, machining on a STL model. The same results as if using check surfaces can nearly always be obtained by using containment boundaries and/or slope range limits. We are planning to implement check surfaces, but we have considered other things, such as the adaptive roughing, more important to implement. 2. No option for "plunge outside boundary". The pocket strategy is optimized for machining cavitites, where plunging outside the boundary does not make sense. Because of the helix/ramp entry moves, and the very smooth entry and exit moves in all areas, most still consider the pocket strategy the strongest roughing strategy available. The new adaptive roughing toolpath (soon to be released) is optimized for both cores and cavities, and it enters outside the stock whenever possible. 3. Processing speed on scallop. It may be possible to reduce the processing time on scallop. Part of the reason why the processing time "seems" longer is the way the tolerance is defined in CIMCO HSM. By default, 50% of the tolerance value is used to define a STL model of the surfaces/solids, and the other 50% are then used to calculate the toolpath relative to that STL model. The processing time for a scallop toolpath can often be improved by changing that ratio on the geometry tab (lowering the percentage used for the STL, thus increasing the tolerance for the toolpath relative to the STL). Working with the settings here should give you a noticeable improvement. 4. Overly complicated "Top of stock" definition. We would disagree that our current method of defining the top of stock is complicated. The top of stock is the highest point on the selected surfaces/solids, or the minimum depth under cutting depths if that is used. By right clicking in the minimum depth field, a menu is given where the minimum depth can be selected from the geometry. While the method used to define the top of stock is slightly different in Mastercam and in CIMCO HSM for Mastercam, I do not see one method as superior to the other. However, there is always room for improvement with any process/feature. 5. Confusing terms. While we have of course tried to use as recognizable words as possible (and use the same terms as in Mastercam when possible), some concepts are difficult to define in a single word (or a few words), and I agree that overthickness is one of them. We welcome any and all suggestions on how we could "re-term" some of these processes. We take everyone's comments and suggestions seriously and it is our goal to keep CIMCO HSM for Mastercam and our other products a customer driven applications. So we welcome any ideas or suggestions on how we can improve the product. At this point we believe we have a very strong product that customers can immediately benefit significantly from. We believe Mastercam with CIMCO HSM for Mastercam is capable of matching and often outperforming any other surface machining product on the market.

"Screen", "Configure", "Files" tab, select "Post processor" under file usage (post processor is already selected by default), click the filing cabinet icon next to where it says file name, and select your post processor.

.model is Catia v4 native format (as others have mentioned), or it could be from "Ribbons" molecular modeling software (though that seem unlikely in this connection). When I get questions about a file format I don't know, then I look it up at FILExt - The File Extension Source. I haven't come across any unknown file type I couldn't identify there.

In the mirror function in CIMCO Edit, you enter a point on the mirror line, and the direction (angle) in degrees of the mirror line. To mirror about the X axis, enter the point 0,0 and the direction (angle) 0 degrees. To mirror about the Y axis, enter the direction (angle) 90 degrees instead.

Good to hear you have things working as you wanted them to. quote: Does it ever end. Just when I think I have everything taken care of I will read about what one of ya'll have done or something funny happens when I program something a differnt way and I will tweek some more. I run into problems, too. New control software versions sometimes means things should be done in different ways, they have new functions, and there keep appearing new machines, each with their own peculiarites.

Kyle, you did not make it clear where you have the two lines you gave as examples, but I think I know why they do not behave as expected. The prv_opcode variable holds the previous value of the opcode variable, and is set when the opcode variable is updated and/or output. As I doubt you have any reason to output the value of opcode, you must update it with the command !opcode. Assuming that your line quote: if opcode <> 3, n," XXXXX ", eIs in you psof, ptlchg0 and ptlchg postblocks, and your line quote: if prv_opcode <> 3 , n, "XXXXX",eIs at the beginning of your ptlchg0, ptlchg0 and peof postblocks, then you need to add the line !opcode to the end of your psof, ptlchg0 and ptlchg postblocks. If you have problems with the codes coming out in too many places, then you might need to include a check of the op_id variable as Ron describes. If you are also using op_id, then that variable also has to be updated for prv_op_id to be of use, so the update line then becomes this: !opcode, !op_id

I hope I have understood your question correctly. The first postblock name on the line is the first postblock in the 'tree'. The second has been called from the first postblock (and so on), and the last postblock on the line is the postblock producing the output (if any) on the line. HTH

Do you have the newest drivers from NVidia ? If not, you should try them. You can download them from Nvidia's driver download page.

You can't - Yet. However, CNC Software should have a converter for SolidWorks 2005 ready very soon (next week or so), and SolidWorks 2005 also use Parasolid version 15, so I would expect that the general Parasolid conversion will also be able to handle Parasolid verison 15 files after that update.

If you have XP SP2 on the new computer, you will probably need this command line installation driver. Unfortuntely it does not look like Aladdin have a GUI installation driver yet that supports XP SP2.

If you want to hardcode them in the post, instead of setting the defaults as James describe, then you need to set the following variables at the top of the pheader postblock: seqno and n : starting line number seqinc : line number increment If you set those variables earlier than the pheader postblock, then they will be overwritten with the values from the NCI file, and if you set them later, then you will already have output line numbers, which means your line numbers will be messed up.

I think you need to edit the last portion like this (added characters in red): #if absinc = zero, initht_a, !initht_i #else, initht_i, !initht_a #'W' is ALWAYS considered to be an INCREMENTAL distance from the #'R' plane regardless of the Absolute/Incremental (G90/G91) setting! # Per CINC docs (pg 8-2, 8-6, 8-11) initht_i, !initht_a # Output the 'W' word DEM

That is a function of the post. There may be a flag you can set to select next tool callouts, the variable used for that flag is usually called stagetool. If there isn't such a flag, then the function would have to be added to the post, and that is a fairly simple modification.

You would need to put that in the psof, ptlchg and ptlchg0 postblocks. You will need to find some variable that identifies whether you will be wanting inverse time feed or not. That can be a misc. value which you set when you make the operations, or you can automate it using some other variable. It is difficult to tell which variable (or combination of variables) would be needed to automate it, without knowing in which cases you need inverse time feed, and in which cases you do not need inverse time feed.

If you go here and click "What's hot" you will see something about Mastercam X on IMTS, from CNC Software.

I just checked. Both with a couple of 3D contours, and on a cylinder surface as you described. The result was clear, the z_min variable does give the lowest point correctly, even if that is on an arc. Breakarcs was set to zero, so it was not arc breakup that allowed the correct z_min to be captured.

I am not certain that is the case. The z_max and z_min values available in the pwrtt postblock might take that into account. That is something that should be tested.

To reuse the min/max values at the toolchange, you will have to scan the buffer for the entry matching the tool at the toolchange. To sort the tools by tool number, you need a sorting algorithm. A good method is this: Compare entry 1 and entry 2. If entry 1 is higher than entry 2, replace entry 1 with entry 2 and vice versa. Repeat for entry 2 and 3 (where entry 2 might be the original entry 1), then for entry 3 and 4, and so on until entry n-1 and entry n, where n is the total number of entries. Repeat the process, but stop at entry n-2 and n-1 Repeat the process more times, each time stopping one step earlier, until the only comparison is entry 1 and 2. Then the tool list is sorted. If you use the same tool twice in the program, then there will still be two entries for that tool in the tool table, and the scan for min/max values will find the min/max values for the first instance of the tool at both toolchanges. That problem can also be solved, by going through the tool list and combining any double entries into one. That should be done after sorting the tool list, as it is much easier to do that at that time.

In order to could reorder the tool table, you will have to write the tool table (including the min/max values) to a buffer in the pwrtt postblock, and then set up a postblock which reorders the lines by tool number and outputs the tool table. The postblock which reorders (and outputs) the tool table should then be called in the psof postblock.

In the text for the prompt, you can insert a variable by enclosing it in double slashes. For example, to insert the t variable (tool number), you might format the question like this: code: fq 1 abc Question about tool number //t// - enter value for the abc variable