<SOLVED> G1 Not working in program

More
13 years 2 weeks ago #39785 by Jerre122
I have found the solution so this is solved.
It proved to be something simple (but it took quite a bit of looking to spot).

I had made a classicladder program to get a delay when reversing spindle direction. I had also altered the HAL signal "spindle-at-speed" for this, so the program wouldn't continue while the delay was still going.
But I made a fault in the classicladder program by connecting an output to the wrong classicladder hal pin, leaving "spindle-at-speed" forever false.

Original question:

Hello,

My machine is finally working in MDI. However, when trying to run a program the machine simply stops moving after the first few lines. There is no error at all.

Example of the first few lines of a program:

Code:
G17 G21 G40 G90 (Horizontal Roughing) T1 M06 S2000 M3 G0 Z406 X382.04 Y-52.32 -->It moves to this point and then stops G1 Z400.63 F1500. Z400 X380.99 Y-52.01 Z399.81 X374.38 Y-49.09 Z398.53

I already tried everything I could think of like deleting the . after the F, changing the place of the F to the line above, adding some modal G code on the first line, but northing is working.
There are some example programs that aren't working either.

I really need a solution.

Please Log in to join the conversation.

More
13 years 2 weeks ago #39787 by Jerre122
Replied by Jerre122 on topic G1 Not working in program
Ok I found out the reason, it turns out I cant use M3 for some reason. I can understand I can't use S2000 since I don't have an encoder, but not being able to use M3 seems weird. For some reason when M3 is included M6 becomes included in the active code list.

EDIT: I can't even turn the spindle on manually and then start the program.
EDIT2: I have found what went wrong.

Please Log in to join the conversation.

More
13 years 2 weeks ago #39790 by andypugh
Replied by andypugh on topic G1 Not working in program
This is very confusing. Can you start at the beginning, or is it all working now?

Using ladder for delays will work, and if you are comfortable with that then that is fine, but there may be other ways (possibly even built-in ways).

If you give us a more clear problem-description then we may be able to provide answers.

Please Log in to join the conversation.

More
13 years 2 weeks ago #39800 by Jerre122
Replied by Jerre122 on topic G1 Not working in program
It is working now.
But I'm always interested to know about improvements.
Any idea about other ways for getting a delay when reversing spindle directions?

Please Log in to join the conversation.

More
13 years 2 weeks ago #39803 by andypugh
Replied by andypugh on topic G1 Not working in program

Jerre122 wrote: Any idea about other ways for getting a delay when reversing spindle directions?


Why do you need a delay? Knowing the problem you are trying to solve would make it easier to know what the best solution is.

The behaviour you want might well be something that you can program into the spindle drive.

Alternatively, if you just want a slow ramp down and up again, look at using a limit2 HAL component between motion.spindle-speed-out and whatever it drives. www.linuxcnc.org/docs/html/man/man9/limit2.9.html


If you are only using M3 and M4, and your spindle runs full speed in either direction, then you can probably do what you want with the "timedelay" HAL function: www.linuxcnc.org/docs/html/man/man9/timedelay.9.html

To avoid a delay when starting from stopped you probably need two timedelays and two XOR functions.
M3-out = M3-in XOR timedelay(M4-in)
M4-out = M4-in XOR timedelay(M3-in).

In HAL code that would look a bit like:
Code:
loadrt timedelay count=2 loadrt xor2 count=2 … addf timedelay.0 servo-thread addf timedelay.1 servo-thread addf xor2.0 servo-thread addf xor2.1 servo thread … # these are inhibits, so only do anything on the on-to-off transition setp timedelay.0.on-delay 0 setp timedelay.0.off-delay 5 setp timedelay.1.on-delay 0 setp timedelay.1.off-delay 5 net m3-in motion.spindle.forward xor2.0.in0 timedelay.0.in net m4-in motion.spindle.reverse xor2.1.in0 timedelay.1.in net m3-delayed timedelay.0.out xor2.1.in1 net m4-delayed timedelay.1.out xor2.0.in1 net m3-out xor2.0.out {parport.0.pin-01-out, or whatever} net m4-out xor2.1.out {parport.0.pin-02-out, or whatever}

Maybe ladder is actually simpler?

Please Log in to join the conversation.

More
13 years 2 weeks ago #39810 by Jerre122
Replied by Jerre122 on topic G1 Not working in program
The reason I needed a delay is because the spindle needs time to stop. If you suddenly reverse the spindle the contactor wich activates the reverse spindle direction would activate before the contactor of the electric spindle brake. The brake wouldn't activate and the spindle would suddenly reverse (in a fraction of a second really) and the 3 V-belts going to the gearbox would slam against their case. I don't think this can be good for the spindle motor either.
Anyway I fixed this in ladder, but made a mistake leaving "spindle-at-speed" forever false. I didn't notice this while jogging or making G0 moves, only when running a program. Thats why it took a long time to find out that this was the problem.
It's solved now.

Please Log in to join the conversation.

More
13 years 2 weeks ago #39811 by andypugh
Replied by andypugh on topic G1 Not working in program

Jerre122 wrote: If you suddenly reverse the spindle the contactor wich activates the reverse spindle direction would activate before the contactor of the electric spindle brake. The brake wouldn't activate and the spindle would suddenly reverse (in a fraction of a second really) and the 3 V-belts going to the gearbox would slam against their case. I don't think this can be good for the spindle motor either.


It's actually probably OK, depending on a number of factors. If the only components involved are a 3-phase motor, the contactors and the incoming mains supply. This is "plug reversing" and it wasn't unusual to have motors deliberately wired to allow it in the days before electronic speed control. It is one way to stop you lathe faster, for example.
I spent some time using a surface grinder where the table traverse was controlled by a an electric motor that was plug-reversed by the trip cams on the table. That was doing 1second clockwise, plug-reverse, 1 second anticlockwise all day.

It's a nasty thing to do to an electronic speed control, but they can typically be set to ramp down and up again anyway, when they are reversed.

Depending on the number of reversals it might even be better in the long term than running a brake. If the motor can handle the reversal without overheating then it will not suffer any wear during the reversal, whereas brakes do wear fractionally with every operation. The belt slap sounds worthy of concern though.

Please Log in to join the conversation.

More
13 years 2 weeks ago #39812 by cncbasher
Replied by cncbasher on topic G1 Not working in program
i'd go further and investigate the belts , chances are either one or more are slack , they should be changed as a set , not independantly .
if one's been changed then that one will be tight but the other will still be slack ..

As Andy says , most motors in this situation are designed to accept some reversal .

Please Log in to join the conversation.

More
13 years 2 weeks ago #39813 by Jerre122
Replied by Jerre122 on topic G1 Not working in program
The brake is a electrical brake wich brakes on the motor itself so it doesn't wear out. It's a "Frenostat 2000" It was originaly on the machine so I decided to keep it for now.

I will see if I can tension the belts more but I think I rotated the motor as far as I could. (for tensioning the motor has a excentric mounting)
Otherwise I will just buy new belts.

Please Log in to join the conversation.

Time to create page: 0.095 seconds
Powered by Kunena Forum