Messages

1061

VB and the development of wizards / Re: Mach3 CB timers()

« on: June 04, 2015, 04:18:27 PM »

OK i take that back I just tested it here. It has a resoultion of 13 decimals but displays as seconds.

Mach3 V.062

1062

Mach4 General Discussion / Re: need a little bit of help

« on: June 02, 2015, 07:49:53 PM »

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

1063

Mach4 General Discussion / Re: need a little bit of help

« on: June 02, 2015, 07:14:03 PM »

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

1064

Mach4 General Discussion / Re: need a little bit of help

« on: June 02, 2015, 12:32:15 PM »

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

1065

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: June 02, 2015, 12:20:52 PM »

Steve THANKS for the List.  It is a BIG help .

(;-) TP

1066

Mach4 General Discussion / Re: need a little bit of help

« on: June 02, 2015, 12:03:33 PM »

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

1067

Mach4 General Discussion / Re: need a little bit of help

« on: June 02, 2015, 11:40:10 AM »

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

1068

General Mach Discussion / Re: Mach3 for press brake controller?

« on: June 02, 2015, 11:09:03 AM »

I agree with Gary a PLC is the way to go here.  Can it be done in Mach3 sure , BUT it will not be a standard type operation that most operators understand.  Can a conversational screen be developed ? Sure if you have the time and money to get it done. Will you have problem with teh PC type installation ? Most likely . Mcah3 and PCs are not always a friendly mix.

Just a thought, (;-) TP

1069

General Mach Discussion / Re: How to make Mach3 jump up uppn pressing ESC

« on: June 02, 2015, 12:45:21 AM »

Set up your safe Z setting to what you want.

(;-) TP

1070

Mach4 General Discussion / Re: need a little bit of help

« on: June 01, 2015, 11:25:55 PM »

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