Messages

411

VB and the development of wizards / Re: How to get the current subroutine file name?

« on: July 18, 2010, 12:57:07 AM »

Scanning with a script may work - you'd have to do some experimenting to see.

I can think of some things that may make it difficult - consider these in the software design.

1) The macropump period is fixed at 0.1 sec - that may or may not be the sampling frequency which will work for you.

2) an alternative to the macro pump is to start a periodic script (See StartPeriodicScript call in programmer's manual). That call allows you to set the period of the periodic script. However, this is new and only available in 3.43.6+

3) scanning the code via an asynchronous routine will mean that you may need to invent software sync/locking tools between threads (if you need the scanner routine to work in conjunction with some other script like your m6). This is not trivial since Mach has no concept of such things at the cypress basic API level.

4) When mach has a gcode file open, I think that mach opens it exclusively as I seem to remember not being able to open a gcode file in an editor when mach has the file loaded. This may cause you trouble since you are wanting to scan the file that is currently loaded into mach.

Dave

412

VB and the development of wizards / Re: How to get the current subroutine file name?

« on: July 17, 2010, 10:40:35 PM »

Interesting...
I didn't know the filename mach reported changes when an external subroutine is called (that's not in the programmer's manual).
I thought Mach just reported the main gcode file name. 

Dave

413

VB and the development of wizards / Re: How to get the current subroutine file name?

« on: July 17, 2010, 08:12:13 PM »

I've become pretty familiar with the Mach Cypress basic interfaces and I don't think what you are looking for is available from the existing interfaces.  I think the only place the subroutine file name is known is inside of mach during gcode execution. 

Dave

414

CVI MachStdMill (MSM) / Re: initialization #expand message

« on: July 17, 2010, 06:40:17 PM »

mick,
OK, this is good as we're making progress.  

I'm still concerned that you are still seeing an expand error. Assuming this is happening at load time, then it's coming from the initialization file - which means the screen set initialization code is not being running for you (the expand error is a script compile syntax error, so that means the script can't get executed).  That will cause down stream problems - so we should sort this out before you go further..

Could you send me a screen shot of the exact expand error message you are now seeing?

Also, now that the screens loads, it would help me to see what's in the history file at the time you see the error. So the next time you see the expand error, after capturing it, please click the history button at the top of the page - this will use notepad to open the mach history file - I'd like to see the history file contents to see if it has further clues in it.

Dave

415

CVI MachStdMill (MSM) / Re: initialization #expand message

« on: July 17, 2010, 03:41:09 PM »

Mick,

OK, that explains the error message to me -

The MSM profile should be loading a screen set in the file "MachStdMill.set" . This file is supposed to be in the default mach install directory.  So with a default install location, you should have C:\mach3\MachStdMill.set

Is that file present?

I suspect the set file is missing - which would also explain why you do not get the MSM screen set loaded at start up by the profile.

I'll tell you how to fix this in a second - first I want to verify what I think probably happened...

I'd bet that to "fix" this, you looked around and found the MachStdMill\set files dir - which tempted you to use the mach menus to load what looked like a good choice: MachStdMill-v3-10x7 - is this a correct supposition on my part?

If my supposition is good, I have to say that what you did probably seems reasonable under the old simple way screen sets operated, but as the saying goes "this is not your father's Oldsmobile"...    

There is only one profile name that should be loaded to run MSM - and that is <mach install dir>\MachStdMill.set
For a default location install of mach and MSM this will actually be C:\mach3\MachStdMill.set

With MSM, one should never, ever, attempt to load a different screen set name manually via the mach menus.
(congratulations on being the first to do this - we knew it'd happen sooner or later. I'm sorry to tell you there is no prize for being first   )
The reason for this is that al MSM scripts/macros make use of the the new #expand facilities in mach (I'll not try to explain those in this thread). Mach looks for expand files locations that are keyed off the loaded screenset name. This means that changing a screen set name will change where mach looks for the #expand files that MSM uses.... Therefore the screeenset name for MSM had to be static and not be changing no matter what resolution screen set was dynamically loaded. The constant, static screen set name that MSM uses is MachStdMill.set

When necessary, behind the scenes, MSM looks at configured options, and copies some base set files as MachStdMill.set and then reloads the MachStdMill.set file - this avoids problems from changing screen set names (this is how the system dynamically changes between the 10x7 and 12x0 resolutions for example - a user should not need to know this).

In any case the rule is that the only set file to load with MSM is always c:\mach3\MachStdMill.set

I am not sure how the file became missing - I know that the install package puts it the Mach3 install dir - if it wasn't getting installed everyone would be seeing the problem you have experienced.

If you do not have that file present, that explains what happened. I am assuming this is the case in the instructions below -

So, back to the issue at hand - please do these steps:
1) close mach down so that none of the files we want to fix up are in use.
2) copy c:\mach3\MachStdMill\Set Files\machStdMill-v3_10x7.set  to c:\Mach3\MachStdMill.set
That will give you back the MSM set file for mach to find. (The alternative is to reinstall MSM over itself to get the missing file back; copying this single files seemed simpler to get you running).
3) things will still not work the next time you start mach/MSM - you will need to use the mach menus to point the profile back to the correct set file name:  using mach menus: view - load screens  and load c:\Mach3\MachStdMill.set
4) close mach (this will get the current settings saves into the profile XML)
5) restart mach with the profile - you should now come up running MSM

I've got my fingers crossed for you - let ms know if this fixes you up.

Dave

416

CVI MachStdMill (MSM) / Re: initialization #expand message

« on: July 17, 2010, 02:14:43 PM »

Mick,

Oh my... well, let's figure this out.

When MSM loads, it uses a facility added to Mach 3.43.x which runs some initialization code when a screen set is loaded.
The message tells me that the ScreenSetLoad script is being run by mach, but that mach is not finding a script source file that is referenced by that macro.

Something is not configured correctly. The error message tells me that mach thinks your profile has loaded a screen set called "MachstdMill_10x7.set" - which is not what should be happening. The name of the MSM screen set file that should be loaded is always "MachStdMill.set" and is found in the mach3 install directory.

So, I suspect that the profile you are using has bad info in it. Therefore, I want to figure out why.

I would like to know:
a) Is mach installed in C:\mach3 or is it installed to a non-default directory location?

b) assuming mach is in c:\mach3, is the c:\mach3\ScreenSetMacros directory present?

c) within ScreenSetMacros, what sub dirs are present?
There should be a c:\mach3\ScreenSetMacros\MachStdMill.set - is this what you see?
Is there any other subdir in the ScreenSetMacros dir?

d) Did you follow the process to make a new profile to run MSM (as given in the readme file)?

e) If so, which approach did you choose?
Did you add the MSM options to an existing profile or add your hardware config to a new profile made form the MSM master profile?

Dave

417

CVI MachStdMill (MSM) / Re: Compressed screens and buttons

« on: July 17, 2010, 01:43:37 PM »

Fabrice,
No problem re the explanations - I'm happy to help.

I'm glad to know the double click symptom is gone. I'll not look into that more unless someone else reports the same thing.

Re using mach's dev rev and MSM on your production machine: Only you can decide if that is a risk you want to accept.

I'm using the mach dev rev and MSM but I'm not a production machine shop and I'm sure that there are things done out there by mach users that I don't do. Please remember that the required level of Mach is the development version of mach and that MSM is beta release software.  We won't claim that beta level software is bug free.

If you have a problem on your production machine with MSM, please report it and we'll try to resolve whatever issues may come up. If it all works fine, please also report that.

Dave
 

Hello Dave,

thanks for all this explanatation. I use a 22" CRT for the control if the CNC with Mach3,
so i havent the problem that i have with the netbook.
But i think some user user this kind of computer with the combination of smoothstepper
to control the cnc, so that can be an alternative.

For the c) question, i cannot reproduce it anymore, i think that was only
on the initial load of the screen just after the installation.

Thank's for the nice work, if i have time tomorrow , i try on the cnc computer,
but, i hope no problem with the developement version of Mach3, this is
my productive computer.

Fabrice

418

CVI MachStdMill (MSM) / Re: Compressed screens and buttons

« on: July 17, 2010, 01:33:52 PM »

This is soooo cool. You guys did a hell of a job. Can't wait for Rev. 4 to be available for beta testing. Any plans for sliders to boost feed rate and RPM on run screen instead of having to type in DRO?

Hi,
Thanks for the kind words!
In the 10x7 set the sliders are available on the fly out (they would not fit in the 10x7 page space), in the 12x9 set, the sliders are part of the run page.

Dave

419

General Mach Discussion / Re: Announcement: MachStdMill beta release is available for download

« on: July 17, 2010, 12:43:38 PM »

Hi,
I got some requests for screen shots - here are three of the pages:
Load page
Probing page (MSM includes built in support for probing operations to set offsets)
Run page

Dave

420

CVI MachStdMill (MSM) / Re: Compressed screens and buttons

« on: July 17, 2010, 11:07:41 AM »

Hi Fabrice,

a) Regular screen sets for mach are created with fixed size bitmaps. MSM (my abbreviated name for MachStdMill) supports two physical screen resolutions: 1024x768 and 1280x1024. In the manual these are referred by the names 10x7 and 12x9.

The 10x7 set is designed to fully use a minimum screen resolution of 1024x768. If one attempts to fit that size bitmap onto a screen that is smaller than 1024x768, the bitmap is taller than what the physical screen can display. On a 600 pixel tall screen you will not be able to see the bottom (768-600) 168 pixels. 168 pixels is actually over 20% of the screen's height.

To squeeze a screen set onto a smaller screen than the screen set was designed for, mach has the "auto-enlarge" option. The option's name is a little misleading as it will both auto enlarge and auto shrink. This does not result in a very nice looking image because Mach either has to throw away lines from the bitmap as it is displayed (auto shrink) or invent and add lines (auto enlarge).
With auto enlarge turned on (to shrink the bitmap to fit the 600 tall screen), you are having mach throw away part of the screen images.

A 1024x768 monitor has just barely enough screen area to hold the controls needed on a page. A early design decision was to make the 10x7 set use the entire 1024x768 screen area and the 10x7 support in MSM is designed to use the entire 1024x768 pixel area of a screen.

For sake of discussion let's assume the windows task bar is 50 pixels tall (the actual size can vary significantly with different windows settings).  For this example, it means that the task bar is using up 50 pixels at the bottom of the screen and so you can't see the bottom 50 pixels of the mach screen with the task bar present. On a 1024x768 physical screen resolution the recommended settings are to set the task bar properties to "auto-hide". This will make the task bar disappear until the mouse cursor is placed over the task bar - you will then be able to see the entire MSM screen.

It is also possible to lock the windows task bar in such a way that mach will "auto shrink" the bitmap to the area left between the task bar top and the top of the screen. This of course makes the visual impact of "throw away lines from the bitmap" effort more pronounced.

The situation is a bit different with the 12x9 screen set support. That set is called 12x9 (instead of 12x10) because the mach window area it requires is approximately 1200x946 (the numbers may not be exact - they are from memory as I write this).  Some of the increased screen area from a 1280x1024 screen was allocated to leaving space for a nominal size task bar. On a 1280x1024 screen the 12x9 screen set will allow you to have the task bar always present on any side of the screen.

By the way, all the mechanisms I have just described are standard windows and mach3 features and are not specific to MSM.

For better or worse, 1024x768 monitors are essentially obsolete. It is becoming hard to find places that sell new 1024x768 LCD monitors. When they are available, they are the same price as 1280x1024 screens. Brand new 1280x1024 monitors are available online starting at around $100. We supported 10x7 because the installed mach3 user base has a lot of 10x7 screens in use, and we supprot 12x9 because that is the least expensive, most easily available new monitor size.

I think that you would have a much better experience by using a 1024x768 or 1280x1024 screen instead of a netbook's 1024x600 screen.  

b) Regarding the "black button" issue: Brian is aware of it and will be looking into it when he gets a chance. Since it is only a visual annoyance (you can actually still click a "black button"), we decided to not hold up the MSM beta release until that bug is found.

c) this leaves one other thing you initially reported. You said that you were having to click twice (not double click) to get a button to activate.  I shrunk a screen resolution to 800x600 and set "auto enlarge" and tested for this here but I have not been able to make this happen for me.
Is this still a problem for you?

Dave