Messages

1

CVI MachStdMill (MSM) / Announcement: MachStdMill End Of Life

« on: June 12, 2021, 03:23:53 PM »

June 2021 -

Calypso Ventures, Inc. has announced that their MachStdMill (MSM) software has been set to End-Of-Life status.

This could impact current licensees ability to continue to use MSM in the future (for example after a PC hardware failure).

For more information, including what current license holders need to do maintain future us of MSM, please see this post on the CVI support site:

http://www.calypsoventures.com/forums/viewtopic.php?f=4&t=1039&p=2538#p2538

David Bagby

2

Mach4 General Discussion / Re: Mach4 Probing and reporting

« on: May 04, 2014, 02:23:16 PM »

Hi all,

HIYA Steve I believe yall missed the point entirely. PROBING is very different than all the other uses for G31 and YES I have used it on cylindrial grinders as well as torque limit skip.

Actually,Terry I honestly mean no offense... but.... I think it's you who have missed the point that the error state at the end of a G31 movement is a separate topic from "what do you want written into a coordinate file".
I get that you only want trip coords written - and that makes sense for some situations - just not all of them
Where I think you are having a tad of trouble is in separating control of what goes into the file from the state when a G31 completes.

WHY not let the machine do the work and take the load off the programmer/operator. Doing an error check(nontrip) at the machine level should be Easy compared to writing TONS of error checking in a probing routine.  The machine is ALREADY looking at the trip flag  if it does not trip  simply allow it to error instead of continue.

Here is the problem: you are assuming that "at the machine level" is identical to "if the probe does not trip, we must estop".
A lua script exteneion as Steve suggests is also "at the machine level".

Many probers will thank you for it

and  I (and I suspect many others) will curse you and all your ancestors and descendents ( if each and every G31 move that does not trip the probe results in the machine generating an error in the control. That would mean that it would be impossible to probe a vector and determine if the path was clear w/o having to reset the cotnrol from the "auto error is no probe trigger" condition. No thanks.

Simply make it an option that is set in systems parameters. You can have it or NOT just change the parameter value.

YES! BUT.... the option you want is not to control the generation of an error at the end of each G31 movement. THe option you want is to control what gets written into a point file - based on the end state of the G31 move - where that state is "tripped or didn't trip during a move". Both trip and not-tripped are valid end states ( and therefore not errors).

In fact, what you want re point file control is a good argument for NOT building a fixed point file application into the control. It would be much better as a control extension that is configurable.


Dave

3

Mach4 General Discussion / Re: Mach4 Probing and reporting

« on: May 03, 2014, 06:02:04 PM »

Terry,
I believe that you are mistaken when stating that a G31 that does not trigger the probe is an error condition. I have no such dependency listed in any fanuc gcode language reference I have; but I won't calaim to have all such relevant publications created since the start of time....
Since I understand that the M4 gcode interpreter has been reworked to be "more fanuc compatible", I would appreciate any pointer you have to a fanuc reference supporting your assertion re this "error condition".

Consider this common scenario: You want to know if the path from you current position to a known position crosses a part or not. This is common, for example, when finding the outline of a 2D part via probing. Common algorithms do a probe a known distance fro the current position in X or Y while looking for the part edge. It is not an error to complete a G31 and end up at the G31 commanded position. In fact, this is exactly what the move was meant to "learn" - that the G31 movement was "clear".

I suspect you are mixing two different concepts: 1) An error condition or not when a G31 movement is completed and 2) what to write into a file as a result of a G31 movement. Those are two independent topics.

#1 concerns the definition of the gcode sate machine at the end of a G31 movement. A skip command that did not skip any movement is not an error state - - it is one of two possible normal, non-error states that a G31 may end with. There are (at least) two common ways to determine at the end of a G31 movement if the probe was triggered: a) compare the current position with the commanded position and b) ask the control for the state of the probe input.

I'd note that support of b) is included in Mach 3. Brian's comment that he thinks he added such a register to indicate this in M4 also implies that M4 was intended to have the same support. When the G31 movement is complete, you inspect the state of the probe signal to learn whether the movement resulted in a trigger event or not (this is why M3 has to keep the  probe positioned with a bit of overrun - so that the probe input state will be correct after the probe movement is done - i.e. at the time an application script checks the G31 ending state).

#2 (logging of G31 end coordinates) is an additional layer added on top of the basic G31 gcode movement. M3 has such a facility and apparently M4 has something similar. However, a desire to write (or not write) a value to a file upon normal (i.e. not error) completion of a G31 is an independent topic. You may or may not want the end point of a given G31 move in the file- it all depends on what you are using the data file for.  Just as you gave an example of a situation where you would not want the ending coordinate written to the file, there are different applications where one would want various combinations of: trigger points, non-trigger points, or both written to a data file.

Please try to logically separate the behavior you may desire at an file write application level from the "error or not" ending state of a G31 movement.

FYI, yes, there are other (non-fanuc) gcode variants where the language is structured such that the gcode program uses different probe commands to handle the combinations of Triggered / not triggered and which is to be considered the "normal / desired" end state. One example I am aware of are the LinuxCNC extensions to RS274 - but I consider that not germaine to the discussion as those are not Fanuc compatible gcode interpreters.
 
Dave

4

Mach4 General Discussion / Re: Mach4 Probing and reporting

« on: May 03, 2014, 11:19:13 AM »

Hi Terry,

IF it reaches the endpoint then it IS an error probing wise.

I understand that a goal of M4 is to make the Gcode closely match Fanuc actions. Given that, I think that the statement you asserted above is incorrect. A G31 is not defined as a "probe only move which is always expected to trigger".  G31 is defined as a "Skip command" (ref smid, CNC programming techniques"). As defined, issuing a G31 to a given coord and having the controlled point reach that coord without the probe triggering is not an error condition.

A probe trigger simply causes the movement to "skip" remaining distance for the G31 (IFF the probe triggers). If the probe does not trigger, then no movement amount needed to be skipped and the end point is the programmed G31 coordinate (which is not an error condition).

Dave

5

CVI MachStdMill (MSM) / Re: Probing and touch plates - your MSM experience?

« on: January 12, 2014, 12:30:57 PM »

Hi,

<ship>
This routine can be automated easily within the MSM app. I can implement it if you can add couple of DRO in your setting page tha i can use.

Thank a lot for your interest

Please feel free to customize MSM to suit your needs. In case you were unaware of it, you can add DROs to MSM screens (there's no need for CVI to do it for you).  I recommend using Machscreen for mach set file editing (that's what was used to create MSM's pages). You're free to add some DROs and script code to support this technique for handling your probe's tip offset errors.  Section 15 of the MSM user manual covers the techniques for customizing MSM.

Dave

6

CVI MachStdMill (MSM) / Re: Probing and touch plates - your MSM experience?

« on: January 12, 2014, 12:25:46 AM »

Hi,
Here is a little document with some diagrams for you to think about. These illustrate some sources of "Cosine error".
When a probe tip is centered on the Z axis, the error is as least a constant with respect to the XY direction of a probe motion.
When a probe tip is off the Z axis center, the error becomes more complex - and that is just in the XY plane.
Now consider a probe direction that is along an arbitrary vector in X,Y,Z....  I think you'll quickly decide that it's much more cost effective to invest in a probe tool that has centering adjustments.

Dave

7

CVI MachStdMill (MSM) / Re: Probing and touch plates - your MSM experience?

« on: January 10, 2014, 01:16:12 PM »

Hi,
I'll try to address your comments here. Please see the information below.

By the way, the main MSM support forums are here:
http://www/CalypsoVentures.com/forums

For future questions you will get a faster response by posting questions there.

 

i experience some problem with your screen.
i use a canadian french computer. So, the default marker for digit is "," instead of ".".
When i edit the tool table, the numeric value in the pop up window use ",". To be able to save my entry, i have to change them all to "."
and i have to do it each time.

I think you have to modify your code to take care of this isue.

I would love to be able to make MSM follow the various regional settings for numbers and currency. Unfortunately, this problem is not in MSM, it is in Mach.  Much of MSM is written in the cypress basic language that mach uses for scripts. Unfortunately neither Cypress basic or Mach itself support internationalization settings. I asked about this for mach 3 and was told by Artsoft that mach3 was never going to be updated to support anything other than US English settings. 

The best I could do was to document this in the MSM release notes. The only regional settings MSM supprots are those that Mach 3 supports and that is only US English settings. Please see teh MSM release notes, section 4 (Known Errata in Mach3), item # 53.

Other thing.
When i probe a pocket or a edge, is not alway to zero it. Often it's because i want to mesure it in reference with another feature. So i propose to add a button to tell mach that i want to zero or not.

This one I can help you with. There is a button called "probe only". It is in the lower left corner of the panels that have the green arrow probing operation buttons. Whenever this button is on, MSM will not tell mach to reset zero to the probe point.
I think this is exactly you are asking for. See section 8.6.3.1 of the MSM user manual.

Other thing,
My probe dont have any possible adjustment. Si the probe is alway off center. To take care of this, i mill a round pocket on my mill table. This pocket is at a know location in the machine reference system. So when i put the prob in, i mesure the center of this pocket. The mesured position of the pocket minus the theorical mesurement of the pocket give me the actual offset of the probe. This way, when i probe a part, i just have to remove the value calculated to know the real position of the part.

To take care of this, i propose to:
-add two value in the screen to enter the real position of the pocket.
-Add a new button in the probing page to mesure the center of this pocket for probe refference purpose.
-Then, each time i probe a part in a specific direction, take care of the compensation for the probe offset.

This type of problem is why I recommend that people use probes that can be adjusted. 

However, I am also thinking about what you have described.
It seems to me that the process you have described is maybe not sufficient to resolve the errors from a probe that does not have a centered tip.  It also seems to only address probes along the X and Y axis.

It seems that the results you are getting are dependent on the diameter of the cylinder that you are boring and using for compensation. I'm thinking of two circles, on inside the other, with their circumferences tangent at one point only. This is what we have for the probe you described. The "compensation amount" is not only a function of the direction of the probe movement relative to the (offset from center)  probe tip, it is also dependent on the relative diameters of the cylinder and the probe tip.
At least Part of this error can not be removed (without using having a physically impossible zero diameter probe tip).

This gets complex quickly and is one reason that the probing routines in MSM are oriented toward increasing productivity of job setups. Most job setup operations only require probes along a single axis, and in those cases it is good enough to assume that the surface that touches the probe tip is perpendicular to the direction of the probe movement.
A probe whose tip is not concentric will create additional error.

Since probes that have concentric adjustments start at about $120. It seems that the most economic way to remove this error is to get a better probe tool. (the reality is that the effort to implement what you describe is much more than $120 of man power time).

Dave
 

Over all, this screen is amasing.
Thanks.

I'll take that as a compliment. :-)

Dave

8

Works in progress / Re: Community Lathe Screen set....... Do you want one? See body......

« on: November 27, 2013, 01:45:32 PM »

OK, I agree that the stock mach lathe screens leave a bit to be desired.
That's one reason we added lathe support to MSM last year.
I anyone wants an alternative UI to use for lathes, one that is already done and released, you can use the MSM lathe screens.
They're available as part of the free personal edition of MSM (so the price is right).
http://www.calypsoventures.com/

Dave

9

CVI MachStdMill (MSM) / Re: question re compensating for probe offset

« on: November 08, 2013, 12:03:03 AM »

if I edit the but on in your probing wizard. is there a way to call the same code twice and print or use the average?

OK, here are some steps to get you started in trying this out...

The probe op results are shown by MSM in the probing panel. The circle routines display X and Y (center position) as well as X,Y width and diameter (X,Y = diam for a circle, different for a rectangular pocket).

I'd do the following manually to see if you get the results you want - then you can code up a button.

For a first step you can do one op, get the values, do the 2nd op and compute. The DROs are also accessible from a mach script, so the button code could become a wrapper - it would do one op (make the call the button already does), get the dro values for the result, rotate the spindle, make the probe op call again, get the values, crunch numbers and away you go.

BTW- the primary support forums for MSM are here:
www.CalypsoVentures.com/forums

Dave

10

CVI MachStdMill (MSM) / Re: question re compensating for probe offset

« on: November 04, 2013, 11:49:20 AM »

Hi,
I moved your post out of the announcement thread to keep things tidy.

Is that possible to edit probing button?

Yes, MSM is fully customizable. How to customize MSM is covered in the mill user manual.

For example:
I want to find the center of a circle. If i want good accuracy, i have to find the circle once then turn the spindle 180 degre and find center again. The résulting real center is the average of both mesurement. That way, all error introduce by the ecentricity of the probe, the TIR of my spindle, ... are wiped off.

To accurately find the center of a circle, you can use the MSM circle center probe routines. Note that MSM supports the ability to find both the center of circular holes and circular extrusions.
I also suggest that you read the section of the manual about probe calibration. The MSM calibration process will take care of the types of errors you mentioned. It is important that each time you mount the probe, that you use the same spindle orientation (since there is not a way to "Read" the orientation of the spindle, there the software can't compensate for an arbitrary orientation).

To be able to do it, i have to modify the probing macro. Is that possible?

The probing library for MSM is not offered in source form. 

Dave