forum.cncdrive.com

I'm using some macros to control some screen elements. When I click the buttons, there's a delay, and it takes about 1 second before I can press it again. Hotkeys assigned to the buttons do the same thing.
This makes the screen response feel a bit sluggish.

For example, on the jog screen, I have a + and - button that changes the jog percent or step increment, depending on which is active. I basically use the same code in a Mach3 screen, and the macro executes as fast as I can press the keys. But in UCCNC, I can only press the key about 1 time/second. So, If I want to cycle through 5 steps, it takes nearly 5 seconds, where in Mach3 I could do it in about 1 second, with 5 quick taps on the keys.

My custom checkboxes (Toggle buttons that activate hidden checkboxes) also act similarly, taking nearly a second to change state.

Is this because the macros are compiled as needed?

Macros compilation time depends only on the speed of the computer.
The macros are compiled by the .NET compiler (CodeDOM).
On the 3 computers I have here the avarage 10-30 lines macros compile in the 50msec range.

If the macro compiles for 1 sec then I would say the computer is too slow for the UCCNC, I mean 1sec compile time is really slow.

If you like me to test the compile time of your macro on my systems then please upload one macro to the forum and I'll check it.

And when executing the macros in g-codes program then compiling may be not that slow even if your PC is slow, because when running g-code the UCCNC looks ahead and compiles macros ahead,
so when the code execution gets there it is very likely that the macro was already compiled and needs to be executed only which takes about zero time.
This differs when you executing the macro via button code, then the compilation of the code starts as soon as you press the button, so if the compile time is high then you will see it as a lag.

Computer is a 6 core i7-5820K, so it's not slow.

Actually, I guess the issue is the speed at which a macro updates toggle buttons and fields.

In Mach3, this macro(VB version) would run as fast as I can click the button.
In UCCNC, I can only click it about once per second.

Code: Select all

double jogp1 = AS3.Getfielddouble(20309);
double jogp2 = AS3.Getfielddouble(20310);
double jogp3 = AS3.Getfielddouble(20311);
double jogp4 = AS3.Getfielddouble(20312);
double jogp5 = AS3.Getfielddouble(20313);
double jogp6 = AS3.Getfielddouble(20314);

double jogstep1 = AS3.Getfielddouble(20315);
double jogstep2 = AS3.Getfielddouble(20316);
double jogstep3 = AS3.Getfielddouble(20317);
double jogstep4 = AS3.Getfielddouble(20318);
double jogstep5 = AS3.Getfielddouble(20319);
double jogstep6 = AS3.Getfielddouble(20320);

double newval = 0;



//MessageBox.Show(jogp4.ToString());

// Continuous
bool buttonstate = AS3jog.Getbuttonstate(161);
//Step
bool buttonstate2 = AS3jog.Getbuttonstate(162);

if (buttonstate)
{
   double currentval = AS3jog.Getfielddouble(913);

   if (currentval == jogp6)
   {
   newval = jogp5;
   }
   
   else if (currentval == jogp5)
   {
   newval = jogp4;
   }
   
   else if (currentval == jogp4)
   {
   newval = jogp3;
   }
   
   else if (currentval == jogp3)
   {
   newval = jogp2;
   }
   
   else if (currentval == jogp2)
   {
   newval = jogp1;
   }
   
   else if (currentval == jogp1)
   {
   newval = jogp6;
   }
   
   else
   {
   newval = jogp1;
   }
   
AS3jog.Setfield(newval, 913);
AS3jog.Validatefield(913);
   

}

else if (buttonstate2)
{
   double currentval = AS3jog.Getfielddouble(2027);

   if (currentval == jogstep6)
   {
   newval = jogstep5;
   }
   
   else if (currentval == jogstep5)
   {
   newval = jogstep4;
   }
   
   else if (currentval == jogstep4)
   {
   newval = jogstep3;
   }
   
   else if (currentval == jogstep3)
   {
   newval = jogstep2;
   }
   
   else if (currentval == jogstep2)
   {
   newval = jogstep1;
   }
   
   else if (currentval == jogstep1)
   {
   newval = jogstep6;
   }
   
   else
   {
   newval = jogstep1;
   }
   
AS3jog.Setfield(newval, 2027);
AS3jog.Validatefield(2027);

}

else
{
   MessageBox.Show("Jog values can not be changed while MPG modes are active.","Step or Continuous Mode Only!!", MessageBoxButtons.OK, MessageBoxIcon.Stop);
}


Even simple buttons like this take the same amount of time.

Code: Select all

bool buttonstate = AS3.Getbuttonstate(20380);

if (buttonstate)
{
   AS3.Setcheckboxstate(false, 35);
   AS3.Switchbutton(false,20380);
}
else
{
   AS3.Setcheckboxstate(true, 35);
   AS3.Switchbutton(true,20380);
}

But toggle buttons for built in functions, like the Offset buttons, work as fast as I can click them.

Hi Gerry,

I've tested your second code yet, because it is shorter and you wrote it also runs slow, so I thought it is easier to test this first.
I've placed a toggle type button 20380 on the screen and added your code to M20380 macro.

Testing the button press the button changes state not immediately, but it also does not take a second, I would say it takes 100-200msec or so probably.
I did not measure the time yet, but it is definitely not seconds on my PC.
I will try to measure the time with a timer will be the next step, but it's not so easy, so it may take some time for me to do that...

OK, I found a way to easily measure the time with a precise timer.
The timer starts on the button press event and stops when the Switchbutton executes and it measures 110-120msec on my PC.

Sorry, I was exaggerating a bit I guess.
The point is that it is noticeably slower than a standard toggle button. Especially when trying to click it multiple times, where it seems like the delay is longer than 100ms.

If it has to be that way, I'll live with it. But it would be nice if it was the same as standard toggle button, where there is no delay at all.

Yes, it will be slower than the standard built in function buttons, because the macro has to be compiled.
The only way to make it faster would be to precompile the code, which idea we were thinking about already,
but it introduces other problems, like when to compile the code and what to store.
One idea is that the macro could be compiled on the software startup,
but then changing the code on the fly would be impossible.
The other solution we thought about is to compile the code when executed and then keep an instance of it and
on second, third etc. runs the compiled code could be executed. But then again changing the code ... the same issue.
And the third thought was to compile and store both the text and the compiled code and on the next runs read the macro text again and again,
but only compile if the text changed. So, it would be fast always (except the very first run) when the file did not change.
The only bad about this solution is that then lots of code and strings may be needed to be stored in memory.

We also thought about using, changing to a different compiler called Roslyn instead of CodeDOM,
because Roslyn is faster and with that we could even build a Visual Studio-like macro compiler/debugger,
but the issue is that it works only on the .NET 4.5 and higher and the biggest issue is that .NET 4.5 is not supported on Windows XP.
So, then the UCCNC would not run on XP anymore, because to use the .NET 4.5 we should re-target the whole application to .NET 4.5

So, so far we frozen these ideas and maybe we will change to Rosyln when XP will be so old that it will finally fade away.

One idea is that the macro could be compiled on the software startup,
but then changing the code on the fly would be impossible.

I could live with that, although it makes testing more tedious. Could you add a button or option to recompile on request? Seems like that would deal with any issues?
Another option might be to only compile macros that correspond to screen buttons. That way you only compile what's needed.
Or, add another range of macros (21,000-22,000?), and only compile macros in a specific range.

but the issue is that it works only on the .NET 4.5 and higher and the biggest issue is that .NET 4.5 is not supported on Windows XP.
So, then the UCCNC would not run on XP anymore, because to use the .NET 4.5 we should re-target the whole application to .NET 4.5

Others may not agree with my opinion, but XP died two years ago. It's 15 years old, and was released before any of your users ever though about having there own CNC machine.
Realistically, 99% of your new customers will not be using XP, so you are limiting yourselves by continuing support for XP.
Lock down a version that works with XP, and move forward. It's better for everyone, now, and moving forward.

I would think that anyone using UCCNC and XP is not your cutting edge user, and would be fine with this.

I had the same issue with Artsoft a few years back. They were limiting Mach4's capabilities, in order to maintain XP support. There have been four new Windows OS's since then. Let it go......

Gerry, You would be surprised how many people still using XP and don't want to change to anything else.
I would risk to say that probably around 40-50% of our users still using XP, so is why we are hesitant to change.

Precompiling could be an option and we could implement that for sure.

Terry,

The g-codes are not slow, I mean they run always with the set feedrate.
What the limitation is that exec.Code motions are not looked ahead, but I think we talked about this earlier, so they will work like if they are executed as if in exact stop mode.
We also talked about making a function which could fill the motion buffer, e.g. exec.Codelong or something like that, but did not get to implement this yet, so it is still to be done.

The MDI may be slower on first run because the module is loaded in by .NET, I'm not 100% sure about this, it is yet a guess only, but will try to look after this.

If a plugin button press is fast or slower depends on what that button executing, if it is calling a .Code directive then it will have the same speed as if a button calls a macro script on a screen press event.
But if the button calls a UCCNC button code then it will be the same fast as a button which calling an internal function from the UCCNC screen.
There is not difference, I mean there can't be difference in the execution speed, because they are calling, doing the same...