forum.cncdrive.com

Am I doing something wrong or is the constructor macro not, or not always, run if UCCNC is started in demo mode?

I detected this after I switched off the machine and wanted to use UCCNC in demo mode to make some changes. I noticed that the fields I am using for my probe screen were not updated to the saved value, but went back to default. It seems that if at that stage I manually run M99998 then the fields get updated every time, but not automatically at start. Have not seen this before and not noticed if the machine is powered up before UCCNC, but in demo mode there seems to be an issue at least with user field updates.

My M99998.txt looks like this so it is really simple:

Code: Select all

//This is the Constructor macro which executes once when the application gets loaded//

AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20002", "0.0")), 20002); // Plate thickness
AS3.Validatefield(20002);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20003", "1.0")), 20003); // Probe dia
AS3.Validatefield(20003);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20004", "2.0")), 20004); // Probing area size
AS3.Validatefield(20004);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20005", "3.0")), 20005); // Fixture clearance height
AS3.Validatefield(20005);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20006", "4.0")), 20006); // Fast probing feed rate speed
AS3.Validatefield(20006);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20007", "5.0")), 20007); // Fine probing feed rate speed. Set to zero if only single probing pass is needed.
AS3.Validatefield(20007);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20008", "6.0")), 20008); // X and Y retract
AS3.Validatefield(20008);
AS3.Setfield(Convert.ToDouble(exec.Readkey("UserTextfields", "20009", "-3.0")), 20009); // Probing depth
AS3.Validatefield(20009);


The code is not run automatically, but every time after UCCNC start in demo I can run it in the MDI manually and then the fields are updated with the saved value. Values are saved in the pro file even in demo mode, so that part seems to work, but the constructor macro is not seems to run, or run before UCCNC is ready for it.

I have never seen this issue. I start UCCNC about 20-30 times per day in demo mode, but constuctor always runs. Try this line at the beginning to see if it is running:

Code: Select all

AS3.Additemtolistbeginning("M99998 started", 2);

It will add the message to the status window so you can check it.

Thank you. I added that line at the very beginning as first line and that confirms what I suspected and seen in my own fields. The M99998 is not run every time. I started/stopped 15 times and out of these 15 the message popped up 4 times only, but it seems that it is random, and the sequence was this:

1: No
2: Yes
3: No
4: No
5: Yes
6: No
7: No
8: No
9: No
10: No
11: No
12: No
13: Yes
14: Yes
15: No

I can't see any pattern but something is definitely strange. Have tested with both 1.2038 and 1.2039 and on two computers, one desktop and one laptop.

It always runs for me.

I've also tested it now and I do not see the issue on my developer PC, but I will look through the startup code to see what could possible cause the issue and will let you know what I find.

cncdrive wrote:I've also tested it now and I do not see the issue on my developer PC, but I will look through the startup code to see what could possible cause the issue and will let you know what I find.

Hi Balázs,
Thank you very much. If you want I can send you all the macro, the probe screen and everything else. I find it strange that this is happening, and what is mostly strange that it happens often but not every time, though I have no problem to repeat it. Perhaps something to do with the Modbus or the macro loop? The VFD is not here, and the macro loop can't get all the data from the VFD when this is happening... So I disabled the Modbus and the macroloop, but it did not make any difference, two successful starts followed a failure.

Hi Josef,

OK, sure, that would be helpful if you can send the profile file and the macros and then I'll try to reproduce the issue.
It is also good if you just zip the files and upload it on the forum.
And I owe you with one e-mail, sorry for not answering for that yet, but could not look through the docs you've sent yet, but it is not forgotten, I will reply that too asap.

cncdrive wrote:Hi Josef,

OK, sure, that would be helpful if you can send the profile file and the macros and then I'll try to reproduce the issue.
It is also good if you just zip the files and upload it on the forum.
And I owe you with one e-mail, sorry for not answering for that yet, but could not look through the docs you've sent yet, but it is not forgotten, I will reply that too asap.

Hi Balázs,
I sent you a mail with the zipped files. You will need more than just the macros and the pro files, so I sent you my screens, BMP files and everything I could imagine you'll need, even my license. This way you can run a copy of my installation. Let me know if I missed something.

However, don't make it the highest priority. Now that I know how it is I can live with it, so if you don't think you have time for this then just ignore.

Regarding the unanswered mail, don't worry, no need to hurry. I did not expect an immediate answer since I know you have to think about it as well.

BTW, as you figured out, now I am home and tested once again several times. Works every time, as long as the UC300ETH is powered up. Fails as soon as I disconnect it. I tried to disconnect the VFD only, but that doesn't make any difference, so it has nothing to do with the Modbus interface, or the macro loop I am using. It seems that it is the loss of connection to the UC300ETH which causes this.

Hi Josef,

Thank you for the files.
I think I found what the problem is.
It is that you have a Stop button call setup for an input trigger pin and if no connection to that or if in demo mode then that has a polarity that it triggers on startup and it calls the Stop button function of the UCCNC.
The issue is that the stop function sets the macrostop variable which the macro executer checks and so it does not run, because the variable is set.
In other words the macro executer thinks that the macro was stopped, because the stop button was pressed (button code was called by the I/O trigger).

I will change the code a bit, so that the macrostop variable can't be set before the constructor macro starts running which will then resolve this issue.
I will also add an exception that the Reset error message will not showup before the constructor macro starts running, because I saw with your profile that the input triggers causing that message to appear on startup which is kind of annoying since you basicly did not press any buttons, but the message appears, because of the input trigger. I will make that message not to appear on startup.

I will make these changes for the next release which I hope I can release over the weekend.

cncdrive wrote:Hi Josef,

Thank you for the files.
I think I found what the problem is.
It is that you have a Stop button call setup for an input trigger pin and if no connection to that or if in demo mode then that has a polarity that it triggers on startup and it calls the Stop button function of the UCCNC.
The issue is that the stop function sets the macrostop variable which the macro executer checks and so it does not run, because the variable is set.
In other words the macro executer thinks that the macro was stopped, because the stop button was pressed (button code was called by the I/O trigger).

I will change the code a bit, so that the macrostop variable can't be set before the constructor macro starts running which will then resolve this issue.
I will also add an exception that the Reset error message will not showup before the constructor macro starts running, because I saw with your profile that the input triggers causing that message to appear on startup which is kind of annoying since you basicly did not press any buttons, but the message appears, because of the input trigger. I will make that message not to appear on startup.

I will make these changes for the next release which I hope I can release over the weekend.

Szia Balázs,

Köszi a gyors választ!

Earlier when I first read your message, I didn't understand it and thought I have done something wrong, but now after I started up my machine and read your message again, as well as checked my configuration I see what you mean.

So, those who said "it is working for me" don't have a hard wired button for Cycle stop (I/O trigger function #130), like I have. I removed it and see that it works without the trigger function. I could live without that, but I prefer not to, so it is good if it gets fixed.

I also noticed that the machine reset message comes before the M99998 message, and since the M99998 is the constructor it should not be the case since the machine is not ready without the macro first run.

Thank you for taking care of this so fast.