Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: glengeniii on July 15, 2010, 11:42:06 PM
-
In VBscript, how can I find out what subroutine is currently open.
Example:
(c:Mach3/subroutines/99999.nc) is the current subroutine opened with a M98 command.
GetCurrentSubroutinefile = linestring 'gets the name of the current subroutine that is open
setuserlabel (1,linestring) 'inserts 99999.nc into userlabel 1
Is there an led that signals when a subroutine is open?
Thanks
George
-
???Um..... Anyone out there? If a M98 P12345 subroutine is currently loaded, is there any way I can request the current sub routine name (M98) in VBscript?
-
There are people here George - I am the 21st person to look at this who doesn't know the answer. :( :(
Tweakie.
-
I've become pretty familiar with the Mach Cypress basic interfaces and I don't think what you are looking for is available from the existing interfaces. I think the only place the subroutine file name is known is inside of mach during gcode execution. :(
Dave
-
OK perhaps I am confused(;-) When you call an outside SUB from Gcode like you want the name appears in the FILE dispaly as
FILE: c:\Mach3/subroutines/99999.nc IS this what you need?? IF so then in VB the Call to retrieve the name is FILENAME
Message(filename) would send that file name down to the error label bar OR you could send it to a userlabel
NOW: This does NOT apply to an "internal" Sub call inside the Gcode file.
OR do you need something else?
-
Interesting...
I didn't know the filename mach reported changes when an external subroutine is called (that's not in the programmer's manual).
I thought Mach just reported the main gcode file name.
Dave
-
(;-) Before Art fries his brain working on strange Gear designs you might want to hook a BrainWave recording device up to him and get the rest of the mach goodies out before he forgets them.
I remember the filename stuff from a ARF function I worked on.
(;-)
-
Thanks for the replies, I really appreciate them. I'm new to VB script and have been struggling with some of it. I created some VB script that I will insert into the M6 tool change file that when a tool change is ran, the script will find certain info in the gcode of the current open file. I use SheetCAM to write my gcode programs, which inserts certain info into the gcode (Processes, Tool Descriptions, Notes and etc.), always using the same format. The script I working on will scan the gcode and post this current info to several userlabels, as well, it will scan ahead to find the next tool change number and post the SheetCAM info that takes place with that tool. This way, while the machine is running, I can see what processes are taking place as well as the next tool number and next processes that will take place so I can get ready for them. It seems to work good, as long as there are no subroutines in the code. The problem that happens is that the script does not recognize that it is in a M98 subroutine, so it scans ahead but does not find the next blocks of SheetCAM info because they are in another file. My current part programs all use a Main Program with M98 calls using the M98(filename.nc) format, not the P word / O word format Ex. M98 P12345. I believe I can get around this by using the M98 P12345 O12345 format because all the gcode will be in one single file. I really don't want to have to edit all my programs that have already been written. Would it be wiser to use a Macro-pump to constantly scan for this info, instead of only searching for the info during tool changes? It seems like it might be a good idea because I could receive real time info of what processes are taking place, not just what processes will take place with a specific tool, Although I'm not sure this is what the Macro-pump is meant for.
-
Scanning with a script may work - you'd have to do some experimenting to see.
I can think of some things that may make it difficult - consider these in the software design.
1) The macropump period is fixed at 0.1 sec - that may or may not be the sampling frequency which will work for you.
2) an alternative to the macro pump is to start a periodic script (See StartPeriodicScript call in programmer's manual). That call allows you to set the period of the periodic script. However, this is new and only available in 3.43.6+
3) scanning the code via an asynchronous routine will mean that you may need to invent software sync/locking tools between threads (if you need the scanner routine to work in conjunction with some other script like your m6). This is not trivial since Mach has no concept of such things at the cypress basic API level.
4) When mach has a gcode file open, I think that mach opens it exclusively as I seem to remember not being able to open a gcode file in an editor when mach has the file loaded. This may cause you trouble since you are wanting to scan the file that is currently loaded into mach.
Dave
-
Not to discourage you BUT that is a pretty ambitious project(;-) for ALL the reasons Dave described and then some. Mach has its limitations with VB interactions. I can see how it could be made to work BUT "I" would ask myself do I really need that much information at the control OR can I get the same info another way that would not TAX mach's processing load.
SheetCam can put out a LOT of operational INFO via it's REPORT engine(hardcopy of the project) AND Mach can tell you what the next tool change is to be.
Here I take the project file and set all the tools and load them into a simple carrosell tooL holder in ORDER of use. Then verify the tool table is correct for each tool. Then as the program cycles tools they are in order and ready to load at tool change time.
Just a thought, (;-) But do let us know how it goes. We all may learn a new trick.
-
Message(filename)
fname= "c:\Mach3/subroutines/99999.nc"
Message(fname) ' this will display the fname to the screen
'I can display the filename
'And see how to assign a variable, display it.
'But don't see how I can set/change the filename from within VB
-
Name Statement
Name oldname As newname
Changes the name of a directory or a file.
The parameters oldname and newname are strings that can optionally
contain a path.
Related Topics: Kill, ChDir
Page 104 of the Cypress manual (;-)
-
I had tried that but with no luck, I get three different error messages. depending on what I attempt
Dim oldname,newname As String
message(filename)
oldname = "c:\mach3\gcode\airfoil.tap"
newname = "c:\mach3\gcode\tt.txt"
newname = "tt.txt"
'Name filename As newname 'path/file access error
message(filename)
Name oldname As newname 'Cannot create a file when that file already exists
message(filename)
'commented out the oldname variable
Name oldname As newname 'The system cannot find the path specified
message(filename)
-
Name "C:\mach3\gcode\drawing1.tap" As "c:\mach3\gcode\drawing11.tap"
BuggyWhipper style (;-)
NOTE: IF you are trying to rename a loaded file then you are going to have to do it a different way. IF you try it straight up you are probable going to CORRUPT mach in a big way.
TO do it, get current file name, get current line#, close file, rename file, reload newfilename, goto line#
(;-) BUT WHY do it at all ????
-
Not to worry, I just checked Art fixed the old problem. Mach will not let you rename the current loaded file(;-)
-
Did you try it? I had tried it and never had any luck with or without the BuggyWhip.
My use is create a nightly script that calls up programs in a sequence. each program has its own fixture offset. The table is filled with multiple different parts to be machined. As it finishes one part it calls up the next. I'm into the lights out production shop. I sleep better knowing I'm making money.
-
YEP it works here. I would not have said anything IF I had not tried it to be sure(;-). Too many things change when you are not looking.
Your lights out approach is not new. You can build a macro with a param call to load the next program based on the param call, then CYcle start the new program.
Just do not end with a M30 but end with the Callingmacro say M549 P Nextprogram. Then instead of ending the program the macro can take control then close the current file , load the param called new file and cycle start the machine to run. Then add the macro call to the end of that file and on and on all night long .
Just a thought,(;-)
-
I think the best approach would be sub calls, Just remember to add the M99 to the end of the file and REMOVE or deactivate any M30's
(tonights run)
M98 "File1"
M98 "File2"
M98 "File3"
etc
etc
etc
m30
%
-
Sorry, I guess I am confused:
Name "C:\mach3\gcode\drawing1.tap" As "c:\mach3\gcode\drawing11.tap"
This renames a files name!
:???
I was asking how to load a new gcode file from VB (or a plugin if need be)
My wish is not to have to edit files to suit the subroutine calls if t all possible
-
Might want to download the manuals(;-)
loadrun("c:\mach3\gcode\roadrunner.tap")
-
I don't mean to hijack this topic but "LoadRun" has been freezing up Mach for me...is this happening to anyone else?
-
Sometimes it runs sometimes it does not run. IF it freezes it is during the REGEN on load.
-
Jason, I looked back through some old trouble notes, try this
Loadrun"C:\mach3\Gcode\Filename.tap"
While Isloading()
Sleep(1000)
Wend
IT seems that mach tries to hop out of VB before the fileload is complete.
Just a thought
-
Terry, Jason,
This is related to the LoadRun topic - below is a little routine I've been using to sync up with the regen operation.
You may find this useful.
DoOEMButton(MachSimRoutine)
call WaitForSimFinish()
Const RegenInProcessLED = 179 ' On during regen & Sim process
Sub WaitForSimFinish()
' the call to start the mach SimRoutine 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(RegenInProcessLED))
' 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
'sleep 10
'message "waiting for end transition"
'sleep 10
' ok the process started, wait for it to end
While cBool(GetOEMLED(RegenInProcessLED))
' wait for process to finish
'message "waiting for sim to end"
sleep(100)
Wend
Sleep (100) ' add a bit of pad time
'message "sim ended"
' ok, best we can tell, the process started and then ended, let's return to the caller
Exit Sub
End sub
-
This was my first attempt but it did work in a dry run.( Note: haven't tried to cut anything yet)
Dim fname1,fname2,fname3,fname4,fname5 As String
fname1 ="c:\mach3\gcode\roadrunner.tap"
fname2 ="c:\mach3\gcode\airfoil.tap"
fname3 ="c:\mach3\gcode\test55.tap"
fname4 ="c:\mach3\gcode\tt.txt"
fname5 ="c:\mach3\gcode\signA1.tap"
For x = 1 To 5
If x = 1 Then loadfile(fname1)
If x = 2 Then loadfile(fname2)
If x = 3 Then loadfile(fname3)
If x = 4 Then loadfile(fname3)
If x = 5 Then loadfile(fname3)
message(filename)
While Isloading()
Sleep(5000)
Wend
runfile()
Sleep(2000)
While IsMoving()
Sleep(2000)
Wend
Next x
message("thats all folks")
-
Thanks Dave I will give it a spin,(;-)
-
That is a really good idea YA-NVR. It just needs alittle more work.
Perhaps use teh question as a front end to load the filenames on the fly
Fname1= Question"File1 name?"
etc
etc
Next how are you going to deal with the fixture offsets between files?
Maybe another question session?
File1OFFSET = Question"FIle1 Fixture#?"
NOTE: You also need to plan on a way to break OUT of the routine in the event you need to STOP IT. I just tried and it was NOT pretty Crashed mach to get out.
Make a screen button to start the process. VERY GOOD idea. (;-)
I think there is a spot available over in the MACH Tool Box for a good AUTO BATCH LOADER (;-)
Might want to start a new thread to continue
-
Thank you Dave, Terry, Ya-Nvr-No and everyone
This seems to work... the reason I took out wait for the regen LED to come on is in some cases the file is aready loaded and that would cause the script to get stuck.
Ya-Nvr-No code looks good cept for if the user Feedholds the current loaded file or other cases that the machine is not moving could cause some issues.
LoadFile"c:\mach3\gcode\roadrunner.tap"
DoOEMButton(MachSimRoutine)
Call WaitForSimFinish()
Const RegenInProcessLED = 179 ' On during regen & Sim process
Sub WaitForSimFinish()
sleep(10) ' we want at tighter loop here
'sleep 10
'message "waiting for end transition"
'sleep 10
' ok the process started, wait for it to end
While CBool(GetOEMLED(RegenInProcessLED))
' wait for process to finish
'message "waiting for sim to end"
sleep(100)
Wend
Sleep (100) ' add a bit of pad time
'message "sim ended"
' ok, best we can tell, the process started and then ended, let's return to the caller
runfile()
Exit Sub
End Sub
-
HIya Jason glad you got it working, I think the auto loader was meant for unatended use where you load up a batch of programs and walk away. Any interaction beyound that is TRICKY. Even just stopping the routine can be tricky(;-) Working on that part. I ran another long test today and it is due to finish about 8am tommorrow. So far so good.
The next test will be to see IF it can handle programs with SUBs. Then test for Users macros That ought to be interesting
(;-)