Messages

161

CVI MachStdMill (MSM) / MachStdMill Beta 12 Released

« on: October 06, 2010, 08:08:55 PM »

Hi,
I have sent MSM v0.4.3 (Beta 12) off for posting on the Mach site.

This is minor rev # change so the installer will require you to uninstall Beta 11 (v0.3.15) before installing Beta 12.

The highlights are:
This release has several minor fixes to user reported issues in the probing lib.
In addition some internal re-factoring was done of entry points into the probing lib; There should not be any user observable changes resulting from this.
The RH/NRH LED has been tweaked yet again for appearance.
An obscure installer bug was fixed (only caused trouble if going form an old alpha rev to a newer beta rev).
Fixed a bug were the length and diam wear DROs were swapped on the Touch page.

The release notes have more detailed info.

Dave

162

CVI MachStdMill (MSM) / Re: Mist and Flood control

« on: October 06, 2010, 07:41:13 PM »

I retested this - works as it should on PP.
flood and mist buttons both turn on the mapped mach logical signals and the corresponding PP pins.

I don't have the SS test bed hooked up at the moment so I could not quickly test the SS.
I'd suspect a SS configuration issue - as both 1024 and MSM make the exact same calls to mach for these functions.

More diagnostic info could be had by trying M7, M8 and M9 via MDI - do those work on the SS?

Dave

Both mist and flood control buttons do not activate the relay in our controller with smooth stepper, not sure what would happen if only using the parallel port.

We switched back to the standard Mach screen and all works as it should.

163

CVI MachStdMill (MSM) / Re: Wear Compensation

« on: October 06, 2010, 07:29:17 PM »

I can fix part of this:

The part I can fix: The two wear value DROs on the WCOffset-touch page were swapped in position.
Thanks for spotting this - it's fixed for the next MSM release (which I'm working on as I post this).

The part I can't fix: Wear values are flaky in Mach3. I'm told it is fixed in V4.
Mach does not consistently apply the wear values, the work around is leave the wear value 0 and adjust the base value.

Dave

164

VB and the development of wizards / Re: inputs and outputs not boolean why? help!!!!

« on: September 29, 2010, 10:55:35 PM »

Uh, something about the phrasing you used made me think I should ask ...

The B variable gets set to a value when the line B = IsActive(YHome) gets executed.
You are coordinating when the signal changes vs when the code is executed as part of your debugging - right?

For example:
1) use the editor to step thru the code - you will get  a value for the input from IsActive stored in B.
(we'll assume the value is true at this point) 
2) change the state of the physical input
3) restart and rerun the code again - when stepping thru it this time you should then get the opposite value for B (since it was true, it would now be false).

I mean no offense by my question; I've just found that some mach users think that scripts are constantly being executed and expect the values to change while looking at things in the editor.

Dave

165

VB and the development of wizards / Re: inputs and outputs not boolean why? help!!!!

« on: September 28, 2010, 08:47:49 PM »

As Ger21 said, what you are seeing is a side effect of the the slightly odd way the cypress basic script editor displays values.
This "editor feature" often leads me to write things differently - try this:

Code: [Select]

‘ Show the user the state of the Y HOME input
Dim B as Boolean

B = IsActive(YHOME)
If B Then
    MsgBox “Y HOME is active”
Else
    MsgBox “Y HOME  is inactive”
End If
Yeah, I know that the above is not considered "good programming style"... but you can hover the cursor over the B variable and see if it is true or false... you get to choose between style and being able able to see the variable value while debugging.

Dave

166

General Mach Discussion / Re: call macro from another macro

« on: September 28, 2010, 02:04:53 PM »

Hi,
I figured I'd throw in an extra 2 cents worth....

Yes M codes can call other M codes - many people find that the resulting actions are not quite what they assumed. This is because there are some synchronization considerations you have to worry about (as Ray pointed out).

Also realize that since Mcodes are just files that contain mach scripts, the script language tools that you have available vary  depending on the version of Mach that you are running.

With later versions of mach, the synchronization considerations can be easier - as there are more tools to help the script writer.
In particular, the 3.43.x development mach versions have programming tools which are not avail in the 3.42.40 lock down release.

To learn about these you go get the current mach programmers ref manual
http://machsupport.com/docs/Mach3_V3.x_Macro_Prog_Ref.pdf

Some key things to read about are:
3.43.x supports named scripts that live on disk. Read about #expand to see where mach looks for named scripts.
For me, this effectively let me eliminate all Mcode to Mcode calling. I only use Mcodes as a link from Gcode to get a script invoked.

Some things to read about for more info:

RunScript()   - this has the nice property that it does not return until the called script is finished.

StartperiodicScript() and StopPeriodicScript()  - these calls allow you to start and stop periodic scripts, and allow you to set the run period - this can be much more flexible than the older MacroPump which has only a fixed period.

Dave

167

CVI MachStdMill (MSM) / Re: How to Enable RPM in MachStd Mill

« on: September 27, 2010, 10:39:15 PM »

Hi Osker,

That is good news - this tells me that whatever the issue was, it is a difference between the contents of the profile (XML) files.

1) Yes, 1024 refers to the pre-MSM screen sets. Sorry for the jargon - "1024.set" is the  file name of the old mach mill 1024x768 resolution mill screens. Many people refer to it as simply "1024". So you did the right thing.

2) The steps you followed had you take the working mill profile, make a copy of it, then manually load the MSM screen instead of the old screens. The result is that you now have a working profile that runs MSM.

3) next step? none.   
Just use the profile that you created (the one I referred to as MSM2 in my instruction steps) - it will be just fine for running MSM. The MSM2 profile will now start MSM when you start mach using that profile. Thus there is no next step - you're all set.

4) OK, this does leave open the intellectual question of what was the difference between the profiles that caused the issue.
Frankly, I'm going to ignore that, as whatever it is, it is not an MSM issue (which is the focus of the beta test phase).
I don't mean to sound like I don't care, but in some sense I don't   
...this is an instance where (knowing that it is not an MSM bug), I just can't afford to spend the time needed to track down the details of a non-MSM issue.

Have fun using MSM, let me know if something else crops up.

Dave

168

CVI MachStdMill (MSM) / Re: Error, artcode 904

« on: September 27, 2010, 11:20:16 AM »

Tom,

I have no idea on this one.
Brian tells me that while "Art codes" sound like they should give a clue, they are emitted from a general error trap - and they often happen as a down streeam side effect of some other problem - so many times the actual "art code" is not of help.

All I can do is ask Brian....

Dave

169

CVI MachStdMill (MSM) / Re: How to Enable RPM in MachStd Mill

« on: September 26, 2010, 11:16:26 AM »

Please try this:

1) I'll call the profile that you made for the 1024 mill screen set "M3M"
2) start the mach loader; Create profile; select M3M as the "clone from" profile, make new profile name (I'll use MSM2 as my example", do not check "default profile values"; click ok
3) you will now be back to the first mach loader screen -
4) select MSM2, click OK -
5) mach will start using the new cloned profile (MSM2), it will load the 1024 screen set (as that was the screen set for the M#M profile)
6) use menus: view, load screens. select c:\mach3\MachStdMIll.set
7) you should now see mach load the MSM screens.

Check the RPM DRO - is it working for you now?

Dave

Dave,

Your assumption is correct, "same system" refers to the hardware setup.  I took this a little further today and setup three identical profiles, as it pertains to the index pulse; one for MachStdMill, one for the original MachMill, and one for MachTurn.  All connected to the same machine and pulse index hardware and parallel port pin 12.  RPM readout is displayed correctly in both the original MachMill and MachTurn screens.  No RPM readout displayed in MachStdMill.

Hope this provides a clue.

Dan

170

CVI MachStdMill (MSM) / Re: Probe question

« on: September 24, 2010, 02:40:48 PM »

Update:
I think I've found this one. I've sent Callum a test version to check.

Dave