save-nc-file-as-a-buffer-then-read-that-buffer-except-it-wont-read-the-buffer

That's the subject of another forum posting addressing the issue

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.

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

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

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. 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! 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.

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.

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. 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 WARtestDIN.Z2G WARtestDIN.Z2G

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