forum.cncdrive.com

Teh old macroLoop bug has show it self again. I have a simple background routine that runs as part of a tool change. It simply toggles and few outpins and writes messages to teh status bar. IT is started from teh M6 by a #var flag #500=1. Teh M6 always ends correctly and teh FLAG is always set correctly. SOMETHING is blocking teh MacroLoop at times . It does not loose code or fail to run certain code or jump over code.

On occasion it will fail to start. BUT it will start at another part in teh Gcode run usually at the next Mcode in teh Gcode program.

This makes it impossible to run teh tool changer. I have tried in on 3 different PC and 2 different controllers. It happens across teh board. Totally unpredictable as to if and when it will work correctly.

Some times it does work and sometimes it does not work.

(;-( TP

Here is a bit more info on teh BUG. When you first start UCCNC the BUG is not active. The macroLoop run fine and does as programmed. After about 20 GCODE program cycles it starts to become active. From there on teh longer UCCNC runs the worst it gets up untill the BUG occurs every cycle.

IF you then shut down UCCNC and restart it starts teh loop all over again. Works fine at teh start until it appears then gets worse until it is every cycle.

Shut down, restart, ETC,ETC

(;-) TP

Here is another tid bit of info on teh BUG. When the BUG becomes active and will not cycle teh MacroLoop RUNNING any outside macro such as a button code THEN teh macroloop will cycle and run.

It is as something is BLOCKING teh Macroloop running and then somethind releases teh blocking and teh macroLoop will then run completly out of sequence to WHEN it should run.

(;-) TP

I have checked the code and there is nothing which could possibly block the macroloop thread to start.
It is a simple Thread.Start command in the UCCNC which starts a new program thread.
If it cannot run then there should be an error in the code or maybe an exception, e.g. a division with a variable which sometimes becomes zero creating a division by zero exception.
Ofcourse this was just an example of what could have happened.

Hi Balazs I hear you pal BUT I also know that it does occur from time to time. I have NO idea what conditions cause it to trip teh Glitch switch but when it does the bug flairs up and you cannot untrip teh Glitch switch. To stop it you have to shut down UCCNC and restart from scratch. There are times I can make it happen on demand and other times I cannot make it do it at all. The conditions change and teh Glitch switch is OFF (;-) and UCCNC behaves as it should. This has been across several controllers and PCs .

I guess me an Derek are just lucky that way. But then again we may do things CNC wise that others never think of doing. We tend to push hard on teh boundaries of the controller and software. Jobs have to get done and bills have to be paid. Then if there is anything left you get to buy groceries.


Have a good one , (;-) TP

The code in the macroloop is too simple, there are basically no conditions to start or not to start, so I see no possible reason at all for any possible bugs which could cause the loop not to start.

Maybe it is a problem with your .NET framework installation, because what happens inside .NET when running a macroloop is that it runs the Visual Studio compiler (CodeDOM) to compile the code.

I could understand that IF it was just one PC but it has occured on 3 different PCs with 3 different OSs . what would be the odds of that .

Hopefully one day I will be able to capture teh condition event that causes it. When you play on teh outer boundaries of the Control you are bound to run into Dragons that no one else sees.

Just a thought, (;-) TP

when it happens what is the memory usage like via the task manager?

Vmax549 wrote:There are times I can make it happen on demand

Shouldn't the answer be within your code there ??