Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: dude1 on May 31, 2015, 04:04:40 AM
-
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
-
thanks to everyone`s help it is working now you have to in cress the wx.wxMilliSleep(10); if you wont to see it moving the DRO`S in editor, in a button you see no movement on screen but I have tested it on a machine and it works
by truck its fast as in blink I will post here for you boys to look at it and if anyone has anything to added please do. I will be adding in credit to who helped and post it to tool box at end of the week
-
here it is it`s not quite right yet you don't see any DRO movement on screen I have tested it on a machine and it does work so use at own risk
--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
wx.wxMilliSleep(10);
--------------------------Move to work zero------------------------------------
local inst = 0;
local rc = 0;
local Xmove = "X20"; --set to x offset from spindle
local Ymove = "Y30"; --set to y offset from spindle
mc.mcCntlGcodeExecute(inst, "G91 G0" .. Xmove .. " \n" .. Ymove.."\n G90 \n");--run some g-code
wx.wxMilliSleep(10); --this is here other wise it`s to fast to see anything on DRO`S in editor
mcState = mc.mcCntlGetState(inst);
while (mcState ~= mc.MC_STATE_IDLE) do --This part is so it will Zero axis`s after movement
mcState = mc.mcCntlGetState(inst);
wx.wxMilliSleep(10);
end
mc.mcAxisSetPos(inst, 0, 0.000) --zero x axis
mc.mcAxisSetPos(inst, 1, 0.000) --zero y axis
-
Nice! I'm impressed...I couldn't get a while or a repeat loop (even with a break) to work for me, just kept freezing the GUI as button scripts are 'ran as events'. I just figured I'd start using wx.wxMessageBox to break up the chunks. I finally got all kinds of movement in on a button script now by breaking it up with the message box (all kinds of mc.mcCntlMdiExecute and mc.mcJogVelocityStart functions going on without racing) for multiple phases in the auto tool button without G31. I was using the message box to prompt the user and when a movement phase was complete, the user just hit ok. This would signal Lua to execute the next chunk in the script. If you don't mind, I'd like to try the while loop with wx.wxMilliSleep combo. Nothing like automation! ...man, I love this stuff! Below is a what I mean, this is just a snippet. I agree with BR549, smart dude. The machine works for us (Period!)
--josh
gCode = "G0 G90 G54 G17 G40 G49 G80\n"
gCode = gCode .."G53 Z0.0\n"
gCode = gCode .."G53 X14.0 Y0.0\n"
gCode = gCode .."G53 X12.0 Y1.0\n"
mc.mcCntlMdiExecute(inst, gCode)
mc.mcSignalSetState (hSigOZero, 1)
wx.wxMessageBox ("Next: Probe table.")
mc.mcJogSetRate (inst, 2, 40)
mc.mcJogVelocityStart (inst, 2, -1)
mc.mcSignalSetState (hSigOZero, 1)
if inputZero ==1 then mc.mcJogVelocityStop (inst, 2)end
wx.wxMessageBox ("Next: Goto Tool Setter Position.")
-
I was thinkin....you think it's wise to dive into the mc.mcMotion functions? Whats up with the "Cycle planner" anywho? I gather it is communication with the motion controller and the core whereas, the motion controller reports (by motor counts) to the core the position of the mill and then the core updates the data on Mach GUI. I wonder if we can control this or is this strictly OEM afforded functions...hmm, idk. And another thing, the screw mapping functions...is that a way to do our axis calibration? I think so, we just have to code it. It seems easy. I just want to know if it is for axis calibration or not. Ok, I'm talking too much. Later Daniel!
--josh
-
it cool you rants are fine
the stupid thing I tried the while loop yesterday same as I have it, it would not work then buttons on screen with code in them stopped working had to replace them now its all fine just one of those random bug`s. it`s fun when things work
-
The "better" way to do this stuff is to use the PLC script in conjunction with a button script. Make a global var in the Load script to work with. Something like "myAction". The button script simply sets myAction to something that the PLC script knows how to handle.
load script:
-- make some global vars.
myAction = -1; -- holds our action code.
myActionExecuting = 0; -- is our action executing? This is like a semaphore.
Button script:
if (myAction == -1) then
myAction = 1; -- set to x20 and y30 offset from spindle.
end
PLC script:
if (myAction == 1) then
mc.mcCntlGcodeExecute(inst, "G91 G00 X20Y30"); -- set to x20 and y30 offset from spindle.
myActionExecuting = 1; -- mark that we are executing.
-- The state of the machine will now NOT be idle. It will be executing the G code.
-- The PLC script runs top down, so the test below will not see the machine in the
-- idle state until the code above has been completed.
end
...
mcState = mc.mcCntlGetState(inst);
if (mcState == mc.MC_STATE_IDLE and myActionExecuting == 1 and myAction == 1) then
--This part is so it will Zero axis`s after movement.
mc.mcAxisSetPos(inst, 0, 0.000); --zero x axis
mc.mcAxisSetPos(inst, 1, 0.000); --zero y axis
myActionExecuting = 0; -- no longer excuting myAction
myAction = -1; -- reset myAction to let another button do something.
end
If you think about it, this is how one would program any PLC where the PLC would be watching an input or register to control program flow. Just think of a button as sort of way to update a PLC register.
Steve
-
this stuff is new to me so I will do stuff wrong all the time I just do it to full time in I have never used a PLC so I would not know how they work I know what they are
-
Thanx Steve! That is the theory I've been needing...another Sticky reply! I think you just unleashed Mach 4's potential right there...to everyone. Wow. It's going to take a minute or two to wrap my thinking cap around that but, yah...freakin awesome education right there.
--josh
-
just so I can get this correct
The "better" way to do this stuff is to use the PLC script in conjunction with a button script. Make a global var in the Load script to work with. Something like "myAction". The button script simply sets myAction to something that the PLC script knows how to handle.
so this bit I just put in screen load script I don't add a ver to the regfile
load script:
-- make some global vars.
myAction = -1; -- holds our action code.
myActionExecuting = 0; -- is our action executing? This is like a semaphore.
got this
Button script:
if (myAction == -1) then
myAction = 1; -- set to x20 and y30 offset from spindle.
end
I just put this in PLC and change the number after axis to set the offset
PLC script:
if (myAction == 1) then
mc.mcCntlGcodeExecute(inst, "G91 G00 X20Y30"); -- set to x20 and y30 offset from spindle.
myActionExecuting = 1; -- mark that we are executing.
-- The state of the machine will now NOT be idle. It will be executing the G code.
-- The PLC script runs top down, so the test below will not see the machine in the
-- idle state until the code above has been completed.
end
-----------...
mcState = mc.mcCntlGetState(inst);
if (mcState == mc.MC_STATE_IDLE and myActionExecuting == 1 and myAction == 1) then
--This part is so it will Zero axis`s after movement.
mc.mcAxisSetPos(inst, 0, 0.000); --zero x axis
mc.mcAxisSetPos(inst, 1, 0.000); --zero y axis
myActionExecuting = 0; -- no longer excuting myAction
myAction = -1; -- reset myAction to let another button do something.
end
If you think about it, this is how one would program any PLC where the PLC would be watching an input or register to control program flow. Just think of a button as sort of way to update a PLC register.
Steve
I have tested as is it runs the same as in a button no seeing moment in DRO`S but it does work. it work`s and does its job so know I can learn other stuff so I can make any code I do easier. I only had to do a laser Zero and a tool height have not tested tool height probing from the manual but it seems to work just testing it.
So thank you very much this would be a better way to do it as the other person who uses the router`s I don't wont them to change anything so it makes it harder to find
thanks Steve may the CNC God`s shine on you
-
its about time you changed your name again, Screwie Louie, screaming ax sound good
yep Steve don't post much but hell it all ways help when he does some people don't like the M4 people not replying much or the blocks that know most of it, but if they gave all the answers no one would learn.
so if we do a code that's good and we did our own hard work them coming along and making it better or showing as a better way is more of a help than not. hell the teacher is coming out in me again.
-
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
Terry... come on now. This is a bit of a stretch, don't you think? What PLC on the planet does not use semaphore like/type logic to control program flow? It is not a glutch, kludge, or workaround. It is the correct way to handle the logic.
And you are right, it is the programmer's job to make sure that the program works. When you are programming a script, you just became that programmer! We give you a plethora of tools to work with too. You have the ability to make the controller do as you wish. If you do the job right, the machine will work for you from that point on. But there is NO WAY that we can guess what the script programmer's intentions for the script are and protect him from himself. I guess we could if we constrained the script environment to only operating in a certain way. But we just threw flexibility out the window!
Yeah, there is a learning curve. No doubt. It will not be everyone's cup of tea. But some people don't build or convert their machines either. Some buy them ready to run. It is the thing I struggle with all of the time. I squeak when I walk so I tend to not want to pay much for anything that I even remotely think I could handle! But I don't have a lot of time to learn new things either. Catch 22! I usually err on the side of cheapness and end up finding/making the time to learn so that I can do it myself. :)
Steve
-
If there is a way for a subroutine (or function or module, etc) to know when a var has changed, I don't know what it might be. If subsequent processing or actions might pick up stale data, it is the programmers responsibility to control that pick-up until the var has the current data. A normal way to do this is with a semaphore (I just call them flags).
The routine that is generating the data sets a 'data is ready' flag when the data is made current. The routing that uses that data waits for the flag before reading the var and resets the flag to 'data is not ready'. This is flow control 101, and is indeed the programmer's responsibility.
Buying a hammer and saw does not make the buyer into a carpenter. Buying a CAD program does not make the buyer into a designer. These are tools, not skills.
It is evident to me that MACH4 has a design goal of supplying tools. One area where they have restricted what a user can do is the screen editor. This is a place where the average user might do 'programming' to modify their screen, and it amounts to 'checkbox programming'. These restrictions make the editor unsuitable for my purpose. Just because I am unhappy about it does not mean I don't understand why it was done and that it makes sense in that application.
However, if similar 'save the programmer from himself' philosophy was extended to scripting, the flexibility would indeed be out the window. The long list of MACH functions is essentially one of many libraries created for a specific purpose. It still requires programming in C and/or Lua to use them and therefor the statement 'when you script, you are the programmer' is accurate, in my opinion.
-
HIYA Steve, (;-) Lets me give you a perfect example. WHAT IF Gcode acted like you say needing someone to baby sit it with semaphores to keep it in sync ??? Does the Gocde side ever get out of sync with millions of lines of Gcode ? NO it does not ? WHy ? Because it was programed NOT to get out of programed order.
Can Mach3/4 get out of sync ?? SURE IT DOES Examples are posted all over the forum where it did. Can you fix some of the issues with the use of semaphores sure you can BUT it is still a Kludge to have to do it.
I KNOW you are more than smart enough to understand that. Could you imagine having to use semaphores in Gcode programing ??
Ladder does not need a semaphore to keep it in sync. You do use loops to wait on events to finish but that is NOT to keep it in order of execution It is simply waiting on an event before it can complete the function. Can you use an out of sync event ? Sure you can but that is the exception NOT the rule.
I have used ladder combined with basic in PLCs that you could NOT get it out of sync. It could not happen. The ladder and Basic were properly integrated to prevent it from happening.
In the Case of LUA and Mach4 in should NOT be able to get out of sync either UNLESS that is what you want it to do. The exception NOT the rule.
LOOK at Fanuc Macro B Does it have that problem ? Not that I remember . I never had to program with semaphores there. Does it use loops sure it does it is a conditional language..
The problem with the use of kluges is it is NOT consistant across different machines. What works on one may NOT work on the next depending on the PC. SO then you have to bullet proof it with long wait states( semaphores) so that the fastest PC will work along with the slowest BUT who knows what the Delay should be ??? In the past every time I thought I had it fixed I would always find a Machine it would not work with. The end result was a function that was terrible to use as it took forever to run and would NOT run smoothly.
Take a Mach 3d probing routine for example. By the time you make it bullet proof it is PAINFUL to watch it work AND there is no way around the problem because of the wait states to insure it stays in sync , does not jump over code sections , and run sections out of order. HAVE you noticed there are ZERO high speed 3d probing routines for Mach3 while all other controllers have a high speed routine ??
I have Used/Tested a LOT of other controllers and Mach has been by far the worse in this respect. With most I can create a 3d probing routine of the creepy crawler type that just zooms across the surface. Try that with Mach. IT IS LIKE WATCHING PAINT DRY.
HOPEFULLY with Mach4 it can now be done all in Conditional Gcode BUT it will only be available in Industrial mode ??
So why can other controllers/PLCs do it and not Mach. Please explain so I will understand. Perhaps it is just ME.
NOW IF Mach4 and Lua were 2 seperate Operating systems running independant of each other I could see the need to intervein. BUT that is NOT suppose to be the case Mach4 and Lua should be integrated to work together NOT against each other.
(;-) TP
-
I just though of another example. Running Gcode in Lua. Obviously there is a problem here with sync as trying to run several lines of Gcode creates a problem. You end up having to RUN mulitple lines of Gcode from a single line with \n.
THAT should never happen . You should be able to simply stack as many lines of Gcode in the script that you need to use AND have each run in proper order SAME as running the Code From the Gcode side.
I ran into that trying to create a 3d probing routine in Mach4.
(;-) TP
-
HIYA Steve
" If there is a way for a subroutine (or function or module, etc) to know when a var has changed, I don't know what it might be. If subsequent processing or actions might pick up stale data, it is the programmers responsibility to control that pick-up until the var has the current data. A normal way to do this is with a semaphore (I just call them flags)."
You are comparing Apples to Oranges. That is NOT a semaphore to control sync. It is a normal function to ensure correct data values are used in that case.
A proper example is when a DRO is updated. SHould you have to GUESS how long it is going to take to update the DRO so you can add a wait state to make sure it happened OR should the core code be "notified" when the update has completed. NO guessing required there. AND it will work correctly over ALL varieties of PCs used.
There is NOTHING which I have said that will HAMPER mach4 as far as flexiblity in Scripting BUT it WILL enhance the reliability of the scripting 3 fold and make it much easier to create a reliable script.
(;-) TP
-
You end up having to RUN mulitple lines of Gcode from a single line with \n.
THAT should never happen . You should be able to simply stack as many lines of Gcode in the script that you need to use AND have each run in proper order SAME as running the Code From the Gcode side.
Terry, I really don't want to get into another argument with you, but I am just curious as to why you see a difference between a pre-written G-code program in a file and 'stacking' lines of G-code in a single string separated by \n.
The interpreter sees the same thing, I would imagine. The only difference is that one set of blocks is read out of a file and one is sent as a delimited string.
In a text file, each line is delimited by some character, typically 'newline' which is just a carriage return and linefeed.
Said another way, the interpreter gets the code a block at a time and executes with no in input from the operator., so why would it matter is the blocks were strung together rather than submitted line by line by successive 'execGcode' functions?
You mentioned 'out of order', I think. Are you suggesting that the string of commands separated by \n is given to the interpreter in a different order that it was in the string? That would be mucho bad.
-
Terry, I think you are missing the point. G code is NOT a programming language in the classical sense. It is a command language. It has no logic statements without the macro B stuff. No way to control the flow at all sans the simple sub routine mechanism at all. For example, what is the G code to test that machine movement has been completed? What in G code notifies the operator of the machine that the G code is complete? I mean standard G code. Not a scripted macro. M00? M01? What action/event is taken by the G code if "G00 X0Y0" is executed and then completed? Nothing. The machine executed the code and then just sits there like a bump on a log waiting for the operator to do something else.
Macro B is not another language. It is an extension of the G code command set. It executes in the same context as the regular G code. Therefore it is an apples and oranges comparison.
Waiting on an event in a PLC with a loop is controlling program flow. It is a LESS efficient way of doing so! Ladder with VB is an extension just like Macro B is an extension to G code. It operates in the same "program" context. It is the same interpreter on the same device. So how would you take TWO PLCs and make them work with each other? That is a better example. You will HAVE to use flow control mechanisms to prevent a race condition in one or the other PLC. Because you are now executing code in two different environments/devices/contexts. Is it a kludge? Certainly not.
With that HUGE thing said, there is no possible way to integrate G code and LUA to the extent you are talking about. Simply because G code can't really "communicate" with anything to that extent. Unless we also interpret LUA along side of G code with the same interpreter, then having what you describe is simply not possible. And then users would have to sprinkle LUA in with their G code just like you had to sprinkle VB in with your ladder logic. Terry... you have to distinguish what is a dream and what is reality.
In my example code above, it uses a semaphore like var to control the execution. Please explain to me how that will not work on different machines? Or for that matter, how would C/C++ mutexes and semaphores not work the same on different PCs? If that were the case, EVERY windows program would have to be custom made for EACH PC. That is not the case. I don't want to argue, but what you are saying is simply not the case and I feel it a disservice to the rest of the community to let such a notion stand.
There is nothing wrong. There is no design flaw. It is working as intended to make the system as flexible as it can be. It is the way it is for very good reasons. The sooner you accept that and just move on, the happier you will be. :)
Steve
-
It occurs to me that the apples vs oranges might be using 'delay' and 'flag' (semaphore) interchangeably and they are not the same thing.
Using delays (ex. 'sleep' in VB) is simply a finite pause in execution and using same could cause all of the symptoms described. Based solely on the descriptions provided, I would speculate that delays are being used which cause additional problems wherein use of flags would eliminate the problems altogether. If you are scripting anything, you have access to the method. I have never heard of a 'sync semaphore', or any other specific kind of flag. The programmer makes them up as needed, for the purpose.
In my code, and much of what I have seen of other's code, typically the routine generating the data sets a flag and the routine gathering the data reads the flag. In this way, the routine receiving the data CANNOT act prematurely and there is NO reason to have delays or slow a program to a crawl in an attempt to guarantee the 'race' is won by one contestant or the other.
There are certainly other methods of program control, but unless I encounter some good reason to use an alternate, I stick with flags.
A method to consider in the DRO example is to use a 'comparative change'. If you want to know when a value has changed, just save the old value and compare it with the new until it changes. I use this a lot in MACH3 VB scripts.
OldValue = GetUserDRO(*********x)
NewValue = question "Where do you want to go?" (script will not advance until user answers)
If NewValue != OldValue
do as requested
else
Message ("You are already there")
end
Without an 'event' (user entering data, input going high, etc), you can create a 'flag' on-the-fly
OldValue = GetUserDRO(*********x)
NewValue = Oldvalue
Call routine that will enter new data into the DRO
counter=0
while NewValue == OldValue
NewValue = GetUserDRO(*********x)
counter ++
if counter > 1000 then
break
end
sleep(100) '<- this is a delay
wend
'Blah,blah do other stuff until you need that new DRO number
if counter > 1000 ' routine timed out, so there is no new data
messageText = "Current DRO*********x data unavailable"
DataXReadyFlag = false
else
messageText = "Data X Update verified"
DataXReadyFlag = true
end
' Time to use the data . .
if DataXReadyFlag and AxisEnabled and (whatever else needs to be ready)
do the deed
else
call error handler 'messageText will have the error
end
Note that I have nested 'flags' (not typically a good idea) and that the var 'counter' is actually acting as a flag, but hopefully the method is clear.
This stuff is a PIA and is boring and time consuming, but as has been said, this is the programmer's responsibility.
When I first perused the new API manual, I was pleased and relieved to see that the MACH4 functions have multiple error codes. Most certainly the footprint of professional programming. Yet, I have seen NO code posted since that document was released that actually shows the available error returns being used . . . uh . . including my own :-[ And within that document is fair warning, by function, of which ones do not wait on execution.
the long list on MACH4 functions is in essence, just another of many libraries. The programmer still must write in C and/or Lua to use these routines. The developers of MACH4 cannot dictate how C or Lua work unless they want to write their own compiler. It would seem that writing MACH4 is enough challenge.
-
You are correct!!! It is prudent to check the API functions for error codes. In examples, I don't write that stuff in, as it becomes time consuming. But it is NEEDED for production scripts to ensure that when things go wrong, it gets handled properly. In the API docs, most of the examples are in C. Some of the functions have LUA examples. But the C examples use the error codes and can be used to deduce what they would be in LUA.
Here is a snippet of a manual tool change M6 macro.
-- M6start stuff here....
--Here, we process an EVT_MACRO_HOLD and enter the macro hold state. We can jog there!
mc.mcCntlSetLastError(inst, "Press Cycle Start to finish the tool change.");
wx.wxMilliSleep(100); -- wait a few so that the GUI can retrieve the message before the machine changes state.
-- A sleep is not generally a good idea to use. But in this case, it is harmless as the wait is minimal.
local rc = mc.mcCntlToolChangeManual(inst);
-- execution resumes from here when the user presses Cycle Start or Cycle Stop or some sort of E-stop or disabling of the machine.
-- but in the mean time the user can Jog, toogle switches, stand on your head, or do anything else he likes!
-- We check the rc of mc.mcCntlToolChangeManual() because the user might have aborted
-- the tool change by pressing Cycle Stop.
if (rc == mc.MERROR_NOERROR) then
-- the user has not aborted, finish the tool change. M6end stuff.
...
end
Steve
-
In my example code above, it uses a semaphore like var to control the execution.
Very much on point. I put another example of this in the preceding code where the var 'counter' is acting as a timer and as a semaphore.
There may be confusion about program control if, as it seems, 'semaphore' is viewed as a 'thing' rather than a concept or method.
I added a few paragraphs to install instructions explaining that 'Modbus' is not a 'thing' that needs to be purchased separately. It is just methodology and rules which allow those (devices) that speak it to communicate with each other.
Virtual entities can be difficult to comprehend if a person is anticipating something tangible.
BTW, I am currently going thru all of my Mach4 code adding error traps where needed now that the information is available to do so . . . and a brief wave of ambition has overtaken me . . :)
Edit: and also making some routines into functions and deciding what parts of the code might be better executed form the screen load script instead of the PLC, now that I have some concept of the difference. i.e. basically getting the 'virtual mop' out and cleaning up the place.
-
this was meant to be about me get a laser zero code working good not a pissing match
-
HIYA Simpson( I use that name because there are 2 Steves)
" The interpreter sees the same thing, I would imagine. The only difference is that one set of blocks is read out of a file and one is sent as a delimited string.
In a text file, each line is delimited by some character, typically 'newline' which is just a carriage return and linefeed.
Said another way, the interpreter gets the code a block at a time and executes with no in input from the operator., so why would it matter is the blocks were strung together rather than submitted line by line by successive 'execGcode' functions?
You mentioned 'out of order', I think. Are you suggesting that the string of commands separated by \n is given to the interpreter in a different order that it was in the string? That would be mucho bad. "
IF that were the case BOTH being the same there would be ZERO difference in the running of the script BUT there IS a BIG difference. Obviously in a single string the order of execution is maintained correctly and it runs correctly. BUT from a multiline input of the exact same Gcode the Mulitline input FAILS to maintain the order of execution and runs out of order. It seems to me that on each line of code it opens a new thread and there is ZERO control over all the threads. THAT is not suppose to happen. The program SHOULD have control of all threads that are created and closed otherwise you get Kaous and that seems to be what is happening. IS IT NOT, Have you tried it to see what happens ?
(;-) TP
-
The PLC flags work! I totally understand this now. This is sweet. No more GUI lock ups, nor while/repeat loop lockups. I'm never going to sleep tonight. I got work to do! ...wait...is work supposed to be fun?
-
HIYA Smurph,
"Terry, I think you are missing the point. G code is NOT a programming language in the classical sense. It is a command language. It has no logic statements without the macro B stuff. No way to control the flow at all sans the simple sub routine mechanism at all. For example, what is the G code to test that machine movement has been completed? What in G code notifies the operator of the machine that the G code is complete? I mean standard G code. Not a scripted macro. M00? M01? What action/event is taken by the G code if "G00 X0Y0" is executed and then completed? Nothing. The machine executed the code and then just sits there like a bump on a log waiting for the operator to do something else."
The control of the Gcode is performed by the core code that controls the Gcode functions . It is the cores responciblilty to control the flow of Gcode to prevent it from getting out of sync with itself. WITHOUT that control the machine could NOT make parts. SO YES something IS controlling the GCODE to keep it all in proper order
Same with the way Mach4 uses LUA as a Macro scripting language. The CORE(mach4) SHOULD have control over LUA to the point it maintains control over LUA created MACHINE FUNCTIONS that are created and used by MACH4. It should NOT depend on the Operator to intervein and maintain order. AND that something is NOT me.
NOW I am not talking about general programing of lua BUT the FUNCTIONS that are unique to Mach4 that are RUN in LUA. IF the core code maintains CONTROL over LUA generated FUNCTIONS we would not be having this conversation.
You being a Master programer do not have the perspective of an operator trying to get a Macro to run correctly and NOT crash an expensive machine or PART or Tool. You can create at will anything that needs to be done I call that a workaround(Kludge). The rest of the world does NOT have that advantage nor should need that advantage as the years learning it detracts from making the parts that feeds the family.
To say that LUA NEEDS to run out of control to make Mach4 "Flexable" would be silly . There is NOTHING stopping a programer from creating Lua scripts as he needs including running out of sync with the core if desired. BUT the "control functions" of Mach4 running in LUA that run the machine should have control over Lua to the point that acccidently getting out of sync cannot happen.
IF "I" can control Lua as you specify why can MACH4 not do it ??
(;-) TP
-
Using the PLC flags as a means to control blocks, yes, this works wonderfully. But, as an example when I execute a function in the PLC ie. mc.mcJogVelocityStart / Stop, my probe will stop the motor and axis from moving (mapped to input 0 not G31) but, if I release a block of gCode ie. mc.mcCntlGcodeExecute, I have no effect over the execution of that line while the machine is running. My input commands to stop from what I have coded are ignored as well as any input signals until that line has finished. I must manually stop from the GUI. Is this what you mean? I'm just trying to comprehend things in my head a little. It's like Block racing vs. block syncing.....am I close?
-
comments from the peanut gallery. me and my theory...motor counts and motion control. to go from (0,0,0) to (10,0,0) we just write G00 G90 X10.0. Lua see's this as just a string. Does the interpreter "interpret" this command as rapid move, absolute position mode, "move positive 10 inches" or is the "move 10 inches" converted by a time/distance formula and this message is passed to the motion controller which relay's the info to the driver (or the motion controller does this and the core just provides the data for the motion controller to convert the X10.0 command via the motion cycle planner?) Wherein this message takes the given motors "counts" (encoder counts or step pulses) per inch in relation to velocity/acceleration/backlash comp. etc...(maybe this is why the core wants a MSG_REPORT_MOTOR_STOP request in order to update the cycle planner, GUI data, and append any files) Unless we can somehow intercept each bit of that message or each individual motor count per move (as if the X10.0 message is broken down into 1,000,000 bits or something) by the PLC to sync LUA and gCode I don't see it happening. Well, yes and no. I see it happening with proprietary software on proprietary machines. I don't see it happening at a reasonable and affordable price point that we get Mach4 for and then place the software on computers and machinery of our choice. The PLC would have to be like quadruple the speed at which the core and the motion controller are communicating plus coordinate lua commands and real time user commands. Idk, shoot. I'm just trying to hang with the big boys. I mean yes, you are right and yes they are right. I just learn how to use what's given to me. What's the word I was taught...????Ah, yes, sensitive site exploitation. Well I'm not going to exploit Mach4 but sure as heck going to manipulate it (within the capabilities that are provided to me). I think I am going to see my way out of this conversation....and not get stuck in the middle. :P I am just trying to learn.
-
...although "Lua uses double precision to represent numbers, your program can run for two hundred years, doing one million insertions per second, before it has problems with overflows." Is that fast enough to accomplish what the requirement is? Dependent on hardware of course ;D
-
Terry... There is nothing in the core that is LUA. The core has no knowledge of LUA. The GUI has LUA. And the macros can be scripted in LUA via the mcLua plugin. When the core executes a macro script, all it does is hand it off to a plugin. If someone wrote a VB script plugin, the scripts could be in VB. If someone wrote a GUI, then they could use VB in that GUI.
GUI --| (LUA for the screen)
Core ---|
Plugins. (LUA for the macro scripts)
The GUI is the HMI (Human Machine Interface). It is where the rubber meets the road for the operator. How the interface operates is up to the user/operator/integrator. The Core is like an operating system. In fact, I used to write operating systems so the Core modeled very closely to that of an operating system kernel. It's sole purpose in life is to provide services to the application layer (GUI) and to interface with hardware via the plugins. The plugins could be considered something analogous to operating system device drivers. The core can be extended via plugins too. This provides future flexibility.
The LUA scripting uses the EXACT same API that we use in C++. It IS the API. It controls the core. Not the other way around. When you hit the Cycle start button, mc.mcCntlCycleStart() is used to tell the core to start executing. So please tell me how LUA that controls the core should be controlled by the core? How could the core ever have dominion over what the M code script wants to tell the core to do? What if the core just said no? That would be useless. Your arguments are circular.
What keeps you from messing up when writing G code? What protects you from yourself? If you tell the spindle to plunge through your workpiece or the the table, what do you expect to happen? It is up to you to write a good G ode program. It is also up to you to write a good script program.
One of the needs that kept popping up for Mach 3 was increased flexibility. Therefore, that was a design goal for Mach 4. I'll say it again. There is nothing wrong with it. There is no design flaw. You can use it. Or not. Your choice. You will be waiting a very long time for someone to make a system like you are wanting. Maybe forever.
And waiting for what? You make the machine do what you want ONE time. Then, you use it! I am an operator. I did this very stuff on my very own machine. It wasn't hard. And I haven't touched it since I did all of the screen and scripts. Not once! All I do is go downstairs, turn the machine on, and run parts. The machine is working for me, as you like to say. The same way every time. Just like I want it to.
Steve
-
something I find interesting the code I did and the code smurph supplied seem to freeze the screen for the amount of time the machine is moving, it start and stops in a instant just when its moving you don`t see any change on the screen.
BR549 I think you where almost correct I should not have lock this sorry
-
was it a mc.mcGcodeExecuteWait function?
-
no it`s whats on page 2 it does not matter as it work`s and it wont crash or anything silly like that it`s just something that happens with the forloop
-
type the 'for' loop out exactly as you typed it...where is it located? ie. button, plc, start up?
-
look at page 2 of this thread
-
Don't see a for loop. I see a while loop in your original code then Smurph gave you an expamle to do the moves with an 'if' conditional statement based on mach's operating state before making the second move. All done in the PLC. If/then statements work. I'd avoid while/repeat loops like the plague inside the plc or button script because of the constant refresh. try the mc.CntrlMdiExecute function. My DROs always update with movement and the screen doesn't freeze. Now, mc.CntlGcodeExecuteWait on the other hand is different. That functions locks everything out (except motion controller/core request/reporting) and gives sole ownership of Mach 4 to that Gcode block until it is complete and nothing updates until done. I know you have mc.CntlGcodeExecute written. I sware my DROs move with that function too...I'll have to check.
--josh
-
if you look back smurph wrote whats good and bad to have as a Gcode string your right its a while loop