Hello Guest it is March 28, 2024, 05:11:50 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - eabrust

Pages: 1 2 3 »
1

Hi all,

I've been working a converting/porting a video camera based plugin I have written for another machine control, over to Mach 4 specific version.  CamCopy M4 is in a fairly functional state now, and I wanted to see if there is any interest in it, either from those that would use such a plugin if offered in the future, or those who may want to help test it out for fun. 

Please check out this demo video:  https://youtu.be/g5mtL2sSXkQ

The video demo  gives a bit of a demo of its basic functionality.  It saves recorded data to either DXF for CSV formats that are readily usable in most all CAM software.   I've primarily been testing w/ M4 ver. 2.4612 and CNCDrive UC100/400 machine controllers. 

My main goal is to reach out to see if there are any Mach4  users who would be up for helping test it out on their machines.  Volunteers would need a usb microscope camera (primary needs are that camera can achieve ~ 30fps @ 640x480), and a machine setup w/ Mach 4.  The program runs along side Mach4 and connects via the IPC interface, so it doesn't need to be installed or modify your Mach4 installation in any way.  The video linked above should give a fairly good idea of the setup.

I don't imagine that CamCopy M4 will be 100% bug free at this point, or work with any and all versions of Mach4 and motion controllers out of the gate, but that's why I'm looking for those that are willing to help try it and provide feedback.  In exchange, volunteers will get a license at no cost.  If interested in being a tester, please send me a private message. 

Thanks for looking, I am interested in any feedback or suggestions anyone may have.

regards
Eric


2
Mach4 Plugins / Re: Mach4 IPC wrapper in VB, looking for some help please
« on: February 23, 2022, 09:55:06 PM »
Out of curiosity/frustration, I uninstalled Mach Build 4612, and loaded an old version, Build 3804.  Without touching any of my test program code or wrapper functions I had already, the SignalGetHandle function now works, I see that the probe signal ID is actually 161, and I wasn't loosing my mind at not being able to get  SignalGetHandle it to work....  I was also able to use the return signal ID value and get the actual probe signal state of true/false, which was what I was after.

Either something in the MachIPC.dll files is different or broken since the x64 version was split out, or  something related to 64 bit version is different is my guess.  Not sure how to confirm that.  Or another thought, have functions been changed over time without updating the API help file?

I can build my test app as a 32 bit version when using Mach Build 3804 referencing the Mach4IPC.dll and things work.  But the test app would only connect/talk to Mach 4 Build 4612 when built as 64bit or AnyCPU, and referencing the Mach4IPC-x64.dll.  If I tried to compile 32 bit w/ Build 4612, nothing worked, and I am on a 64bit Win10 pc.

Any other ideas on what I'm seeing between the different builds of Mach4 and the IPC interface?

I'd like to try porting and developing an app of mine over to Mach4, but seeing issues with trying to do so currently since I get different results via the IPC interface with different Mach builds.

Thanks again,
Eric


3
Mach4 Plugins / Mach4 IPC wrapper in VB, looking for some help please
« on: February 22, 2022, 08:20:24 PM »


Hi all,

I have been working on a VB.net wrapper for the MachIPC.dll interface, and have made good progress by scouring the forum, reading the API help file, and a lot of trial and error, way more error than good trials :) .  My goal is interfacing a probing application of mine written in .Net to Mach4 thorough the IPC interface.

I have a decent amount of functionality working in a test app, except for a few problems I want to see if I can get some input or help on.

For starters on where I’m at with success: I can jog, read DRO positions, get probe position data and hit status from  a G31, read the controller state, send MDI move commands, etc.  That all worked relatively straight forwards without much hassle, and creating the wrapper functions was not much of an issue.

What is currently giving me issue is trying to get status of signals (such as probe input  active or not), so I can display the equivalent of a status LED. 

As I take it, first you have to poll Mach 4 to receive the signal’s current handle, then get the status of the signal using the handle in a second call. 

My issue is I can’t get past the first call to get the handle, I get an error response of -28 (MERROR_IPC_NOT_READY). 

For reference, my wrapper function definition is:

Code: [Select]
<DllImport("mach4ipc-x64.dll", CallingConvention:=CallingConvention.StdCall, CharSet:=CharSet.Ansi)>
        Public Shared Function mcSignalGetHandle(ByVal mInst As Integer, ByVal sigid As UInteger, <Out> ByRef handle As UInteger) As Integer
        End Function

And function call is:
Code: [Select]
            Dim sig As UInteger
            err = CType(Signal.mcSignalGetHandle(0, 164, sig), mc.mcError)

The above assumes I’m trying to get the handle of signal #164 (which I’m hoping is the probe input, but I’m probably off a few…)
When my demo app loads, I do call mcIpcInit(127.0.0.1)  , and get an error response of 0, so I’m definitely connecting and getting a good response from the MachIPC.dll initially, and many other functions work great even before I used mcIpcInit().

I’ve been struggling with the mcSignalGetHandle() long enough, time to ask for help.  If anyone has any input on what I’m messing up to get the signal handles back, I would greatly appreciate the help and input.  Or is it possible there is an issue on the M4/Lua side?

And a bit of other info, my testing is being done w/ Mach4 build 4612, I'm using the MachIPC-x64.dll, and compiling any cpu

thanks in advance for any input,
Eric

4
Video P*r*o*b*i*n*g / Re: Best setup for probing a trumpet mouthpiece
« on: November 18, 2015, 06:29:08 PM »


Here are the problems I had to solve: the software can't handle both big diameter ruby tips. 3mm with a step over of 0.5mm won't happen.
If you need a small step over like 0.2 or 0.3mm you need a 1.5 or 1.0 ruby tip.

Inviato dal mio iPhone utilizzando Tapatalk

Tony,

Glad you got all sorted and are making useful measurements!  You are correct about the probe ball size relative to stepover... but the issue is really just trigonometry related.  As the ball becomes large compared to the stepover, any 'error' in how squarely the probe hit occurred relative to the surface of the part translates into large relative error of where the touch is calculated to have happened.  That error then compounds in the following moves.  Thank you for reporting out your results and feedback.

You're also right that deflection errors can be calculated out.  The 'mill' version of ProbeIt can take it out by probing a ring gauge, but not the 'lathe' version.  Main reason is that you can really only hold the probe one way in a mill, but you can orient a probe in several different ways on the lathe... tip along x, tip along z, held at an angle, etc...  so I didn't want to add an additional complication on the lathe version (which was really just an experiment)

Rich,
Any easy workaround to a screenset conflict is to just make a new profile by duplicating your existing profile, and revert that copied profile to a standard screen set and radius mode (if diameter mode is your standard work enviornment).  You can then use the wizard from that profile without issue.

regards,
Eric Brust / CraftyCNC
 

5
General Mach Discussion / Re: MachTurn G31 problem
« on: December 05, 2014, 08:07:10 PM »


Hi Mav,

FYI, the wizard you downloaded is mill specific, and geared towards working in X/Y plane.  I'm working on a lathe specific version (X/Z plane).  What you have may not do what you want, and may have issues if you are in 'diameter mode' on lathe. 

I don't know why your code wouldn't work, do you have DRO 818 and 1151 in your lathe screenset somewhere for the macro to pull values?  that's all I can think of.  I can just MDI G31 commands, and they work for me.

Here is some rough code that I've used before to set the XDRO to a value based on a measured part (ie, if put a 2.0" bar in, I have to touch off and set X=2.0).  Note this is some rough code based on cutting/pasting a portion out of a larger script, and I've replaced some references to DROs with just numbers so it should run if you just paste it into a button.  I don't guarantee it is error free :)  test with care.

Not sure if it helps, but hope it does.

regards,
Eric

Code: [Select]
'set some variable, these are hard code for paste to button, but you could load DRO values...
frate1=1 ' feedrate
Xstart=GetoemDRO(800) 'current position
Probemax=1.0
Xset=2.0    ' this is the diameter of the stock to touch off on
Xend=Xstart-probemax
xretract=.1 ' how far to pull back after touch
hittol=.002 ' this is a small amount to see if hit or missed


' here is probing
Code "G31 x" & xend  & "F" & FRate1
While IsMoving()
wend

'================
xhit = GetVar(2000)
yhit = GetVar(2001)
ZHit = GetVar(2002)

if xhit=0 and yhit=0 and zhit=0 then
sleep(15)
xhit = getoemdro(800)
yhit = getoemdro(801)
zhit = getoemdro(802)
else
end if
'=================

if abs(xHit-xend)<HitTol then
message "missed target"
code "G01 x" & xstart
while ismoving()
wend
exit sub
end if

 
'xset = xset + (ProbeD/2) ' Adjust up  by Probe Radius to set Z at ball center (you may not want this, as I do this when using a probe with ball tip)
SetoemDRO(800, xset) ' Set XDRO to center of ball, bottom of ball as surface variable.
sleep(1000)


xclear= xset+Abs(xretract) ' retract away after touch.
Code "G0 x"&xclear
While IsMoving()
Wend


And a similar snippet for probing from right to left in Z

Code: [Select]

'set some variable, these are hard code for paste to button, but you could load DRO values...
frate1=1 ' feedrate
Zstart=GetoemDRO(802)
Probemax=1.0
Zset=2
Zend=Zstart-probemax
zretract=.1
hittol=.002 ' this is a small amount to see if hit or missed



Code "G31 z" & zend  & "F" & FRate1
While IsMoving()
wend

'================
xhit = GetVar(2000)
yhit = GetVar(2001)
ZHit = GetVar(2002)

if xhit=0 and yhit=0 and zhit=0 then
sleep(15)
xhit = getoemdro(800)
yhit = getoemdro(801)
zhit = getoemdro(802)
else
end if
'=================

if abs(ZHit-zend)<HitTol then
message "missed target"
code "G01 z" & zstart
while ismoving()
wend
exit sub
end if


'zset = zset + (ProbeD/2) ' Adjust up  by Probe Radius to set Z at ball center (you may not want this)
SetoemDRO(802, zset) ' Set ZDRO to center of ball, bottom of ball as surface variable.
sleep(1000)


Zclear= zset+Abs(zretract)
Code "G0 z"&zclear
While IsMoving()
Wend


6
General Mach Discussion / Re: MachTurn G31 problem
« on: December 04, 2014, 09:57:27 PM »
Hey Mav, 

What version of Mach are you running?

I have used G31 commands in turn via both MDI and in VB macros.  I am using Version R3.043.066.  What does a snippet of your code look like?

Regards,
Eric

7

How do I enable a “wait until line is finished” type of logic into movement and non-movement commands?



Can you break your movement and non-movement commands up into different subroutines / functions, then call the subroutines from  a main routine in the order/timing you need?


sub main()
Call Sub1
sleep(10000)
Call Sub2
sleep(200)
End Sub


Sub Sub1()
Dim temp As Double
code "g01 x 10 f 40"
While IsMoving()
sleep(10)
Wend
End Sub

sub Sub2()
Shell("notepad.exe")
code "g01 x 0 f 40"
temp = FileLen("c:\temp\test.txt")
Print temp
End Sub

and so on, breaking your routine into chunks you call in order with time delays as you need.  This is also where you could make use of #expand or runscript to repeat chunks of repetitive code, or just keep calling back to a given sub again and again.



Sorry if this isn't remotely close to what you are trying to accomplish.

Regards,
Eric

8
I've put out a new revision of ProbeIt wizard, V1.1.2 is available for download.

Some of the changes:
   ·   Records Z postions in DXF now (can do 2.5D parts with various profiles at different elevations).     
   ·   Warn of 'zero mode on' when recording    , turn off DXF temporarily  
   ·   Updated Calibration Option 2 (now sets an x/y offset instead of allowing negative tip vallues for correction)     
   ·   Update setZ (change ZDRO set to center of ball)     
   ·   update touchz (change surface to bottom of ball)     
    ·   Added Z up/down buttons for manual control     
    ·   Constrain slope change on perimimeter routine added     
   ·   Added rapid FRO control      
   ·   Fix tip correct lookup error (negative angles caused issue)     
   ·   Fixed perimeter DXF write of interpolated Corners     
    ·   Altered calibration routines to discard prior data.
   ·   General screenset cleanup and bugfixes
   ·   Manual updated and improved to describe usage.

Some known issues:
*This wizard IS NOT COMPATIBLE with MachStdMill from Calypso Ventures, and cannnot be run while using MachStdMill Screenset due to conflicting use of DROs/LEDs/etc.  A workaround to use this wizard is to setup another Mach3 Profile that uses a standard screenset (1024.set, 2010 screenset, etc).
* This wizard is known to work on machines driven from the standard parallel port, a Smoothstepper, or CSMIO.  There is NO guarantee that it will work properly with any other external motion control device, as actual probing is handled within the motion controllers firmware and not Mach.  Test at your own risk.
* You must have Mach3, version 3.43.19 or later.  I recommend the latest lock down or 3.43.66 or later.  This wizard is untested with any 'modifed' version of Mach3, such as the version provided by Tormach.  Test at your own risk.

For any existing users:  to update, just replace your existing 'probeit' folder in addons with the new version, but keep and transfer over your license file if you have one.




9

atwoodr,

I think what you are looking to use is the #expand command.  It is only in the later (V3.43.19 or after) Mach3 I think.

To use, put your 10 to 15 subs into their own m1s file called whatever you name it.

at the bottom of your button code, you would insert the following:
#expand "c:\mach3\the path to your m1s file\filename.m1s"   (the quotes around the path are required)

You can use this recursively and straight from a button.
ie, you can #expand a script into the button without your code being in the button, and then you can also have your script file contain an #expand in it to pull in different files that have code you want to reuse.

Good luck!


10


Thanks for the suggestion on FRAPs, I'll give it a look.

Eric

Pages: 1 2 3 »