GPP - '@arc' and '@m_feed-spin'

[mattpatt]

Right chaps.

I have an issue (that I've temporarily solved) with the gpp file so that it's outputting code that I don't want.

Using the trace all I can see that it's an issue with SC 2009, but not with SC R12

If I mill a hole using helical depth in the 'depth type' option on the technology tab then the code outputs:

(1)@arc ==> xpos:0.000T ypos:-9.965T zpos:-10.000T feed:200.000F feed_teeth:0.100F spin:0.000F

whereas with SC R12 it outputs:

@arc ==> xpos:0.000T ypos:-9.965T zpos:-10.000T feed:200.000F feed_teeth:0.100F

Notice the extra 'spin:0.000F' in the 2009 version

Now, this extra bit of code is the problem, as the next command is @m_feed_spin, which then sees this as a change of spindle speed and throws up:

N24 S100 M3
N25 G4 X1.5

This is because I have the following in the gpp file:

@m_feed_spin
if change(spin)
{nb,'S'spin:integer_def_f, ' M'mcode}
{nb,'G4 X1.5'}
endif

This works to change my rough spindle speed to my finish spindle speed with a 1.5 second delay to get things up to speed before cutting.

Now, to stop this from happening I've done the following:

Added to @init_post:
global logical S_Depth_Type

Added to @start_of_job:
if depth_type eq 3 then ; 3 = 'helical' depth type
S_Depth_Type = TRUE
else
S_Depth_Type = FALSE
endif

and finally changed @m_feed_spin:
if change(spin) and S_Depth_Type ne TRUE
{nb,'S'spin:integer_def_f, ' M'mcode}
{nb,'G4 X1.5'}
endif

These changes have stopped the output of the unwanted code if helical is chosen, so has got me out of the immediate problem. Not sure how it's gonna affect other things though! gulp!

If anyone has any bright ideas on another work around for this, or can see potential problems in my code I'd be happy to hear your views.

Oh, and I got the idea from Jake T-B's post about my coolant problem so thanks to him for this workaround :-)

Regards,

Matt.

[Brakeman Bob]

Upgrades strike again! Matt, what SP are you on with SC2009 as it may have been fixed (I'm running SP3 and I have SP downloaded awaiting installation even though SolidCAM have taken down from the website).

One approach to this problem is to set up a global variable for spindle speed (say "true_spin"), transfer the value from spin to to true_spin in @start_of_job and then test for it in @m_feed_spin.

@m_feed_spin
if spin ne true_spin
do the necessary...... finishing off with
true_spin = spin
endif

That shouldn't interefere with other functions in the post.
Bob

[mattpatt]

using solidcam sp2.

Can't seem to get this working properly!

If I generate two operations, first rough then finish (same tool), the @start_of_job value for 'spin' is the 'spin_rate' for both. It doesn't appear to do the switch to the 'finish_spin' until it reads @m_feed_spin.

I guess I could try to use another variable in @start_of_job to distinguish between R & F such as wall_offset, but it's a little vague.

I also tried to put a message in the misc. parameters box. This then came up with the message in @start_of_job so I could use that possibly to fire up another global variable.

Anyway, it's heading towards 9pm, so time to go home methinks, and worry about this tomorrow. I'm not admitting defeat yet!