Messages

311

CVI MachStdMill (MSM) / Re: Edge Probing

« on: August 04, 2010, 12:52:34 PM »

Thanks to lots of work by Tom, we have identified what is happening on his system.
see
http://www.machsupport.com/forum/index.php/topic,15564.msg104401.html#msg104401
for notice of a probing bug (all versions of MSMs)

Now if we can just find the solution, we will have him probing also....

Dave

FYI - for those following this thread, I spoke with Tom earlier today.
He's planning on using MSM to do a job he has to get run.
(Brave man to do a real production part on beta software, I suggested that beta software should not be part of a critical path job, but he wants to use MSM).

In a couple of days when his parts are done, and schedule is more flexible, he and I will get back in touch to figure out the probing things he is seeing.

Dave

312

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

« on: August 04, 2010, 12:48:47 PM »

FYI -
see
http://www.machsupport.com/forum/index.php/topic,15564.msg104401.html#msg104401

for notice of a probing bug (all versions of MSMs)

Dave

313

CVI MachStdMill (MSM) / Notice: Probing bug found with SS systems

« on: August 04, 2010, 12:47:24 PM »

NOTICE: Probing bug found.

OK, this is going to sound a bit weird, because it is...

If you re using a SS, AND you are probing, AND the WCOz <> 0, then a probe may get crashed into a work piece.
A similar bug may exists for X,Y (not fully verified yet) when using a SS and WCO <> 0.

It appears that something about this combination makes the internal tip comp calculation done by Mach (or the SS plug-in, I don't know how that is split between the two) not use the same calculation as other cases.

Software combination:
mach 3.43.10 (or 3.43.12 - they both do the same thing)
MSM 0.2.1 (beta 3)
SS plug-in:  "SmoothStepper Beta2 Ver 0.0150ogx Config"

The bug does not manifest itself on a PP system.

I have gathered all the data and test results to show the problem, and shipped it off to Brian for some help.

Until we get the root cause figured out and solved, please be extra careful when probing with a SS.

Dave

314

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

« on: August 04, 2010, 12:36:01 PM »

Are you using a PP or a SS?
Dave

Dave:

Thanks for the clarification on the gage block. I still can't figure out the"X/Y Face not found".

The probe travels correctly to and touches the face, the "Probe active" LED turns on, then the probe returns to the original position and displays the "Face not found" message. (i.e., it behaves exactly the same as when I exceed the "Max Probe Distance", except it clearly senses the probe being triggered and returns to zero when it touches the face...)

Thanks

315

VB and the development of wizards / Re: Activating/Deactivating E-Stop from within VB?

« on: August 03, 2010, 07:59:11 PM »

Terry,
The fact is that DoButton should not be used for new code. Period. End of story. No If's, And's or but's about it. 
The poster was clearly writing a new script.
There is simply no % in writing new code that uses deprecated APIs.

I just report the decisions as I've been told them:
On V4 the plan is to allow two types of scripts to run:
1) V4 API mode - this will use calls that use the new resource numbering scheme. So these scripts will HAVE to be all new (or rewritten versions of old scripts).

2) V3 compatibility mode - this will be (most of the) existing scripts using V3 API calls.
My understanding of current plans is that DoButton, Get/SetDRO and Get/SetLED et all, are going to be disabled in v4 - including the V3 API mode in V4.   

It's literally been years since the old style calls were deprecated - ever since the DoOEMButton, GET/SET-OEM/User-LED/DRO functions calls were added - that's been a very long time.

I've been in the software game since the late 1960's. - You can believe me when I say that I understand the issues around API changes.

If you want to see some of the issues you're fond of complaining about resolved, you'll have to get used to using some new calls. Some things just can not be fixed using the old API calls - that's a fact.

In all cases,  the use of deprecated calls is a bad idea for new code.

(and it doesn't matter how nice an old API looks on the shelf next to the worn out buggy whip...  )

Dave

HIYA Dave, Just to mention that Fanuc learned a valuable lesson long ago about depreciating old code. After that mess they put it back in(;-) pronto.

Just a thought,(;-)

316

VB and the development of wizards / Re: Activating/Deactivating E-Stop from within VB?

« on: August 03, 2010, 06:10:57 PM »

Be aware that DoButton is deprecated - please do not use it for new code.
The older DoButton call is slated to go away in Mach3 V4.

Use DoOEMButton instead.

Dave

317

VB and the development of wizards / Re: Activating/Deactivating E-Stop from within VB?

« on: August 03, 2010, 04:55:12 PM »

Ah, ok then ....

Get the latest Programmer's ref manual (v0.22) from the documentation page of machsupport.com
Look at the DoOEMButton() function description, then
see the magic numbers in tables near the end - I think you want button 1021.

Dave

318

VB and the development of wizards / Re: Activating/Deactivating E-Stop from within VB?

« on: August 03, 2010, 04:03:55 PM »

Hi,

No offense, but I think either there is a terminology issue here - Or perhaps you want to rethink the desire to disable estop via software.

E-stop circuits are supposed to external to mach and all hardware based. My understanding is that multiple countries have safety regulations which prohibit having software as part of the E-Stop facilities. An E-Stop facility has to always work and can never be disabled. This is not the same as the machine being disabled- when an estop circuit says "don't run", the machine is disabled - but the e-stop logic circuit is not - it is doing it's job of keeping the machine from running.

I suspect the reason that there is no script API for "disabling e-stop" is that this would be a safety problem (and in contradiction of various regulatory agencies).

Consider:
1) mach disables e-stop
2) run some script that causes movement etc - and it goes wrong....
3) operator lunges for e-stop button only to find it is not working (estop is disabled)... very bad mojo.

Now then, if instead of estop, you mean that you want to make Mach3 change states between "ready" and "not ready" - that you can do from a script - it's the reset OEM button call which does this.
Note that you will not be able to make mach "ready" if the e-stop input signal is active - which is how things should be.

Just my 2 cents worth...

Dave

319

CVI MachStdMill (MSM) / Re: Manuals not available thru the reference page. For me

« on: August 03, 2010, 02:39:21 PM »

Hi,

I see "C:\Program Files (x86)\... in the path for the reader - which is a clue that you have 64 bit windows installed as this is the folder for 32 bit apps on win64 installations.

Therefore, I deduce that you are running a 64 bit version of windows - is that correct?

Assuming my deduction is correct, I'm sorry, but I have to point out that Mach3 is not supported on 64 bit versions of windows.
Please refer to the main Machsupport.com web page where it says:

Mach3 Minimum Requirements:

    * 32-bit version of Windows 2000, Windows XP, Windows Vista, or Windows 7 Operating System

I am unable to assist with problems arising from the use of an unsupported OS version.
For running Mach3, you need to use one of the supported Win32 versions of windows.

Dave

320

CVI MachStdMill (MSM) / Re: Beta 3 a success

« on: August 03, 2010, 12:43:28 PM »

Calum,
Thanks for letting me know beta 3 helped- 
Dave