Enhancement Request

[RayLivingston]

Hmmmm..... I made this post yesterday, and it seems to have gone into the bit bucket.....

Anyway, I've been playing with the CutViewer demo, and I REALLY like it! However, the lack of support for any kind of multi-fixture machining is a pretty serious limitation, as a large percentage of jobs I do require multiple fixtures. This currently requires me to make multiple G-code files just to feed into CutViewer. It seems to me there is what should be a pretty simple change that could be made that would allow a single file to be used instead - Allow the STOCK to be re-defined on-the-fly. This would allow me to run up to a fixture change, see that all cuts up to that point were correct, then continue execution, which would first define a new piece of stock, to be used for the next fixture. There would, of course, be false collision reports at times, but I could live with that. It would, of course, be MUCH better if we could instead re-orient/re-position the existing partially machined stock mid-program, but I can see how that would be a lot more work.

BTW - Seems really odd to me that if the program contains multiple STOCK declarations, that there is no error message, and the LAST one is the one that is used, even if it is the last line of the program. Seems to me it should use the first, and either ignore, or complain about, the others.

Regards,
Ray L.

[Randy]

Ray, welcome to the forum.

I'm not sure I quite understand what you're describing. Do you have a part that has the outside profile machined first, then it needs to go in, say, machined soft jaws for more machining? Since CutViewer is limited to rectangular or cylindrical stock definition, I'm not sure how that would work.

One thing you could do would be to place all your stock definitions at the beginning of the file and comment out all but the first. Put a break point in the gcode at the end of the section using the first stock size and run CutViewer. Then comment out the first, uncomment out the second and move the breakpoint to the end of the section using the second stock size. CutViewer would run up to that point only. Etc. CutViewer is actually a "subtractive" solid modeler so it literally steps the cutter through a solid model of the rawstock to generate the cut workpiece, so it has to generate the history of all the cutting that has gone on before on that workpiece.

BTW I think that since CutViewer parses the whole gcode file when you load it, that's why it just keeps the latest stock definition you gave it.

But if you are moving your workpiece from fixture to fixture, won't you have separate gcode files for each step of the machining anyway? I think that there is something fundamental that I'm missing (go figure... )

Randy

[RayLivingston]

Randy,

Here's a simple example of what I'm suggesting - Suppose you have a part that needs to be machined on the top and the bottom. You put the stock in your vise, and machine the top side, then flip it over, and machine the bottom side. On the machine I can do this with a single program that stops in the middle, prompts me to flip the part over, then changes fixtures (G54-G59) to correct the offset, if necessary. With CutViewer, I'd have to break this into two programs, or the bottom side machining is done, effectively, to the top side of the part, which has already been machined. So, if I could simple re-define the stock at the point where I need to flip the part over, I'd start the bottom side machining with a "fresh" piece of stock, so all the bottom side machining will appear correctly (minus any areas where the top side machining and bottom side machining intentionally overlap).

Now suppose instead of machining the top and bottom I have to machine the top, and one side. Now, even the size/shape of the stock may change for the side machining. Again, being able to re-define the stock would allow me to properly model all the operations in a single G-code file.

Make sense?

Now, as far as handling true two-sided machining, I don't know how you generate the 3D graphical representation, but doesn't your renderer provide transforms, that would allow you to rotate/translate the world coordinates on the fly? Unless I'm missing something, that would allow you to model multi-sided machining with very little programming effort, I would think. You would need to only support a new directive like:

(TRANSFORM,XOFFSET, XROTATION,YOFFSET,YROTATION,ZOFFET,ZROTATION)

BTW - Would be nice too if there were a way to embed a PAUSE into the G-code, rather than having to find, and set a breakpoint, at the right place in the code each time it's run. This, too, would facilitate doing checks on multi-sides machined parts.

Regards,
Ray L.

[Randy]

Ah, I see now, Ray. See, I was missing something fundamental.

No, CutViewer is strictly a single-sided viewing program. It is independent of MeshCAM, and was originally written by a (I think) Russian named Stanislav Gorkun. I don't know who is supporting it now, but Stan never did really address any of my even simple enhancement requests, but did offer workarounds that he felt did address my comments.

From past emails it seems like it was quite a feat to get CVM to do what it does do. It is very reliable for what it does, but what it does is what it does, if you get my meaning.

Randy

[RayLivingston]

Randy,

That's disappointing. I think it has the "bones" of a really great simulator. It would be really to see it extended just bit - it would make it FAR more useful. But, I guess the 2008 copyright date, and the lack of traffic here, should've been a clue....

Regards,
Ray L.

[Randy]

Ray, you probably already know this but whenever you want a pause in your gcode just put in an M0 (number zero) line. You can have your postprocessor put it in at a toolchange, before or after a rotary axis indexing, etc. and the machine will pause until you hit the Start button (or onscreen equivalent). I just checked and, although it works in the real world, unfortunately CutViewer just blows past the M0...

Randy