[LeWhite]

V25 sim reports a collision and gives a block #. The statistics gives a move # are they rhe same? The reported collisions state 'flute collision (rapid moves'). I made sure the tool flutes are long enough and my clearance planes are high enough. There is no red on the material or the part that I can see. I also visually checked tool path around the block # and the move #. Also single blocked the sim. I dont want to break a couple of $120 em..what am I missing here?

[RAF.]

From what I have found is that the Move List # is just a waste and more less the same for statistics #. To find the crash in the Gcode I have to dig a thru a better backplot to find it. So to me the sim that comes with Bobcad is just about useless for that.

[jrmach]

What is with all you guys using $120 EM
I am Frugal and have to shop flea-bay

Is there anyway of sharing a file ?

[LeWhite]

A couple of bull EM with non stock radii extra long.
Damn near impossible to post file from mobile.
So block number is not the same as move number
Sim has time base and NC base render. Might try NC
does BBC Sim trigger alarm at collision or have look ahead?
Might just run the part @ 5% rapid

[BurrMan]

What machine do you have selected for the job and what cc options are defined for it?

[LeWhite]

Good idea I'll check mañana.

[SBC Cycle]

....The reported collisions state 'flute collision (rapid moves').

Typically when I've seen that "collision" it's because the tool has made a rapid move right down on top of the floor of a part. I'm not saying to ignore it (nor is it something I like the toolpath to do) but it's probably not going to devastate your tool. Won't be good for it either so proceed with caution and possibly slow down your rapids if possible in that section of the code. Of course, as you know, the Move # doesn't mean a whole lot as far as finding it in the actual G-code block.

[RAF.]

Try to figure at what line of the Gcode this is using the Move list.

[LeWhite]

Thanks guys sbc &raf. I have set sim to stop on collision(s) &what I have found was a false report. Heres how; 2d profile, side rough has a straight feed in to the next lap around, not too good, but it is what it is. I used the 2d strategy advanced (open) pocket to an island cause the island was far to the side of the work. This strategy uses a link that looks like the 3d advanced rough 'S' link. Kinda like a circular lead in but in 2d. This is a much better move to the next lap but sim didnt like it and must have read it like a circular rapid. Al are you listening? 'S' link is a better 2d side roughing path. Sooo as said proceed with 5% rapid and hand on the big red knob You guys are the greatest!

[jrmach]

Do you have Preditor Editor level 2 ?
I use the simulation for pretty pictures,I use Preditor for peace of mind.
That is why I asked if you had a file,like to try preditor and see if it shows up

[LeWhite]

Yes I have Edit/DNC pro. Nothing I can see there. Can backplot show any errors? I don't see any triggers to set Do I need to build a custom template or is 4AXVMILL or Haas4AXVMILLgood enough? Preditor did stop when G code called a G55 (mach setup 2).

[BurrMan]

The movelist is the toolpath you see in the viewport as it's raw moves.... The movelist is processed by "MillingPostExe.exe" per the post processor's instructions and converted to gcode. The movelist and gcode wont have any reference to each other that's visible because "X.2076 Y.7241 I-.4348 J-1.8282" could represent 50 movelist lines, or 200 depending on the machining tolerances you've set....

The movelist will help you though, in some advanced situations....

But the way the movelist will help you with the sim is, the error is at a specific movelist that you can navigate to.... You can review where/what the tool is doing there in relation to your geometry where you can determine whats going on.... If it is the tool rapiding to a milled plane, you should easily see that is the point of the error.... If you don't have the pro sim, which will show you defined components of the machine, you may be hitting the flute you've defined on some part of the machine you don't see (this may be a simple work offset setting that doesn't matter to your actual machine and the gcode).............

I don't think you will be able to reverse engineer the gcode back to the originating movelist without a specialty tool that equates to "MillingPostExe.exe" and the originating params that were passed to it from the CAM feature...