save NC file as a buffer, then read that buffer ... except it won't read the buffer

[kcham]

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 size

string5       : ""      #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.

[Colin Gilchrist]

On 12/21/2020 at 12:27 PM, kcham said:

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 size

string5       : ""      #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.

Can you please attach a copy of the Post you are using, the Mastercam File you are using for testing, and the text file you are trying to read in as the buffer?

You set Buffer 5 File Name to <path>mct.txt.

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've got a few ideas to try and test, but would prefer to not have to create all the test code from scratch. 

 

[kcham]

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

[kcham]

The attached NC file would be the one that I want to read in as a buffer

[kcham]

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.

[kcham]

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)

[Colin Gilchrist]

On 1/4/2021 at 2:01 PM, kcham said:

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)

Hey, sorry I missed your reply.

I'll try and dig into this issue one of these evenings after work, when I have some time available for testing.

Out of curiosity, after you performed the 'file rename' to create the new Buffer File, filled with data, did you try using the 'fclose' function to close the file, before 'reading record zero' to get the buffer size? You might be getting an error because the file is still open in Memory, even though you see the new file being created "on disk".

[kcham]

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.

[kcham]

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

[kcham]

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)

[Colin Gilchrist]

I'm glad you finally figured out your issue.

Playing and testing your code can lead to some surprising insights into how any system works, especially MP.

One tip I can give you for testing: use the 'mprint' function.

'mprint' can be used to display a string to the user (you), and is an excellent way to see what the "state of a variable is", while the Post is running.

Mprint displays a dialog box, that contains one-or-more strings. You can add a "carriage return and/or line feed" ASCII Character, to a string, to allow you to get multi-line output in the Mprint dialog box.

result = mprint("This string will be displayed to the user")

You can use a String Literal (anything between a set of Double Quotes) ["This is a string"], or you can put in the name of a String Variable, which then gets displayed in the dialog box.

One thing to be careful of; when you display a String with Mprint, there is no "name of the string" that is shown by default. So I will almost always use 2 Mprint statements, in my Posts. The first Mprint is used to "tell the user what string is being displayed next".

      strb5 = rbuf(5, rc5) #Get next string from Buf 5
      result = mprint("The next string displayed has been read from Buffer 5")
      result = mprint(strb5)

 

Have you watched my MP101 Class videos on YouTube yet? There are 28 videos that cover "Basic Post Processing". Once you get through watching those, I also uploaded one of my old "Buffer Classes" to YouTube as well. So you might get some benefit from watching that content, even though you are already using more advanced Post logic and concepts with what you are currently doing.

[kcham]

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.

Quote

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

[kcham]

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

[Guest]

Thanks for sharing!

[Colin Gilchrist]

Another development tip for you:

You should learn to use the Mastercam Code Expert File Editor, for developing Posts.

The reason is that MCE has "code auto-complete" built in for the MP Language. As you begin typing, the MCE will display a list of Post Blocks, Variables, Strings, Operators, and Functions, which start with the 'letter that you begin typing'.

When that 'list' pops-up, you can hover your cursor over each 'displayed name', and a little help-tip will pop-up, describing the item, and potentially showing a sample of usage.

For example, look up the Operator 'drs_str' in this auto-complete list, and it will give you a brief description of how it is used.

All pre-defined variables should have a Dollar Sign as the terminator for the variable name. When you type in a correctly-spelled variable name in MCE, the variable will turn 'blue', indicating that MP has recognized it a pre-defined.

User-defined variables should never include the Dollar Sign character.

All String names in MP must begin with the character 'S'. Numeric Variables can begin with any Alpha Character. (No variable may begin with a number.)

Variable names can contain both alpha and numeric characters, and the Underscore character, but those are the only valid characters allowed.

MP is a "column dependent" language.

This means there is special significance if a variable name or post block "begins in the 1st column". Whenever something starts in Column 1, that thing is a "definition". No other use of that variable or Post Block Name, may start in the 1st column. This ensures that things are defined in only one spot, within the PST script file.

You'll notice that all other "Post Lines", will be indented in the PST file. Standard indentation is 6 space characters.

[SlaveCam]

On 1/15/2021 at 8:02 PM, Colin Gilchrist said:

You'll notice that all other "Post Lines", will be indented in the PST file. Standard indentation is 6 space characters. 

I wish Code Editor had a beautify code option, or even re-indent feature. Many posts I have edited have indentations all over the place, with spaces and tabs mixed.