M65 P9001 Q3 #1=1.111 #2=2.222

[Robertspark]

It would bd handy for me.... but i dont think anyone has the interest....

Id like conditional parametric programming... but again.... who uses it....

[Robertspark]

It would work MUCH smoother IF we had persistant #vars for things like Xpos Ypos Zpos Apos ,etc. For now I simply use a macroloop to populate teh #vars same as Fanuc.

+1

it would not take much to populate static (persistent) vars from within uccnc as part of the release, and it would have little to none overhead in doing it as part of the release.

It would be nice if they followed the Fanuc var referencing too {the probe inputs do....#5061 - #5066}

#5001 - #5007, programmed endpoint of previous block
#5021 - #5027, current machine co-ordinates
#5041 - #5047, current absolute co-ordinates

[beefy]

One thing I had hoped for was to be able to Compile macros to protect macro code for OEMs. They will NOT play if they cannot protect their resources. And I cannot say I blame them for that.

DLL plugin code can be decompiled back to the C# code, at least to some degree. There's even free decompilers out there. Don't know if compiled macros could also be decompiled back to their C# or VB code too.

With the THC I was developing for UCCNC, some of the programming involved among other things, calculating mathematical constants to make the code run quicker in the microcontroller. I was going to do the heavy calculating in a UCCNC plugin but thought anyone can simply decompile my code and see what I'm up to. So at present I'm more just looking toward doing whatever I can in the micro, which can be read protected. More of a hassle and extra load on the micro, but don't know how to protect my code in UCCNC.

Keith.

[Robertspark]

The way around this is to tie the compiled code to a licence file which uses the UCxxx serial number which is hard coded into the motion controller.....

That way it works the same was as UCCNC and you just ask the purchaser for their hardware serial and you provide a licence file along with the DLL.

Field 906 is the one you want to tap into

[Robertspark]

DLL plugin code can be decompiled back to the C# code, at least to some degree. There's even free decompilers out there. Don't know if compiled macros could also be decompiled back to their C# or VB code too.

I dont think it is possible to fully decompile the dll back to c#. C# is a high level language, so there is a lot of low level code that is hidden within other functions which are linked to other dlls.

Decompiling to assembly is possible and also i believe c.

However.... the output depends upon how inteligent the decompiler is. A uccnc function for instance uc.code() will be created from many lines of actual code to allow a string value to be passed to uccnc so decompiling that function will look very different / complex.

..... anything is possible.... but how much time do you want to expend in decompiling it..... in the case of a thc.... you still need the external hardware device and code for the mcu. Windows is not realtime so some stuff can be sporatic depending upon what else is going on at the same time, hence evdn uccnc uses a buffer (a small one).

As i said earlier .... just code it to use a licence file which uses the serial number of the device and maybe also the device type (also able to be called by field)

[Rescaled]

DLL plugin code can be decompiled back to the C# code, at least to some degree. There's even free decompilers out there.

There is even online C# decompiler that is free and does not require registration.