Messages

61

CVI MachStdMill (MSM) / Re: Clone Screen button values?

« on: September 10, 2011, 02:09:24 AM »

Hi, head over to the thread you started on the MSM support forum - I did a customization example and grabbed screen shots as I went. The example tutorial can be seen in your other thread at

http://calypsoventures.proboards.com/index.cgi?action=display&board=discussion&thread=163&page=1

Dave

62

General Mach Discussion / Re: MACH3 Manuals and Docs

« on: August 29, 2011, 01:55:19 PM »

HIYA DAVE, Sounds good for the MSM users but what about the rest of the world(;-).

Well.... I think the best way to skin that cat is for the rest of the world to become MSM users!   

Are you still in charge of the Mach3 Programmer guide? I found a few more things not in it and also have a suggestion for the Buttons,dros,leds section.

Informally, I seem to have the care and feeding of that manual. Shoot me an email - I add corrections that people point out and send updates to Brian when there are enough of them to warrant a rev.

Dave

63

General Mach Discussion / Re: MACH3 Manuals and Docs

« on: August 29, 2011, 01:02:54 PM »

Hi Terry,
Good idea, but it would not be a "first"     

Just one of the benefits of MachStdMill is that it automatically installs all the Mach manuals as part of the package. (with one exception for a manual that the (c) holder would not give permission to redistribute, For that manual, MSM installs a pointer doc to where to get the manual on the web - once that is done, the manual opens from a button on the reference page just like all the other manuals).

Dave

64

Works in progress / Re: New IPS (Interactive Programming System) Professional Screen for Turn

« on: August 26, 2011, 03:06:41 PM »

Hi,
There is a mach script call to get the mach version - with that you can test at run time to see if you find yourself on a version that has a particular feature implemented or not. See GetMachVersion in the Mach prorammer ref manual.

Dave

65

VB and the development of wizards / Re: Using G-code files in Button Scripts

« on: August 15, 2011, 02:27:59 PM »

Hi,
This may help -

Code: [Select]

Const RegenInProcessOEMLED = 179 ' On during regen & Sim process

Sub WaitForSimFinish()
' the call to start the MachSimRoutineOEMBtn is not synchrounous - in V3 it starts off a separate process that does the mach sim
' this routine attempts to wait until the sim routine is finished.
'
' ok this is an imperfect routine in that there is a potential timing hole.
' not much we can do since mach does not provide semaphores or locks for async operations.

' the "RegenLED" is supposed to be on while the regen (and Sim) operation is in process and then
' it goes off when the process finishes.
' we wait for the LED to come on - that should mean that either
' a) the sim process is in progress, or
' b) the sim process finished before we had a chance to see it was in progress
' then we wait for the LED to go off - that should mean the process is completed.

'message "starting sim wait"
While Not CBool(GetOEMLED(RegenInProcessOEMLED))
' process is not running, wait for it to start
sleep(10) ' we want at tighter loop here
'message "waiting for led to go ON"
Wend

' ok the process started, wait for it to end
While CBool(GetOEMLED(RegenInProcessOEMLED)) 
' wait for process to finish
'message "waiting for sim to end"
sleep(100)
Wend
'message "sim ended"

' ok, best we can tell, the process started and then ended, let's return to the caller
Exit Sub

End Sub ' WaitForSimFinish


Dave

66

General Mach Discussion / Re: Pobleme with G31 and axis compensation using formula

« on: August 02, 2011, 06:39:53 PM »

Hi,
This is an educated guess - I suspect it's a bug in Mach.
I say this because I've learned that Mach is not consistent about handling coordinate transformations when reporting G31 touch points. For example Mach does not handle Coordinate rotations and G31 correctly (where that means "mathematically correctly").

Since the formula you are using should be treated (from a math viewpoint) as a concatenated coordinate transformation, I have this gut level feeling that this could be another example of not all parts of mach uniformly handling all other parts of mach....

My suggestion would be to get a (as simple as possible) reproducible test case, write up the steps to show the problem and then contact Andrew at artsoft
Andrew is the first line bug checker these days - if you can show the problem to him, he can be the path to further action inside artsoft.

Dave

67

General Mach Discussion / Re: G31 Probe problem

« on: July 31, 2011, 01:46:04 PM »

Terry, Terry, Terry..... 

Are you trying holding out a baited hook to see if I'll bite? 

HIYA DAVE,So when I do a Code"G31 X10" and the probe never stops when it hits the switch(led comes on) it is the programmer fault(;-). When I do a Code"G31 X10" and it does not make the move untill 3 OTHER commands have processed and THEN the G31 show up and is processed, THAT is the programmers fault?

I almost forgot my personal favorite. I a probe cycle with the proper wait states so the entire Cycle will work on this computer. Run it on the computer next to it and it fails by  jumping over sections of code. The wait state timing was off.

I'm not going to take that bait.   
You offer up some fragments of your past experiences and ask me if those are "the programmer's fault". I will not attempt to answer that actual question as presented - as it can not be reasonably addressed with only the information provided.

You report that have not had success in making probing work from scripts. Your have experienced what you have experienced. 

My point was that your experience does not prove that probing will always be unreliable if done from a script. 

You are essentially asserting that you have not made it work reliably, therefore it can not be made to work. You  have then stated this as an incontrovertible fact in various posts. I know your motivation is to help Mach users - and I admire that - you do a good job of it.  I am simply noting, that for this particular topic, the assertion made is not true. The assertion that probing from scripts can not be reliable made has been dis-proven by multiple "proof by example" reports - my myself and others, that probing CAN be done reliably from within scripts.

For this specific topic, I felt that readers deserved to know that there are others with different results who do not draw the same conclusion re "impossibility".

Yea I know semaphores. Dang Dave this is 2011 the Control program has to do something on its own like keeping track of its threads. (;-)

(;-)

I don't think I made any comments about what I would ***like*** to see mach include for programming support.  I have a long list of those.... pragmatically mach, is what it is at any point in time. 

I have 5 years worth of error and crash data that says otherwise. I have probably over a million (literally) probe cycles in gcode without failure.Can't say the same thing about the macro side.

OK, you have 5 years of problems with scripts and probing.
You have no problems when using G-Code.

That is your experience - it does not prove that probing is ***always unreliable*** if done from a script.

OK, now then I will shift a bit here and say this:

I tried very hard to start my post by saying that I was NOT trying to start a flame war. I meant that.
Yet as I write this post I am seeing other responses, some of which are asserting that I said things I did not actually write in my post. That is how flame wars start and grow - I have no interest in participating in the way the thread seems headed, nor do I want to be fanning the flames.

All I tried to do was
1) point out that not everyone has the same successful / unsuccessful experience when doing probing from scripts.
2) ask that those stating something as a fact to please consider not stating personal experiences as a proven fact.

There is no need for us all to create a raging argument - there is no personal challenge involved in this topic - and I certainly didn't intend anyone feel challenged by what I wrote.

Different people have had, and will continue to have, different experiences, with different aspects of Mach's features.

Dave

68

General Mach Discussion / Re: G31 Probe problem

« on: July 30, 2011, 03:56:52 PM »

Hi Guys,
I have seen this "mach urban legend" expounded that probing does not work reliably in macros (scripts) several times.
This time, on this morning, I choose to offer an alternate viewpoint...   

Let me start with, I am absolutely, NOT, I repeat not, trying to start a flame war of any type.
I speak up now only because dis-information (even when made from the best of intentions), particularly from community members who I respect, concerns me a tad.  For context, I've had some conversations where confused,  non-expert mach users have asked me about this urban legend.

IMHO, telling people that probing can not be reliable when done from a script is a disservice to the readers of the posts. The (incorrectly IMHO) repetition of this assertion does not help users - it just makes them think that a rather significant part of mach (the entire macro scripting facility) is unreliable. 

Why do I have this differing opinion?

To date, I have direct experience with a pretty good size user base that does probing operations, with mach, via scripts, day in and day out, and they have been doing this for between 1 and 2 years now.

Since I developed and market mach enhancement software, the experience has given me some reasonably broad experience from which to form my opinion.  I don't have a way to know how many probing operations each user does; So I have no idea how many individual probing operations that all adds up to - but I am pretty sure that it is not a trivially small number.

During the 2 year experience since I started the software project, not one single time have I been able to identify a  problem that could even remotely be attributed to the way a G31 command was submitted to mach - be it either via Code("G31") from within a script, or as a G31 block in a G-code file.

Yes, my probing software has had some (usually minor) bugs in it during the last two years, and they were always script logic bugs.  At no time, has there ever been an issue, where there was as G31 command that did not work just because it was "from inside" a script.

In fact, (as I'm pretty sure you guys know) in a script, the way that a G31 operation is invoked is by issuing a G31 command - as g-code - via the Code() call. Internal to mach, the script Code() calls and the Gcode interperter both get the G31 command inserted in the code queue. The processing is identical (or so Brian tells me ) from that point on.

The reality is that a script author can write good scripts, and they can write bad scripts. Script quality is not an inherent "a script was used" issue - it's a script author skill level issue.

Are really good scripts easy/trivial to write? Not really, the difficulty level will depend on the programming skills of the author and also on their knowledge of how mach and the target machine operate.

I've looked at a lot of mach scripts in the last 2 years - and the code quality, and the reliability of the script actions varies a lot (!).  Again, that's not evidence that scripts are inherently unreliable (it is evidence that the programming skill level of script authors varies).

I know you guys are both pretty good at understanding mach itself. I take at face value that you may have had problems with scripts you have written. And the details of G31 actions can be tricky.

Where I differ is with the implication that probing is not, and can not never be, reliable when used from a script.

Perhaps it would be more accurate to say that "writing complex, professional quality scripts for Mach can be difficult".

OK, I hereby turn off this mini-rant.
(sorry, it was not meant to be a rant, but I fear it could read that way) 

Dave

69

CVI MachStdMill (MSM) / Re: Fly out panel and screen resolution

« on: July 11, 2011, 12:12:10 PM »

Hi,

Dave, the main reason for me is to be able to change the FRO or Speed-overwrite quickly with a mouse click without opening the fly out window.

I understand the desire - there are trade-offs which had to be made due to the limited space available on a 10x7 screen. In the 12x9 resolution, the overrides are on in the run page.
And while no one will believe it today - when the MSM design was done, wide screen format monitors were much more expensive than the 4:3 aspect monitors - so the design goal was 4:3 rather than 16:9. 

Couple of little comments I have about MSM.
I usually set WCO with probe before I load the file or do anything else really.  When you go to WCO / probing, there isn't a place to change the tool to the number that probe is assigned to, I have to go to a touchoff tab to change the tool number.  It would be more convenient to have the tool number change on the probing page as well.

I bet you are changing the current tool by typing a value into the current tool DRO. That's actually not the best practice - in fact, If I could disable that use of the current tool DRO, I would do so. FYI, I'm told that DRO will not allow that action in Mach v4. Doing things that way causes some technical problems that I'll spare you the details of.

The base problem is that is just changes the "current tool # inside mach w/o doing any of the other actions that a tool change could/should do. For example none of the MSM Tool Change option code will be run as no Tool change sequence gets started... that can blow up a part program if it was expecting all the tool change actions to happen (for example a tool to get measured as part of the tool change) but they didn't get done.

During the MSM design phase, Brian wanted the model to be that all tool changes would be done via GCode - this gives a consistent result internal to mach.

I suggest that you try to break yourself of the habit of changing the current Tool DRO value, and instead get in the habit of doing T# M6 in the MDI control - which is the recommended "best practice".

This also resolves the issue of needing the "tool # DRO" - as the MDI line is on all the primary pages. 

The other thing is the tooling numbers.  I set tools manually on the machine for each job.  It would be nice if there were - + buttons next to the current tool field so that you can just click the buttons to increase/decrease tool number (like there is for tool viewer)

Again - if you do tool changes via T#M6 in MDI, this becomes moot.

Lastly, sometimes I get lost and need to ref an axis or all axis when setting up tools, it would be nice to have a button on the tooling page at least for z axis ref.

There are separate ref buttons for each axis on the run page.
The design was to keep the tooling page for tooling - and referencing axes was not viewed as strictly a tool operation. I realize that referencing impacts other things, and in some sense everything interacts with everything else 


Dave

70

CVI MachStdMill (MSM) / Re: Fly out panel and screen resolution

« on: July 08, 2011, 04:08:41 PM »

Hi,

I'm afraid that we don't have a way to make the fly out panel "stick" when pages are changed.
That action is controlled internal to mach and there isn't an interface for MSM to use to ask mach to "pin the fly out" open.
BTW - this action will be the same for either 10x or 12x9 resolutions - since it is mach's action, it is also what happens for all bitmap screen sets.

FYI - This idea has been requested by a couple of people, and I've suggested it to Brian and he said he would consider doing it.

Dave