I am trying to get my code for Laser Zero working properly I have it so it turn the output on/off (will have a Laser on button that's easy) then move to require position.

then what I would like is for it to zero out the axis`s it does not do it in the correct order it zero`s the axis first before the required move.

I am using

mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)

to zero the axis`s

this is the code
--Laser Zero

local inst = mc.mcGetInstance();  --Get the instance of the controller
local out5= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5);  --Get the out5 handle
local outstate = mc.mcSignalGetState(out5); --Output TOGGLE
   if (outstate == 1) then
       mc.mcSignalSetState(out5, false);
     else
       mc.mcSignalSetState(out5, true);
    end

local inst = 0;
local rc = 0;
local Xmove = "X2";
local Ymove = "Y3";
    rc = mc.mcCntlGcodeExecute(inst, "G91 G0 \n" .. Xmove .. " G91 G0 \n" .. Ymove);

    mc.mcAxisSetPos(inst, 0, 0.000)
    mc.mcAxisSetPos(inst, 1, 0.000)

if (mc.mcInEditor() == 1) then
end

can some one point me to what I should use or what am I doing wrong

thank

pain in the a

Maybe use this instead?

mcCntlGcodeExecuteWait

thanks ger I for got to say its in a button my bad

it has to be mc.mcCntlGcodeExecute had a mistake in the string thank you, you know who you are.

made a change to this rc = mc.mcCntlGcodeExecute(inst, "G91 G0 \n" .. Xmove .. " G91 G0 \n" .. Ymove); it will be something that needs to go in here just need to look through the example`s again and the M3 code what you did I think, to look at the lay out. it took me 4 months to get this far with the code and me saying to someone use the log when testing code did it my self hell it cant work when you have Xx 20 and Yy10. fun fun

right have the output on off working the move works but the silly zero axis code still zero`s the axis first before the move takes places does anyone know how to make the zero axis code run last this is what I have

--Laser Zero

------------------------turn output on/off------------------------------------
local inst = mc.mcGetInstance();--Get the instance of the controller
local out5= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5);--Get the out5 handle
local outstate = mc.mcSignalGetState(out5);--Output TOGGLE
   if (outstate == 1) then
       mc.mcSignalSetState(out5, false);
     else
       mc.mcSignalSetState(out5, true);
    end

--------------------------Move to work zero------------------------------------

local inst = 0;
local rc = 0;
local Xmove = "X2";
local Ymove = "Y3";
    rc = mc.mcCntlGcodeExecute(inst, "G91 G0" .. Xmove .. "\n" .. Ymove.."\n G90 \n");
    if rc ~= mc.MERROR_NOERROR then return "GCode failed",false end

local inst = 0;
local XAxisPos = 0;
local YAxisPos = 0;
local AxisNumber = X_AXIS
local AxisNumber = Y_AXIS
 mc.mcAxisSetPos(inst, 0, 0.000)
 mc.mcAxisSetPos(inst, 1, 0.000)
   
    if (mc.mcInEditor() == 1) then
end

Sounds to me you have a race condition where Mach4 looses control over the Lua threads. You are going to have to use a wait state to control the flow WHICH to me defeats the entire value of a FAST lua script.

We all pooh poohed Mach3 for doing just that and it seems here we are with the same problem with Mach4.

Just a thought, (;-) TP

Mach4 does not lose control of the Lua threads. It is the code
writer's job to control program flow. The tools needed are in
Mach4 and Lua. You cannot simply wish things will run in the
expected order, you have to plan and use semaphores and
wait conditions to control program flow in multi-threaded
real  time systems.

Steve Stallings

more to learn then, I will see if I can find something to make the code wait something was suggested but could not get that to work. silly question what are semaphores

silly question what are semaphores

Semaphore is probably not the correct name in the Lua environment, but a semaphore
is a way for one thread to signal to other threads that it is done.

this was suggest to try it did not work, now for some reason it does will play some more and post back. if I can get it to work I will stick it in tool box

local inst = mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F50");--run some g-code
wx.wxMilliSleep(10);
mcState = mc.mcCntlGetState(inst);
while (mcState ~= mc.MC_STATE_IDLE) do
mcState = mc.mcCntlGetState(inst);
wx.wxMilliSleep(10);
end
mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)
mc.mcAxisSetPos(inst, 2, 0.000)

The use of semaphores is a glutch fix that may or may NOT work across different machines/Pc's  Same with Mach3. Each PC can have different timing aspects to threads and what triggers a race condition. That has been proven many times in Mach3 I dought if controls are not in place to prevent it it will also occur in Mach4.

It should be the Programers job to make SURE that the 2 code systems are integrated to prevent it from occurring UNLESS you want it to run out of sync.  Syncronous ,Asyncronous I believe is the term.

I have used many systems that simply are designed to NOT allow an out of sync race condition to ocur UNLESS you requested it to do so.

WHY put the load on the OPs to prevent a race condition (You working for the machine (;-( ) When it should be the controllers job to prevent it in the first place. ( The machine working for you (;-) ).

Just a thought, (;-) TP