39 replies to this topic

[Paul Decelles from CNC Software]

I'm not a local post processor guru but I can tell you that those parameters are not available.  Sorry to be the bearer of bad news.

[Crazy^Mill/Turn]

Paul could he build a buffer method like Zmax and Zmin and then from there use to come with what the range is for the toolpath is question?

[Müřlıń®]

I wonder if a script could be made to copy the numbers from your NCI file to your NC file.

[K2csq7]

Paul, Thank you, I would much rather hear the bad news than spin my wheels...

[Colin from CNC Software]

M30,

I'm glad you've taken an interest in editing Post Processors, but some of the information you posted is incorrect, so I'm going to take a minute and clear some of that up.

Mastercam passes information to the post processor in two general ways: as information in the NCI file (this infomation populates Pre-Defined variables automatically), and as Parameters that are written to a Temporary file called the .OPS file. This .ops file is then read by the Parameter Read functions, and certain values are extracted. These values are then put into user defined variables as either a String, or a Numeric variable.

Some of the information is available Multiple times. For example, Tool Information is available for every Operation directly in the NCI file. But Parameters from your individual toolpaths (like Depth Cuts, or # of Multi-passes) are also written to the .ops file, for every Operation. This is infomation that is available in the .ops, but you have to write custom logic in your Post in order to extract these values and do something useful with it. So if you had 5 Contour Operations that used Depth Cuts, and you had a Parameter Read/Write setup to capture that, you'd have to make sure you were using a Buffer, because the Depth Cut parameter would change for each toolpath.

You mentioned that some Parameters are in a group of Variables. The reason we do this is to create an Implied Array. This Array is used in combination with a Buffer. A Buffer is used to read, sort, and output information.

So just creating an ordered list of variables and then using a Parameter read/write routine does you no good, unless you use it in combination with a Buffer read/write routine. Why? because that ordered list of variables will only contain the information for the last Operation, without using a Buffer.

By the way, you can all thank Paul Decelles for coming up with the Parameter Read functionality.

[Colin from CNC Software]

Ok, I stand corrected. The .Ops file went away in X3 or X4, the Parameters are now written to a "Memory Map". This is basically the same process as before (with the Ops file), but it is cleaner and doesn't involve using an 'external' file. Also, the Parameter Read/Write functionality was added to the MP Language by Jeff Hill, and Paul did the rd_cd, rd_md, stuff in the the Post file.

One thing about working here, it keeps you on your toes...

[K2csq7]

Thanks for the clarification Colin....... no sarcasm intended...
Am I correct in thinking there is no way to access the limits shown in the my original post and use them in the post?

[Tim Johnson]

About the .ops files.... They were regular files in V9 weren't they? I'm going by memory (which seems to get worse more quickly these days) but I think I read somewhere the the .ops file was going to replace the .nci file within the next couple versions of V9. Did I remember correctly?

[Colin from CNC Software]

Keith,

As Paul stated, there is no way to access those limit parameters. Those particular data fields are part of a package that CNC Software purchased from Module Works. Due to that fact, we can't write them to the memory map.

Tim,

I'm not sure what the old plans were, but the NCI file isn't going away, and the .ops file has changed. It is now part of the 'Memory Map', which is basically a chunk of Memory that temporarily holds all this information, and is discarded when the Posting process completes.

We do have changes coming to the NCI, but I can't really talk about that yet.

[EX-wccprogrammer]

Put your limits in Miscellaneous Reals section and use them from there.

[Müřlıń®]

Quote

As Paul stated, there is no way to access those limit parameters. Those particular data fields are part of a package that CNC Software purchased from Module Works. Due to that fact, we can't write them to the memory map.

Ya but you could copy those para's using some sort of hypertext protocol and capture the contents of those zones on the screen.  All one would have to do is to pull up that axis menue to trigger it store to a buffer.

[K2csq7]

Misc reals...
thanks, that is what i have been running with so far, I appreciate all who have helped...

[Jimmy Wakeford from Barefoot CNC]

Keith what was the "post work" you were wanting to do. Maybe there's another route to get there. Maybe set up min_limit_c and max_lim_c and in pcout/pfcout:

pcout/pfcout
   if cabs < min_limit_c, min_limit_c = cabs
   if cabs > max_limit_c, max_limit_c = cabs

If you needed it at top of nc you could write everything to subout = 1 then in peof switch to subout = 0 put limits in and mergesub?


Colin, I never noticed the .ops file wasn't there any more. Memory map is basically the same thing then, just available at run time?

[M30]

Colin from CNC Software, on 15 February 2011 - 02:51 PM, said:

M30,

I'm glad you've taken an interest in editing Post Processors, but some of the information you posted is incorrect, so I'm going to take a minute and clear some of that up.

Much appreciated. There is always more to learn. Some of what I assume to know is empirical, and based on working with posts alone. I love hearing the straight facts from the source. It would be awesome if some of this information was stickied in a post processor section of the forum.

Good discussion all. I'm enjoying it.

Cheers,

M30
post.processor.guru@gmail.com

[Colin from CNC Software]

Darn, thought I had different news for you...

[K2csq7]

prmcode$ 10120. 	0
prmcode$ 10121. 	0
prmcode$ 12258. 	0
prmcode$ 12259. 	0
prmcode$ 12260. 	0

Awesome Colin, thanks for not letting this one die...anyone have a clue as to why my "parameter dump" skips the parameters I need?
I read that these values would be output in radians instead of degrees...

[K2csq7]

Crap....
Thanks anyway.:lol:

[K2csq7]

Me to M30, good stuff

Jimmy, what I am doing with this stuff is...My machines are not really full 5 axis (big horizontals with a rotary on a rotary) (the rotarys don't stop on a dime) so for rotary work I set the limits so the XYZ axes take care of the "ends" of the path and the rotary does all the stuff in the middle. When the machine is moving XYZ it takes the feedrate as a normal IPM feed, when the rotary is the only one moving the machine/control sees the feedrate as degrees per min.
I have added stuff to the post so when the machine is on the "limits" I set (pic in first post in this topic) it will change the feedrate to a different value (one I specified in the tool defintions' plunge rate), not the operations plunge rate (inches per min)) and when it is not on the limits the feedrate gets output as the operations feedrate (I plug it into the operation as degrees per min).

It is working great so far... here is what the posted code looks like..(surfacing toolpath stepping over in X). For the code below 24.8 is the feedrate in IPM and 83 is the degree per min equivalent. The finished surface does leave visual evidence of the feedrate transition, but no gouging. (You wouldn't see it if I didn't show you)

(  1/4 BALL ENDMILL   )
N204 M11 (UNLOCK B)
N206 M21 (UNLOCK C)
( LOAD T2 M06 )
N208 M00
( CONFIRM T2 H2 D2 DIA =.25 TOOL OAL: 2.5 )
N210 G0 G17 G90 G54 X-41.5603 Y-6.6474 C12.952 B75.28 S1400 M3
N212 G43 H2 Z-12.5517
N214 X-35.1868 Z-14.2261
N216 Z-14.6261
N218 G1 Z-15.0261 F24.8
N220 X-35.1729 Y-6.5068 Z-14.9732
N222 X-35.1588 Y-6.3602 Z-14.9194
N224 X-35.1455 Y-6.2187 Z-14.8688
N226 X-35.1441 Y-6.2034 Z-14.8634 C13.391
N228 C13.868 F83.
N230 C14.353
N232 C14.83
N234 C15.309
N236 C15.785
N238 C16.259
N240 C16.734
N242 C17.203
N244 C17.676
N246 C18.142
N248 C18.613
N250 C19.074
N252 C19.544
N254 C20.
N256 C20.503
N258 C20.98
N260 C21.49
N262 C21.966
N264 C22.483
N266 C22.96
N268 C23.483
N270 C23.96
N272 C24.489
N274 C24.966
N276 C25.502
N278 C25.979
N280 C26.522
N282 C26.998
N284 C27.548
N286 X-35.1313 Y-6.0636 Z-14.8148 C27.555 F24.8
N288 X-35.1166 Y-5.898 Z-14.7588
N290 X-35.1043 Y-5.7551 Z-14.712
N292 X-35.0889 Y-5.7569 Z-14.7123
N294 X-35.1012 Y-5.8998 Z-14.7592
N296 X-35.1159 Y-6.0649 Z-14.815
N298 X-35.1286 Y-6.2047 Z-14.8636 C27.548
N300 C26.998 F83.
N302 C26.522
N304 C25.979
N306 C25.503
N308 C24.966

[Jimmy Wakeford from Barefoot CNC]

If I understand correctly you want it to change feedrates if only a rotary axis is moving by itself.(?)

Maybe an easier way to do it would be to test xinc,yinc and zinc to see if any of those are moving. Maybe add something like this to pfr$

feed_chg : 0
pfr$
   feed_chg = 1
   if xinc <> 0, feed_chg = 0
   if yinc <> 0, feed_chg = 0
   if zinc <> 0, feed_chg = 0
   if feed_chg = 0, feed_out = fr_pos$
   if feed_chg = 1, feed_out = other_feedrate

[Jimmy Wakeford from Barefoot CNC]

I used to use:

   if xinc <> 0 | yinc <> 0 | zinc <> 0, feed_chg = 0

..but changed the format to make it easier to read.