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:

<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:
            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

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