O/T Bridgeport Interact w/ Heidenhain Controller

[bhyde]

Ok... So I have several Bridgeport Interacts with Heidenhain controllers. The problem I am running into is the controller throws up an alarm "incorrect H". I have contacted Heidenhain about this problem and they just say that the controller was modified by bridgeport. Contacting Bridgeport is a moot point considering their circumstances. This problem is a new problem and has only came up since we switched from Cimatron to MasterCam. Has anyone else ran into this problem??

 

Btw.... This only happens when surface machining w/a very long file. I have tried everything from modifing communcations protocols to reducing the decimal places for posting.... To no Avail...

 

Suggestions would be greatly appreciated!

[Dan Bedore]

have you tryed filtering with Metacut this would reduce your file size.

[bhyde]

No... We dont have Metacut View. I guess that

I am trying to solve a problem that never existed before we switched to MasterCam, So I am having a hard time justifing the purchase of software to correct the problem.

[P_Scott]

bhyde,

 

There is a Filter built into Mastercam which will reduce your file size if used correctly. In V9 the filter settings are found in the "Total Tolerance..." button on the third parameters page of the operation. I typically use a 2:1 filter ratio but one of the others may work just as well for you. There are also "create arc" switches below the filter settings. These will attempt to fit arcs to your many tiny lines in the surface toolpaths. That is one reason why the file is reduced in size. HTH

[bhyde]

Scott,

 

I really dont think that the problem is in the file size. These machines have been used on some very long toolpaths before we switched to MasterCam.

We are not really concerned with the file size because we set the machines up and run them overnight so the cost is negligable. We are more concerned with why Cimatron was able to do some very similar parts without creating errors at the controller.

The problem therein lies between, in my opinion, the post processor or the program creating the code. Dont get me wrong, MasterCam is a very good program. I just need to understand the problem and exactly what is creating it. In my humble opinion, these particular machines should not be used for creating such complex surfaces because basically they are just a glorified drill press with a calculator attachment.

 

As always, I do appreciate any and all input!

I dont always post in here, but I do check in

and learn all I can!

[ssibiski]

The only time i have ever run ito a similar problem( although it was on a completely different machine fadal) it was becase my H value had some how ( a bad hand edit by me) gotten a negative value placed into the code.

Don't know if this will help but it is something to check.

 

Good luck

 

Steve Sibiski

[Will Slota]

"Incorrect H"?? Sounds to me like the "T" and "H"

codes need to be of the same value i.e. tool 7 has height offset 7..T7&H7. Some older machine controls would have seperate offsets for H and D offsets which is why you still have the ability to set them to different values in the tool definition. For example the first 30 offsets are used for the "H" offsets and the next 30 are used for the "D" values such that T5 corresponds with H5 and D35. This can all be setup using the job set up. Set your tool offset registers to length 0 Diameter 0 and make sure "ADD" is checked. I'd think that if your numeric code calls out "T5" and then "H19" your going to get an error like this.

 

Now I may be off base here because everyone elses replies refer to file length stuff but I just thought I'd put that out there to consider.

 

[ 01-24-2003, 05:54 PM: Message edited by: 5ax ]

[Roger Peterson]

When you look this error up in your machine manual what does it give you for a root cause or explanation? In many situations a given error message can be caused by several completely different problems. I'm sure with more info someone on this forum can help.

 

Thanks,

 

 

Can you run different "H" values for one tool in one program? The output of a G43 H** is a modal output. Mastercam normally doesn't output this again until it is needed after a G49 or at a tool change. Is there anything that could be cancelling the length offset other than a G49 in your code, are you calling a macro that could cancell the length offset. When your machine is stopped when you come in in the morning check to see on what line of code it stopped and I'm sure a quick look at the code and the problem will reveal itself.

 

[ 01-24-2003, 06:35 PM: Message edited by: Roger ]

[steve f]

bhyde,

 

Mastercam is not likely your problem but the post processor probably is. If Cimatron was outputting code that worked and Mastercam isn't, compare two files from identical/similar toolpaths using something like Cimco Edit and find out where the differences are. Your post can be modified to output exactly the same as Cimatron or whatever it takes to make your control swallow the code. If your find the "offending" H in your programs, post a sample of the program lines before and after the problem and somebody will help you fix the problem in your post processor.

 

Steve

[bhyde]

The Heidenhain Controllers dont use "H" values for tool offsets at all. They use "tool call 1" for example. The manuals that came with the Bridgeports dont describe the "incorrect h" problem. Heidenhain will not take credit for this particular feature. I have looked this up on the net many times and all I can find out doesnt really explain the problem. Most sites refer to "incorrect h" as a math error.

Go figure.....

Like I said before...If it was up to me, I would flush these machines like the @$%@*^ they are. Prefer full 3+axis machines more than these.

[Guest CNC Apps Guy 1]

I'm with Steve. I'd make a G-COde File in Cimmatron then one from the same model in Mastercam that will deliver the error and compare the differences. I would ted to thing you reight in the guess that it is most likely some sort of math error.

 

HTH

[Claus@Cimco]

Hi

To me it looks like somekind of communication problem.

H is the standard file extension for Heidenhain NC files. And as it only happens on long files, it might be some handshaking trouble.

Have you tried changing the handshake to software handshake. Or to both Hardware and Software handshake?

Are the FIFO buffer for the serial port enabled? If yes disabled it. For Windows 2000 (Control Panel - System - Hardware - Device manager - Ports - "Select port" - Port Settings - Advanced - FIFO).

 

Are you using FE(Heidenhain protocol) og EXT (Standard RS232)?

 

 

Claus@Cimco

[Richie21]

Maybe the previous software used wasn't working either, but someone "fixed" it. Now the fix is gone.

I may be a "whodondeit" when it worked.

 

I am a cnc machinist (and programmer), I cannot even begin to tell you how often we as operators need to do things our way or it will not work at all. This is an understatement.

 

Did some key person leave ?

 

The question to ask may be: why did it work before.

 

Just a thought.

[Claus@Cimco]

Hi Bhyde

 

I don't think it's a math problem. If it runs with small programs, it will run with large programs too. It doesn't make any different if you write hundrede lines or millions of lines, its the same math that is done over and over again.

btw. Does the program stop at the same line every time or is it at a different line. If it a different line it for sure not the post processor, but more likely a communication problem. See my prev. post

 

Claus@cimco

[bhyde]

Claus,

 

Thank you for your response. I have impemented the change you suggested and hopefully that works.

Time will tell. We are currently on another rev of parts not requiring surfacing but I will keep you updated.

 

Thanks to all for the suggestions! One of the best reasons to be on this forum! Now only if other software makers would have something similiar... Hmmmmmmm....

[cheong]

bhyde,

Hope that will not late to reply you post.

I also have face that problem once time. I cannot remember what I already adjusted. I'll try to recall my memory.(I used MPHEID,V8.1.1)

 

1. Filter

If you used Filter,I very sure (I've check and found it)that the endpoint of the arc cannot contact with next entity.

So to test this, please make 2 program, 1 program WITH Filter and another one is WITHOUT Filter. Try send it to CNC machine and see the result.

 

2. CNC Machine Parameter.

Mode = EXT

5030 = 1 (blockwise on)

 

3. N-block

The program much start with N = 0, otherwise alarm will occur.

Example:-

0 BEGIN PGM 1234 MM

1 TOOL DEF 1 L1. R10.

2 TOOL CALL 1 Z Sxxxx

.

.

.

.

22 L Z+50.000 R F9999 M

23 STOP M02

24 END PGM1234 MM

 

 

HTH.

[Henk]

Hi

 

As Claus said, .H is standard heidenhain extension. Maybe there is some wrong in the program head, Check between "good" en "bad" files.

For communication with our Deckels we use "TNCremoNT", avaidable on the Download Area at heidenhain.com

[bhyde]

Cheong,

 

Actually..I think you are right in some respects. I am going to try both solutions that make sense. Clause and yours. The "incorrect h" value would suggest that there is a math problem. I will verify this and let you all know what the solution is.

 

Thank you..

[Oppiz]

I'm programing 2 bridgeports with heidenhain interact controls. I've never had this problem. what control are you running? I use TNC150 and TNC370. Maybe I can help.

 

[ 01-29-2003, 10:14 AM: Message edited by: OPPIZ ]

[bhyde]

Oppiz,

 

They are running a TNC 2500... I am glad I dont have to run a bridgeport. But be that as it may. I still have to fix the problem.