Post processor problem solvers needed.

[SpazMachine]

I don't know a ton about changing posts, just enough to cause trouble and not enough to get out of trouble. I need some advice. I have this post set so when the WCS changes, the machine G28s out of the way and puts in a M00. It's worked just fine until this program came along. Take a look at the code:

 

...

N7750X.1672Y-2.105Z.1614

N7752X.1686Y-2.0962Z.1609

N7754X.1775Y-2.0379Z.1526

N7756X.1851Y-1.9754Z.1448

N7758X.1895Y-1.9286Z.1402

N7760X.1925Y-1.8837Z.1373

N7762X.1957Y-1.8068Z.1341

N7764X.1963Y-1.7898Z.1333 ---- This Y value needs to be down there

N7766G0Z.2583

N7768Z5.

N7770M05

N7772G05 P0

N7774G91 G28 Z0

N7776G28 X0 Y0

N7778M00 (G55 EROWA UP)

N7780(T426#100)

N7782G55

N7784S12000M3

N7786G90 G00 X0 Y0

N7788G43 G00H10Z5.

N7790M46

N7792G05 P10000

N7794G17

N7796X-.1753 --------- I need the Y value here!

N7798Z.3137

N7800G1Z.1887F15.

N7802Y-1.7908F45.

N7804X-.1745Y-1.8222Z.1891

N7806X-.1723Y-1.874Z.1874

N7808X-.1686Y-1.9266Z.187

N7810X-.1633Y-1.981Z.1878

N7812X-.1556Y-2.0397Z.1899

N7814X-.147Y-2.0936Z.1928

...

 

If you look, after the M00, the machine is supposed to go to the correct XY value before going down. It always has but these two operations have an odd coincedence. The ending Y value for the first op is exactly the same as the starting Y value for the second op. I guess the post decided since it didn't change, no sense putting it in. Bad times.

 

Anyway, here is a chunk of the post that outputs this section:

 

ptlchg0 #Call from NCI null tool change (tool number repeats)

#"(im doing a null tool change)", e

if oldie<>workofs + 54,

[

"(wcschanged. I'm doing stuff.)", e

pbld, n, "M05", e

pbld, n, "G05 P0", e

pbld, n, "G91 G28 Z0", e

pbld, n, "G28 X0 Y0", e

pwcs

pbld, n, *speed, *spindle, pgear, strcantext, e

pbld, n, "G90 G00 X0 Y0", e

while tlngno>100,

[

tlngno=tlngno-100

]

pbld, n, "G43 G00", *tlngno, pfzout, scoolant, next_tool, e

pbld, n, "M46",e

pbld, n, "G05 P10000", e

#pcan1, pbld, n, "(out1)", *sgcode, *sgabsinc, pfxout, pfyout, e

#pcan1, pbld, n, "(out2)", *sgcode, *sgabsinc, pfxout, pfyout, e

pcom_movea ------------------------------------------------- this is the line that's blowing off the Y value

]

else,

[

#"(wcs didn't change, do't do anything crazy)", e

]

pcuttype

pcom_moveb

c_mmlt #Multiple tool subprogram call

comment

pcan

result = newfs(15, feed) #Reset the output format for 'feed'

pbld, n, sgplane, e

pspindchng

pbld, n, scoolant, e

if mi1 > one & workofs <> prv_workofs,

[

sav_absinc = absinc

absinc = zero

pbld, n, sgabsinc, pwcs, pfxout, pfyout, pfzout, pfcout, e

pe_inc_calc

ps_inc_calc

absinc = sav_absinc

]

if cuttype = zero, ppos_cax_lin

if gcode = one, plinout

else, prapidout

pcom_movea

c_msng #Single tool subprogram call

 

It looks like that pcom_movea is the culprit. Do any of you guys know where it's butt is so I can kick it? It just needs fixed.

 

Thanks for your help guys.

 

Cody Archibald

Tek Tool & Plastics

[crazy^millman]

Well you put up the B not the A. I would look at my pfyout and see if they are pyout the pfyout forces Y where as a pyout will not and if the same vaule as what is in the NCI then you get no vaule. You can use an * to make it force out Y move as well.

 

HTH

[SpazMachine]

Okay, in the prapidout I changed the pxout and pyout to pfyout and pfxout. It seems to work now. It that a fair fix or did I do it the stupid way? Also what is the difference between pcom_movea and pcom_moveb?

 

Cody Archibald

Tek Tool & Plastics

[Roger Martin from CNC Software]

pcom_moveb #Common motion preparation routines, before

.. do motion output...

pcom_movea #Common motion preparation routines, after

[Tim Johnson]

It looks like your post may already be written to support your problem with maybe an extra condition added.

 

code:

---

if mi1 > one & workofs <> prv_workofs,

[

sav_absinc = absinc

absinc = zero

pbld, n, sgabsinc, pwcs, pfxout, pfyout, pfzout, pfcout, e

pe_inc_calc

ps_inc_calc

absinc = sav_absinc

]

---

If you add a condition like this;

code:

---

if (mi1 > one & workofs <> prv_workofs) | oldie <> workofs + 54,

---

it MIGHT work. It's definitely worth a try anyway.