Thank you, I will look at these as soon as I can. I went through all of the lessons in http://mathcentre.ac.uk/students/topics/ on Vectors again this weekend. -Gary

for instance... our drawings are in metric but we still program in inch for the time being. In 2018 I can analyze a distance and choose to view the result in Inch or Metric, in 2020 I can do that plus I can analyze an entity and view the result in Inch or Metric. That's big time saver for me; I don't have to continually multiple by 25.4 on my calculator, have a minor heart attack, correct my dyslexic calculator entry, and calm down again, lol. Many moons ago I wrote programs in Pascal, C (yes, C, not c++ yet) and Assembler. I never found writing a working program to be the big issue, the big issue was trying to think of all the things that could go wrong. And, these were tiny programs compared to Mastercam. Hats off to CNC and all the programmers out there.

It sure seems to be that way, so many of the posts that I have used have been from lackluster to terribad. I think I read somewhere in here (forum) posts that you wrote about vector math, I just looked back for a bit but could not find them. You seem to be really up on things, nice talking to you! -Gary Yes, exactly what I meant by the above ^^^

The machine has been running the entire time on prior operations to the ones that I need the right-angle head for. I am looking ahead. I've only been at my current job for a year and I've only had need of the right-angle head in the last month or so. Consequently I did not know anything about the post's right-angle head capabilities. The current process is to write a program in the XY plane and copy-and-paste that into a template with the proper codes to pick up the head and setup the G180. Of course that is time consuming and error prone so I want it fixed as soon as possible. With the recent slowdown created by COVID I have had some time to work on this while I am at home. I learned long ago that the key to life is balance. That balance in business is measured by ROI - return on investment. I've often chided others for being 'penny wise and pound foolish' and I certainly do not wish to be accurately described as a hypocrite so I am very diligent to watch the time I spend on this while I am on the clock. I do most of the post work on my own, I started writing posts after taking a one-week training course for Intellipost, which was an Automation Intelligence product, in 1989 iirc. I have been writing posts ever since but mostly for two axis lathe, 3 to 4 axis mill. Along with getting the output the machine requires I also really enjoy getting code that is formatted exactly the way I want to see it. And the latter is a want and not a need; some get confused about that and start majoring in the minors... For instance, I have posts that use buffers and redirection to suspend the output of the tool table until the either the descriptor/properties and/or the first manual operation comes out so that I get a descriptive header right after the program number. I used sysinfo to get the programmer's Windows username and then, stripped it down to the first initial, capitalized then the last name with first letter also a capital. Next the tool table and then the rest of the program. I have a threadmilling macro that I wrote that can do NPT and straight threads. I created a custom drill cycle to call it using tosz$, initht$, refht$, etc. with some of the drill parameters. This was a big time saver and prevented mistakes created by editing the NC code. The macro can do straight threads, single or multiple steps, NPT threads, has provision for a rough and finish pass, can be called by G65 or G66, does not use G41 so I can leadin with an arc, I do the cutter comp internally based on macro variable pulled from the current tool parameters in the machine. It does not use circular motion for the thread so I don't get an alarm for the arc endpoint lining up with the start when milling NPT, I linearalized it every one degree... overkill, I know, but a 31 control has no problem and does not lag. We used this all day every day at a former job, we milled thousands of threads with it. A typical day there would see us drill and threadmill on the order of 2,000 holes. Additionally I created a custom drill cycle to handle some special drills that were much like gun drills. The cycle used parameters like the ones mentioned about and fed the drill in to a certain depth and feedrate using G1, then finished the hole and fed back out at another feedrate. All as per company procedure. So, the time spent developing those posts was so well spent. And finally, I am innately curious, I enjoy many types of programming, I like math, and love to learn so this is all interesting to me.

Will you explain this to me? I don't know how to create a plane in the post, that's a new concept for me. When I programmed my test part in Mastercam I made a cube and drilled holes and circle milled in the front, back, right side and top planes. I set it up as an HBM type of part such that the bottom plane would be resting upon the face of the rotary table and the front plane was my zero. I wanted the B axis angles to control the angles for the right-angle head. xabs = vequ(x$) I was looking at how the coordinate mapping is done (this is from the Generic Fanuc 4X Mill) but I got tripped up pretty quickly with the above statement... vequ is "vector equivalent" and makes a copy of the vector according to Mastercam's documentation... but... x$ is an X position and so is xabs so I'm lost on this already. It seems to me that vequ should need an array as an argument...? Thanks for the reply Alex -Gary

Husker, You are spot on, it is an MVR, MVR-30 to be exact and the right angle head that we have also indexes in 5° increments, I wish it were the 1° but at least we have one to work with. In regard to the G68.2, I was just using that as a reference for anyone that is not familiar with the G180; it is great that you are. I fully intend to use G180, I wish I knew more about it. I asked for information about it but no one here is interested in helping me obtain it. One thing at a time though... I will ask MLC for some help as they are our reseller. The thing that I really dislike about the current post is that I have to input a misc real for the angle, the hack post I wrote gets the angle from the work plane so I don't have the chance to forget to input it or input it incorrectly. It is possible I am not using the current post correctly, though. No one here knows much about it. I like the idea of using misc reals for the W axis, but there none left, the post is using every one of them. Currently, I have it setup to ask two questions when I post, one for a W clear plane and one for the W working plane which is normally zero. There are some misc integers available I think. Thank you for your help and also thank you to 5th Axis CGI for the reply. I was not aware that I could ask CNC Software for help on a post if MLC cannot satisfy my requirements. -Gary

Hello All, We have a right-angle head post that was purchased from our reseller for our vertical bridge mill but it is terribly clunky, it requires that we put Miscellaneous variables in to signal that the right-angle head is in use (ie 90) and then one for the tool vector and even then it does not map the coordinates such that the Z axis is in the Machine XY plane which is required for the G180 to work correctly. This G180 is a macro that I am pretty sure, at it's core, uses G68; it behaves similar to the G68.2 P1 that I used for Mazak. I made a copy of that post (it's a five axis) and tried to get it to put out the G68 but I cannot get it. Should I be able to? That is my first question. So, I made a copy of the Generic 5-axis Fanuc post and configured it as a table/table machine so I can get XYZ coordinates as if I am always in the top plane, I have the primary and secondary angle zero and directions set such that I am getting good code. I am using m6$ as a trigger to put out the G180 but it feels like a hack using the table/table setup when it is not. And I really need to get rid of every s_out so that it never puts out a C code because the G180 uses C for it's fixture offset. I tried making it as a head/head machine but did not have any luck with the G68 there either. So, the second question is, am I better off sticking with the table/table hack or should I be able to use a head/head machine to get what I need? That is I suppose, dependent upon the answer to the first question, if I can get the right-angle post working or not. Thanks in advance for any help.

I just looked at this again, trying different machine definitions, configs, etc... but what I have discovered is scaling the part to inch puts out the G70 and vice versa. So, thanks for the input, I think I understand it now. I thought switching the configuration was the key, but I switched and told it NOT to scale the part and the G70/G71 stayed the same, then I manually scaled it without changing the configuration and the output DID change. Gary

So I think I have it sorted out... I can't test it until tomorrow morning but I believe the Configuration chooses between Inch and Metric when posting out, and the Machine Definition only needs to be adjusted for maximums such as travel limits, feedrates, etc. Anyway, that is what I came up with thinking about this during the afternoon yesterday. I've never tried switching to a metric config, it'll be interesting to see if the feedrates in my part file change. Seems like I'll need to scale my part up by 25.4 and probably feedrates too. Then check clearance planes, depths of cut, WCSs, etc.

I searched on this forum for "Metric Machine Definition" but got a large number of hits that don't seem to apply to my question... I'm not a great search guru apparently... My question is what makes the difference between a Metric and inch Machine definition. There appears to be only one Control Definition and one Post, that is to say, there isn't a Metric Control Definition and Metric Post for the Metric Machine Definition AND an Inch Control Definition and Inch Post for the Inch Machine Definition. So, the machine definition is the deciding factor, I just don't see how. I've made machine definitions from scratch for Inch version machines but never noticed or thought about what makes the difference. tia, Gary

Geez Louise... I got it, I had the 4th parameter, the Initialize flag, set to a 1 so it was trying to initialize a pre-existing ASCII text file. So, that is why it would run just fine as long as I had run it beforehand and left the "Keep flag" set to 1. In that case there was an existing file for it to initialize. So here is the setup now: #region - Buffers # -------------------------------------------------------------------------- # Buffer definitions # -------------------------------------------------------------------------- #Buffer 1, output strings for testing wc1 : 1 #Initial count for write buffer 1 rc1 : 1 #Initial count for read buffer 1 size1 : 0 #Buffer 1 size string1 : "" #Buffer 1 fbuf 1 0 80 0 1 #Buffer 1 #endregion - Buffers and it seems to be running fine. As an aside, there is some confusion now about that new 5th parameter, it designates whether or not it is a string buffer... previously the third parameter had to be set to 80 in order to make it a string buffer, now the fifth parameter set to a 1 designates that it is a string buffer and you can have up to 380 characters each string.

I am attempting to use the MCX file descriptor as a program header of sorts. I want it to come out just after the first line that has the program number. I can do that with ease but I also get the operation comments for the first operation, which I want to come out after the toolchange. So, I setup a buffer to trap the Operation Comments and I put them out at the appropriate place, this all works okay-ish with the exception of I get one error message upon writing the first line and consequently miss that line in the output. The documentation says that the buffer file is opened upon the first writing to it so it seems like it should work. The error message says: RUN TIME -PST(897)- Error opening buffer file:C:\Users\myname\Documents\my mcamx8\MILL\NCI\testtx1. Buffer number with error is 1. Line 897 is the first time I write to the buffer. As I stated above, all subsequent writes are fine. #region - Buffers # -------------------------------------------------------------------------- # Buffer definitions # -------------------------------------------------------------------------- #Buffer 1, output strings for testing wc1 : 1 #Initial count for write buffer 1 rc1 : 1 #Initial count for read buffer 1 size1 : 0 #Buffer 1 size string1 : "" #Buffer 1 fbuf 1 0 80 1 1 #Buffer 1 #endregion - Buffers pcomment2 #Output Comment from manual entry scomm$ = ucase (scomm$) if gcode$ = 1005, sopen_prn, scomm$, sclose_prn, e$ #Manual entry - as comment if gcode$ = 1006, scomm$, e$ #Manual entry - as code if gcode$ = 1007, sopen_prn, scomm$, sclose_prn #Manual entry - as comment with move NO e$ if gcode$ = 1026, scomm$ #Manual entry - as code with move NO e$ if gcode$ = 1008, scomm$ = wbuf(1,wc1) #buffer Operation Comment output if gcode$ = 1051, sopen_prn, scomm$, sclose_prn, e$ #Machine name if gcode$ = 1052, sopen_prn, scomm$, sclose_prn, e$ #Group comment if gcode$ = 1053, sopen_prn, scomm$, sclose_prn, e$ #Group name if gcode$ = 1054, sopen_prn, scomm$, sclose_prn, e$ #File Descriptor #endregion psof$ #Start of file for non-zero tool number pcuttype toolchng = one if ntools$ = one, [ #skip single tool outputs, stagetool must be on stagetool = m_one !next_tool$ ] pbld, n$, *smetric, e$ if convert_rpd$, pconvert_rpd pbld, n$, [if gcode$, *sgfeed], *sgcode, *sgplane, scc0, sg80, *sgabsinc, [if gcode$, *feed], e$ sav_absinc = absinc$ if mi1$ <= one, #Work coordinate system [ absinc$ = one pfbld, n$, sgabsinc, *sg28ref, "Z0.", e$ pfbld, n$, *sg28ref, "X0.", "Y0.", e$ pfbld, n$, sg92, *xh$, *yh$, *zh$, e$ absinc$ = sav_absinc ] pcom_moveb pcheckaxis c_mmlt$ #Multiple tool subprogram call ptoolcomment comment$ while rc1 < wc1, [ string1 = rbuf(1,rc1) sopen_prn, string1, sclose_prn, e$ #Operation comment ] pcan pbld, ssync, *t$, sm06, e$ The while loop is also in the null toolchange and toolchange. I read through the "What's New" docs up to X7 to see if there is anything new in buffering but I didn't see anything about opening the files... the only thing I saw is the new fifth parameter to explicitly state that it is a string buffer or not. If I set the buffer to retain the file and post it out again, it will run just fine since the file already exists, but that's not ideal. Thanks in advance, Gary

Ron, thank you... these seem to pertain to the definition of the cycle, which I was ok on, I was baffled as to how to configure the text in the popup window for the drilling parameters, JParis answered my question above. I sure appreciate that you guys are out there and willing to help! -Gary

I see in your second screenshot that you have been able to customize the "Apply custom drill parameters" label, I know how to configure the standard ones, would you please tell me how to configure the labels for the Custom Parameters? I tried adding in more fields starting with 12 and going up to 20 but they don't appear anywhere like they do when I alter the ones numbered from 1 to 11. Thanks in advance