Hi,
This may help -

Const RegenInProcessOEMLED = 179 ' On during regen & Sim process

Sub WaitForSimFinish()
' the call to start the MachSimRoutineOEMBtn is not synchrounous - in V3 it starts off a separate process that does the mach sim
' this routine attempts to wait until the sim routine is finished.
'
' ok this is an imperfect routine in that there is a potential timing hole.
' not much we can do since mach does not provide semaphores or locks for async operations.

' the "RegenLED" is supposed to be on while the regen (and Sim) operation is in process and then
' it goes off when the process finishes.
' we wait for the LED to come on - that should mean that either
' a) the sim process is in progress, or
' b) the sim process finished before we had a chance to see it was in progress
' then we wait for the LED to go off - that should mean the process is completed.

'message "starting sim wait"
While Not CBool(GetOEMLED(RegenInProcessOEMLED))
' process is not running, wait for it to start
sleep(10) ' we want at tighter loop here
'message "waiting for led to go ON"
Wend

' ok the process started, wait for it to end
While CBool(GetOEMLED(RegenInProcessOEMLED)) 
' wait for process to finish
'message "waiting for sim to end"
sleep(100)
Wend
'message "sim ended"

' ok, best we can tell, the process started and then ended, let's return to the caller
Exit Sub

End Sub ' WaitForSimFinish


Dave

I thought that I would give an update of where I have got to in all of this so that it may be of use to others.

Having got to the point of being able to load and run G-Code programs using a screen button, I spent some time during the last couple of weeks looking at what approach works best when several buttons are to be used. What I am trying to do involves 8 or so buttons each running different pieces of code and I originally thought that having these as discrete programs, loaded each time they were needed, was the best way to go.  However the main problem is that loading the individual program each time is really tedious.  The other problem is that if parameter (#) values are used in the G code, they are not carried through from one operation to the next

The approach I have found works best is to have everything in one (fairly long) program with the code required for each button as a subroutine.  One can then use a # parameter to call up the subroutine required.  The essential parts of the program then looks like this:

M98 P#41 (CALLS THE SUBROUTINE NUMBER THAT #41 IS SET TO)
M2
%
O1 (SUBROUTINE 1)
LINES OF CODE
M99 (SUBROUTINE RETURN)
%
O2 (SUBROUTINE 2)
LINES OF CODE
M99 (SUBROUTINE RETURN)

And so on.  The subroutines can themselves call other subroutines.

The deficiency in this simple arrangement is that When the file is loaded one would really like Mach3 to run through the whole program and carry out all of its checks.  If the  structure is as above, there is really no "path" all the way through for this to occur. This can be overcome by using a starting subroutine, that is called at the loading
stage, which is itself used to call all of the other subroutines in turn, e.g:

M98 P#41 (CALLS THE SUBROUTINE NUMBER THAT #41 IS SET TO)
M2
%
O1 (SUBROUTINE 1 - TO ALLOW WHOLE PROGRAM TO BE CHECKED OUT)
M98 P2 Q1
M98 P3 Q1
...and so on for all of the other subroutines
M99 (SUBROUTINE RETURN)
%
O2 (SUBROUTINE 2 - PROGRAM FOR FIRST BUTTON)
LINES OF CODE
M99 (SUBROUTINE RETURN)
%
O3 (SUBROUTINE 3 - PROGRAM FOR SECOND BUTTON)
LINES OF CODE
M99 (SUBROUTINE RETURN)

An M2 also appears to be needed after the last subroutine return.

One can use a button to load the file using button code along the following lines

SetVar(41,1) 'Set #41 to call subroutine 1'
Rem other # values may need to be set to avoid issues like dividing by zero
LoadFile("C:\Mach3\User GCodes\G-Code File.txt")
Sleep(3000) 'Allow 3 sec for file to load and be checked through'
Rem the time has to be adjusted according to the program length

The button script to run the operation in subroutine 2 is then along the lines:

SetVar(41,2)
Rem set any other # parameters as necessary
RunFile()

One can use "If" statements in the button script to check that various conditions are met before the piece of code is run.

What I have described is mainly what has to be done to make the approach work but a few further points need to be made:

1.The above approach with a two line main program to call the subroutine required gives some strange problems that I don't really understand.  What works better is to have a similarly short main program that calls a subroutine that in turn calls the other subroutines, i.e. 

M98 P10
M2
%
O10
M98 P#41 (CALLS THE SUBROUTINE NUMBER THAT #41 HAS BEEN SET TO)
M99
%
O1 (SUBROUTINE 1)
% etc.


2. It is OK to use user defined macros in the program to set UserLEDs, DROs etc.

3. When carrying out an operation using the button script after RunFile() has been called it sometimes appears necessary to have a short pause (e.g. Sleep(200))
otherwise the operation is missed.


I hope all of this will be of help to someone.

J

I think You are really taking the long way around the block and with that causing problems . About the 2 or 3 loop into a sub array and mach can get lost (known bug).

#vars stay active until mach shuts down they do not clear themselves between programs. Some 500-600 hold their values when mach shuts down(stored in XML)

I would be glad to help if you want it, (;-) TP

Thanks TP,

As I commented at the start of this I am new to programing of this type and have a lot to learn. I cut my teeth on Fortran4  back when, I did some Basic programing in DOS days.  I have now had some experience writing and running G-code programs for my CNC lathe and mill. The next challenge is VB script; macros, wizards etc.  The frustrations are that the available documentation leaves something to be desired, there are glitches in the way Mach3 runs G-code and some things in VB script just do not work - at least not exactly as one might expect.

Returning to the actual subject, I would certainly appreciate more help. I did have problems getting # values to carry through but that could be because something else was wrong.  The approach I have taken allows all the G-code to be loaded in one shot, then, when one hits a button, the relevant part is executed without any noticeable delay.  However if there is a way of loading and executing the relevant piece of code when the button is hit, without the delays that occur while Mach3 checks it through (or whatever happens), then I would like to know how this is done. Dave suggested using Sub WaitForSimFinish() but I have not had any success using this - maybe I did not properly understand how it is used.

J

If all you want to do is execute specific G-code on a button press, why not just use...

code "X1Y1Z1"

Inside a script?  Is there some reason why this won't work in your application?  If you want to use just one script for many buttons and set variables on each button press, there is also an easy way to do that.

Where a couple of simple G-code commands are required I have used this approach and it is OK. The problem I have found is that where machine movement is concerned, if you have a series of commands you need to put  While IsMoving()  Wend after each.  (This came up in " Newbie - having trouble with simple scripts.")  If not the execution of the VB script just blasts through the other commands while the machine movement is taking place and they are basically ignored.  Its a similar problem to when a file is being loaded.

If you are trying to use a lengthy G-code program putting in the extra statements makes the programing tedious and you also end up with large embedded files.  Minimizing the amount of button script and keeping the majority of the code for the machining operation in a separate file just seem a better way to go.

J

You could always write a script that builds the G-Code into a teach file.  You still use the code ("X1Y1Z1") syntax, but instead of Mach executing the command, it writes it to the teach file.  After you're done writing the teach file "CloseTeachFile" then "Call OpenTeachFile()".

The end result is a program that looks and runs like any other program.  No wait states or anything like that.

I have attempted to use the TeachFile approach following what I can see in the literature but without any real success.  Could you just walk me though the statements needed to create a simple one and then call and use it - preferably giving an example that you know works? - I have tried following examples that have not worked for me.

I do have some concerns about the approach partly because you would seem to end up with almost as many statements in the Teaching code as there are in the G-code file it creates.


J

You have to write the code one way or another.  The real advantage to using a script to generate a teach file is that you can generate code interactively.  I have canned programs that are over 1000 lines where the script is only a fraction of that.  Using for loops you can repeat repetitive code without typing each line.  Using conditional statements, you can write one script that generates numerous different programs.

Here is a simple example.  Post a block of code you'd like to run in this manner.


  OpenTeachFile "TeachFileName.tap"
  code "G20 G40 G91.1"
  code "G0 Z0.5"

-------------------------------------------------------
Put as much code as you want here.
-------------------------------------------------------

  CloseTeachFile
  Call LoadTeachFile()    

You can take a look at some of the wizards for good examples as well. They're all scripted, and many use teach files.