开云体育

Jeff:

Hmm, I could understand if it was reverse of that, but for MAch2 to read
23 then 25 is a bit strange...

Art
www.artofcnc.ca

Art,
My point was that there is some sort of interaction between Mach2 and
the OCX. I was stating that before I ran the ocx my frequecy as
measured by Mach2 was 23KHZ. After running the OCX the frequecy
measured by Mach2 is now 25KHZ.??

Jeff E.
--- In mach1mach2cnc@..., "Art Fenerty" <fenerty@a...>
wrote:

Jeff:

The ocx test is a very bad way to measure your pulse frequency. It
uses a method where it says to the system, start counting, wait one
second and then stop counting. What is the total?
The problem here is it asks the APPLICATION system to time the

one

second. One second in the app system can vary a wide margin

depending

on system load and several other factors.

In the program , on the diags page, the DRIVER is told to measure
one second via the number of clock cycles send to the CPU chip, so

if

your running a 700Mhz system, the driver will count the number of
interrupt cycles which occur over the period of 700,000,000 clock
cycles. This is much more accurate and is the best indicator of
actual pulse timing. The OCX test , while a good quick test, has no
meaning in the context of your pulse speed. (Remember, it was

written

before Mach2 was, so its technology is somewhat behind.)

Thanks,
Art

Scott:

Is your program written with G1 moves? OverRide will not override a G0
move.

Thanks,
Art
www.artofcnc.ca

Hi,i am having a problem with the feedrate overide in mach 2,seems as
something is holding it back,when i ajust the override nothing
changes,can anyone give me quick idea where to correct this,I`ve been
at it all day and still can`t the get the speed up,jog speeds are
fine,g-codes are fine.
Thanks
Scot
UK

Thats the problem. I kind of figured it was somthing I was screwing

up.

No problem. As I said earlier, the problem is not the user, simply a
matter of complexity. I fully understand..

Art
www.artofcnc.ca

--- In mach1mach2cnc@..., Art <fenerty@a...> wrote:

Derek:

Do you have a G49 in your program? If you do, then "runFromHere"

will, when

executing the program from the begginning, will turn off the

offset, this

will mean you are NOT offset the way you think you are.

Thats the problem. I kind of figured it was somthing I was screwing
up.

Thanks Art

Steve:

What seems to happen is on hitting the first g32 line, the motor is

switched on momentarily and then off

Which motor, you mean the spindle motor???? The motor should be running
and up to speed when the G32 is called. Or do you mean the Z motor starts
and then stops?

Art
www.artofcnc.ca

Derek:

Do you have a G49 in your program? If you do, then "runFromHere" will, when
executing the program from the begginning, will turn off the offset, this
will mean you are NOT offset the way you think you are. If you like, send me
the program so I can try it here. My tests this morning indicate that it
seems to be working, but it may depend on the program. This may be a matter
of having an offset applied, then it get cleared or changed when the program
runs from the beggining.

Send me the program and a sequence of operations to repeat this and I'll
see if its a bug.....

Thanks, Sorry for the drilling...
Art
www.artofcnc.ca

On Tue, 26 Aug 2003 11:20:56 -0300, you wrote:

Normal Spin Count 2937 3090 2989

Current Spin Count 4813 4696 5216
Spin adder 1552 1751 1578

These particular values look pretty good. Remember the numbers are
multiples of 40us, so a Spin countof 2937 is .117 seconds per rev and 3090
is .120 seconds per rev or 512RPM and 500RPM respectively. This is not a
wide variance. But the Current Spin values indicate a slowdown to .192 sec
per rev or 312RPM, which is quite a slowdown, it is suspiciously close to
half the true speed which would occur if the sensor sometimes misses a pulse
or two.....

500rpm is set value, and motor never moves more than 2 or 3 rpm off
this under normal use

No missing pulses I can see?

You say there is no noticable slowdown, but these figure indicate quite a
reduction...I have to give some thought as to what would create this type of
situation.....

I just ran some tests on mine and cannot get the spinadder to go way up
unless the sensor is not feeding back. But if this was true then the Spindle
RPM would be jumping around quite a bit.....

What seems to happen is on hitting the first g32 line, the motor is
switched on momentarily and then off. Sometimes not enough to get 1
revolution - then spin adder goes up and up and at some value it
suddenly goes -ve value and motor starts. It also seems that all the
corrections are negative values, even when positive is called for?

On my machine there is a fair amount of inertia to overcome so changes
in speed are not instantaneous, to go from say 0 to 500rpm takes 3
seconds, 500 to 1000 another 3, 0-1000 also takes about 3. To stop
from 1000 takes 4 and 2 from 500.

Another thing I just though of - would altering the steps/unit help?
At the moment spindle range is 0-1100 with 500 steps per unit, vel
39.25, 250 acceleration - pulse width is 5uS and prechange 5uS.

--
Steve Blackmore

Hi Art
When ever I use the run from here command I end up burying my bit
into the work.
Here's the deal. I have a model that is in the +Z envelope. I'm
using a G43 tool offset. When the preparatory move window pops up
if I click on ok the tool moves in X,Y and Z to the X and Y
coordinates and the Z goes to zero burying itself into my work then
coming up to the specified Z level in the preparatory window. If I
specify a safe Z height as a positive it ignores the tool offset
and tries to run above my home position. Tripping my limit switch.

This has been going on for a long time now not just this version. If
this isn't a bug then please let me know what I'm doing wrong.

Thanks
Derek

Hi All:

It has become quite apparent that I could go to RC34572 if we continue as
we have been. So, in order to clear things up and to make life easier for
not only John (The Doc wizard) but for myself, Release 1.0 has been
released.

This is the new lockdown version. Are there bugs? You bet, more than
likely. But I suspect, as in any software program, bugs will always
remain.(Certinly Mach1 and Master5 have their fair share...) However, this
version has tried to clear as many as possible. Bug reports are very low,
almost 95% turn out to be settings and such. This is due not to stupidity,
but to complexity. As Mach2 has grown, the complexity has also grown. This
means that no matter what I do, bugs will remain and get added as features
grow. I am about to increase the complexity 10 fold with the new macro
capabilities, so while Turn will remain Alpha level for awhile, Mill is
ready for full release. This allows me to at least coordinate a proper
"LockDown version" which is now online.

Release 1.0 will become 1.01..etc as bug fixes are done, but a new
development version D1.0 will be added on next release and from there on the
D version will be transfered to the newest release version as the D Series
prove themselves.

The first thing that will get me in hot water here, is the screen layout
has shifted some. It is now a 4-axis screen layout with the screen somewhat
cleaner and less cluttered. (Before you scream at me, if you don't like it,
simply select "Layout/ Load Layout" and select the 1024Classic.set and you
will be forever more back to the classic layout.)

The new layout has a CV indicator light on it to tell if G61G64 are
working properly. They do on mine...

As bugs are reported, I will post them on a page to be added to the site
labeled "Known Bugs" so that you can check to see if your particular bug is
being worked on. This will drop the email traffic as well as the list
traffic on known bugs. My intent is to begin releasing bug releases when
necessary , but to keep the development rolling with macro commands being
added weekly until the list is quite large. User macro's will be released in
futrure D-Versions as we get to that stage. Turn will continue its
development at the same time.

All this is necessary due to extreme time limitations and demands. The
G2002 project is about to start in earnest, and I have several other things
being done in parrallel. I am a victim of unexpected success on this project
with OEM requests coming in weekly from around the world. I am very sorry
for the brevity of my responces lately, I am juggling heavily on many fronts
and its making me appear a bit schitzoid in some of my answers. This release
level is meant to address several things in terms of coordinating my time
properly and while I realize the opinion of a few will be "Its not yet ready
for full release", this is not backed up by the number of users who have and
are switching full time to Mach2. (If Windows waited for bug free operation,
XP would be RC76554764.2).

I would ask you to bear with me over the next few weeks while we get this
new lockdown version to a good level of stability for its user base and then
new features will appear in the D-Series.

Thanks, I appreciate your support and your help with this project. Mach2 is
now fully released and it reflects your experience, opinions, knowledge,
arguments, conversations...I hope you like the result.

(Behold..our fully functional ( or fully released anyway) Death-Star...)

Art
www.artofcnc.ca

On Tue, 26 Aug 2003 11:20:56 -0300, you wrote:

Normal Spin Count 2937 3090 2989

Current Spin Count 4813 4696 5216
Spin adder 1552 1751 1578

These particular values look pretty good. Remember the numbers are
multiples of 40us, so a Spin countof 2937 is .117 seconds per rev and 3090
is .120 seconds per rev or 512RPM and 500RPM respectively. This is not a
wide variance. But the Current Spin values indicate a slowdown to .192 sec
per rev or 312RPM, which is quite a slowdown, it is suspiciously close to
half the true speed which would occur if the sensor sometimes misses a pulse
or two.....

500rpm is set value, and motor never moves more than 2 or 3 rpm off
this under normal use

No missing pulses I can see?

You say there is no noticable slowdown, but these figure indicate quite a
reduction...I have to give some thought as to what would create this type of
situation.....

I just ran some tests on mine and cannot get the spinadder to go way up
unless the sensor is not feeding back. But if this was true then the Spindle
RPM would be jumping around quite a bit.....

What seems to happen is on hitting the first g32 line, the motor is
switched on momentarily and then off. Sometimes not enough to get 1
revolution - then spin adder goes up and up and at some value it
suddenly goes -ve value and motor starts. It also seems that all the
corrections are negative values, even when positive is called for?

On my machine there is a fair amount of inertia to overcome so changes
in speed are not instantaneous, to go from say 0 to 500rpm takes 3
seconds, 500 to 1000 another 3, 0-1000 also takes about 3. To stop
from 1000 takes 4 and 2 from 500.

Another thing I just though of - would altering the steps/unit help?
At the moment spindle range is 0-1100 with 500 steps per unit, vel
39.25, 250 acceleration - pulse width is 5uS and prechange 5uS.

--
Steve Blackmore

Normal Spin Count 2937 3090 2989

Current Spin Count 4813 4696 5216
Spin adder 1552 1751 1578

These particular values look pretty good. Remember the numbers are
multiples of 40us, so a Spin countof 2937 is .117 seconds per rev and 3090
is .120 seconds per rev or 512RPM and 500RPM respectively. This is not a
wide variance. But the Current Spin values indicate a slowdown to .192 sec
per rev or 312RPM, which is quite a slowdown, it is suspiciously close to
half the true speed which would occur if the sensor sometimes misses a pulse
or two.....
You say there is no noticable slowdown, but these figure indicate quite a
reduction...I have to give some thought as to what would create this type of
situation.....

I just ran some tests on mine and cannot get the spinadder to go way up
unless the sensor is not feeding back. But if this was true then the Spindle
RPM would be jumping around quite a bit.....

Art
www.artofcnc.ca

On Mon, 25 Aug 2003 18:21:01 -0300, you wrote:

What are the Normal and current SpinCounts doing and what does the
netrance trigger say..

They jump about all over the place, on three runs at the end I get
different values each time - note these are when file has finished
Which it seems to be doing most of the time now, but not always!


Normal Spin Count 2937 3090 2989
Current Spin Count 4813 4696 5216
Spin adder 1552 1751 1578


Dont appear to have a netrance trigger??


When it doesn't complete the spin adder initial values during the
"initial pause" go crazy counting up to hundreds of millions.

Had a look at the spindle pulse on the 'scope - it's nice, clean and
square with full 5V drop. Pulse width at 500 rpm is 2ms

Speed is within a few revs of commanded when doing straight turning,
with no appreciable slow down on cutting.

I've also tried inverting the signal with no difference.
--
Steve Blackmore

This is an easy question for all of you. I just purchase a
Visualmill 4.0 from Bob and I need to know the better post to be
used for Mach2. I can?t see anything generic in the list.

Luis,
When I looked a month or so back on the Mecsoft download posts screen
the very last post is for Mach1. I don't know how it got there but
its there. Works OK for me.

Roger

Jeff:

The ocx test is a very bad way to measure your pulse frequency. It
uses a method where it says to the system, start counting, wait one
second and then stop counting. What is the total?
The problem here is it asks the APPLICATION system to time the one
second. One second in the app system can vary a wide margin depending
on system load and several other factors.

In the program , on the diags page, the DRIVER is told to measure
one second via the number of clock cycles send to the CPU chip, so if
your running a 700Mhz system, the driver will count the number of
interrupt cycles which occur over the period of 700,000,000 clock
cycles. This is much more accurate and is the best indicator of
actual pulse timing. The OCX test , while a good quick test, has no
meaning in the context of your pulse speed. (Remember, it was written
before Mach2 was, so its technology is somewhat behind.)

Thanks,
Art

Art,

Could you tell me why my pulse frequency went from 23Khz to 25Khz
after running the OCX test?

For weeks my frequency was a rock solid 25Khz (plus some small
amout) then I installed RC11 and it went to 23Khz. I unistalled the
driver - re-installed the driver multiple times no change. So last
night I ran the OCX test and it jumped back to 25KZ and has stayed
there. Have I missed some process along the way?

Jeff E.

Tim:

Good point. Perhaps a Ref button on tha main screen, this would
zero a machine that has no home switches....

As to removing Jog on the first screen, Tried that, went there, got
tons of abuse and went back....I still get abuse over the fact that
Jog is not on the MDI screen....

I will remove the zero buttons from the MDI screen though. The MDI
screen is really the only Modal screen in that context, so I do agree
that it should be more of a MDI only type of screen. I do think it
should have indicators as to the state of the engine on it though to
reflect what you have MDI'ed into the mix.

Thanks,
Art

Isak:

The results you describe are exactly what will happen if CV mode is
on, was it on for this test, and if you turn it off does the same
thing happen?

Thanks,
Art

Thanks Bob. I will try Fanuc.



--- In mach1mach2cnc@..., "Robert Campbell" <bob@c...>
wrote:

Luis,

Try the Fanuc post. If you have a problem, I should be able to

create a

special post.

Bob Campbell
----- Original Message -----
From: "Luis Serrano" <serrano@q...>
To: <mach1mach2cnc@...>
Sent: Monday, August 25, 2003 1:46 AM
Subject: [mach1mach2cnc] Post Processor for Mach2

Hi all,

This is an easy question for all of you. I just purchase a
Visualmill 4.0 from Bob and I need to know the better post to be
used for Mach2. I can?t see anything generic in the list.

Thanks for your help.

p.d. I have also tried to find this answer in the other forum
archive but failed.

Luis.



To unsubscribe from this group, send an email to:
mach1mach2cnc-unsubscribe@...



Your use of Yahoo! Groups is subject to