Is there a way outside of creating a plugin to get around the size limit of an .m1s file? When I try to debug any .m1s file over 65kb it says "Error -  Not enough storage to complete this operation. Any ideas?

wow - you must have a big script... I thought I was the only one to have run into that trouble.
I've seen that happen when a single m1s file gets large for the mach script editor.

I found that while a single large source file can cause that trouble, but if you use #expand to make one logical script out of multiple smaller source files that you can avoid the problem.

I did this general approach:

main script body m1s file with entry points etc

then put additional parts on other source files via
#expand <part 1>
#expand <part 2>
etc
(You can look up the #expand syntax in the mach programmers ref manual - the above is not a working example)

The odd thing is that you can still load the entire thing into the script editor and the editor will expand it all out for debugging etc.
So loading multiple expanded scripts is ok, while a single larger source script may fail.

Dave

The problem with expand is that it requires 3.43.06 and the target version is 3.42.040. Is there a way to create a dll in like VS2010 Visual Basic? What I run into there is I don't know how to import the DRO and Led conditions and values. Any other ideas?

Yep, that's the problem. You can make a DLL and call things in the DLL from a mach script, but you're right that you won't magically know anything about mach DRO or function calls etc inside the dll.
The newer tools in 3.43.xx are not in 3.42.xx because they were invented later.
I'd suggest considering moving to mach 3.43xx so you can use the tools it provides.
Other solutions fall into the category of "you can program up most anything if you want to expend enough effort..."

Dave

Other solutions fall into the category of "you can program up most anything if you want to expend enough effort..."

Would you care to elaborate on that? I have spent hundreds of hours already on this project. Most of it has been learning one aspect or another of mach3 or VB. 

Sorry, I'm was not trying to be flippant, just noting that since you have a computer and multiple programming languages available, that with enough effort there is almost always some solution to the problem at hand. Of course that does not mean that the solution will be considered "reasonable" - that depends on what constraints you assume.

Some examples for this case:
1) Move to mach 3.43.xx - this lets you have larger scripts via #expand; requires a mach version shift.
2) Split the script into smaller scripts and invent a way to call the smaller scripts as needed. May require refactoring the script's functional split. May also require macros calling macros - and then you get to invent your own IPC synchronization methods.
3) If the limitation is in the editor, one could write a new script editor (I'd done that and essentially implemented  #Expand before it was added to mach - that let me deal with the large MSM scripts while #Expand was being implemented).
4) you could move all the logic into a DLL written in your language of choice and invent a way for the DLL to call back to cypress/mach to get DRO/LED info.

It's all just a matter of the amount of effort you can/want to expend.

Dave

What's "reasonable" depends on the level of desperation or determination, doesn't it?    I was thinking of trying to write a wrapper for the c++ headers that I needed and then finish in VB.Net.

Thanks a lot for your time and ideas.