You are not logged in.
This has so far baffled every tech support person to whom I have described it:
Many of my programs (Fanuc) use subroutines and macros. The tool path monitor shows the entry into the subroutine correctly, tracks through it correctly, but returns to the main program at the beginning rather than at the line following the subroutine or macro. What is worse is that this does not happen all the time. Just often enough to be a pain. It can happen whether I have the tool path monitor open or not. That is, I can run part of the program and then open it (the tool path monitor) to find myself at the beginning of the NC code when I should be somewhere else. It does not seem related to any specific commands. I have been unable to make it consistently reproducible. I thought it was specific to my computer but I recently got a new one with 2 gig of ram and a high end video card, but the problem is still there.
Has anyone else experienced this problem? Were you able to overcome it? If so, how?
Thanx,
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
You are not crazy I have the same issue with or without sub call and yes it is intermittent Vericut seems baffled. The only way to snyc it back up is reset. :?
Offline
You are not crazy I have the same issue with or without sub call and yes it is intermittent Vericut seems baffled. The only way to snyc it back up is reset. :?
Vericut Tech support had me alter the line in the vericut.bat file:
%start_cmd% "%CGTECH_JRE%\bin\javaw" -Dsun.java2d.noddraw=true -Xms16m -Xmx128m -Xss8m -classpath "%CGTECH_CLASSES%;%CGTECH_CLASSES%\CGTech.jar;%CGTECH_CLASSES%\iText.jar" Vericut %argstr%
changing "Xms16m -Xmx64m -Xss4m" to "Xms16m -Xmx128m -Xss8m" as shown above. The results have been mixed at best. The NC code tracker still gets lost, and I have seen some strange crashes. I might as well set it back.
Thanks for your reply.
Anyone else encountering this bug?
It is a bug, repeatable or not. My speculation is that it is related to the multithreading capabilities of Java. Windows assigns the tool path tracking thread a low priority and it gets bumped.
I keep pressing "Esc"...
but I'm still here!
Offline
Hello plh, if you haven't done so already, please send a set of files to support@cgtech.com that demonstrate the problem you are having. I would like to take a look at them. Send them "ATTN: Gene" and I will get them --Thanks!
Offline
Hello plh, if you haven't done so already, please send a set of files to support@cgtech.com that demonstrate the problem you are having. I would like to take a look at them. Send them "ATTN: Gene" and I will get them --Thanks!
I have done that already. The problem cannot be demonstrated in the usual sense, because it only happens sometimes, to some people. However, as you can see from this thread, I am not crazy, it really does happen. Not always, but just enough to be a pain in the twiggit.
Thanx,
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
It happens to us also. Can't pin it down. It is a real pain at times.
Jerry Millett
Jerry Millett
Offline
It happens to us also. Can't pin it down. It is a real pain at times.
Jerry Millett
Just so we know we are talking about the same thing: In my case, the model display is OK, that is, the model is doing what it is supposed to be doing, but the tool path monitor subwindow is in the wrong place. When it enters another subrouting it is in the right place within the subroutine, but when it returns to the main program it is lost again. I have not tried anything that involves a subroutine within other subroutine, so I don't know what would happed in that case.
In any case, I can keep running the simulation if I don't care to look at where I am in the NC code. But usually, I do care, so it is a problem.
Thank you for your reply. If enough people post about this one, who knows? It might get fixed!
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
It happened to one of our guys today. So we were able to reproduce and investigate. It was with multiple toolpaths and subroutines.
There is a setting to "initialize Machine/Control between NC Programs", make sure it is checked
Offline
It happened to one of our guys today. So we were able to reproduce and investigate. It was with multiple toolpaths and subroutines.
There is a setting to "initialize Machine/Control between NC Programs", make sure it is checked
Mine's been that way all along. So, that can't be it.
Thank You,
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
SergeV wrote:It happened to one of our guys today. So we were able to reproduce and investigate. It was with multiple toolpaths and subroutines.
There is a setting to "initialize Machine/Control between NC Programs", make sure it is checked
Mine's been that way all along. So, that can't be it.
Thank You,
-plh
Now that you (the people at Vericut) can see that we are not crazy, that this actually does happen, what is being done about it?
Thank You,
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
The steps that caused the problems were on multiple setups with subroutines; the user load his first stage, cuts it, then moves his stock and load the NC programs for the second stage. While in the second stage VERICUT gets lost in the subroutines.
With subroutines, VERICUT scans the NC program before cutting to maps everywhere in the NC program where it needs to loop out and back for subroutines. If "initialize Machine/Control between NC Programs" is checked, there is a scan at the beginning of each program.
If it is not checked and a NC program is added or replaced, all NC programs are scanned together when Play is pressed. They are considered like one long file.
So, to answer your question; What is being done about it?
When we have some files and the steps to reproduce the problem, it is easier for our developers to implement a fix.
In 6.0 we have done some changes to the scanning logic. Most changes were due to the multiple setup capabilities. By having all the NC programs present at the start of processing, aleviate smany of the problems.
Offline
This also happens to all the users at my company, (we are still on V5.4.4, too busy right now to make the jump to V6).
BUT, I don't want to initialize between programs, because I will lose my NC variables!
And, like others have stated, it does not happen every time!
Austin NC APT administrator.
Custom configure GPost for Pro/E,
and other ANC applications.
Offline
[snip]
So, to answer your question; What is being done about it?When we have some files and the steps to reproduce the problem, it is easier for our developers to implement a fix.
In 6.0 we have done some changes to the scanning logic. Most changes were due to the multiple setup capabilities. By having all the NC programs present at the start of processing, aleviate smany of the problems.
I now have 6.0.1 loaded and it is still happening. If it is of any help to the developers: I have noticed that it happens more frequently following changes to the NC program. I will have the program open in UltraEdit. I reset Vericut. Close the NC program window. Save the (changed) program (in UltraEdit). After that it is more likely to skip out when returning from a subroutine. Seems worse if lines have been added or deleted, but I have not kept any records. Then after a second re-start it usually tracks OK.
This is an expensive piece of software. So my question remains. What is being done to fix this problem? What, What, What?
-plh
I keep pressing "Esc"...
but I'm still here!
Offline
Plh,
I am very happy to tell you that your problem can be fixed with a bit of education.
When you load a new Project file or press RESET, you must have noticed that there is a delay. This is a scanning pass. VERICUT reads all the NC programs and subroutines to find out when and where to jump in and out of the subroutines.
VERICUT makes an Itinerary based on line numbers. And then starts back at the befinning and cuts the part.
If you edit the main program or the subroutines after you press RESET and before pressing PLAY, VERICUT might actually be confused and not jump to the correct line while cutting because you added or removed some lines.
This is why it works correctly the second time you play the file (you pressed RESET and scanned the files).
This is not a bug, this is how VERICUT works.
So the solution is that if you edit your program, you MUST always RESET before you press play.
Offline
Plh,
[snip]
If you edit the main program or the subroutines after you press RESET and before pressing PLAY, VERICUT might actually be confused and not jump to the correct line while cutting because you added or removed some lines.This is why it works correctly the second time you play the file (you pressed RESET and scanned the files).
This is not a bug, this is how VERICUT works.
So the solution is that if you edit your program, you MUST always RESET before you press play.
Thank You!
Since I have been scrupulously following that sequence I have had no trouble.
-plh
I keep pressing "Esc"...
but I'm still here!
Offline