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.