Machsupport Forum
Mach Discussion => Mach SDK plugin questions and answers. => Topic started by: dz32 on February 08, 2016, 10:35:52 AM
-
Hi, I didnt see any samples of automating mach3 from VB6,
but I was able to put one together see attached example
hopefully others will add to it as they need more features
and probe the api more
-
the git repository where you can find any updates for this is here:
https://github.com/dzzie/home_automation/tree/master/mach3_vb6
-
One other note I will put in here. I have seen it mentioned allot that after the first time you use the Mach4.CMach4Doc object, then close your program, that you have to restart Mach in order to get a hold of it again.
This is a COM reference counting issue. It must not be properly calling Addref().
If you make an extra call to it manually, then it wont be unloaded from memory when your plugin exits. With this you can start up your plugin and do testing as many times as you want without having to restart Mach each time.
-
Welcome to the forum dz32.
Just had a quick look but this looks like it could be fun.
Thanks for sharing.
-
Thanks for the welcome :)
Another file of interest will be a dump of the (192!) function names and prototypes supported by the IMyScriptObject interface.
For some reason they would not show up in the VB6 IDE so I had to dump them with another tool.
They are syntax color highlighted with VB6 prototypes in the attached rtf.
A listing of just the function names is at the bottom which may be easier to scan.
-
found the documentation on the IMYScriptObject functions and OEM codes:
http://www.machsupport.com/wp-content/uploads/2013/02/Mach3_V3.x_Macro_Prog_Ref.pdf
-
Was just going to send you that - you beat me to it.
You might want to take a look at this http://www.machsupport.com/forum/index.php/topic,6657.0.html
and this http://www.machsupport.com/Mach3Wiki/index.php?title=Main_Page
section 4 and 9 for things like symbolic constants and param strings etc.
Couple of questions:
I see in your readme you say that Mach3 versions after 3.042.020 dont properly register the COM objects in the registry.
As it happens I use 3.042.020 but is there any way to fix things for later versions? Otherwise although this is interesting to play with I'm wondering if it's of practical use as I guess most?/a lot? of folks will be using later versions.
-
Awesome thanks for the links. There is definitely allot of information to take in !
Assuming that the registry keys were not removed for a reason, we will be able to manually add them back in
so that it will work for latter versions. This is on my to-do list and should not be to hard.
For the project I am working on I really want the Mach integration.
It might be nice to be able to use the most current version.
For those curious here is the idea I am working torwards, (trainable CNC paths vrs conventional programming through manual, cam, or scanned/converted paths)
http://sandsprite.com/blogs/index.php?uid=13&pid=377
-
Assuming that the registry keys were not removed for a reason, we will be able to manually add them back in
so that it will work for latter versions. This is on my to-do list and should not be to hard.
I think that would certainly give it more legs
For the project I am working on I really want the Mach integration.
Thanks for the link of what you're up to. I'm not quite sure I understand why you need Mach-automation though.
Once you have your PC program create the gcode - why not just load and run in Mach normally? What am I missing?
-
Thanks for the link of what you're up to. I'm not quite sure I understand why you need Mach-automation though.
Once you have your PC program create the gcode - why not just load and run in Mach normally? What am I missing?
The first thing that caught my eye was using the integration to make the testing and calibration
stages easier. The first test will be something like:
set 0,0 on a parts corner, manually move the gantry around to the various hole centers. hit a button
to record the spot this builds a list in the pc program. go back to 0,0.power steppers, then click another button
to send first point in list to mach, click to send next point and cycle through the list.
This should also be useful latter for quickly transferring hole patterns from parts to mounting plates without
really having to measure.
Other ideas to build on top of it. Maybe I could also break out of the gcode a bit.
Add a layer of logic on top where I can take physically separate gcode files, stack them in a que to run.
still fleshing out ideas but it seems super useful.
-
I've had a bit of a hack and changed a couple of things. See what you think.
Mainly I've changed the class to a module. The problem was that you had to access the methods and properties either via wrappers like mach.<helper> or via mach.oScript.<method>
As there can only ever be one instance of mach it seems easier to just access the object method directly.
So now you could do for example:
mach3.getOEMDRO(800) directly without the need for any wrappers.
Anyway - see what you think.
-
yup looks good, class or module is fine. The reason I was adding wrapper functions around the oScript methods
was so that you had intellisense. I left oscript public so you could still access it directly to get ahold of everything.
type mach dot, and then it will pop up a list of the available functions. once
you select the function, it will then show you the function prototype. Otherwise you have to type blind
and it can not help on misspellings and you have to type the entire method name out manually
wrapping the functions, you can also include some extra functionality. In the git repo I have done this for a couple
such as the RunGCode
Sub RunGCode(singleLine As String, Optional andBlock As Boolean = True)
On Error Resume Next
oScript.code singleLine
If andBlock Then
While Me.IsMoving
DoEvents
Wend
End If
End Sub
for the SendOEMcode you can also specify the argument to be of an enumeration type.
This will automatically display a list of available options you can choose from by name instead of having to
remember (and latter read) just numbers
Public Enum OEMCodes
oem_FeedPerMin = 39
oem_FeedPerRev = 40
oem_JogCont = 204
...
end enum
Sub SendOEMCode(code As OEMCodes)
On Error Resume Next
oScript.DoOEMButton code
End Sub
another feature is to the read and write properties wrappers to simplify the interface
Property Get SpindleRPM() As Double
On Error Resume Next
SpindleRPM = oScript.GetRPM()
End Property
Property Let SpindleRPM(x As Double)
On Error Resume Next
oScript.SetSpinSpeed x
End Property
In order to read or set the rpm with this interface change, now all you have to do is:
msgbox mach.SpindleRPM
msch.SpindleRPM = 1200
I am not sure if modules allow you to use the property get/let construct.
-
I know the extra wrappers look like allot of typing and extra complexity initially, but they really make using the code latter almost brain dead simple and way less typing and way less error prone. it takes memory out of the equation and just shows you what functions it supports, what the arguments are , and in some cases like the enumerations lets you select the argument value you want from a list it automatically displays. Thats the real strength.
-
Ok i did a bunch of testing on XP and win2k. I updated the InitMach() routine to automatically add the missing registry entry if its not found. Now works without problem with the current Mach3 build. I didnt try Vista+, should work fine but you will probably need to "Run as Administrator" for the first time so it has permission to add the registry keys.
The new initilization logic looks like this:
https://github.com/dzzie/home_automation/blob/master/mach3_vb6/CMach.cls#L165
Public Function InitMach() As Boolean
On Error Resume Next
InitErrorMsg = Empty
If Not isMachRunning() Then
InitErrorMsg = "Mach3 must be running"
Exit Function
End If
If Not isMachCOMObjRegistered() Then
If Not RegisterMachCOMType() Then
InitErrorMsg = "Could not register Mach ProgId in Registry. Run again as administrator."
Exit Function
End If
End If
Set mach = GetObject(, "Mach4.Document")
If mach Is Nothing Then
InitErrorMsg = "Failed to GetObject(Mach4.Document) " & Err.Description
Exit Function
End If
IncrementRefCount mach
Set oScript = mach.GetScriptDispatch()
If Err.Number = 0 Then
InitMach = True
Else
InitErrorMsg = "InitMach Failed: " & Err.Description
Exit Function
End If
End Function
-
adding a zip of current snapshot for convenience/archival
-
I know the extra wrappers look like allot of typing and extra complexity initially, but they really make using the code latter almost brain dead simple and way less typing and way less error prone. it takes memory out of the equation and just shows you what functions it supports, what the arguments are , and in some cases like the enumerations lets you select the argument value you want from a list it automatically displays. Thats the real strength.
I have a lot of respect for what you've done. You clearly know your way around COM and the registry. I think you may be forgetting though that there are thousands of seasoned macro writers out there that know the existing calls and OEM codes and constants almost like the back of their hands. They SHOULD (IMHO) be able to use your automation without learning virtually anything new.
Example:
Your way
ReadDRO(axis_x)
The existing way
getOEMDRO(800)
So imagine one of these seasoned users. S/He's looking to read a DRO. He get's the dropdown and he scrolls through looking for getOEMDRO. It's not there. First thing he's going to say is WTF? Then eventually he realizes he needs to use ReadDRO. Second thing he's going to say is WTF have you changed the name for? We've been using getOEMDRO for donkey's years and now it's called something else... It's then going to get even worse because he's going to type 800 for X only to find it doesn't work.
It seems to me to be a real shame because I think what you've done has value.
So, FWIW - if you must have intellisense, I'd suggest you name the wrappers identically to the existing calls and don't introduce new symbolic constants.
Anyway - it's your gig as they say and these are obviously just my opinions and hope none of this p***es you off..
Thanks for sorting the version issue though - I think that's a great step forward. You obviously know your way around the registry - good work.
-
that perspective makes allot of sense. Everything should kept identical to the documentation and expectations of users who are use to using it and know it inside and out. I didnt take that into consideration.
I am totally new to these functions, so I am trying to digest whats there, find what I will need and make it as simple to use as I can for me. I know I wont be using it everyday, a project here, a project there. For me I will need all the major functionality to be hand fed to be with the intellisense lists and enumeration types otherwise I will have to dig out the docs every time for every task.
The beauty of open source is it doesnt have to be A or B. The way it should be is exactly the way it makes sense to the people who use it. Not offended at all ! Consider my contribution the answers and code bits for the referencing counting and component registration. Grab that and run with it :)
-
I think your contribution is great. I know quite a few folk have tried to sort the automation interface out (I'm one) and AFAIK you're the first to have done it. Certainly if anyone else has - they haven't shared it AFAIK.
Like you, I won't be using it every day as generally you can achieve a hell of a lot with just macros. However I have a couple of ideas that this may well be ideal for.
Any help you need - I'm sure you'll get it here.