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.  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   

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?