Messages

611

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: June 05, 2014, 02:41:40 AM »

Nick,

Normally, the macros will not have the issues you are seeing.  The reason why you are seeing them now is that we changed LUA versions between build 1767 and 1817 and there are incompatibilities with the compiled scripts between the versions.  Normally, the installer will install the macros with mcc files that work and there will be no issues.

For the macros, Mach uses the mcc files.  The mcs files are just a way of getting to the mcc files that us humans can read and modify.  Mach can run without ANY mcs files if the mcc files are compiled and correct. 

Changing LUA versions is not something we will do once we release.  We just made a push to get to the latest code base for everything we use so that we don't feel the need to do it at a later date after release.  In the future, a normal user should never see this.

Build 1817 has a whole host of changes including a move to wxWidgets 3.0, LUA 5.2, and we went from using the static CRT to the dynamic CRT.  Hence the massive difference in build numbers.  I also did a wholesale change on the API (I'm so glad I haven't re-written the API docs again!).

We have one more big change to do before release which is the installation location (feature request and docs not withstanding).  We are planning to conform to MS program installation locations so that Mach will be installed in the "Program Files" for system wide operation (requiring Admin privs) or it can also be installed in a user folder without admin privs.

Steve

612

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: June 05, 2014, 02:20:35 AM »

Choose no.  For some reason, I linked with the debug code in that last build. 

Steve

613

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: June 04, 2014, 08:32:37 PM »

It is because some mcc file is still in there somewhere when it tried to roll all of them up into the one big mcLua.mcc file.  Incompatible mcc files prevent this from happening. 

The rule of thumb is if there is no mcLua.mcc file, then there is an error in at least one script or the mcc files are incompatible.  Those are the only two instances we have found that prevent the mcLua.mcc file from being built.   

Be sure that if your scripts reference any scripts external to the profile (like in Mach4/Modules dir), that those scripts also have their mcc files deleted.  You may have to compile external scripts in the mcLuaEditor as the auto compile will not work for scrips outside of the macros dir.

Steve

614

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: June 04, 2014, 07:57:37 PM »

1817 used LUA 5.2  So we shipped it without the *.mcc files to ensure that they get rebuilt.  Once you press Start Cycle, they will build and the mcLua.mcc will be created.

The mcc files are not compat between LUA 5.1 and 5.2.  So if you have any scripts that you wrote, delete all of the mcc files and let them rebuild.

Steve

615

Galil / Re: Galil And Lathe

« on: June 03, 2014, 06:15:52 PM »

https://www.youtube.com/watch?v=JfnQxDPWoEQ

Steve

616

Mach4 General Discussion / Re: Read write to a DRO ??

« on: June 02, 2014, 12:22:34 AM »

Damn!!!!  Now that was using your head!  Hmm...  Me thinks you are getting good at this Terry.

You can use the OnUpdate and OnModifiy scripts to display and edit scaled values too.  Used if a DRO doesn't show you something the way you want it too. 

Steve

617

Mach4 General Discussion / Re: Mach 4 Feature Request

« on: May 29, 2014, 11:52:14 PM »

Err...  not correct.  Mach4 is Mach4.  There is no difference between Hobby and Industrial, code wise.  The only difference is the license.  The Industrial license "turns on" Industrial features.  But the code base is the same.  That demo version has the capability of running 6 planners.  But since there is no license, it only runs in demo mode with only 1 planner.

The API documentation will come.  I write good API docs.  I just can't write them at the same time I'm developing.  It turns out that I need two hands on one keyboard at a time. 

We don't have the resources to not wear many hats.  I guess we could go out and hire 5 to 10 more people.  But the price of the software would go up.

And what's with the ATC?  My machine has an ATC and it works fine.  The m6 macro handles it.  The m6 that is in the demo is just that, a demo.  Or am I missing something?

Steve

618

Mach4 General Discussion / Re: Mach 4 Feature Request

« on: May 28, 2014, 05:18:25 PM »

We picked LUA because it was the fastest script language available.  And it was written in C which means it is portable and can run on any platform that has a C compiler.  We looked at Python because it seems so popular.  But it was rather slow when compared to LUA.  I don't like the "looks" of LUA very much.  It is true that it does have some C constructs.  But it also has some BASIC like elements to it as well.  And then it has some stuff that really can't be labeled as being like anything else on the planet!  It is bizarre in a lot of ways.  But it is fast and powerful.  The next best thing to true compiled code. 

I wanted to use AngelScript, which is more C like in syntax.  It was pretty fast too.  Not as fast as LUA, but it was faster than Python.  But with AngelScript, we would have had to write all of the wxWidgets bindings and that would have been a real pain.  Plus LUA is so versatile as far as embedding it was concerned.  So LUA won the script battles.

Steve

619

Mach4 General Discussion / Re: Mach 4 Feature Request

« on: May 27, 2014, 07:47:37 PM »

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

620

Mach4 General Discussion / Re: MACH4 Mcode testing

« on: May 27, 2014, 06:59:11 PM »

I don't know Terry.  It was never a design goal to have M codes run subs.  But it is probably possible. 

The build that you have has an issue where IF the G code that is passed to mc.mcCntlExecuteGcode() or the Wait variant DOES NOT produce any movement DIRECTLY, it will basically just return.  For example, one of your previous M codes was trying to do "T111 M6" on one line.  Well...  that line produced no direct movement of any sort.  M6 could have possibly produced movement, but only as a result of another interpreter firing up.  Thus it would have been indirect.  In any case, the only line that was processed was that "T111 M6" line and the rest was ignored.  So the same thing is going to happen with "M98 P5555 L1". 

I'm working on making the mc.mcCntlExecuteGcode() calls work in a different manner where they are not waiting on movement, per say, but rather the execution of the code to be completed.  It seems all just a play on semantics, but there is a difference.  And with this, it just may be able to run subs or G65s.  i don't know yet though.

Steve