kcham
-
Posts
35 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Store
eMastercam Wiki
Blogs
Gallery
Events
Posts posted by kcham
-
-
On 1/15/2021 at 11:09 AM, kcham said:
save NC file as a buffer, then read that buffer ... except it won't read the buffer
That's the subject of another forum posting addressing the issue
-
On 1/16/2021 at 7:04 AM, Tim Johnson said:
I use Vericut to debug variables. It works great.
Are you running the postprocessor file itself through Vericut?
-
I just started forcing output of variables during development to see what they are. I have given up on watch lists in the debugger. Also another very experienced and helpful user in another forum subject suggested using mprint to output messages on variables during posting, and I have used that lately in addition to the forced output.
-
1
-
-
example no longer needed...see save NC file as a buffer, then read that buffer ... except it won't read the buffer for resolution of the issue I was having
-
1
-
-
Here's the version of ppost$ that ended up working for my purposes in case it helps anyone out there.
ppost$ #entire postblock added,ev121120_0644 #saves NC file as a buffer in order to put order of operations/filename list in proper places #"ime" is "initial manual entry", "oofn" is "order of operations/filename list" sncfile = spathnc$ + snamenc$ + sextnc$ #store path for nc file sauxfile = spathnc$ + snamenc$ + sextaux$ #store path for aux file sbufname5$ = spathnc$ + snamenc$ + sextnc$ #make path for buf5 same as nc file spathaux$ = spathnc$ #set path for aux file snameaux$ = snamenc$ #set filename for aux file auxprg$ = 1 #access aux and wipe it newaux$ #open aux for output subout$ = 2 #direct output to aux file size5 = rbuf(5, 0) #open buf5, read size rc5 = one #set read variable to start at record1 while rc5 <= size5, #be sure reading of buffer stops when last record is reached [ string5 = rbuf(5, rc5) #read current record in buffer,set string5 if string5 <> s_init_loc & string5 <> s_oofn_loc, *string5, e$ #output string5 as is unless it is an ime or oofn flag else, [ if string5 = s_init_loc, #output initial manual entry from sub stream if string5 is ime flag [ subprg$ = 2 newsub$ mergesub$, e$ ] if string5 = s_oofn_loc, #output oofn list from lcc stream if string5 is oofn flag [ lccprg$ = 2 newlcc$ mergelcc$, e$ ] ] ] ret_b6 = fclose(5) #close buf5 return = fclose(sauxfile) #close aux return = remove(sncfile) #delete existing nc file return = rename(sauxfile, sncfile) #rename aux as the nc clearsub$ #clear sub file to prevent duplication @ next posting clearlcc$ #clear lcc file to prev dup @ nxt postg
-
1
-
-
4 hours ago, Colin Gilchrist said:
Playing and testing your code can lead to some surprising insights into how any system works, especially MP.
I agree. I enjoy digging into stuff like that quite a bit, and I would do it a lot more often if I had more time around the shop floor's programming needs. It's a miracle that I've been able to spend as much time as I have on this post.
Quote4 hours ago, Colin Gilchrist said:One tip I can give you for testing: use the 'mprint' function.
I had not thought about using mprint like that so I very much appreciate the advice. I'll surely be playing around with that as I continue/complete building this post!
4 hours ago, Colin Gilchrist said:Have you watched my MP101 Class videos on YouTube yet?
No, sir, I have not, but I will definitely check them out. I need to get more into the habit of proactively improving my understanding of MP (you know, before I'm super-frustrated because I can't get something work like I want it to).
Again, Colin, I am grateful for your time here, and I see that you are constantly helping folks out so I can only hope to begin to repay the favor one day soon.
-
1
-
1
-
-
On 12/21/2020 at 11:27 AM, kcham said:
I'm guessing that this is going to be something simple that I'm missing
FOUND IT!!! It's amazing how a buffer file actually begins to work when you define it correctly as related to how you want to use it!
Here's the change that did it: (change initialize flag to 1)
old: fbuf 5 1 255 0 1 #Buffer 5
new: fbuf 5 1 255 1 1 #Buffer 5
I was basically telling it to read a new buffer instead of reading the one that was already there. (You know, the one that I wanted to use.)
For reference in case anyone is watching, below is the current configuration of ppost$ in my file. Obviously, everything past the "subout$ = 2" is just temporary for testing and will be much further developed moving forward, but I am very happy to be past being unable to read the buffer
Colin, thank you for spending some of your valuable time on this. I probably should be ashamed that it took me [how many?] weeks to figure this out, but I've been doing this long enough to know that such things end up being some of the best learning experiences. Again, I really appreciate your attention here as it helped maintain the hope that this would be figured out one way or another no matter how frustrated I got in the interim.
ppost$ #entire postblock added,ev121120_0644 #saves NC file as a buffer in order to put order of operations/filename list in proper places sncfile = spathnc$ + snamenc$ + sextnc$ sauxfile = spathnc$ + snamenc$ + sextaux$ sbufname5$ = spathnc$ + snamenc$ + sextnc$ spathaux$ = spathnc$ snameaux$ = snamenc$ auxprg$ = 1 newaux$ subout$ = 2 *sncfile, e$ *sauxfile, e$ *sbufname5$, e$ *ret_nc, "......nc file closed? = 0 if successful", e$ *ret_rnm, "......renamed to buffer? = 0 if successful", e$ *ret_b5, "......buf5 closed? = 0 if successful", e$ *ret_b6, "......buf5(2) closed?", e$ size5 = rbuf(5,0) *size5, "......should be bigger than zero", e$ string5 = rbuf(5,3) *string5, "......output string5 value?", e$ #return = rename(sauxfile, sncfile) #*return, e$ #"return is 0 if successful & -1 otherwise", e$ #"is the NC file now the aux file?", e$ #return = fclose(sauxfile) #return = remove(sncfile) #return = rename(sauxfile, sncfile)
-
OK, I actually got to work on this quite a bit today. My exploration of the lathe canned cycle helped me fix buffer6 and get it working, but did not help me at all with buffer5.
Pasted below are the new versions of the pcomm_hdr and pcomm_hdrbuf postblocks which fixed buffer6 for me. You'll have to initialize sav_rc6 at a value of zero in order for pcomm_hdrbuf to work. Notice that I was able to use a .txt file extension with no problem on buffer6 once I played with the lathe canned cycle enough to see that that was not the problem. (So I was wrong in my previous post when I said it looked like that was part of the problem.)
pcomm_hdr #output to code header before motion #pcomm_hdr added new,ev121120_0644 s_dwl_txt = scomm$ result = strstr(s_dwl_sep, s_dwl_txt) if result, [ s_dwl_tm = s_dwl_txt s_dwl_txt = brksps(end_str_ix$, s_dwl_tm) s_dwl_tm = "F" + s_dwl_tm dwl_tm = scan("F", s_dwl_tm) string6 = drs_str(2, dwl_tm) + ";" + s_dwl_txt ] else, [ dwl_tm = dwl_def string6 = drs_str(2, dwl_tm) + ";" + s_dwl_txt ] sbufname6$ = spathnc$ + snamenc$ + "234" + ".txt" size6 = rbuf(6,0) string6 = wbuf(6,wc6) pcomm_hdrbuf #read buffer 6 for dwell note output #pcomm_hdrbuf added new,ev121120_0644 = if sav_rc6, rc6 = sav_rc6 else, rc6 = one size6 = rbuf(6,0) if size6, [ while rc6 <= size6, [ string6 = rbuf(6,rc6) *string6, e$ sav_rc6 = rc6 ] ] return = fclose(sbufname6$)
Pasted below is my current state on ppost$. It's quite "dirty" right now as I've been trying different combinations by commenting and uncommenting things as I saw what the results were. You'll need to initialize several variables at a value of zero (ret_nc, ret_rnm, ret_b5, ret_b6) for it to work as is. Note that none of these variables receive the "successful" value in their current state.
ppost$ #entire postblock added,ev121120_0644 #saves NC file as a buffer in order to put order of operations/filename list in proper places sncfile = spathnc$ + snamenc$ + sextnc$ sauxfile = spathnc$ + snamenc$ + sextaux$ sbufname5$ = spathnc$ + snamenc$ + ".txt" #sbufname5$ = spathnc$ + snamenc$ + sextext$ #sbufname5$ = spathnc$ + snamenc$ + sextnc$ #sbufname5$ = "K:\Corp\Engineering\Programs\Eddie\mcamtemp\mct.txt" #sbufname5$ = "C:\Users\evanek\Desktop\mctemp" ret_nc = fclose(sncfile) ret_rnm = rename(sncfile, sbufname5$) ret_b5 = fclose(sbufname5$) ret_b6 = fclose(five) auxprg$ = 1 newaux$ subout$ = 2 *sncfile, e$ *sauxfile, e$ *sbufname5$, e$ *ret_nc, "......nc file closed? = 0 if successful", e$ *ret_rnm, "......renamed to buffer? = 0 if successful", e$ *ret_b5, "......buf5 closed? = 0 if successful", e$ *ret_b6, "......buf5(2) closed?", e$ size5 = rbuf(5,0) *size5, "......should be bigger than zero", e$ string5 = rbuf(5,3) *string5, "......output string5 value?", e$ #return = rename(sauxfile, sncfile) #*return, e$ #"return is 0 if successful & -1 otherwise", e$ #"is the NC file now the aux file?", e$ #return = fclose(sauxfile) #return = remove(sncfile) #return = rename(sauxfile, sncfile)
So I'm still pulling my hair out on buffer5. Is it because it's at the end of everything in ppost$? Does MP treat buffer files differently there? As before, I can watch the state of the files and see that the "rename" is working: The NC file disappears, and the filename given for buffer5 appears with all of the data from the NC file in it. However, I can't find any combination of closed/opened/initialized files that allows MP to read buffer5. Try again tomorrow...
-
No problem, Colin. I'm grateful for you having a look at it no matter what timeframe is possible. Frankly, as much as I see your name all over the place when it comes to Mcam posts, I don't know how you have time to help anybody. I haven't gotten much chance to look at it myself since my last post. (When your planning/scheduling department refuses to do any planning or scheduling for the last month of the year - assuming they actually do any of it during the remainder of the year, then it creates a programming emergency the first 2 weeks of the year once they realize what they should have been having me do during their month off.)
In my current copy of the post file, I have an fclose (albeit commented) in the position you suggest above. I uncommented and played with it a little bit yesterday afternoon before I left the office, and I did not realize any positive results.
This morning I'm playing with it from a little different direction. I see that the real number buffers are working just fine, but that the string buffers are not working at all. For that reason, I decided to backtrack and play with the lathe canned cycle output a bit since it uses buffer3 which is a string buffer. I had originally turned the subprogram and canned cycle capability off in my control definition because the machine this is meant to serve only takes longhand G-code, so I turned those back on for the purposes of playing with it. Then I created a canned rough operation so that I could look at how this processes since I am assuming that it would still work from the original download of mplmaster. I'm still playing, but here's what I've seen so far:
1. When I comment the original "sbufname3$ = spathnci$ + snamenci$ + sextext$" and add in "sbufname3$ = "C:\Users\[username]\Desktop\mctemp\LcC.txt"" as the alternative, I get the same error when posting that I've been getting when trying to use buffer5 or buffer6 which is that it cannot read the buffer.
2. When I then comment the "sbufname3$ = "C:\Users\[username]\Desktop\mctemp\LcC.txt"" and add in "sbufname3$ = spathnci$ + snamenci$ + ".txt"" as the alternative, I still get the same error. (Original "sbufname3$ = spathnci$ + snamenci$ + sextext$" still commented)
3. When I uncomment the original "sbufname3$ = spathnci$ + snamenci$ + sextext$" and comment the other 2 alternatives mentioned above, there is no error, and the lathe canned cycle output looks correct at a glance.
So far, it looks like the .txt extension may be a problem even though it works for the real number buffers just fine. I also notice that (I think...haven't looked too deeply into it) that the post never uses a wbuf to write to buffer3. It gives it sextext$ as an extension, and then it appears to just write to it using the ext output stream (which I'm already using for something else that may or may not interfere) before using rbuf to set string3 for output. Not sure where all that's leading me just yet, but I should have a few more hours to play with it this morning before I have to temporarily move on to some other programming to keep the shop happy.
-
1
-
-
Sorry, everyone... When I gave my disclaimer above about the post being "ugly", I didn't realize the HUGE difference in the output once you uncomment the ppost$ block. In order to see what I was seeing, you will need to comment the last 3 lines of the ppost$ postblock.
On 12/25/2020 at 8:03 PM, Colin Gilchrist said:Then rename either the NC File or Buf 5, (I would recommend testing the argument order).
I would recommend moving the 'newaux$' command variable, just after 'auxprg$ = 1', so that you change 'subout$' after invoking a new Aux program.
I haven't done much testing with the argument order Colin suggested above. I did some testing on this, but did not realize any meaningful results. I have moved the location of the newaux$, but that will come into play after I somehow get past this buffer problem. #return = fclose(sauxfile) #return = remove(sncfile) #return = rename(sauxfile, sncfile)
-
I see this morning that I had the read/write variables for Buffer6 called incorrectly @ pcomm_hdr & pcomm_hdrbuf. In my haste, I had used rc1 & wc1 instead of rc6/wc6. I have corrected that in my copy of the post, but I still get the same error which seems that MP is unable to access the buffer file to write to it/read from it even after it is successfully created.
Also to test, I had Buffer1 (which is a real number buffer that was already setup in the mplmaster post when I downloaded it) output to the same file path as my attempted string buffers (Buffer5 & Buffer6). B1 outputs there fine so I know I don't have a problem with user access to the path/location of the file. Once I saw this, I suspected that my problem has something to do with the fact that I am trying to use string buffers. Just to see what happened, I temporarily changed the 1 in the 5th place of the fbuf statement for B6 to a zero (to tell MP it was a numeric buffer instead of a string buffer), and I don't get any errors while posting. The txt file is created and populated with a lot of numeric gibberish (not sure where it comes from, but that probably doesn't matter in this case). Changed that 5th place back to a 1, and went right back to getting the error saying that it cannot access the buffer file. Not sure what that means yet, but I figured it might be a clue to someone else.
-
The attached NC file would be the one that I want to read in as a buffer
-
Please see attached Z2G. I have shortened the mcam (and subsequently the NC) file to keep from sharing info that I am not allowed to share, but that should not change the problems I'm having. Please note that, after creating this post, I decided to temporarily bypass the problem so that I could work on further developing the post to meet the other demands I have for it. Currently ppost$ is commented so that I can bypass that area until I'm ready to come back to it. It also looks quite a bit different from my original posting because I tried several things to solve the issue before commenting the area and moving on to other development tasks in the post, but the guts of what I originally posted are still there even though some of it is commented between other additions. The post is quite "ugly" right now because I have a lot of things still in the process of development, but the problem outlined above should still be readily apparent.
Since creating the post, I have also (right before I stopped working on it for the holidays last Friday) decided to add Buffer6, and I appear to be having the same problem with it in a different area of the post (pcomm_hdr & pcomm_hdrbuf). Please know that I threw this area of the post together quickly right before the end of the day so there may be some other problems there that I haven't discovered yet.
The items going to the lcc ouput stream are the entries that I want to add back to the file as an "order of operations/filename" list
-
On 6/6/2002 at 9:20 AM, Jim Evans from CNC Software said:
PPOST. This call is made at the end of processing after all files have been closed and before exiting. Using this postblock, you can open the NC file as a buffer and read the lines of code one at a time, doing a renumber and then writing them back out to a temporary file. Once complete, delete the existing NC file and rename the temp file to NC.
Anyone willing to share an example of the code used to do this? For some reason, I can’t read the buffer that the NC file is saved to. Thx
-
So I'm creating a post for a machine which is usually a conversational machine, but can also read NC-style code when needed. The machine uses a main part file (the .WAR file), and then the NC-style program is stored within a sub-file (the DIN file) which is stored within the .WAR file. The WAR file is a bunch of gibberish code with the text of the DIN files in it (surrounded by codes which cause the DIN files to be separated into separate files within the WAR file when the WAR file is loaded into the machine.)
I want the names of all of the DIN files to show up in each individual DIN file. Since I have to wait until they are all named before I can do this, I am trying to use ppost$ to go back and read all of the filenames so that they can be output as comments within all of the DIN files. You know ... the old "save the NC file as a buffer, then read the buffer... ..." thing. Most of this I have already figured out, but the problem stopping me from going there is that I am so far unable to get MP to read the buffer file.
I've read about this method many times, but this is the first time I actually need to do it. I'm guessing that this is going to be something simple that I'm missing, but I'm blinded by frustration at this point and getting nowhere! Please see what I've done below and set me straight where needed if you would be so kind. (Also, please note that the things I've pasted below are a very simple skeleton of what I'll end up doing, but I'll build all of that once I get past this not being able to read the buffer thing.) Thanks,
I can see that there is actually a TXT file created when it hits the "return = rename(sncfile, sbufname5$)" line, and I have opened the file to confirm that the data from the NC file is actually going in there. However, the value of "size5" when I force it to output is zero, I get the error pasted at the very bottom when it hits the "string5 = rbuf(5,1)" line, and there is no output when I try to force output of "string5" just for testing.
#Buffer 5, used to output order/filename list,ev121120_0644
wc5 : 1 #Initial count for write buffer 5
rc5 : 1 #Initial count for read buffer 5
size5 : 0 #Buffer 5 sizestring5 : "" #Buffer 5
fbuf 5 1 255 0 1 #Buffer 5
...
ppost$ #entire postblock added,121120_0644
#saves NC file as a buffer in order to put order of operations/filename list in proper places
sncfile = spathnc$ + snamenc$ + sextnc$
sauxfile = spathnc$ + snamenc$ + sextaux$
sbufname5$ = "K:\Corp\Engineering\Programs\mcamtemp\mct.txt"
return = rename(sncfile, sbufname5$)
auxprg$ = 1
subout$ = 2
newaux$
size5 = rbuf(5,0)
*size5, e$
string5 = rbuf(5,1)
*string5, e$
return = fclose(sauxfile)
return = remove(sncfile)
return = rename(sauxfile, sncfile)21 Dec 2020 11:09:42 AM - RUN TIME -PST(2417)- Cannot read record in buffer 5. File associated with issue: K:\Corp\Engineering\Programs\mcamtemp\mct.txt.
-
1
-
-
I'm having the same trouble Kevin E was. Any new tips/tricks on this?
-
I'm using 2017, and they are dirtied when I change them
-
4 minutes ago, Colin Gilchrist said:
What are your Post Development goals? Are you looking to just make edits to existing posts, or will you be building complete new Posts for your machines?
Colin,
Initially it will be making changes to existing posts. I can see that morphing into making major changes to existing posts very quickly. We have everything from Fanuc lathe posts which just need some minor code structure edits to Fanuc 4- or 5-axis mill posts that require slightly more involved code structure edits to Seimens/Heidenhain 4.5- or true 5-axis posts that need some pretty major changes because the software versions in our controls are oddballs. I don't see myself ending up building complete new posts (at least not anytime in the near future). We kind of stopped trying to get outside sources to fix the posts years ago because it seemed that everybody just kind of lost interest when they figured out that we also wanted them to fix the problems that were created when they "fixed" our known issues. We have just been living with some things (hand edits to code) for several years now. Also, in the past, our management core has just thought that you just hire a guy for a week, get him to fix some post problems, and then your are fixed up forever. They don't realize that posts are living things that have to evolve as you do different things in your programs, and we are a low quantity job shop that does a lot of one-off weird stuff on a daily basis. A recent scrambling of my employer's hierarchy has given me a direct superior who believes us so far when we say that a post will always be a work in progress and who is also willing to develop an internal capability for fixing our posts to do exactly what we want. So...I am jumping at the chance to develop our own capability (and hurry before they change their minds). I have been a programmer for many years, and I have played around with our lathe posts some. However, I have always been swamped with programs to do, and I have never had the time to really see anything but the most simple of post changes through to my full satisfaction.
I definitely will follow your advice on the MPMaster above, and I am very grateful for the information and will gladly accept any other tidbits (or 4-course meals) you can send my way.
Thanks again
-
1
-
-
Definitely will do, Colin. Thanks.
-
Thanks for the replies so far... OK, my superiors are sending me to the corporate training course on Basic MP Posts. Any advice for me?
-
On 6/1/2018 at 3:49 PM, Orvie said:
The material will always be available to you this way.
Orvie,
Were there not helpful materials sent home with you from the corporate training class? I had heard that there was a massive book available somewhere which had detailed information for future reference. With things like post processors (and, let's face it, programming in general) the most valuable instruction is not the initial training, but the hands-on experience and solving of problems that happens thereafter.
Thanks,
kcham
-
I am considering taking this course. I'm wondering if anyone out there has taken it and has recommendations about how to prepare. I see in the description of the course @ mastercam.com that there are several knowledge/understanding prerequesites required, and I don't think those would be a problem. Just looking for some advice from someone who has gone through it as far as what to expect from myself as well as the training provided in the course. Thanks in advance for your submissions.
-
Thanks gcode. I checked "Plain" in the tool appearance area, and the tool is now sufficiently displayed.
-
I am running X2 MR2 lathe. I have noticed that, when I use a full radius grooving tool, then the tool will not display in backplot. I have seen this several times now and it is very annoying. In each case, all of the other tools used in the Mcam file display just fine in backplot. That fact makes me think that this is yet another MasterCam bug. Any ideas?
Fadal Subroutine Post
in Industrial Forum
Posted
save-nc-file-as-a-buffer-then-read-that-buffer-except-it-wont-read-the-buffer