Short G1 ignored in ver 14.7 CNC Pro

[HuFlungDung]

I'm not up to date and don't have a Camsoft maintenance contract, hence my post here.
I never noticed til today that a sequence of very short movements could result in the G0 mode kind of overrunning G1 mode. See the note in my program below. It could be a motor tuning issue, but of course, I do not wish to insert a "WAITUNTIL STOP" command
in my G0 or G01 because of the resultant lousy profiling performance. However, I do use a DECELSTOP command in the G0 before the RAPID command

G90 G80 G40
G53 X0 Z-3.6
G92 X-4. Z0.1
M27 M3
T3 (CUTOFF TOOL ON REAR TOOLPOST)
M8
M98 L100 R29
M5 M9
T0
G98
M40
G99 M2
O100
M0 (RELEASE COLLET AND RECLAMP AFTER WORK MOVES TO STOP)
G0 X-.65 Z0.
M27
G1 X-.45 F4.5
G0 X-.65
G1 Z-.035 <---If I use a G0 here, then the next G1 is ignored and moves at rapid speed
G1 X-.6 Z0.
G0 X-.65
G0 Z.075
M28
G1 X-.5 Z0. F2.5
G1 X0.0000 F4.5
G0 X-1.
M27
M99


Below, is my naked G0 and G1 logic, for as much as you can make of it all by itself

DISPLAY1 t :TEXT 1;t :\81=t
IF\99=0THENIF{\3+\4}=0THENIF\5=1THENLABEL2 YOU FORGOT TO PROGRAM SPINDLE FWD/REV :[CYCLEBUTT] :EXIT
LABEL2 ;11
IF\99=0THENIF\5=1THENLABEL2 SPINDLE IS STOPPED;12 'detect a stopped spindle by M5 flag
DECELSTOP
RAPID z;{x/2};0
IF\99=1THENIFt<>\408THEN\408=t :FILEWRITE (T\408) :READNOTE \409 :FILEWRITE (\409) :FILEWRITE M0
IF\99=0THENIF\5=1THEN [CYCLEBUTT] 'if a dryrun is not in progress then if an M5 was not cancelled my an M3 or M4 ,go to the macro
\100=z
\101=x
-----G0
IF f=0THENLABEL2 YOU FORGOT TO SPECIFY A FEEDRATE;12 :[CYCLEBUTT] :EXIT
LABEL2 ;11
IF\99=0THENIF\5=1THENLABEL2 SPINDLE IS STOPPED;12 'detect a stopped spindle by M5 flag
GO z;{x/2};0
IF\99=0THENIF\5=1THEN [CYCLEBUTT] 'allows the program to run through with axis locked M31
\100=z
\101=x
-----G1

[camsoft]

Hello HuFlungDung,

There's nothing wrong with your G code program or in your GCODE.FIL file. While there is plenty of extra logic in G0 & G1, the important commands RAPID and GO are correct.

Try these things:

(1) Tighten your TOLERANCE
(2) Set BLEND to zero

A common occurrence is that the velocity (feedrate) carries over from one move to the next while making a transition from one velocity to the next, fast or slow.

The G1 is not ignored, instead because the move G1 X-.6 Z0. going G0 X-.65 is short when it gets within tolerance or is set to start to BLEND early it will pick up the G0 in the next move ahead in G0 X-.65. If the move were longer you would see it feed G1 at the F4.5 feedrate until it got within tolerance or else with in time value in milliseconds set by BLEND early.


Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

[keithorr]

I have maybe a similar situation?
In order to smooth out the motion, I use a large blend value of -300. (300ms). This along with a large tolerance value of "1" helps interpolated G1 moves from being jerky and keeps the machine for stopping with a "Feedrate too slow" message. (even if the feedrate is 2000). One problem though is that M and F values are read before the motion of the same line is being processed.

i.e.

G01 zippidee do-dah whatever F1200.
20 lines later
still G01 (modal) moves
5 lines after that
X this Y that Z the other thing M115
X yadda Y yadda Z uh-huh
G11 the end.

The M115 activates at the 20th line, not the 25th.

Also, unless I insert a M code with a
!WAITUNTIL STOP
!SLEEP .5
after the G11 and make the machine wait, any following command begins without any decel/acceleration. If the G11 is followed by a G10 with a feed of F1000., the line with the G11 SLAMS to a halt and the machine jerks to the G10 motion.

I'm not just blending the axis values, I'm blending all of the letter codes too.

Using a small blend value causes the machine to halt at each line of code until the program is satisfied with the position.

Kind of a rock and a hard place for me. The machine has a lot of inertia/load and I'm still trying to figure out the best compromise.

So... What are you using for blend/tolerance?

____________________

Oh great, I type all this out while CamSoft is posting the same ideas. Well, at least I know I'm on the right track.

[Carlo Rechi]

I am using a Blend of 0 and a Tolerance of .0005 and mine is running okay. When I cut splines I use Fastmode or Smoothing with G61,G64 or G8 and G9 and I can go pretty fast. I have ran many jobs and they all seem to run pretty smooth and run the G and M codes where I put them. I think your WAITUNTIL stop command would be removed and your Tolerance should be less. You should try some other settings because something is screwed up.

Carlo

[keithorr]

What speeds are you running? Also, my G8 doesn't function well. Each block accels and decels. Doesn't matter what value I place after the "L", 1 or 100.

[Carlo Rechi]

It's not my machine. They normally cut 30-40 ipm on most jobs but I have seen it run through a G code program at several hundred ipm.

Carlo

[camsoft]

Hello All,

Timing is everything. You want those settings tight.

This is a actually one of those complex subjects with a very niche answer that applies to each application on a case to case basis.

HuFlungDung is running a lathe and Keithorr is running a 6 axis robotic arm for glass grinding and polishing.

There are general terms that do apply here to all cases, but it does boil down to what carlo said. It's all in settings and knowing what your machine can or can not do. We viewed the video on your web-site of the Robot arm retrofit you did and we're quite impressed. Hence, we can see how a long robot arms weight and inertia would be extreme.

If setup right, the system has the ability to out perform the speed, accuracy and cut quality of the most expensive CNC systems out there.

There's much more to this subject than just setting up BLEND and TOLERANCE. You have to understand the best settings for you, which would be different than other peoples. There are other features to use as carlo suggested such as Fastmode or G8 & G9 , but this suggestion doesn't apply to what you're describing per say.

Without a DECELSTOP , WAITUNTIL STOP could suddenly end if used like this and should not be placed in a G1 normally. As already menetioned it would be lousy to stop and go while cutting. Even on a robot a M code with a WAITUNTIL STOP is also not normally used, unless again depending on the application case if motion is required to be sure it's stopped first to doing something such as grind or polish the glass. This is not the answer either in this case.


To better understand this subject in whole there are several Solutions in the Search for Solutions that reflect upon this. Each case if different, so pick out the explanation that fits best. Some topics sound similar but are not related. There's lot there to study.

The TOLERANCE should never be greater than what your machine mechanically can handle. A setting of 1 is extreme and a BLEND of -300 is almost 1/3 of a second time wise.

The system never should slam unless you want it too. This is usually a combination of settings that come into play, but in general terms slam either because you have it set to stop too fast (DECEL) or take off too fast (ACCEL). One setting may work good on one machine and bad on another. Linear motors have excellent acceleration and can take off and stop quickly. The G forces are so much better that the ACCEL and DECEL values can be entered in the millions and you would never notice a jerk or slam.

As you wrote in your last post "Each block accels and decels" This tells us you have some extra logic in there telling it to do so. It won't do this unless it's told to. However, in a robotic application it is common practice to position each move of the arm with accel and decel. Metal cutting is different. You're video is looking good. Your application is unique. There's not too many glass grinding and polishing 6 axis robot out there. We can see how you had to develop some special routines and logic. Good job, we never really knew what you were doing.

The ideal settings would be TOLERANCE of a micron and zero BLEND with ACCEL and DECEL values in the millions with a few ounces of weight to move , but that's why we have user defined settings. Not every machine is built this way and we can't all afford over sized servo motors.


A wide opened TOLERANCE is bad because it tells the system you're okay with the position accuracy and anything that falls within this zone is acceptable. Any negative BLEND causes the next line to process this many milliseconds early. A little BLEND is okay, but in most system it's never needed and should be set to zero and of course a small Tolerance is okay, but again never more than what's acceptable. If you find that either of these cases reasonable values don't help and you have to enter extremes you should think about motor size, faster computers, ball screws, mechanical slop, weight, load, inertia, etc..etc..etc.. You want these settings tight.

The blending of feedrates are a different story and have nothing to do with mechanical reasons, unless again the settings would have to be set looser than acceptable because of a mechanical or motor problem. Here the 4 settings are really what matter most to tighten this up. TOLERANCE, BLEND, ACCEL and DECEL. We covered Tolerance and BLEND and only the manuals would go into this further. So now it's the theory of how feedrates make their transition from a higher rate of speed to a lower rate (DECEL) and from a low rate to a higher speed (ACCEL). If these settings are set with very large values the feedrate issued would jump with no noticeable ramp up or down in velocity. Here you would notice a slam or jerk. As you lower the values, a ramp or transition is made between the two feedrates smoother. The lower the values the smoother the flow. However, when speaking of ACCEL when the next line of G code is coming up the system will see this in advance and makes it's transition to the new speed upon reaching destination when satisfied within Tolerance distance or time setting with BLEND. Decel is different and can be affected by other commands such a DECELSTOP or end or program or even WAITUNTIL STOP. Decel will calculate in advance how far back or early it needs to start slowing down inorder to be deceled at the end of the move. The rate in which both accel and decel happen or make these transitions are user programmable.


Tech Support
CamSoft Corp.
951-674-8100
support@camsoftcorp.com