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.