[HuFlungDung]

I'd like to ask Camsoft a few questions, without causing any kind of a war. Yet, I want to do it publicly, so that others can see and add their useful input.

I don't have an ax to grind right here, but I have wondered a few things as I have used the Camsoft GUI for a while.

Here are some of the questions:
The use of the optional skip character, commonly the forward slash: now as background to this, I know that Camsoft and the Galil motion card seem to have a "program length buffer". This means unlimited lookahead, but I really have no idea how other "black box" cnc's handle this problem with hundreds of line lookahead, either.

What happens is that, even though I might program a button on the GUI to act as the "Block skip", it really has no effect unless I reload the current nc program. I contrast this behaviour with the Fanuc style control, which monitors the state of the optional skip switch (might be called block delete, too) on the fly. This permits the machinist to make a decision while the program runs, as to whether he wants to skip an upcoming certain block or not. He does not have to reload the program to make the block skip functional.

So, if I have made myself clear, is there any way to improve this emulation of the Fanuc "block skip" switch? Or perhaps, the way I am thinking of using it "in real time" so to speak, is unusual? What is the consensus on using the Block skip switch?

Secondly, and I think this is quite an important issue, is interrupting an nc program to change an insert. This could be a common requirement, I think. As I understand it (using version 14.7), I would want to go into Jog mode, and move the tool to clearance or something, change the insert, and then resume the program.

I created some logic which saves the current position when the jog window is activated. I have a button which will permit me to return the machine to exactly where it was when the jog mode was entered. But this is kind of useless, because now the main program has been cancelled already because at present, going into Jog mode cancels the execution of the nc program. Is there any way to work around this?

Thirdly, and this might be what your answer would be to the question I just asked, but I really don't understand the utility of the mouse driven "graphic viewport mid program start". Feel free to expound on the virtues of this for all to read about. Although the feature was introduced some time ago, I have not played around with it to any extent. Here is the problem with the concept as I imagine it: just clicking somewhere on the graphic backplot of the part seems a tad crude, as a way to safely get going in a program that was already underway. If the graphic backplot has any degree of 3d complexity to it, how is it possible to pick the restart point? I ask this because I really want to know if I have missed some vital clues as to how this should work. Oh, for sure I know about the prompts for tool change, spindle on, etc, but that could even be a source of confusion and error if the user makes a mistake. What if he clicks on a toolpath for the wrong tool? Since I have not used the Camsoft GUI for mill yet, I can only imagine bad things happening. I just don't understand how there could be enough intelligence in the program to make this sort of start, safe to do.

Finally, fourth question, the onscreen editor could use some more concise functions, in order to make it clear what is going on, and to save unnecessary mouse clicks to make it all happen. Currently, whenever I edit a program, it is usually for the sake of permanent change that I intend to keep. This means I have to click Save, then do it, then open the file manager, go and look for the nc program's name and reload it, to make certain that the changes I have edited in, are indeed in effect. Otherwise, I will be running the file from the temporary version (mdi.job) loaded in the mdi window. This version will be lost if I shut down the program, and if I don't think to go in and change the file name from mdi.job to whatever it should be. I feel that this is an unusual amount of work to have to go to, when the norm should be that original file saved on the hard drive should be the one that is written to, and saved, and automatically reloaded without all this fuss. To me it would seem to be much less common that I would actually want to auto-save a temporary alteration of a file, and risk losing my edits on the "real" file.

However, I would be in favour of having one backup copy of the permanent file made, each time the file is edited. This would simply be such a thing as changing the file extension to .bak, and then creating the new file containing all the edits under the current .job extension.

Now, if I choose to do a mid-program start from the mdi window, this makes more sense to me, and seem safer. However, what I don't like about doing this, is that by starting mid program this way, the GUI assumes that this is now the current program in its entirety. That is, after I get to the M30 or M2, the GUI reloads from the previous midprogram start point. I think this is risky. I think that the entire original program should reload after a midprogram start. Maybe there is a way to force this to happen that I don't know about?

Sorry for this being so long, but I had the time just now to sit down and write it all out. I look forward to discussion and tips on these questions.

Thanks.