Problems with torchmate

[jprobst]

Does anybody have this same problem? What happens is when the torch is traveling from point A to point B the torch comes down and ignites. It does it all the time. When I'm running a program or when its just sitting there. I called the tech support months ago when it started and they sent me a new driver, didn't work. They wanted me to go out and diagnose it with them on the phone. I told them that i couldn't cause the shop is too loud and I'm not sure what to look for. I then sent them an email asking them to send me instructions to diagnose it after hours with my father who is familiar with these things. Never heard anything back from them.
So my question to anybody is if anyone has had the same problem and what they did to fix it. I'm assuming its the signal generator and a new one is $1300 bucks. This thing is only a year and three months old. It started happening right after the warranty expired. IT's becoming a big problem. We can't let the machine run unmaned and sometimes it comes down where a part was previously cut and dropped out and it rips the end of my torch up. The replacement piece is $80 and already had to replace it twice.
I don't have time to go over it on the phone, and would like some instructions on how to diagnose it. If any body can help I would greatly be appreciated.
It's a torchmate 3 5'x10' table with a hypertherm powermax 1600 and torch height control.

[Mike@Torchmate]

What is the exact sequence of events during this operation.

Does it rapid travel to the cut,and along the way it will come down and sense the material and try to pierce? What happens when it gets to the cut? Does it stop the torch, move it to the home position at the top? Does it come down and sense the material again and cut out the shape? At the end of the cut does the Torch retract to it's home?

This is why a phone call is the best way to trouble shoot this type of a problem, due to the fact that there is a lot of different possibilities depending on the answers to these questions.

Due to the specific question of it is coming down and sensing the material during the rapid travel, I can come up with a few conclusions, and I will list them below.

A) The software is activating the output line during a rapid travel feature, most likely a software setting if it is 100% consistent, every rapid travel movement. Since you say it does it when it is just sitting there not running code, I would say that it is not the problem.

B) The plasma interface relay box itself is activating the height control, regardless of signal from the signal generator, test by turning the signal generator off or unplugging the output connector and see if it still randomly fires while sitting idle. If it no longer does, the output lines in the signal generator may be defective and outputting voltage when it is not supposed to be. To test that theory we would test with a multimeter the output line for +5v DC. If the signal generator was outputting this 5v randomly without being activated by the software, the problem I would say is the signal generator.

C) The relay itself is activating and telling the height control to activate regardless of input from the signal generator. Test by hooking a continuity tester or the ohm setting on your multimeter, to the back of the relay box to the two small screws. Unplug the relay box from the signal generator, and unplug the wires going to the start input on the height control. If it randomly activates the relay (should have a loud audible clicking noise) with no input, and no connection other then power, it would be a defective interface box)

D) If with the plasma interface box disconnected from the start input, you have the AVHC unit powered on and it randomly activates, goes down and sense the material, and fires the torch, then the problem would be with the AVHC box itself.

The key factor to all of these conclusions is that the AVHC unit is receiving the fire signal (closed loop) from the system with no input from the software. It could simply be a loose wire hanging in the wind, and that the software is activating the output line in between cuts. You think since it is a firing issue they must be related, where perhaps it is not. Let me know what other questions you need answered

[jprobst]

Yes, when it is rapid traveling to the next cut it comes down while still moving and ignites(while it is still moving) and will cut until i stop it. So what i've been doing is standing there and when it travels i watch it and when it starts to do that i press the feed hold button, it comes down ignites, returns home, then i press the start button and it continues with the program. Now somedays it doesn't do it, somedays it does it alot. Some days it does it through the first part of the program but not the second. I did go over my settings with the torchmate tech support and everything was in order. I will try the other things you mentioned in your reply. thank you for your help

[Mike@Torchmate]

What we'd like to see done next is to run the program with the Start Input wires disconnected from the plasma interface side, and hook a multimeter up to those two points. Run the program as you normally would, and set the multimeter to check for continuity between those two points. At the beginning of every cut, it should show a closed loop, and at the end of every cut, the loop should open back up. It should rapid travel to the next cut and repeat.

If it is showing a closed loop between cuts, most likely the system is telling the torch to fire for one various reason or another, the M-Code executions come to mind, where there is a setting that says Execute at Start/End of Motion. It has the ability to activate an m-code at the beginning and end of every motion regardless of cutting or rapid travel.

[LenMcC]

I'm having a somewhat similar but different problem, and it's only with one spot in one code. The g-code was generated in TMcad. When I execute the program, the first 4 parts cut properly. Then, instead of raising the torch and rapid travelling to part 5, the torch stays down and lit as it moves to part 5. The g-code looks right (see below) and I've played with it a bit without luck. One thing I noticed is that the line of g-code PRIOR to the G00 command stays highlighted while the machine moves to the G00 point.


G01 X0.000 Y2.650 (cutting last side of part 4... THIS LINE STAYS HILIGHTED WHILE TORCH CONTINUES TO CUT TO X37.5 Y7.7 IN NEXT LINE)
M51 (torch off)
G00 X37.579 Y7.759 (rapid to part 5)
M50 (torch on)
G02 X37.6769 Y7.6403 I-0.0000 J-0.1000 (begin cutting part 5)

Also, we are cutting in manual (ATHC off).

[Mike@Torchmate]

I'll have to run that section of G-code on one of our machines here, but it may have something to do with the timing of the M51 and the G00. Normally in our g-code you do not need to add in the M50/M51 commands because the automatic executions will add them in for you invisibly so you are just seeing cut lines (G01,G02,G03) and non-cut lines (G00) in the g-code screen. My guess is that it is not being executed and thus the output line is staying on (torch on and cutting) during the rapid travel machine movement.

If you can reset that g-code to be used with Automatic Executions, I would bet you will not experience the problem.

[LenMcC]

Originally Posted by Mike@Torchmate If you can reset that g-code to be used with Automatic Executions, I would bet you will not experience the problem.

Is that a setting in TMcad? I did notice that when I import a .dxf directly to TM without using TMcad, there are no M commands... Deleting M50 and M51 has no affect in that section of code I posted. Also, I did try restarting the computer, but no change.

I'm not a pro with g-code, but I find it peculiar the way this code is consistently running. Are there a lot of automatic or hidden bits of code that aren't editable? Behind-the-scenes type stuff? I don't know if this is worth mentioning, but in this same program, when the machine is rapid traveling and it crosses over some part cut lines (so it's not cutting, just moving to the next part across a line it already cut), the speed momentarily ramps down then back up. There are no loss of steps, and there is nothing in the code that I see making this happen. Just G00 Xxx Yyy, and somewhere in the middle of executing the line, the machine slows and speeds on it's way to the destination. Again, consistenly in the same spots.