Hello Guest it is March 28, 2024, 06:02:56 AM

Author Topic: Disappointment  (Read 12368 times)

0 Members and 1 Guest are viewing this topic.

Disappointment
« on: July 18, 2010, 07:41:05 AM »
Disappointment yes, the screens look great but i just don't get the fact that you have to use the latest development version to use the screenset.

Sorry but i will not be bug testing the development version "Mach3 R3.043.10 "

Maybe someone can explain ?
The Good Thing About Mach3, Is It's very Configurable

The Bad Thing About Mach3, Is It's Too Configurable

Offline thosj

*
  •  532 532
    • View Profile
Re: Disappointment
« Reply #1 on: July 18, 2010, 09:24:58 AM »
My understanding is lots of things needed to be changed to make the new screenset function like v4 will function in the future, hence, the dev version requirement. There seems to be much functionality in the new screenset unavailable in lockdown Mach3.

You are, of course, free to NOT use the dev version nor the screenset!

Reading thru the new screenset documentation, I'm reading it like a novel (!), it's pretty nice. Dave, great work on the docs, amazing, let alone the screenset itself. You really need a PayPal Donate spot somewhere (perhaps you do), some of us would pay for this! I haven't loaded v3.043.010 yet on my actual machine computer, will probably try today, but it works fine on a test computer so far.



--
Tom
Re: Disappointment
« Reply #2 on: July 18, 2010, 09:37:46 AM »
thosj

Yes i can understand that, Brian will admit in the past he has fixed one thing only to break something else.

I have had personal experience myself of almost breaking a probe due to an upgrade that changed the way the probing routines worked.

The Good Thing About Mach3, Is It's very Configurable

The Bad Thing About Mach3, Is It's Too Configurable
Re: Disappointment
« Reply #3 on: July 18, 2010, 12:26:50 PM »
Hi Phil,

"Maybe someone can explain ?"

I guess that would be me  :D
Here is some historical context to assist in understanding how we got to where we are today and why the mach dev rev is required for MSM -

The MSM project originally was a User Interface (UI) redesign with the specific target of providing UI support for changes that Brian was making for V4.  The project started in Q3 2009 and a lot of manpower time has been invested to get to the beta release stage.  This MSM package has been in development for about 9 months - obviously, I have not been using the latest mach dev version for that entire time, instead I prototyped the code using the V3 lock down revs of Mach.  This means I was attempting to prototype v4 features by running on on the V3 mach kernel. (BTW, that is not a simple task).

I was pretty successful in doing much of the feature set with V3 - but some things just couldn't be implemented w/o mach V4 support. Along the way I kept a list of things that could not be done without additional script application programming interface (API) support. I also had a list of things that could not be trusted to work correctly in all cases (on V3, without access to info that mach did not expose at the scripting interfaces).

A couple of months ago, I suggested that by adding key portions of the needed APIs to V3, and then making a few of the screen pages reflect V3 (instead of V4) functionality, we could have a spin off version that had 80%+ of the user exposed functionality running on V3. That proposal had both pros and cons....

Pros:
It would provide significant new functionality to users of V3
It would would be a means to get wider spread testing of the package (the Alpha test group size was around 15 people).
It would begin to shift the user base into learning the new UI which would in turn lower the learning & test curve for V4 later on.

Cons:
It meant that Brian would have to put some significant level of work into V3 to add the new APIs.
That time had to come from somewhere - so this would push back other tasks.

The decision was made to create a V3 version of the MSM v4 project.

The minimum APIs we needed to add grouped into a couple of categories:
a) Correct functionality
b) Automated installation
c) Code maintainability  

I'll give an example of each category.

Functionality:
Essentially, every single script that exits prior to MSM that attempts to implement probing functions for Z can be made to crash a probe. In the dev rev we added an api to get the state of the mach option "IncludeTLOinZFromG31()". Without that call, the only thing a programmer could do is assume the state of the corresponding general config page option. You could not even cheat and read it directly from the profile XML (I did that) as the XML is not updated until mach exits.

Set this option different form the Z probing code's assumption and the result is a crashed probe. (you don't want to learn that the same way I did.... )  It's unacceptably dangerous to release software that requires that all users, set multiple options, exactly right, to get the software to work correctly.

Automated installation:
Paraphrasing something I said in another thread and playing on a well known car slogan: "This is not your fathers screen set".

MSM is much more than a set of bitmap screen images. It's really a significant functional enhancement for Mach 3 V3. To get this functionality working on V3 requires a lot of stuff to be going on under the hood.

The alpha packages for MSM were a pain to install and a pain to support - even for a small group of people. Alpha testers had to do things like edit their macro pump to patch in MSM support code and install and hand enable several brains.  It was simply unreasonable to consider rolling out this package for beta test unless a clean automated installation was part of the package.

Multiple APIs were added to enable this to happen. Examples include:
1) Screen sets can now have load and unload scripts that mach runs automatically. Think of these as simple constructors and destructors for a screen set object. We even did this in a way that you can use the facility with old screen sets.
2) To avoid editing user macropumps, we invented periodic scripts. Mach can now run multiple periodic background scripts. MSM fires up the ones it needs from it's initialization code.
3) There is now a way to get brains automatically loaded by mach w/o user intervention via the menus.

Code maintainability:
I have not counted it up lately (I don't really need to know), but I know that the script code in the MSM package is well over 5000 lines...
It is simply impossible to create something of that size and reasonably maintain it without the use of some supporting software tools. We added some key facilities to Mach scripts to support the creation and use of maintainable code:

#expand - this feature implements simple pre-processing for mach scripts. From a maintainability standpoint, it enables one source script to live in one place. This is a huge quality improvement.

For example, the page change buttons in MSM run a script routine. There are over 100 buttons in the screen set that can change a page. In prior versions of MSM, each and every one of those buttons had to have a copy of the routine in it - that's a nightmare if you want to change the routine. Now there is one copy of the routine, in a named script file on disk, that each button uses.  

This is a classic case of a huge effort to provide a feature that enhances quality and maintainability, but that is totally invisible to 99.9% of mach users. Getting this to all work required a huge effort by Brian and I thank him again for doing it.

All the features have been in development for several months (I've been using unreleased mach dev revs for MSM work) and were publicly first made publicly available with mach 3.43.6.  Because of the extensive use that MSM makes of the new APIs, I think they are likely to have been better tested prior to release than the casual user might suspect.

All these things were done in order to enable us to provide the MSM v3 package. We've tried hard to make the user experience simple and easy.   ...and none of this is possible with the 3.42.40 lock down revision - and hence the requirement for use of the mach development version.

Now, having said all this, and again saying that I think the MSM package is pretty stable... we are pragmatic. This is a beta test program for both the Mach Dev rev and MSM.  The software has been through a pretty long Alpha test program before getting to the beta stage, but we all know that when you let more people try it, things will get done that were never anticipated. I expect that bugs will be found - that is, after all, the main purpose of a beta test program.

Each user has to decide for themselves if beta software is appropriate for their use or not. There is absolutely nothing wrong with deciding to let others have the new experiences and waiting until later to jump in.

Dave
Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com
Re: Disappointment
« Reply #4 on: July 18, 2010, 01:07:12 PM »
Hi Dave,

Thank you for your time in answering my concerns. Trouble is i read so many forum posts where users complain if they can't do something the WAY THEY WANT so i am sure there will be lots of users breaking it. :(

I also understand from reading your reply that the new screenset is to be considered BETA and having got Mach3 working consistently i will wait some time before i take the plunge in updating. :-[

The Good Thing About Mach3, Is It's very Configurable

The Bad Thing About Mach3, Is It's Too Configurable

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: Disappointment
« Reply #5 on: July 18, 2010, 04:11:49 PM »
Dave,
Thanks for your replies as i have been following them. I know a lot of effort was required to get it where it is.
Good job on the manual  as i know what it takes to do one.

No problem with the installation but haven't tried it out yet. Just need to get familar and confortable with the screens.
Then maybe I'll try it out. Maybe even probing with bendable probe..... ;)

? Does this version restrict the number of MPG's that can be used?

Comment: Page 37 / 38 you may just want to add a one line which says, if  user has no limit switches then just
position the tool to desired location and ref all.


BTW, I guess turning will get a turn for some attention......soon?  >:D
RICH


Re: Disappointment
« Reply #6 on: July 18, 2010, 05:11:38 PM »
Hi Rich,

Some answers to your questions are below -

Ah, bendable probes - they can be a great idea!
I have to use this as an excuse to share a pic I made during a particularly bad day while debugging the probing routines - pic attached.

"? Does this version restrict the number of MPG's that can be used?"
Nope, MSM does not impose any restriction except that I could only fit one MPG in the jogging panel on the screens. This was a trade off between generality and complexity - we figured one MPG covered most MPG users.

"Comment: Page 37 / 38 you may just want to add a one line which says, if  user has no limit switches then just
position the tool to desired location and ref all."
noted - I'll add that to the new "review this list" - please send any other things found while reading the manual.
Manuals are hard to do, I have relied on reviews by others and hope to further improve it further as the beta program progresses.

"BTW, I guess turning will get a turn for some attention......soon?  Evil"
 ;) sorry, my only comment will be "no comment" wrt to questions re future plans or projects that Brian may have. You have to go ask him those questions  ;D

Dave
« Last Edit: July 18, 2010, 05:18:58 PM by DaveCVI »
Author of the MachStdMill Extensions for Mach3
www.CalypsoVentures.com
Re: Disappointment
« Reply #7 on: July 23, 2010, 11:16:39 AM »
Dear friends, I have to jump in on this one. 

MSM does present a question for those who are already using highly customized screen sets.  Namely, you're used to having it your way and MSM may not fully cater to that way, "So how do I get MY way NOW with MSM?!??"

Believe me, as a dedicated Aqua user (thanks ger21!), I was in the same boat when joining the alpha test.  But, as Dave has described, there is a lot more going on here than pixels and a couple macros.  In the end, you have to consider that MSM represents how Mach3 is going to work with screen sets going forward.  It's not, "just another screen set", in other words.  From that perspective, you're going to have to take a look at it at some point.  Of course, that's a point of you choosing, so its fine to just ignore it until it is production if you like.

OTOH, Dave really has done a superb job and Brian has added some goodies that give this screen set some capabilities you can't get anywhere else.  Whether you want to start learning about how that's done (so you can get your goodies integrated) or just enjoy using it, Dave makes either route pretty easy.  His documentation is a treat and he knows what he's doing as a software engineer, so it won't be time wasted if you're so inclined.

Best Regards,

Bob Warfield
Try G-Wizard Machinist's Calculator for free:

http://www.cnccookbook.com/CCGWizard.html

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: Disappointment
« Reply #8 on: July 23, 2010, 05:15:17 PM »
Hey Bob,
Maybe said differently it could go like this at some point,
"There are no known bugs in the MSM screen or MACHx" that said, it must be in how you modified the screen, config, your code or whatever.
We all have some base point which we refer back to as known to be solid for what we do.
As a major update you need to have a silmiiar point to kick off from.
My nickle......FWIW
RICH
Re: Disappointment
« Reply #9 on: July 23, 2010, 10:08:03 PM »
Assume all software has bugs, because it does.  It's only a matter of whether you want to dive in before someone is saying the obvious ones have been found (that's a beta), or wait for production, when finding the obvious bugs takes a little longer.

Cheers,

BW
Try G-Wizard Machinist's Calculator for free:

http://www.cnccookbook.com/CCGWizard.html