Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: CNCSarnia on August 12, 2011, 02:06:16 PM
-
I am just getting into screen customization and writing script for buttons. Looking at the Programmer's Reference Manual it should be possible to load and run G-code files using the LoadFile() then RunFile() commands so that hitting the button will cause that piece of code to be executed. The files given in the example are .TAP files and I see that the Wizard files stored in the GCode directory of Mach3 are in that format. The G-code files created normally (using Notepad) are in the .TXT format and although it is possible to load these files and they will run and do some things, the commands that should make the axes move do not function.
Should this approach work? do I need to generate .TAP files and if so how? or am I completely out to lunch with this approach?
Help would be appreciated
-
The .tap/.txt extension will not make a diiference as long as MACH will except it. There is a list in the manual .
Are you refereing to the GCODE Programs or Macro programs. Gcode Programs can ONLY run Gcode commands. A macro program can be a mix of Gcode and MachCB.
Can you post an example ?
(;-) TP
-
I was surprised to find that none of the examples in the Programmers Reference actually work. They all fail on my machine! LoadRun(File) stalls on generating the toolpath. The LoadFile(Filename), RunFile() example does not work because it executes way too fast. RunFile() is executed while LoadFile is still working. The IsLoading() example doesn't work because IsLoading() goes false early, before LoadFile() is complete, or at least before Mach is ready for a Cycle Start. Here is an example that will work for sure. I'm running 3.043.022, but that shouldn't matter.
LoadFile("D:\Mach3\GCode\roadrunner.tap")
' Wait for Load to Complete
Do
Sleep 100
Loop While IsLoading() 'Wait until LoadFile reports that it is done.
Sleep(100) 'Extra sleep time to allow LoadFile to actually be complete
' Run the File
RunFile()
-
In regards to notepad, you may have to change the file type to "All Files (*.*)" for it to "Save As..." an extension other than .txt when writing from scratch. If it already has a different extension and you just hit "Save", it wouldn't change the extension, but otherwise it wants to make it .txt by default.
Give that a try.
-
ALSO MAch does not CARE about the extention name It can be anything other than a control extention such as exe,dll,com,etc
As long as the content is Gcode it can read and run it.
(;-0 TP
-
Nice to know the exact extension limitations. Thanks.
Chris
-
All of the programmers guide examples do work
LoadFile("D:\Mach3\GCode\roadrunner.tap")
While IsLoading() 'Wait until LoadFile is done.
Wend
RunFile()
OR JUST
LoadRun("D:\Mach3\GCode\roadrunner.tap")
(;-) TP
-
OK, I'll check on another machine. I only said I was surprised that they weren't working on my machine. This is a quad-core on Win7 64bit so that may be my problem. If that's it then it's the first script problem I've noticed on this configuration.
Thanks for confirming.
Chris
-
32 bit is the standard.
(;-) TP
-
A lot of things don't work properly without the PP driver installed, and it doesn't work on 64 bit.
I've found that just testing new screens without the driver installed resulted in a lot of things not working correctly.
-
Gerry same here, (;-) TP
-
32 bit is the standard.
(;-) TP
Thanks for stating the obvious.
-
(;-) IF it is so obvious why are people still trying to run 64 bit?
(;-) TP
-
Thanks for your input everyone but I still cannot get anything to work. The G-code file I was trying to use originally was fairly long so I just created a really simple file to test things out :
%
% Test Pogram 1
%
G91 (RELATIVE MOVEMENT)
G0 X1 Z2 (MOVE TOOL)
M2 (END)
I saved this in a new folder under Mach3 then created a "Test" button on one of the screens in Mach3Turn to load and run the file:
LoadFile("C:\Mach3\User GCodes\Test Program 1.txt")
RunFile()
The file is clearly loading because it appears in the G-code listing. Also, when I use the normal "Cycle Start" button the program runs and the axes move. However when I hit the "Test" button the "Please Wait - Generating Path" message flashes and nothing else happens.
I have tried While IsLoading() Wend between LoadFile and RunFile, I have tried Sleep(1000) as well, I have even tried loading the roadruner.tap file as suggsted and that does not work either.
If I put Code "G0 X1 Z2" as script in the button it does what I intended!
Gerry; what is the PP driver you mentioned? It looks as if there is something missing in my setup?
J
-
What version of Mach3 are you using?
What OS are you using?
When you installed Mach3, did you install the parallel port driver?
-
OK did some testing here V.038. NO LPT driver loaded
LoadFile("C:\mach3\gcode\testprogram.txt")
While Isloading()
Sleep(1000)
Wend
RunFile()
This will run fine here EXCEPT it is VERY dependant on the Sleep Value. Get it too short and it blows right by the Runfile() and does NOT start the program. IF I test with a large Gcode file the value need to be larger as well or it fails to start.
LoadRun("C:\mach3\gcode\testprogram.txt")
LoadRun() Loads the program BUT FAILS to start the program . It Fails EVERY time. That tells me there is a serious problem as it blows right by the start command IN a system script as well as the macro script. There is no way to add a wait state in the SYS script(;-)
(;-) TP
-
Retested with the new improved dev verison .044
Same Problem no change
(;-) TP
-
Thanks again guys. For developing programs I am running R3.043.022 (the latest version?) on my laptop using Windows XP, my lathe has R.042.029 running on Windows 7 but behaviour is essentially the same.
After trying things over again it does seem that as BR549 says, the Sleep() part is critical:
LoadFile() - Runfile() does not work
Loadfile() - While IsLoading() - Wend - Runfile() does not work either
LoadFile() - Sleep(1000) - Runfile() does work
Loadfile() - While IsLoading() - Sleep(1000) - Wend - Runfile() also works but no better than the previous set of instructions
I thought that I had tried last two approaches prevously but without success - maybe something else was wrong.
I have checked different sleep times and Sleep(300) (300ms?) is the minimum to load the few lines in my test program.
Anyway, with your help my problem appears to be solved, although the sleep time will presumably have to be extended for longer programs. Unfortunately it also appears that the manual does not give the whole story on what is required for loading and running files.
J
-
Someone should mention to Brian that the While IsLoading is broken, so he can fix it.
-
I have played around some more and I think I understand what is going on a little better:
When one uses LoadFile() it not only loads the file but goes through quickly (ignoring M0/M1 stops and all time constraints) to check for errors, to generate a toolpath and probably do some other things. The latter part seems to take much longer than the actual loading. Putting in a sufficiently long Sleep command allows one to see all of this happening. If the Sleep time is not sufficient and RunFile() kicks in before the loading + other processes are complete, then the RunFile() command is ignored.
This is fine when developing the program because it throws up any errors, however once everything is working OK it results in an irritating delay while the system does its checks. A "Cancel" button comes on the "Please Wait - Generating Path" display but there does not seem to be a way of programing this to cut out the delay.
Any ideas?
J
-
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.
-
HIYA J, There are many ways to do what I think you want. It depends on exacly what you need. MACH3 is VERY powerful in some respects.Here is an example of a simple 4 button function Gcode program that for the most part takes VB out of the equation for motion control yet allows you to use the VB functions to selct moduals to run in any order you choose.
Sample Gcode Program with all moduals included in the Base code. Note that each modual has a SUBProgram place marker (o1,o2,o3,o4)
G90 G54 G80 (etc,etc)
G0X0Y0Z0
/M2
o1
G1 X1 Y0 F50
X1y1
X0y1
X0y0
/M2
o2
G1 X5 Y0 F50
X5y5
X0y5
X0y0
/M2
o3
G1 X10 Y0 F50
X10y10
X0y10
X0y0
/M2
o4
M30
VB Button scripts for buttons, one for each screen button
Code"m98 P1 L1"
DoButton(0)
Code"m98 P2 L1"
DoButton(0)
Code"m98 P3 L1"
DoButton(0)
Code"m98 P4 L1"
DoButton(0)
Load the master Program. IF you want Mach3 to check the code then press the block delete button and mach will preveiw all moduals and display what it can on the screen. To run turn OFF the block delete button.
Next select what modual you want to run and press the correct button. It will MOVE to that modual and run the code . At the M2 line it will stop.
Next select the next modual you want to run and press the button . It will move to that modual and run the code. At the M2 line it will stop.
To end press the button for selection 4 and it will run the M30 ,end the program and rewind back to the top.
IF you want to run the program end to end and in that order then turn ON the block delete and Mach will run it start to finish.
There are Many OTHER ways to do this as well. You could have a SINGLE intelligent button that ASKS you what modual you want to run next AND even be able to input #variable values into play.
Hope that helps, (;-) TP
-
Thanks for your input everyone. I have been occupied with a few other things since last weekend but I will try out the suggestions and let you know how things have worked out.
There is one question I still have? Why do G-Code files created using Teachfile run without any delays whereas those created manually as .txt files have to go through some sort of checking out process when loaded into Mach? I know the latter are .tap files but when you change the file extention of some examples in the GCode folder to .txt and read them in Notepad they look just like manually created files.
J
-
The teachfile/Run process bypasses the NORMAL load/verify process NOT a good thing.
(;-) TP
-
I have been away for the last couple of weeks but have been been able to work on these button scripts from time to time.
Thanks to rrc1962 I have been able to make the TeachFile approach work and I can see its virtues in some instances. However for what am trying to do I think the approach suggested by BR549 fits better. The idea of writing individual subroutines that can be called from the buttons meets my objective of putting most of the code into a separate program and minimizes what is in the button script(s).
The standard Mach3Turn screens (I am working on a lathe at present) do not have a "block delete" button so I have added one. When testing changes to the code one can load the file using the normal "Load" button then as was pointed out, turning on block delete allows the code to be checked through for syntax errors. For normal operation, once the code has been checked, I then have a button to load the pre-tested program and carry out various preliminary steps. At the beginning of this button script are a couple of statements to turn block delete off.
A series of other buttons are then used for the actual tool setting and turning operations. In most cases these comprise some "if" statements to check that it is OK to carry out the operation then the subroutine call.
Overall the system is working very well but there are a couple of points where I have questions:
1. The subroutines (if that terminology is correct) begin with (e.g.) o1 and end with /M2 but I am also calling further subroutines from within these using M98 P10 (for example) to call o10. I have then ended those subroutines with M99 in the normal way. From an operating standpoint this all works OK but on checking through and also in operation one gets the message "Return called with no Sub in effect .... looping" when these further subroutines are called. The operation seems OK but I am concerned about seeing this error message.
Is there a better way of setting up and calling "sub-subroutines"?
2. Is there anywhere where these more advanced programing features are
written up?
Again I am very grateful for all of the help that has been given I have now put together something that works as originally planned although I am sure there are more elegant approaches to the programing. I am sorry that I have not kept the dialogue flowing very well but time working on this has been limited
J
-
YOU really need to post a copy of the file structure showing the full routine. Other than that I would just be guessing as to how you actually coded it.
Your request carried a bit beyond what you asked for(;-)originally.
There is really only 2 ways to setup and call subs. They are both covered in the manual.
(;-) TP
(;-) TP
-
The file structure I am using is based around having a subroutine that does what is required by a particular button and using a statement like Code"m98 P1 L1" then DoButton(0) to call that subroutine. The system I have is along the following lines (suggested earlier.)
O1 (Subroutine to carry out actions for button 1)
..lines of code
M98 P10 Q4 (call further subroutine for operation that is repeated several times)
.. more code
/M2 (end of operation for this button)
%
O10 (subroutine for repeated operation)
... lines of code
M99 (subroutine return)
A similar approach is used for other buttons calling subroutines O2, O3 etc.
The approach works well but during the checking through process, when the subroutines like o10 are reached one gets the error message "Return Called with no Sub in effect ... looping." One can step further through the checking out process by hitting "Cycle start" each time and in practice the program seems to execute as intended. However I am always concerned with when an error message comes up in case something unanticipated may happen at some point. The main question therefore is can one do what is outlined above in a neater way? It is possible to call everything from the button script; the first part of o1, o10 however many times it has to be repeated, then another subroutine with the second part of o1, but that makes things more complicated.
(Maybe I should just ignore the error messages and just get on with the machining!)
In the last reply "the manual" is referred to. Which manual is this? I have looked through the Mach3 G & M code sections, I have Smid's book on CNC progaming, I have all the information handed out by Gerry at the last CNC workshop and tried to find everything that is applicable on the Mach3 website. However I have not seen this approach with subroutines ending with /M2 and being called from a button using Code"m98 P1 L1". A reference would be appreciated.
Concerning the scope of all this: When I started out I knew what I was trying to achieve but really did not know what was involved in getting there. Now I have a much better understanding of all the issues and again I very much appreciate the help that has been given.
J
-
OK IF you are calling SUBS from inside a SUB in Macro you are in UNCHARTED ground there is really no way to predict what will happen IF you run it.
The method I showed you is not really a SUB call it is a GOTO statement left over from the original Code that Mach3 was built on. It just happens to work reliably in a simple 1 time call to a sub without the need to return. Perfect for remote calls from a BUTTON or a goto piont in a GCODE program FROM a macro. It has MANY uses.
Very few people even know it exists . There are still undocumented things in MACH3 (;-) but not as many as there once were. I am all the time plundering throught the original base code and LOOKING in mach3 to see IF any remants remain. (;-)
If you try it otherwise you may NOT have a return point to go back to in the macro and it should error out or maybe something else who knows. Like I SAID uncharted GROUNDS.
USE WITH CAUTION,
(;-) TP
-
OK thanks for the clarification. I did not realize that we are so far into uncharted teritory.
As I said, although I get the error message when checking through, the program does execute as one would hope/expect. I guess I need to carry out some more extensive testing to get a measure of confidence that there are not some hidden issues.
Thanks again
J
-
IF you get it to do correctly please let us know I can add it to the unknown list(;-)
(;-) TP
-
OK, most of the development has been "dry" running on my laptop but I have now started using the program to cut metal - I will let you know how it goes after I have made a few pieces.
J
-
I had an E-mail indicating that a reply had been posted by yingxuy, but it does not seem to be here. However it did prompt me to give an update on progress: I have not posted anything for a while because the screen I created with buttons calling G-code files is working well and I am using it quite often my workshop. Therefore as feedback to BR549 - yes what we discussed earlier does work and I have not experienced any problems.
What I have created is something like a wizard but I think it does more than most I have looked at. Basically it is an automated turn to diameter program for the lathe that allows one to specify start and finishing diameters, nominal roughing and finishing cut depths and the number of finishing cuts to be used. It works out how many roughing cuts are required and carries these out. It then stops after each finishing cut so that the measured diameter can be entered and cut depth adjusted so that one can reliably turn to within a few tenths of a "thou". The cuts are remembered and one can then repeat the exact sequence on additional items being turned.
if anyone is interested please let me know.
J