开云体育

On Saturday 06 March 2004 22:30, Ed Gilbert wrote:

Hi Jeff,

You should try to keep the signal and voltage wires as far apart as
physically possible. If the wires do come in close proximity or cross each
other try to do it at 90 degree angles, do not run them parallel as this
increases capacitive coupling.

Although you are correct about the coupling, I beleive you are fundamentally
wrong about the approach. If you have to keep your encoder wiring phyiscally
separate from the motor drive wiring that is telling you that you have got
something badly wrong with your shielding. The *correct* solution is to get
the shielding right so it doesn't matter where you put the wires. Any other
solution is just a sticking plaster waiting for a stray pulse to come along
and upset things.

--
RapidCut CNC Technology

CNC Plasma Cutter

On Saturday 06 March 2004 21:56, ja_erickson wrote:

Greetings,

How far away from a 230 vac spindle motor do you have to keep a
shielded encoder wire? or dont you have to worry about it.
Can you zip tie a servo motor output wire and its encoder wire
together or is this a bad practice.I'm concerned about noise
and crosstalk and such. Generally speaking how far should I keep
AC wiring from DC step and dir. wires, encoder wires etc.

If you have done your wiring correctly, have your current paths right, and
have followed good practice, then you can tie the whole lot in together. In
commercial machines you will find everything runs down one big plastic cable
snake.

If you find you are having problems, the solution is to solve the shielding
issues n your wiring. moving them further apart is just sticking plaster. the
fundamental problem will still be there.

I run the step and direction pulse to my geckos right up alongside my plasma
torch cables, and shielded correctly I have no problems at all.

--
RapidCut CNC Technology

CNC Plasma Cutter

Hi Frank,

As Art has stated it is a feed back problem. If the servo has no feed back
it will just run away when the power is applied. Make sure you have the
encoders wired properly and supply voltage to the encoder. If the motor runs
full speed you are not getting any signal at all. If the motor kind of lumps
along then you are missing one or the may be backwards.


Best,

Ed Gilbert

Gilbert Engineered Systems
632 Warrenton-Embro Road
Macon, NC 27551
252-257-0539

Hi Jeff,

You should try to keep the signal and voltage wires as far apart as
physically possible. If the wires do come in close proximity or cross each
other try to do it at 90 degree angles, do not run them parallel as this
increases capacitive coupling.


Best,

Ed Gilbert

Gilbert Engineered Systems
632 Warrenton-Embro Road
Macon, NC 27551
252-257-0539

Greetings,

How far away from a 230 vac spindle motor do you have to keep a
shielded encoder wire? or dont you have to worry about it.
Can you zip tie a servo motor output wire and its encoder wire
together or is this a bad practice.I'm concerned about noise
and crosstalk and such. Generally speaking how far should I keep
AC wiring from DC step and dir. wires, encoder wires etc.

Thanks
Jeff

IMHO, Mach2 should be capable of getting the data as

a point cloud, but the act of identifying features (such as circles,
straight
edges, corners) and producing machining strategies is the job of an external
application ...

Or a "Single Funcion Screen set..." ;)

Art
www.artofcnc.ca

Frank:

If your servo's are running continously, you have a wiring problem with
your encoders I think... Try reversing the A&B perhaps?

Art
www.artofcnc.ca

Just checking in for last minute mail, glad to hear things are starting to
shape up Peter, Good luck with it..
I've spent the day troubleshooting the dreaded memory leak, FINALLY I have
found the source of the problem.
Hopefully I can solve it before I leave, it will make quite a difference to
the low memory users. Its like pulling teeth
tracing this one down but I'm actually to the routine causing the memory
gobs being wasted...

Thanks,
Art
www.artofcnc.ca

On Saturday 06 March 2004 11:45, Digital audio Pro wrote:

Robin, sorry for my bad english, you didn't understood all what i mean.

3D mapping is not a CAM feature. It is for compensating geometric
distorsion of the physical axis

right, understood. This is already implemented in EMC to some extent (the
forward/reverse kinematics and the leadscrew non-linearity compensation
tables) so I suspect it can be added to mach2 easily enough, as the hooks
might already be there to some extent.

Gecko mode is for the gecko 2002.

right, I thought you meant for G201 etc ...understood.

Sometimes there is no need to go through a CAM program for simple parts.
G70, 71, 72 if i remeber are simple turn cycles for roughing - finishing.
There is too the G96 constant surface speed to implement in mach2.

hmm ... agreed. these are machine specific features, but yes, adding them
does help I guess. I have some specific features I;d like to see for plasma,
so I undertand this.

Encoder feedback pointless ? : all professional machines have encoder
feedback, sometimes with a double feedback, even if they use steppers.

OK, I havent seen any pro machines with steppers and encoders, but if you say
they exist .. I'll believe you. What is probably not possible to do in Mach2
is use the encoder as part of the feedback loop, as in true servo control.
many of the the encoders can end up outputting quadrature pulses af several
hundred kilohertz and reading it into the parallel port of Mach2 is probably
not feasible. You'd need a proper dedicated counter and some way of reading
it I guess ... and even then, what do you do if they are in error? All I can
see to do with a stepper is abort the program, recovery could be difficult.

Using linear scales liek Rennishaw encoders etc to provide real feedback
would also need a servo card .. I cant see how it would fit in with the
current scheme, but Art would have to answer that to be sure.

Advanced digitizing : for example to digitize non rectangular parts. Did
you try to digitize a circular part ? the rectangular moves will wast a lot
of time.

yes, but really that is not a digitizing question, that is a post processing
of the digitized data. IMHO, Mach2 should be capable of getting the data as
a point cloud, but the act of identifying features (such as circles, straight
edges, corners) and producing machining strategies is the job of an external
application ...


--
RapidCut CNC Technology

CNC Plasma Cutter

I have every thing hooked up and running on the bench. The servo
motors run continuously? When the program tells the motor to move it
stops turning and the moves in spurts when it should be moving all
the time.

I am using HP 500 line yielding 2000 counts/rev encoders.
I am using a Mach2 board and software.
Geckos 320's

Is there something that needs adjustment on the geckos or in the
mach2 software? need setup tips.



Thanks
Frank

Hello Art,

Have a nice vacation.

I have the OCX working from Vb (occasionally), there are still a lot
of questions.
I'll test and struggle some more and in 5 to 6 days I will send you
all the code for debugging.

The most "luck" I had with ExecuteGCode.
I also had StraightFeed work

Seems that we will get to the bottom of it soon.

Absorbe some sun for me too !
Best regards
Peter


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

Hi Mark, Les..et all.

There seems to be a growing interest in useing the OCX for

application

development. Unfortunately I never use VB and don't know how on a

good day.

I can tell you a few things..

1) You application will read demo unitl the engine is fully

started. It is

the process of starting the engine that verifies your license.

2) Errors like crashing are probably due to all the graphics

involved.

Perhaps no screens should be loaded. It should be possible to

InitEngine,

StartEngine, Reset, and then StraightFeed(x,x,x,x,x,x). If

someone writes

such a beast and it won't feed, I will debug and let you know why

it won't

run as it is. I would love to see a guide to VB'ing the ocx and

will assist

all I can.

If you guys get an application that is crashing or doing

something

improper, send me a non-debug version and I can use it to debug

with and let

you know the trouble. I suspect that, unlike C++, VB may have

trouble with

the graphics, but it should still be able to move the motors and

such via

OCX control. While I did design everything as an OCX for that very

reason,

till now, no-one has wanted to use it in this way. I will, of

course, help

as much as I can along the way..

Thanks,
Art
www.artofcnc.ca

First let me appologize - I'm posting this question to 3 groups, so
if you get it more than once, please resond on whichever you like.

I'm about to design the controls to an Omron G5+ (same as Yaskawa and
a few others) VFD for my Bridgeport (1 1/2 HP). I'm using MACH2 CNC
software.

There are (as in most VFD's) a bunch of contacts both in and out.
I think I've got the speed and direction control figured out, but I
understand that contacts can be used for E-Stop and other functions.

Which contacts into or out of the drive do you recommend using and
how would you impliment them.

Also, there is a setting to output the motor speed as analog voltage
(0-10 volts D.C.). Most of the circuits I've seen convert from PWM
to a voltage to control the drive. MACH2 has the ability to read a
sensor delivering pulses so that it knows what speed a spindle is
turning. Is there an easy way to go in the other direction and
convert the analog voltage to pulses so that this can be emulated and
fed back into MACH2 as speed (as if a rotary encoder was being used)?

Thanks,
Jeff

Scout

Yes it does declare itself as a trial version but
It is not time limited. The only limitation is that any
Drawings printed have a Dolphin watermark displayed
In the print area.

Regards

Michael

Hi Jeff:

Sorry for the delay therew, it is on the list...I've just been too burnt
out to add them, I will do so when I return...

Thanks,
Art
www.artofcnc.ca

Thanks Michael,

I downloaded the Partsmaster verison. Is that the one you were talking
about? It said it's a trial version; does that mean it will expire in 30 days
or something?

Or was I supposed to download the Mach2 version; I didn't look like they
were free.

Scout

--- In mach1mach2cnc@..., "Michael Milligan"
<zen11777@z...> wrote:

Scout

You can download Dolphin CAD for
Free, at the moment this is available from our
Website, www.dolphin.gb.com <> .

This will provide you with a 1st rate drawing
module which supports DXF export.

Regards

Michael
Dolphin Cad Cam Systems Ltd

Hi Art,
If I understand what you say about Mach2, it measures inaccurately
placed sensors and compensates for that potential problem.

Suppose one has a motor pulley that has a few thou (") runout and
not running at 1 to 1 ratio.
So, on the first measured rev, although the sensors may be perfectly
spaced, Mach2 thinks they are not. On the next partial rev it thinks
that the rotational speed has varied, which may or may not be true.

If my thinking is right, multiple sensors would make my thread
cutting worse, or ??

Jerry

Ok, I must then start seeking different ways for controlling my
setup. I got the card free of charge from one guy who wanted me to
write an EMC driver for it. And I could just easily use steppers for
my setup, or boards that allow step/dir in and servo out.

I haven't written any drivers in Windows, all drivers I have made
have been in Linux. In Windows I have made just "plain" software and
some dll's for our company.

Thanks for quick answer,

Henkka

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

Hi Henry:

Sorry, but it would be just about impossible. The Mach2 driver is
extremely tight, Servo-To-Go people took a look at the problem and

gave up.

The driver and the OCX are just too strict in the way they do

things in a

buffered environment that it doesn't easily translate to anything

like doing

a linux driver for it. It could be done, but I doubt you'd want

to put in

that kind of work for a single board. Have you coded WDM drivers

under NT

before ??

Art
www.artofcnc.ca

Art:

Just a humble request for a couple more activation outputs.

Jeff

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

Steve:

Lets take into account tool offsets!
As it stand now the display is no more than a rough estimation of
where the tool may go! It's caused more than one or two queries

in the

past!!

Yes, this is an issue that I'd like to put to rest,

unfortunately, its

much more difficult than most would think, unless I do a redraw

all the

time. For example, you load a job, so the G-Code is translated to

create a

toolpath. It has no choice but to use current offsets and

locations as the

drawing parameters. This means if you change a tool, zero to a new

position,

basically change anything, then the drawing is no longer accurate.

A regen

is required. But you can imagine the problem if I do a redraw

everytime some

one changes something. A 500,000 line drawing can take 2 seconds

to redraw

on the slower machines, this means a 2 second redraw occuring

possibly in

the worst possible moment and affecting the cut.
Luckily, this has affected some users more than others.

Typically,

the more experienced ones with the more complex programs. The

reason I'm

looking at redoing it all is that exact reason, in order to

eliminate the

kludges which have created the trouble. (Actually, mill works much

better

than turn does in terms of drawing, lately I have only fixed the

mill

drawing , as I know turn will be the biggest challenge...)
That why this particular fix has one of the highest priorities...

Art
www.artofcnc.ca

On Sat, 06 Mar 2004 07:47:20 -0400, you wrote:

Lets take into account tool offsets!
As it stand now the display is no more than a rough estimation of
where the tool may go! It's caused more than one or two queries in the
past!!

Yes, this is an issue that I'd like to put to rest, unfortunately, its
much more difficult than most would think, unless I do a redraw all the
time. For example, you load a job, so the G-Code is translated to create a
toolpath. It has no choice but to use current offsets and locations as the
drawing parameters. This means if you change a tool, zero to a new position,
basically change anything, then the drawing is no longer accurate. A regen
is required. But you can imagine the problem if I do a redraw everytime some
one changes something. A 500,000 line drawing can take 2 seconds to redraw
on the slower machines, this means a 2 second redraw occuring possibly in
the worst possible moment and affecting the cut.

A regen whilst paused during tool changes shouldn't cause any problem
should it? Maybe give the option of ignoring tool/work offsets
completely for display purposes.

Luckily, this has affected some users more than others. Typically,
the more experienced ones with the more complex programs. The reason I'm
looking at redoing it all is that exact reason, in order to eliminate the
kludges which have created the trouble. (Actually, mill works much better
than turn does in terms of drawing, lately I have only fixed the mill
drawing , as I know turn will be the biggest challenge...)
That why this particular fix has one of the highest priorities...

Thanks. As it stands it's impossible to tell if the gcode is going to
do what you expect without using an external program when tool offsets
are used.

--
Steve Blackmore

Thanks art. Wich debugger are you using ? the free one on the Microsoft site
or an embedded visual studio one ? perhaps they are not the same.

Olivier.