New Hurco VM20 won't read my programs
Recently (well, not so recently now) we got in a brand new Hurco VM20 as business is expanding and our small VM1 needs some help. Anyway, after about a month of catching up on backed up orders and another month of calling, emailing and trying to resolve the issues with Hurco I am still unable to get the VM20 to read the programs without errors.
According to Hurco, the VM20 should use the same post and read the same programs the VM1 uses. However, this is not the case. When loading identical code into the two machines the VM20 always spits out the error message, "Cutter comp lead-in violates contour." The VM1, on the other hand, has no errors and runs the program exactly as it should. At first I thought it had something to do with Z ramp tool paths, but tried programming with all constant z level paths and still get the error. Second, I thought it was the i and j output for lead in and lead out arcs on tool paths (because the error always occurred on the first line of code containing i's and j's), so I tried straight line lead in and lead out paths and all that did was turn into some type of ~45 degree lead in and out paths that cut into my part where it shouldn't.
Needless to say, I have 10,000 lb paperweight sitting here that can't make me any parts. Any ideas?
Is the code turning cutter comp on as it is arcing into the workpiece? I have had some machines that will read it okay and others that will not. You can still arc into the workpiece, just make sure cutter comp doesn't turn on until it engages the part.
[QUOTE=jolson89;1789343Needless to say, I have 10,000 lb paperweight sitting here that can't make me any parts. Any ideas?[/QUOTE]
Is the lead in parameter the same for both machines/programs?
Kinda like the "tool too large" in conversational.
Thanks kevkess, i'll have to check into where exactly the cutter comp turns on.
As far as the lead in parameter, I have tried multiple numbers for it. Tried matching the numbers between machines, zero, and just the default. All of which still spit out the same error.
have you sent the code to Hurco so they can run it?
I would send a copy of your program, as well as the software version of your machine to firstname.lastname@example.org.
Check the machine parameters. Sounds like one machine is looking at the cuttercomp value as radius and one is looking at the comp value as diameter. Make the hurco match the other machine.
Also check the manuals and verify the I,J,K values that are defining arc center are defining this the same way. On most machines these values define arc center as the incremental distance from the arc start point to arc center. I have seen some machines that the I,J K values are from arc cnter to arc start point and some even use absolute values.
Third thing... is to remove all G41 and G42 from the program and see if the machine will run the program. That will verify that it is in fact a cutter comp problem.
If I remember correctly, Hurco's are kind of an odd ball on the way they program.
The VMX42 at work can be "glitchy". I sometimes have to rewrite a line of code and delete the original line. Don't know why but it works . . . sometimes. I also find it useful to occasionally flip the machine off. It doesn't solve anything but it is good for my mental health.
Rather begin with a short linear movement and turn on comp on that movement. The following arc will then be compensated and the tool will not violate the profile.
Originally Posted by kevkess
Yes, I have already sent code and software version to Hurco.
Originally Posted by len_1962
Just got an email today saying that their may be a new version of software for the machine by the end of the week. Guess it's just a long waiting game.
Would just like to update and say that Hurco got a tech in and the issue has be resolved. In the end it was something that could have been solved over the phone, however it was just something that was overlooked or just simply unknown. It had to do with the tool list setup on the new winmax control vs. the older ultimax control. Also could have been solved in our post processor, however the entire goal here was to use years of programs produced by that post and use the same code on both machines.