HIYA Simpson, A lot of controllers have a version of the TLM even lower end controllers (FlashCut as just one example). In the Haas version you have a menu to select the type on wear function you plan to use for each tool .  Be in cut inches, #holes drilled # tapped holes,etc,etc.  

In the industrial scene you rarely cut much air (can't afford to) so to base it on cut time does work out well.  AND for the most part it IS part magic.  To work well you start with your TOOL manf recomendations as to tool life UNTIL you collect enough of your OWN data to make adjustments.

AND yes there are ones that use load parameters as well as heat sensors,rpm,chipload, etc. You can have whatever you want you just have to want/need it bad enough to pay for it(;-).

In the Haas version you can also spec out replacement tools in the ATC so when TOOL#1 gets to the service life it automatically switch over to use tool #101(same type tool) and carries on. I have seen machines that had tool changers to feed tool changers where the machine cut for weeks at a time .  

SO TLM is nothing new in the machining world. Heck I have a version that runs on a plasma machine to track consumables and it also gives out the average CO$T per CutTimeUnit of the electrode , nozzle.

You can ALSO use your CAM to help track CUT units. SheetCAm does a great job with that. It transfers the Cut data into Mach3 though the Gcode #vars and we pick it UP from there and process it as we please.

In TLM there ARE many options to play with.

(;-) TP

For now, the only way I can see MACH4 being completely screwed up is if there is as little emphasis put on quality documentation as there was with MACH3. It is an incredible lack of respect for peoples time to make them dig and dig and jump through hoops and experiment and beg, borrow and steal to get even the simplest tasks accomplished  . . all due to nonexistent docs. My hope is that MACH4 fares much better in that regard.

IMHO the importance of this statement can not be over emphasized.

Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.

Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

HIYA Simpson, A lot of controllers have a version of the TLM even lower end controllers (FlashCut as just one example).
<snip>

This is great info. Thanks for the explanations.

In TLM there ARE many options to play with.

Well, hold that though because is speaks to my original premise; that MACH4 can be the 'Burger King' of CNC. i.e. 'Have it Your Way'!.

The notion that you are getting an incomplete piece of software that you have to 'finish yourself' would be a very unsettling prospect for users who are not programmers. I get that.  AND unfortunately the MACH marketing team, if there even is such a thing seems to specialize in shooting themselves in the foot, so I would not hold my breath for participation by the developers in any incentives to stimulate the community in producing these needed utilities and scripted features.

Providing a chain saw to a remote village is a noble act, but if the villagers have no idea how to use it and no gas to run it, really you have not accomplished anything useful.  So they have this great tool with massive capabilities, but while they are waiting waiting waiting for someone to bring some gas and show them how to use it, it just sits and gets rusty. It will be unfortunate if MACH4 takes this path. After all the work put into this project, it would be a shame if the result is moving from providing broken tools that are difficult or impossible to use to providing GREAT tools . . . .  that are difficult or impossible to use.

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?  

I grant that it was technically incorrect for me to state 'Lua is C' because to be literally accurate; it is a scripting language based on C. This is the statement made by the author of Lua and by the org that is maintaining and distributing Lua.

Portuguese and Spanish are not 'the same' language, but the languages of these neighboring countries has the same roots and persons speaking the languages can have a conversation . . . at least as well as an American and a Brit . .  both of whom claim to be speaking 'English' . Ever talk to a Bayou Cajun or someone from Rural Arkansas? Is that actually English?  Are you supposed to need subtitles for English speakers?  

There are currently 3 flavors of C and they are not compatible with each other, BUT, any C programmer can look at any of the code and clearly recognize it as C code. I was moaning about having to learn vet another new language to develop on top of MACH4 . . until I researched Lua. As soon as I saw the Lua code, I though "Hell, this is not so bad, just another flavor of C, no biggie."

Lua is scripting and it is designed to be embedded in apps, so you are correct in that it is not ACTUALLY 'C' or more accurately one of the official flavors of C, however, I disagree that comparing it to C is unlikely to produce anything useful. Who ever heard of Lua? My initial reaction was not uncommon. Had I known that Lua looks like C, walks like C and quacks like C, I would not have wasted all that good whining on it.  

I have followed the Mach4 threads for a while.  I don't have the expertise of either simpson36 or BR549, but I can see both of your viewpoints.  I can program and I plan on trying to make a contribution in that area, but I'd obviously prefer to get as many features without programming as possible.  I like both of simpson36's views that the community can contribute a lot of the features to Mach4 through scripting and that there needs to be good documentation.  Every programmer likes to develop features, and very few programmers like to develop docs.  How will documentation for the 'core' features and community contributed features be related?  The more tightly integrated they are, the better.  The current forum is great if  you post a problem and someone answers you.  It's not so great for trying to find the answer to your question by searching through previous posts.  It seems like an actively curated, organized wiki might be a good solution.  There should be multiple indexes organized based on different criteria.  This would allow a lot of the work for the documentation to be taken off the backs of the dev team.  The docs for the core functionality would be curated by the dev team or some other expert, the structure of the add on features could be curated by someone like simpson36, and the entries for the specific features could be curated by the feature creators.  Links could be made from the wiki to the forum.  I know this will take work to set up, but I think it would be worth the investment after the core functionality is set up. I would much prefer a solid but limited core with good documentation over having more core features without documentation.   I also think it needs to be as easy as possible to add the desired community-generated functionality to Mach4 from within Mach4. 

The docs for the core functionality would be curated by the dev team or some other expert, the structure of the add on features could be curated by someone like simpson36,

Appreciate the vote of confidence, but I am far too busy to contribute in this way. I am already spending a lot more time on this forum than I should, but in my opinion, there is a 'make or break' topic on the table (as it should be) re: documentation, so I'm trying to get my 2 cents worth in on the assumption that the developers are paying attention to this this thread.

I would much prefer a solid but limited core with good documentation over having more core features without documentation.

Can't agree more. The demo release is identified by the top developer as have an objective of 'letting people play with the screens'. Well, it take about 2 minutes to make a pretty button . . so if that satisfied the objective, then they have done a great job. Making the button do something useful is an entirely different matter and that feels like a rewind to the guessing game that was MACH3.

In my never-so-humble opinion, the great emphasis on fixing bugs at this point is misplaced. The emphasis should be placed on providing at least rudimentary documentation WHILE there are people available and willing to evaluate how the screens work in a manner that has some bearing on the usefulness of MACH4 as the foundation it has been hyped to be. I got Modbus going under TCP and finally got some data moving between my processor and MACH4. While I very much appreciated the help provided by the developers (and it would NOT have been possible without that help), the effort was just unjustifiably great for such a small fragment of accomplishment, and I have chosen not to continue evaluating MACH4 until there is enough docs that I am not literally wasting my time digging and guessing.

Riddle me this: how much actual impact would the eval process take if a particular bug gets fixed now or in two days. OK, how much actual impact would it have on the eval process if those two days were used to provide at least some crude useable documentation?

I was excited to have the opportunity to evaluate MACH4, but I have stopped. There are some big dogs around here who have contributed massively to MACH and are getting unhappy. The nasty part about that is the negative feelings are primarily due to misconceptions and it seems I am the only one trying to explain why MACH4 extensibility is actually a very good thing . . . but without the ability to provide an example without spending ridiculous amounts of time. It's getting old fast.

  I also think it needs to be as easy as possible to add the desired community-generated functionality to Mach4 from within Mach4. 

If MACH4 were my product, and was close to release, I would already have somebody assigned to this task full time. However, I don't see this happening and I for one would be happy to have some documentation instead. MACH4 looks really good and I'd be happy to evangelize for it, but not if amounts to selling snake oil. We need to be able to produce examples of what MACH4 extensibility can actually do. THAT is what will excite the skeptics and generate the buzz.

When some docs appear, I'll jump back on board, but for now I'm just collecting info on interesting topics and then adios.

Guys, we are simply not going to have API documentation until Mach 4 is done.  We already tried documenting it, spent nearly a whole month doing so, all to have it become totally useless because Mach 4 changed so much.  4 weeks blown to high heaven!  A lot of the changes have been based on your comments, suggestions, and feature requests.

But the docs that we did were really nice for the two weeks they were valid.

So docs will come in time.  And we are WELL aware that everyone wants them.  But we are not a 500 employee company.  We don't have someone to put on the documentation task full time, as bad as I wish it we were able to do so.  That and the fact that whomever it is that does the documentations will also need to be a C++ programmer.  So it will be Brian or myself doing the documentation.  BTW, I was the poor sap that did the month long documentation stint that became relegated to uselessness.  Has anyone else experienced working a solid month on something and having it all be for naught?  It is NOT cool.  Not at all. 

Which came first, the chicken or the egg?  All I can say is the guy developing the egg was pissed when the guy developing the chicken changed the chicken.  Or vice verse.  Even if it was the same guy developing both!

Steve

Quote

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?

You evidently don't understand what makes a SCRIPTING language a SCRIPTING language or you wouldn't need to ask that question. However, from the Lua site - Page 1 para 1.

Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection,

These are (some) FUNDAMENTAL language defining characteristics. Not ONE of them applies to C.

You evidently think similar syntax is THE defining factor in language comparison. You also evidently misunderstand the term "compile" in that you think "compile" automatically implies the target is machine code. It does not. As a scripting language it would not make sense to compile Lua to machine code.

any C programmer can look at any of the code and clearly recognize it as C code.

What a silly thing to say - I've been programming professionally in C (and many other languages) for over 30 years and I see Lua as Lua. Just as any C programmer looking at Java would see it as Java just as any C programmer looking at C# would see it as C#. Why do you assume that the whole world sees things as you do after your five minutes of exposure?

Who ever heard of Lua?

Literally thousands - if not hundreds of thousands of people who use it all the time. Why oh why do you think nothing exists until YOU'VE heard of it?

Lua looks like C, walks like C and quacks like C

On a dark night, to those who are not that familiar with ducks, it might LOOK like a duck but it most certainly does not WALK or QUACK anything like a duck.

Quote from: simpson36 on May 27, 2014, 02:35:04 PM

Quote

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?

You evidently don't understand what makes a SCRIPTING language a SCRIPTING language or you wouldn't need to ask that question. However, from the Lua site - Page 1 para 1.

Quote

Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection,

These are (some) FUNDAMENTAL language defining characteristics. Not ONE of them applies to C.

You evidently think similar syntax is THE defining factor in language comparison. You also evidently misunderstand the term "compile" in that you think "compile" automatically implies the target is machine code. It does not. As a scripting language it would not make sense to compile Lua to machine code.

Quote from: simpson36 on May 27, 2014, 02:35:04 PM

any C programmer can look at any of the code and clearly recognize it as C code.

What a silly thing to say - I've been programming professionally in C (and many other languages) for over 30 years and I see Lua as Lua. Just as any C programmer looking at Java would see it as Java just as any C programmer looking at C# would see it as C#. Why do you assume that the whole world sees things as you do after your five minutes of exposure?

Quote from: simpson36 on May 27, 2014, 02:35:04 PM

Who ever heard of Lua?

Literally thousands - if not hundreds of thousands of people who use it all the time. Why oh why do you think nothing exists until YOU'VE heard of it?

Quote from: simpson36 on May 27, 2014, 02:35:04 PM

Lua looks like C, walks like C and quacks like C

On a dark night, to those who are not that familiar with ducks, it might LOOK like a duck but it most certainly does not WALK or QUACK anything like a duck.

You conveniently side stepped my contention that the author and org site refer to Lua as 'based on C' and instead launch into some esoteric definition of a scripting language. The line you quoted has to to with Lua being embedded . . which I already stated. I also already stated that you are CORRECT in that Lua is not LITERALLY yet another flavor of actual 'C'.  What more do you want? I don't understand what your rant is all about.  

You also have your own definition of 'compiled' which for some reason is only valid if the end result is machine code. Instead of educating me, you should be informing Lua and the MACH4 developers and anyone else who does not have your 30 years of experience and is using the term 'compiled' all over the place. Egad! What is wrong with these people?

On a dark night, for those not familiar with forums, it may seem that the alleged thousands of people who know all about a new scripting language has some relevance to this conversation. Your incorrect assertion that I somehow control what the 'WORLD' thinks is also irrelevant. I never said anything at all about the 'WORLD'. I have two words for you to contemplate: HOBBY FORUM followed by 'where people have posted that they are lamenting having to learn a 'new' language just to use MACH4.

You expanded this from a local forum to the 'WORLD' and from a genealized observation to an Uber Tech Debate that really has no bearing on MACH4  . . at all. Behaving  as if I purchased commercial time on CNN to spread some contrived self serving evil agenda is a bit over the top, don't you think? Geeze, get a grip.

You clearly also turned this into a personal attack. Very naughty, especially for a moderator. No soup for you!  

Let me recap what ACTAULLY happened; SOME members of a group that I belong to was lamenting what they perceived as a large learning curve to climb as part of a move to MACH4, namely Lua.

ALL I said was "Hey guys, not so bad, the part you see is like C"   I left out the part where I said "Except those of you 'hobby guys who are worried about learning a new language' and yet are also computer scientists who author entire scripting languages and write compilers. For YOU guys, LUA is very different."

Sorry I missed mentioning that last part and thanks for filling in the blanks. Now everyone has a clear picture of my ignorance and will not be swayed by my heretical ramblings.

If I promise to behave, and then you won't need to spend so much time critically evaluating every word I post, could you then possibly put those 30 years of professional C experience to good use by writing some freaking documentation for MACH4?  Pretty please. I'll be good, I promise.

You sir, are as slippery as an eel - changing your argument as you go and making out that's what you said in the first place. I quoted the bit that I disagreed with - nothing more - nothing less. I'm not going to follow you around the block as you pretend you said something else and worse, pretend I said things that I didn't.

As far as a personal attack is concerned - I don't recognise that at all. could it be that that's just the way YOU see it whenever anyone has the bare faced cheek to disagree with you?