I've been playing with VB scripting a bit tonight to see if I can get a MCC miniLab-1008 ( http://www.measurementcomputing.com/cbicatalog/cbiproduct_new.asp?dept_id=412&pf_id=1522&mscssid=UQAPC1BR1GS68M5XNR5G403JEBKB291E ) to work for I/O in Mach3.  I had used it previously to control a vise, enclosure door and misc in conjunction with a drip-feed program I wrote for our Dyna 2400 mill in the lab.  I'm upgrading and would like to continue using this same unit as I have it and it gives me an excuse to delve into scripting (and then plugins).

Anyhow, I just did a basic script to try and discover the board name of the first MCC board hooked to the system.  Since I'm sitting in my easy chair watching a MythBusters re-run  I of course do not have one hooked up and expect to have an error returned.  So I do get an error, but have yet figured out a way to handle it from within the script (or even get the Long that is returned by the .dll).  I've attached the code and error dialog box that pops up.

So, is there a method to handle/catch errors within the script?  I've looked through the Cypress docs and did not locate anything. Thanks...

Here is the code:
Declare Function cbGetBoardName Lib "cbw32.dll" _
    (ByVal boardNumber As Integer, ByRef boardName As String) As Long
   
GETFIRST = -2
cbGetBoardName (GETFIRST), bName$

I hooked up the above mentioned board today and was able to make it's 'connect' LED blink via a script.  Now I will work on gettign some I/O working via the macro-pump.  Should work OK for thigns like coolant etc.  The board is USB based has 28 digital I/O (24 of them throug a 27 pin d-sub that hooks right to an Opto-22 SSR board) as well as a few analog I/O for just over $100 USD.

I'd still be intersted if anyone knows how to do error handling in the script.

Thanks.

That looks pretty cool. Keep us updated.  Sorry i can't help, i am programmatically challenged

chad

Hi,

Error handling in VBA is done with 'On Error Goto' the target of the Goto is a line label.  There is an Err object that contains all the information you need about the error.  To reset the error handler execute an 'On Error Goto 0'.  After handling the error you can resume execution at the next VBA statement with a 'Resume Next'.

-James Leonard

I was able to get it configured and read one input last night.  I'm going to start working on a 'Setup Wizard' today, which will both make it easier to see what the I/O do and allow it to be configured easier.  The cool thing about the MCC stuff is that the programming interface is (generally) the same no matter what bus.  So you can write one program to allow interfacing USB/PCI/PC104 based I/O.

EDIT: just saw the post above on error handling, Thanks! I did find out how to do error handling - use 'On Error'!

The docs mention the use of a 'declares file', which presumably is a sort of header file but there is no information on its formatting nameing or referncing.  Any ideas.

One of the weak links in the Mach VB is that all the parts of a VB application must be in the one file- either one button script, or one macro. So you cannot have a Declare File. You can, of course, declare (DIM) variables, etc at the top of any file, and you can have multiple subroutines in the file. What you cannot do is call a subroutine that is part of one button script from another button script.

Note a screen can have an init file, init.m1s in the same folder with the screen file. The init code will run before the its screen is opened. You cannot DIM objects there for use in your screen, but you can set DROs, and LEDs for initial values.

Since the Cypress docs talk about things like declare file I assume it would be possible for a better VB environment, just not the way Mach uses the scripting engine.

Hi,

If you want to do a lot of programming for this device, then write a DLL and call it from Mach3 VBA.  If you want to use VB, then write the DLL in VB6, otherwise C++ would be good.  Once you call the DLL you can do anything you want there, subroutines, etc.

-James Leonard

James, the MCC board ships with a .dll a.k.a. the 'universal Library'.  I was just trying to avoid having all the declare statements for the various dll functions in the script itself (rather put them in a header file).  No big deal, just messier looking code.

Idealy, the interface for the MCC boards would be through a plug-in.  But I'm not ready to try that yet.  For now being able to turn things on/off via a script will be fine.

Thanks for the help everyone, I'll work on this a bit more tonight.