Date   
Re: Get symbol to output to top text file

mlmcnc
 

Here are some thoughts which I hope might help.
I'm not sure that the Mill Layer is the most appropriate. It is usually used for cutting the board outline and as such, it is usually cut to the full board depth. Not what you would want for a logo.

I am assuming that you want this to be cut into the copper along with the tracks etc. If this is the case then you should put the arcs in the library part  on layer 1 (top copper). If it then needs to go on the bottom then you just need to mirror it in properties.

As for the PCB-Gcode text file, the only things that will go in here is actual text (and it must be vector text) that is on the Mill layer. If it is normal it will go in top text, if it is mirrored it will go in bottom text.

Regards
Martin Marriott
mlm Solutions

Eagle 7.10 & PCBGCODE 3.6.0.4

nlebelin@...
 

I encounter a problem that never happened and hope help to found answer/solution.

In fact when I start ULP PcbGcode ( all settings are as usual and correct for my use..) the drawing is performing and stop without opening the view and further seconds later freeze Eagle forcing me to close same.

I make numerous tests and noted that the problem could came from the _outlines_ polygon for the ground which appears to be created during the operation.

I modified the original GND polygon dimensions and sometimes said sometimes I obtain a result but with a etching around the circuit which is not necessary as thereafter I mill same. Of course the etching has the dimensions of the polygon and out of the spécifications needed.For example a non rectangular polygon is functionning 

I made plenty circuits without trouble and are very disapointed particurlarly for this one which is very very simple one with only 3 components ,-)

In the past I never had this problem and assume it could be something between 7.1 and PcbGcode.

For your guidance i'm on Win7 64 but it was same in the past. 

It appears that the correspondig .tap is created but not sure it is correct, I checked with Cambam.

Any body had same game?

Thanks

F1NST Bernard

Get symbol to output to top text file

scott.goldthwaite@...
 

I created a little antenna symbol in my library, it's just 3 small arcs, and put it on the Mill layer.  I'd hoped pcb-gcode would output this to the top text file, but it didn't. It doesn't show up in the Mill file either.  I'm not really surprised, but is there some sort of trick I can use so it will show up on the top text file?

Re: Parallel port buffer?

Roy Emeny
 

Thanks Paul,

Suffering from a 'no time to do anything period' here at the moment. As soon as I get a chance will try driving directly (no computer) and test each axis. Take the point re larger mass to move on the x axis - I was looking for a software/electronic reason when probably the answer was simply - weight!
I am assuming that their would be no problems with running the x axis at a slower speed than y axis?
Micro stepping - is this a Linux CNC term don't remember coming across it in the Mach 3 setup?
My last move was to install Linux CNC  on my 'mill computer' to give that a try (keeping an image of my mach3 setup) so nothing ready to go at the moment - hope to get more playtime over Christmas.
Thanks for all the info.
Roy


On Thursday, 20 November 2014, 23:29, "Paul Kiedrowski paul_kiedrowski@... [pcb-gcode]" wrote:


 
Hi all,
Just a few cents worth on this topic. There always seems to be a lot of people with issues like this.
As far as using a Windows PC with Mach3, it should work fine with the printer port connected directly to the motor drivers, assuming they are opto isolated themselves.
Keep in mind, the printer port outputs are designed to drive a load LOW, not HIGH. On laptops, you sometimes have to set the port settings to NOT use 3.3V levels. EPP mode is good.
This is called a pull-down transistor. The pin drivers can sink up to 25mA from the motor driver. The pin is usually connected to the negative side (cathode) of the opto isolator LED, then thru a resistor, and then to +5V (external to the PC, on the motor drive connector).
So when the transistor turns OFF, the LED is shut off because there is no current, not because the voltage is being driven high.
When it's ON, it sinks 8 to 15 mA thru the LED to ground and turns on the other side of the opto-coupler.

Of course it is always advisable to use shielded cables (connect shield to PC ground), and keep as short as practical (i.e. not 50 or 100 feet).
I think going thru one of those "breakout/isolator" boards is not needed.

The key to getting your machine running is to test it without a PC first.
Buy or make a variable frequency pulse generator that will sink at least 8-10mA and 5V peak (to drive the opto coupler inputs).
Having an oscilloscope handy to verify the drive levels is helpful.
Vary the frequency from 100 Hz up to the max where the motor torque peters out (typically around 5 to 10 kHz).
Listen for frequencies where it vibrates. Apply a load to the axis to feel the smoothness.
Run it in both directions (change the DIR input). Decide where the torque is just too weak.
Just be careful doing this, don't run it into the end stops!

Then you can see exactly what your machine speed range is.
In my case, I am always limited by the safe cutting speed of the tool, NOT the machine feed rate.
Oh and I forgot to mention, always use microstepping, at least 1000 steps per revolution.
Most motors have 1.8 degrees per step which is 200 steps per turn.
The finer the step, the higher the pulse frequency you have to use.
Beyond about 2500 steps per turn, there isn't much benefit.
But never use full step. Half step is the minimum (i.e. 400 steps per turn) to avoid major vibration.
And keep the drive mechanism free of play (use good quality ball screw and a good shaft coupling mechanism).

One last thing, keep the mass you are moving to a minimum. Usually X axis is the most mass, which I think is why it seems to give people the most problem.
But that can be hard to do.

-Paul

--------------------------------------------
On Sun, 11/9/14, Roy Emeny forjacdf@... [pcb-gcode] wrote:

Subject: Re: [pcb-gcode] Parallel port buffer?
To: "pcb-gcode@..."
Date: Sunday, November 9, 2014, 1:30 AM


 









Thanks to all
for quick and informative responses - gosh, many
possibilities, sitting here reading and
learning.Keep the ideas coming
please I am sure I am not the only one extremely interested
in what is being said. Excellent
forum.Roy




On Saturday, 8 November 2014, 22:06,
"Dan Andersson dan@... [pcb-gcode]"
wrote:





 













Roy,



Both environment's shows shortcomings when you push
them.



XP is probably the best of the Windows versions but you
can't push it if using a parallel port.

Win XP was never designed to do real time stuff so we must
applaud it to be able to run MACH3

as well as it does. Solutions and workarounds? Run it slow
as you describe it. Get the kettle on and

have yourself a cuppa while waiting for the mill. Or - get
one of these USB cards for cnc-milling.



Linux can be more demanding as many average users are
unfamiliar with it. Linux is as crap as XP when

dealing with Real Time like CNC milling machines. This is
solved by using a special RT Kernel, adopted

for real time purposes. As far as I know, linux doesn't
support the USB milling adapters ( yet? ).



LinuxCNC ( EMC2 ) versus MACH3? Both do the job good
enough.



If your system bites you even if running slow, try
downloading and burning a on cd version of LinuxCNC.

Generating the setup file should be reasonably straight
forward as you already have one from MACH3.



But be aware, changing to Linux is not a one size fit all
solution...



///Dan, M0DFI



On 08 Nov 2014 11:37:42 -0800

"forjacdf@... [pcb-gcode]"
wrote:



> Hi All

>

> Interested to see yet another report of occasional
large jumps (only 2 mm - you lucky man!).

>

> This topic has come up many times, strangely always
seems to be the X axis. About 18 months back I started one
myself. I did all the thinks suggested re currents voltages
etc, won't bore everyone by repeating the list.

>

> In the end the only thing that worked was reducing the
speed during high speed traverses, which of course has less
effect on total time than you would expect.

>

> I only make perhaps 20 boards a year so milling slowly
isn't really a huge problem but the fact that I have had
to reduce speed to about a quarter of what the mill should
be capable of irritates me just because I feel I have failed
to get the system to work as it should.

>

>

> At the reduced speed (for high speed traverse) the
mill is totally reliable.

> When it was unreliable it would jump a large amount
(5-10mm) but this only happened perhaps once say every 10
000 instructions, about every fourth side of a pcb.

>

> I think it is an issue with windows (or perhaps I
should say time sharing systems) . I am using Mach 3, XP
and parallel port. Have done all the tweaking of XP
recommended and get the same results on two desktops and an
old laptop

>

> I know I could get smooth stepper and use USB and if I
made more boards I would, but really it is difficult to
justify the outlay for what I do, plus it would be really
nice come up with a simple solution.

>

> I was surprised when I searched for parallel port
buffer and all I got were circuits that were only current
buffers. I was expecting something which included memory
buffering. Is the reason that they don't seem to exist
because when using a parallel port the computer is
determining the variable speed relationships required for
milling complex shapes?

>

> If I was using a USB interface would the responsibility
for timing be handed over to the interface?

>

> Does Mach3 behave differently in these two situations
(parallel/USB)?

>

> I did try Linux CNC briefly but couldn't make it
work - probably because I had a Mach3 system 'kind of
working' and didn't put the time in.

>

> I did see a posting from someone saying that Linux CNC
was the answer to life the universe ..... but a friend who
is a 'Linux man' tells me that he can see no reason
why Linux would look any more like a dedicated system than
Windows does.

>

> My main computer has multiple drives and four different
operating systems. Would be lovely to have a fifth that was
a dedicated CNC operating system that could take the output
from PCB-GCODE and just 'do the job' without having
to service interrupts from the Windows/Linux worlds. Though
I guess this would rule out that other great program
auto-leveller(?) Hey ho!!

>

> If anyone has got this far, is still awake and can
unscramble the above ramblings it would be great to hear
your thoughts - or perhaps there is a thread somewhere that
explains all?

>

> Roy



--

Your value doesn't decrease based on

someone's inability to see your worth.
























#yiv1320487898 #yiv1320487898 --
#yiv1320487898ygrp-mkp {
border:1px solid #d8d8d8;font-family:Arial;margin:10px
0;padding:0 10px;}

#yiv1320487898 #yiv1320487898ygrp-mkp hr {
border:1px solid #d8d8d8;}

#yiv1320487898 #yiv1320487898ygrp-mkp #yiv1320487898hd {
color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}

#yiv1320487898 #yiv1320487898ygrp-mkp #yiv1320487898ads {
margin-bottom:10px;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad {
padding:0 0;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad p {
margin:0;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad a {
color:#0000ff;text-decoration:none;}
#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc {
font-family:Arial;}

#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc #yiv1320487898hd {
margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}

#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc .yiv1320487898ad {
margin-bottom:10px;padding:0 0;}

#yiv1320487898 #yiv1320487898actions {
font-family:Verdana;font-size:11px;padding:10px 0;}

#yiv1320487898 #yiv1320487898activity {
background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}

#yiv1320487898 #yiv1320487898activity span {
font-weight:700;}

#yiv1320487898 #yiv1320487898activity span:first-child {
text-transform:uppercase;}

#yiv1320487898 #yiv1320487898activity span a {
color:#5085b6;text-decoration:none;}

#yiv1320487898 #yiv1320487898activity span span {
color:#ff7900;}

#yiv1320487898 #yiv1320487898activity span
.yiv1320487898underline {
text-decoration:underline;}

#yiv1320487898 .yiv1320487898attach {
clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}

#yiv1320487898 .yiv1320487898attach div a {
text-decoration:none;}

#yiv1320487898 .yiv1320487898attach img {
border:none;padding-right:5px;}

#yiv1320487898 .yiv1320487898attach label {
display:block;margin-bottom:5px;}

#yiv1320487898 .yiv1320487898attach label a {
text-decoration:none;}

#yiv1320487898 blockquote {
margin:0 0 0 4px;}

#yiv1320487898 .yiv1320487898bold {
font-family:Arial;font-size:13px;font-weight:700;}

#yiv1320487898 .yiv1320487898bold a {
text-decoration:none;}

#yiv1320487898 dd.yiv1320487898last p a {
font-family:Verdana;font-weight:700;}

#yiv1320487898 dd.yiv1320487898last p span {
margin-right:10px;font-family:Verdana;font-weight:700;}

#yiv1320487898 dd.yiv1320487898last p
span.yiv1320487898yshortcuts {
margin-right:0;}

#yiv1320487898 div.yiv1320487898attach-table div div a {
text-decoration:none;}

#yiv1320487898 div.yiv1320487898attach-table {
width:400px;}

#yiv1320487898 div.yiv1320487898file-title a, #yiv1320487898
div.yiv1320487898file-title a:active, #yiv1320487898
div.yiv1320487898file-title a:hover, #yiv1320487898
div.yiv1320487898file-title a:visited {
text-decoration:none;}

#yiv1320487898 div.yiv1320487898photo-title a,
#yiv1320487898 div.yiv1320487898photo-title a:active,
#yiv1320487898 div.yiv1320487898photo-title a:hover,
#yiv1320487898 div.yiv1320487898photo-title a:visited {
text-decoration:none;}

#yiv1320487898 div#yiv1320487898ygrp-mlmsg
#yiv1320487898ygrp-msg p a span.yiv1320487898yshortcuts {
font-family:Verdana;font-size:10px;font-weight:normal;}

#yiv1320487898 .yiv1320487898green {
color:#628c2a;}

#yiv1320487898 .yiv1320487898MsoNormal {
margin:0 0 0 0;}

#yiv1320487898 o {
font-size:0;}

#yiv1320487898 #yiv1320487898photos div {
float:left;width:72px;}

#yiv1320487898 #yiv1320487898photos div div {
border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}

#yiv1320487898 #yiv1320487898photos div label {
color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}

#yiv1320487898 #yiv1320487898reco-category {
font-size:77%;}

#yiv1320487898 #yiv1320487898reco-desc {
font-size:77%;}

#yiv1320487898 .yiv1320487898replbq {
margin:4px;}

#yiv1320487898 #yiv1320487898ygrp-actbar div a:first-child {
margin-right:2px;padding-right:5px;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg {
font-size:13px;font-family:Arial, helvetica, clean,
sans-serif;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg table {
font-size:inherit;font:100%;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg select,
#yiv1320487898 input, #yiv1320487898 textarea {
font:99% Arial, Helvetica, clean, sans-serif;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg pre, #yiv1320487898
code {
font:115% monospace;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg * {
line-height:1.22em;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg #yiv1320487898logo {
padding-bottom:10px;}


#yiv1320487898 #yiv1320487898ygrp-msg p a {
font-family:Verdana;}

#yiv1320487898 #yiv1320487898ygrp-msg
p#yiv1320487898attach-count span {
color:#1E66AE;font-weight:700;}

#yiv1320487898 #yiv1320487898ygrp-reco
#yiv1320487898reco-head {
color:#ff7900;font-weight:700;}

#yiv1320487898 #yiv1320487898ygrp-reco {
margin-bottom:20px;padding:0px;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
li a {
font-size:130%;text-decoration:none;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
li {
font-size:77%;list-style-type:square;padding:6px 0;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
ul {
margin:0;padding:0 0 0 8px;}

#yiv1320487898 #yiv1320487898ygrp-text {
font-family:Georgia;}

#yiv1320487898 #yiv1320487898ygrp-text p {
margin:0 0 1em 0;}

#yiv1320487898 #yiv1320487898ygrp-text tt {
font-size:120%;}

#yiv1320487898 #yiv1320487898ygrp-vital ul li:last-child {
border-right:none !important;
}
#yiv1320487898



Re: Running ULP program pcb-gcode from Eagle

Robert Wood
 

GRAHAM, THANK YOU VERY MUCH I WILL TRY THAT.
BOB.
 

 

From: pcb-gcode@...
To: pcb-gcode@...
Date: Fri, 21 Nov 2014 11:22:14 -0800
Subject: [pcb-gcode] Re: Running ULP program pcb-gcode from Eagle

 
Just an idea. If you are using Win7 or Win8, then program files is a restricted folder for non administrator users.
I run Eagle in an XP virtual machine so cannot verify this might be the problem.
A quick test if not already running as administrator would be to reinstall PCB-GCode and run it while logged in as administrator.

It is possible to relocate all the Eagle and PCB-GCode files to a standard folder where your user id has total access. This would be the best solution if the test above let's things work.
Graham


Re: Running ULP program pcb-gcode from Eagle

gebowes
 

Just an idea. If you are using Win7 or Win8, then program files is a restricted folder for non administrator users.
I run Eagle in an XP virtual machine so cannot verify this might be the problem.
A quick test if not already running as administrator would be to reinstall PCB-GCode and run it while logged in as administrator.

It is possible to relocate all the Eagle and PCB-GCode files to a standard folder where your user id has total access. This would be the best solution if the test above let's things work.
Graham

Re: Running ULP program pcb-gcode from Eagle

Art Eckstein
 

Bob,
Have you checked to verify that the file "pcb-gcode.h" is actually located in the directory mentioned??? 

Art


At 11:56 AM 11/21/2014, you wrote:


Hello Art,
Thanks for your email, I have read the readme file, and set the pointer to the ulp files. I still get the same error with a number eight in brackets (8) at the end of the message.  What I don't get is it will run any of the .ULp files, apart from gcode files. I know it is getting the program source, because if I double click on the error message. It list the source program list. Thank you for all your help.
Bob.
 

To: pcb-gcode@...
From: pcb-gcode@...
Date: Thu, 20 Nov 2014 19:11:08 -0500
Subject: Re: [pcb-gcode] Running ULP program pcb-gcode from Eagle

 
Bob,
Dumb question, but did you explicitly follow the installation instructions in the "Readme.html" file that is included in the zip package?
Specifically the following paragraph:
"Unzip the pcb-gcode archive and move the files to a folder. I like to create an eagle folder in my $HOME directory, then create a ulp folder there, and put the pcb-gcode files in it. In the Eagle Control Panel, in Options | Directories… add the path to the ulp folder you created as the first entry in the User Language Programs option. Here are typical paths for the operating systems Eagle supports:
OS In Control Panel Real Paths
Mac OS X $HOME/Documents/eagle/ulp:$EAGLEDIR/ulp /Users/John/Documents/eagle/ulp
/Applications/EAGLE/ulp
Linux $HOME/eagle/ulp:$EAGLEDIR/ulp /home/john/eagle/ulp
/opt/eagle/ulp
Windows $HOME/eagle/ulp;$EAGLE/ulp C:\Documents and Settings\John\My Documents\eagle\ulp
C:\Program Files\EAGLE\ulp"?

IF I remember correctly, this is a sticky point that must be followed.  I always just unzip the file to a folder and point to that in the directory options.

HTH

Art
Country Bubba



 At 10:50 AM 11/17/2014, you wrote:


Hello Can anyone help me please. I am using Eagle to try and run PCB-GCODE.ULP. It wont run and comes back with error message. "UNABLE TO OPEN INCLUDE FILE 'SOURCE/PCB-GCODE.H'

I AM COMPLETLY NEW TO THIS ENVIROMENT SO PLEASE HELP THANKS.


BOB.




Re: Running ULP program pcb-gcode from Eagle

Robert Wood
 

Hello Art,
Thanks for your email, I have read the readme file, and set the pointer to the ulp files. I still get the same error with a number eight in brackets (8) at the end of the message.  What I don't get is it will run any of the .ULp files, apart from gcode files. I know it is getting the program source, because if I double click on the error message. It list the source program list. Thank you for all your help.
Bob.
 

To: pcb-gcode@...
From: pcb-gcode@...
Date: Thu, 20 Nov 2014 19:11:08 -0500
Subject: Re: [pcb-gcode] Running ULP program pcb-gcode from Eagle

 
Bob,
Dumb question, but did you explicitly follow the installation instructions in the "Readme.html" file that is included in the zip package?
Specifically the following paragraph:
"Unzip the pcb-gcode archive and move the files to a folder. I like to create an eagle folder in my $HOME directory, then create a ulp folder there, and put the pcb-gcode files in it. In the Eagle Control Panel, in Options | Directories… add the path to the ulp folder you created as the first entry in the User Language Programs option. Here are typical paths for the operating systems Eagle supports:
OS In Control Panel Real Paths
Mac OS X $HOME/Documents/eagle/ulp:$EAGLEDIR/ulp /Users/John/Documents/eagle/ulp
/Applications/EAGLE/ulp
Linux $HOME/eagle/ulp:$EAGLEDIR/ulp /home/john/eagle/ulp
/opt/eagle/ulp
Windows $HOME/eagle/ulp;$EAGLE/ulp C:\Documents and Settings\John\My Documents\eagle\ulp
C:\Program Files\EAGLE\ulp"?

IF I remember correctly, this is a sticky point that must be followed.  I always just unzip the file to a folder and point to that in the directory options.

HTH

Art
Country Bubba



 At 10:50 AM 11/17/2014, you wrote:


Hello Can anyone help me please. I am using Eagle to try and run PCB-GCODE.ULP. It wont run and comes back with error message. "UNABLE TO OPEN INCLUDE FILE 'SOURCE/PCB-GCODE.H'

I AM COMPLETLY NEW TO THIS ENVIROMENT SO PLEASE HELP THANKS.


BOB.


Re: Running ULP program pcb-gcode from Eagle

Art Eckstein
 

Bob,
Dumb question, but did you explicitly follow the installation instructions in the "Readme.html" file that is included in the zip package?
Specifically the following paragraph:
"Unzip the pcb-gcode archive and move the files to a folder. I like to create an eagle folder in my $HOME directory, then create a ulp folder there, and put the pcb-gcode files in it. In the Eagle Control Panel, in Options | Directories… add the path to the ulp folder you created as the first entry in the User Language Programs option. Here are typical paths for the operating systems Eagle supports:
OS In Control Panel Real Paths
Mac OS X $HOME/Documents/eagle/ulp:$EAGLEDIR/ulp /Users/John/Documents/eagle/ulp
/Applications/EAGLE/ulp
Linux $HOME/eagle/ulp:$EAGLEDIR/ulp /home/john/eagle/ulp
/opt/eagle/ulp
Windows $HOME/eagle/ulp;$EAGLE/ulp C:\Documents and Settings\John\My Documents\eagle\ulp
C:\Program Files\EAGLE\ulp"?

IF I remember correctly, this is a sticky point that must be followed.  I always just unzip the file to a folder and point to that in the directory options.

HTH

Art
Country Bubba



 At 10:50 AM 11/17/2014, you wrote:


Hello Can anyone help me please. I am using Eagle to try and run PCB-GCODE.ULP. It wont run and comes back with error message. "UNABLE TO OPEN INCLUDE FILE 'SOURCE/PCB-GCODE.H'

I AM COMPLETLY NEW TO THIS ENVIROMENT SO PLEASE HELP THANKS.


BOB.

Re: Parallel port buffer?

Paul Kiedrowski
 

Hi all,
Just a few cents worth on this topic. There always seems to be a lot of people with issues like this.
As far as using a Windows PC with Mach3, it should work fine with the printer port connected directly to the motor drivers, assuming they are opto isolated themselves.
Keep in mind, the printer port outputs are designed to drive a load LOW, not HIGH. On laptops, you sometimes have to set the port settings to NOT use 3.3V levels. EPP mode is good.
This is called a pull-down transistor. The pin drivers can sink up to 25mA from the motor driver. The pin is usually connected to the negative side (cathode) of the opto isolator LED, then thru a resistor, and then to +5V (external to the PC, on the motor drive connector).
So when the transistor turns OFF, the LED is shut off because there is no current, not because the voltage is being driven high.
When it's ON, it sinks 8 to 15 mA thru the LED to ground and turns on the other side of the opto-coupler.

Of course it is always advisable to use shielded cables (connect shield to PC ground), and keep as short as practical (i.e. not 50 or 100 feet).
I think going thru one of those "breakout/isolator" boards is not needed.

The key to getting your machine running is to test it without a PC first.
Buy or make a variable frequency pulse generator that will sink at least 8-10mA and 5V peak (to drive the opto coupler inputs).
Having an oscilloscope handy to verify the drive levels is helpful.
Vary the frequency from 100 Hz up to the max where the motor torque peters out (typically around 5 to 10 kHz).
Listen for frequencies where it vibrates. Apply a load to the axis to feel the smoothness.
Run it in both directions (change the DIR input). Decide where the torque is just too weak.
Just be careful doing this, don't run it into the end stops!

Then you can see exactly what your machine speed range is.
In my case, I am always limited by the safe cutting speed of the tool, NOT the machine feed rate.
Oh and I forgot to mention, always use microstepping, at least 1000 steps per revolution.
Most motors have 1.8 degrees per step which is 200 steps per turn.
The finer the step, the higher the pulse frequency you have to use.
Beyond about 2500 steps per turn, there isn't much benefit.
But never use full step. Half step is the minimum (i.e. 400 steps per turn) to avoid major vibration.
And keep the drive mechanism free of play (use good quality ball screw and a good shaft coupling mechanism).

One last thing, keep the mass you are moving to a minimum. Usually X axis is the most mass, which I think is why it seems to give people the most problem.
But that can be hard to do.

-Paul

--------------------------------------------

On Sun, 11/9/14, Roy Emeny forjacdf@... [pcb-gcode] <pcb-gcode@...> wrote:

Subject: Re: [pcb-gcode] Parallel port buffer?
To: "pcb-gcode@..." <pcb-gcode@...>
Date: Sunday, November 9, 2014, 1:30 AM


 









Thanks to all
for quick and informative responses - gosh, many
possibilities, sitting here reading and
learning.Keep the ideas coming
please I am sure I am not the only one extremely interested
in what is being said. Excellent
forum.Roy




On Saturday, 8 November 2014, 22:06,
"Dan Andersson dan@... [pcb-gcode]"
<pcb-gcode@...> wrote:





 













Roy,



Both environment's shows shortcomings when you push
them.



XP is probably the best of the Windows versions but you
can't push it if using a parallel port.

Win XP was never designed to do real time stuff so we must
applaud it to be able to run MACH3

as well as it does. Solutions and workarounds? Run it slow
as you describe it. Get the kettle on and

have yourself a cuppa while waiting for the mill. Or - get
one of these USB cards for cnc-milling.



Linux can be more demanding as many average users are
unfamiliar with it. Linux is as crap as XP when

dealing with Real Time like CNC milling machines. This is
solved by using a special RT Kernel, adopted

for real time purposes. As far as I know, linux doesn't
support the USB milling adapters ( yet? ).



LinuxCNC ( EMC2 ) versus MACH3? Both do the job good
enough.



If your system bites you even if running slow, try
downloading and burning a on cd version of LinuxCNC.

Generating the setup file should be reasonably straight
forward as you already have one from MACH3.



But be aware, changing to Linux is not a one size fit all
solution...



///Dan, M0DFI



On 08 Nov 2014 11:37:42 -0800

"forjacdf@... [pcb-gcode]"
<pcb-gcode@...> wrote:



> Hi All

>

> Interested to see yet another report of occasional
large jumps (only 2 mm - you lucky man!).

>

> This topic has come up many times, strangely always
seems to be the X axis. About 18 months back I started one
myself. I did all the thinks suggested re currents voltages
etc, won't bore everyone by repeating the list.

>

> In the end the only thing that worked was reducing the
speed during high speed traverses, which of course has less
effect on total time than you would expect.

>

> I only make perhaps 20 boards a year so milling slowly
isn't really a huge problem but the fact that I have had
to reduce speed to about a quarter of what the mill should
be capable of irritates me just because I feel I have failed
to get the system to work as it should.

>

>

> At the reduced speed (for high speed traverse) the
mill is totally reliable.

> When it was unreliable it would jump a large amount
(5-10mm) but this only happened perhaps once say every 10
000 instructions, about every fourth side of a pcb.

>

> I think it is an issue with windows (or perhaps I
should say time sharing systems) . I am using Mach 3, XP
and parallel port. Have done all the tweaking of XP
recommended and get the same results on two desktops and an
old laptop

>

> I know I could get smooth stepper and use USB and if I
made more boards I would, but really it is difficult to
justify the outlay for what I do, plus it would be really
nice come up with a simple solution.

>

> I was surprised when I searched for parallel port
buffer and all I got were circuits that were only current
buffers. I was expecting something which included memory
buffering. Is the reason that they don't seem to exist
because when using a parallel port the computer is
determining the variable speed relationships required for
milling complex shapes?

>

> If I was using a USB interface would the responsibility
for timing be handed over to the interface?

>

> Does Mach3 behave differently in these two situations
(parallel/USB)?

>

> I did try Linux CNC briefly but couldn't make it
work - probably because I had a Mach3 system 'kind of
working' and didn't put the time in.

>

> I did see a posting from someone saying that Linux CNC
was the answer to life the universe ..... but a friend who
is a 'Linux man' tells me that he can see no reason
why Linux would look any more like a dedicated system than
Windows does.

>

> My main computer has multiple drives and four different
operating systems. Would be lovely to have a fifth that was
a dedicated CNC operating system that could take the output
from PCB-GCODE and just 'do the job' without having
to service interrupts from the Windows/Linux worlds. Though
I guess this would rule out that other great program
auto-leveller(?) Hey ho!!

>

> If anyone has got this far, is still awake and can
unscramble the above ramblings it would be great to hear
your thoughts - or perhaps there is a thread somewhere that
explains all?

>

> Roy



--

Your value doesn't decrease based on

someone's inability to see your worth.
























#yiv1320487898 #yiv1320487898 --
#yiv1320487898ygrp-mkp {
border:1px solid #d8d8d8;font-family:Arial;margin:10px
0;padding:0 10px;}

#yiv1320487898 #yiv1320487898ygrp-mkp hr {
border:1px solid #d8d8d8;}

#yiv1320487898 #yiv1320487898ygrp-mkp #yiv1320487898hd {
color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}

#yiv1320487898 #yiv1320487898ygrp-mkp #yiv1320487898ads {
margin-bottom:10px;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad {
padding:0 0;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad p {
margin:0;}

#yiv1320487898 #yiv1320487898ygrp-mkp .yiv1320487898ad a {
color:#0000ff;text-decoration:none;}
#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc {
font-family:Arial;}

#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc #yiv1320487898hd {
margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}

#yiv1320487898 #yiv1320487898ygrp-sponsor
#yiv1320487898ygrp-lc .yiv1320487898ad {
margin-bottom:10px;padding:0 0;}

#yiv1320487898 #yiv1320487898actions {
font-family:Verdana;font-size:11px;padding:10px 0;}

#yiv1320487898 #yiv1320487898activity {
background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}

#yiv1320487898 #yiv1320487898activity span {
font-weight:700;}

#yiv1320487898 #yiv1320487898activity span:first-child {
text-transform:uppercase;}

#yiv1320487898 #yiv1320487898activity span a {
color:#5085b6;text-decoration:none;}

#yiv1320487898 #yiv1320487898activity span span {
color:#ff7900;}

#yiv1320487898 #yiv1320487898activity span
.yiv1320487898underline {
text-decoration:underline;}

#yiv1320487898 .yiv1320487898attach {
clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}

#yiv1320487898 .yiv1320487898attach div a {
text-decoration:none;}

#yiv1320487898 .yiv1320487898attach img {
border:none;padding-right:5px;}

#yiv1320487898 .yiv1320487898attach label {
display:block;margin-bottom:5px;}

#yiv1320487898 .yiv1320487898attach label a {
text-decoration:none;}

#yiv1320487898 blockquote {
margin:0 0 0 4px;}

#yiv1320487898 .yiv1320487898bold {
font-family:Arial;font-size:13px;font-weight:700;}

#yiv1320487898 .yiv1320487898bold a {
text-decoration:none;}

#yiv1320487898 dd.yiv1320487898last p a {
font-family:Verdana;font-weight:700;}

#yiv1320487898 dd.yiv1320487898last p span {
margin-right:10px;font-family:Verdana;font-weight:700;}

#yiv1320487898 dd.yiv1320487898last p
span.yiv1320487898yshortcuts {
margin-right:0;}

#yiv1320487898 div.yiv1320487898attach-table div div a {
text-decoration:none;}

#yiv1320487898 div.yiv1320487898attach-table {
width:400px;}

#yiv1320487898 div.yiv1320487898file-title a, #yiv1320487898
div.yiv1320487898file-title a:active, #yiv1320487898
div.yiv1320487898file-title a:hover, #yiv1320487898
div.yiv1320487898file-title a:visited {
text-decoration:none;}

#yiv1320487898 div.yiv1320487898photo-title a,
#yiv1320487898 div.yiv1320487898photo-title a:active,
#yiv1320487898 div.yiv1320487898photo-title a:hover,
#yiv1320487898 div.yiv1320487898photo-title a:visited {
text-decoration:none;}

#yiv1320487898 div#yiv1320487898ygrp-mlmsg
#yiv1320487898ygrp-msg p a span.yiv1320487898yshortcuts {
font-family:Verdana;font-size:10px;font-weight:normal;}

#yiv1320487898 .yiv1320487898green {
color:#628c2a;}

#yiv1320487898 .yiv1320487898MsoNormal {
margin:0 0 0 0;}

#yiv1320487898 o {
font-size:0;}

#yiv1320487898 #yiv1320487898photos div {
float:left;width:72px;}

#yiv1320487898 #yiv1320487898photos div div {
border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}

#yiv1320487898 #yiv1320487898photos div label {
color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}

#yiv1320487898 #yiv1320487898reco-category {
font-size:77%;}

#yiv1320487898 #yiv1320487898reco-desc {
font-size:77%;}

#yiv1320487898 .yiv1320487898replbq {
margin:4px;}

#yiv1320487898 #yiv1320487898ygrp-actbar div a:first-child {
margin-right:2px;padding-right:5px;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg {
font-size:13px;font-family:Arial, helvetica, clean,
sans-serif;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg table {
font-size:inherit;font:100%;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg select,
#yiv1320487898 input, #yiv1320487898 textarea {
font:99% Arial, Helvetica, clean, sans-serif;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg pre, #yiv1320487898
code {
font:115% monospace;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg * {
line-height:1.22em;}

#yiv1320487898 #yiv1320487898ygrp-mlmsg #yiv1320487898logo {
padding-bottom:10px;}


#yiv1320487898 #yiv1320487898ygrp-msg p a {
font-family:Verdana;}

#yiv1320487898 #yiv1320487898ygrp-msg
p#yiv1320487898attach-count span {
color:#1E66AE;font-weight:700;}

#yiv1320487898 #yiv1320487898ygrp-reco
#yiv1320487898reco-head {
color:#ff7900;font-weight:700;}

#yiv1320487898 #yiv1320487898ygrp-reco {
margin-bottom:20px;padding:0px;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
li a {
font-size:130%;text-decoration:none;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
li {
font-size:77%;list-style-type:square;padding:6px 0;}

#yiv1320487898 #yiv1320487898ygrp-sponsor #yiv1320487898ov
ul {
margin:0;padding:0 0 0 8px;}

#yiv1320487898 #yiv1320487898ygrp-text {
font-family:Georgia;}

#yiv1320487898 #yiv1320487898ygrp-text p {
margin:0 0 1em 0;}

#yiv1320487898 #yiv1320487898ygrp-text tt {
font-size:120%;}

#yiv1320487898 #yiv1320487898ygrp-vital ul li:last-child {
border-right:none !important;
}
#yiv1320487898

Running ULP program pcb-gcode from Eagle

Robert Wood
 

Hello Can anyone help me please. I am using Eagle to try and run PCB-GCODE.ULP. It wont run and comes back with error message. "UNABLE TO OPEN INCLUDE FILE 'SOURCE/PCB-GCODE.H'

I AM COMPLETLY NEW TO THIS ENVIROMENT SO PLEASE HELP THANKS.


BOB.


Re: Parallel port buffer?

Dan Whittemore
 

Hi Rene,


My experience has been that it is not the OS nor the parallel card but usually the controller card itself. I was originally using one of the controller cards from china because it was inexpensive and quicly available but was able to build my own controller and am using that now with much improvement.  I will say that I have had a better experience with LinuxCNC then I did with Mach3.  I was also able to reduce latency by removing the high priced video card that was in the PC with a simple card with a fair amount of video ram.

Re: Parallel port buffer?

Z P
 

Mesa Electronics and a number of other electronics manufacturersa make a PCI based interface card which eliminates the task of pulse generation and timing from the realm of software to hardware.

That is not a solution which will make Your stepper move faster.

Stepper motors suffer from resonance issues ( mass of rotor and stiffnes of magnetic circuit ) whihc requires special consideration in the design of the stepper motor driver.
It is said that Gecko drivers provide best speed/acceleration performance.

So if Your PC is not giving You joy select a driver card which willoperate with prefered software ( windows..linux) and setup the conditions to suit the actual motor driver to obtain improved machine performance



From: "Roy Emeny forjacdf@... [pcb-gcode]"
To: "pcb-gcode@..."
Sent: Sunday, 9 November 2014, 17:30
Subject: Re: [pcb-gcode] Parallel port buffer?

 
Thanks to all for quick and informative responses - gosh, many possibilities, sitting here reading and learning.
Keep the ideas coming please I am sure I am not the only one extremely interested in what is being said. 
Excellent forum.
Roy





On Saturday, 8 November 2014, 22:06, "Dan Andersson dan@... [pcb-gcode]" wrote:


 


Roy,

Both environment's shows shortcomings when you push them.

XP is probably the best of the Windows versions but you can't push it if using a parallel port.
Win XP was never designed to do real time stuff so we must applaud it to be able to run MACH3
as well as it does. Solutions and workarounds? Run it slow as you describe it. Get the kettle on and
have yourself a cuppa while waiting for the mill. Or - get one of these USB cards for cnc-milling.

Linux can be more demanding as many average users are unfamiliar with it. Linux is as crap as XP when
dealing with Real Time like CNC milling machines. This is solved by using a special RT Kernel, adopted
for real time purposes. As far as I know, linux doesn't support the USB milling adapters ( yet? ).

LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.

If your system bites you even if running slow, try downloading and burning a on cd version of LinuxCNC.
Generating the setup file should be reasonably straight forward as you already have one from MACH3.

But be aware, changing to Linux is not a one size fit all solution...

///Dan, M0DFI

On 08 Nov 2014 11:37:42 -0800
"forjacdf@... [pcb-gcode]" wrote:

> Hi All
>
> Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).
>
> This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.
>
> In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.
>
> I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.
>
>
> At the reduced speed (for high speed traverse) the mill is totally reliable.
> When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.
>
> I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop
>
> I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.
>
> I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?
>
> If I was using a USB interface would the responsibility for timing be handed over to the interface?
>
> Does Mach3 behave differently in these two situations (parallel/USB)?
>
> I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.
>
> I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.
>
> My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!
>
> If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?
>
> Roy

--
Your value doesn't decrease based on
someone's inability to see your worth.




Re: Parallel port buffer?

Roy Emeny
 

Thanks to all for quick and informative responses - gosh, many possibilities, sitting here reading and learning.
Keep the ideas coming please I am sure I am not the only one extremely interested in what is being said. 
Excellent forum.
Roy





On Saturday, 8 November 2014, 22:06, "Dan Andersson dan@... [pcb-gcode]" wrote:


 


Roy,

Both environment's shows shortcomings when you push them.

XP is probably the best of the Windows versions but you can't push it if using a parallel port.
Win XP was never designed to do real time stuff so we must applaud it to be able to run MACH3
as well as it does. Solutions and workarounds? Run it slow as you describe it. Get the kettle on and
have yourself a cuppa while waiting for the mill. Or - get one of these USB cards for cnc-milling.

Linux can be more demanding as many average users are unfamiliar with it. Linux is as crap as XP when
dealing with Real Time like CNC milling machines. This is solved by using a special RT Kernel, adopted
for real time purposes. As far as I know, linux doesn't support the USB milling adapters ( yet? ).

LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.

If your system bites you even if running slow, try downloading and burning a on cd version of LinuxCNC.
Generating the setup file should be reasonably straight forward as you already have one from MACH3.

But be aware, changing to Linux is not a one size fit all solution...

///Dan, M0DFI

On 08 Nov 2014 11:37:42 -0800
"forjacdf@... [pcb-gcode]" wrote:

> Hi All
>
> Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).
>
> This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.
>
> In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.
>
> I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.
>
>
> At the reduced speed (for high speed traverse) the mill is totally reliable.
> When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.
>
> I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop
>
> I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.
>
> I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?
>
> If I was using a USB interface would the responsibility for timing be handed over to the interface?
>
> Does Mach3 behave differently in these two situations (parallel/USB)?
>
> I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.
>
> I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.
>
> My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!
>
> If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?
>
> Roy

--
Your value doesn't decrease based on
someone's inability to see your worth.


Re: Parallel port buffer?

mahmod nassary
 

Month ago while i made 3d dolfin after 14204 g code line my machine x axis shift the drawing 5 cm, i check all boards and code but no solution i have till now, i use pc xp core 2due, parrelel

Any one know why?
Sent from Huawei Mobile

"René F. Viancos S. rene@... [pcb-gcode]" <pcb-gcode@...> wrote:

With the last Intel mini itx motherboards with legacy ports (lpt and
serial) and atom dual core, winxp unattended, mach3 and the cheapest
Probotix break out board (not opto isolated) and Probotix stepper drivers,
muy probkema with steps loosing dissappear. I think was a problem with the
mother board busses and multiplication performance.

Try with the M525WD mini itx Intel mother board (under U$ 100)

Bests from Chile

René
El 08/11/2014 23:00, "Harvey White madyn@... [pcb-gcode]" <
pcb-gcode@...> escribió:



On Sat, 8 Nov 2014 21:01:56 +0000, you wrote:





Roy,


Both environment's shows shortcomings when you push them.


XP is probably the best of the Windows versions but you can't push it if
using a parallel port.
Win XP was never designed to do real time stuff so we must applaud it to
be able to run MACH3
as well as it does. Solutions and workarounds? Run it slow as you
describe it. Get the kettle on and
have yourself a cuppa while waiting for the mill. Or - get one of these
USB cards for cnc-milling.

No version of windows was designed for real time. From what I
understand, MACH3 runs at top priority and hijacks a number of windows
functions to do as well as it does.



Linux can be more demanding as many average users are unfamiliar with it.
Linux is as crap as XP when
dealing with Real Time like CNC milling machines. This is solved by using
a special RT Kernel, adopted
for real time purposes. As far as I know, linux doesn't support the USB
milling adapters ( yet? ).

Exactly the case as I understand it, in terms of a real-time kernel.

DOS, since it's a very simple machine, can do real time with turbo
CNC, or at least real time enough that it works well. I've been
advised never to use it on a laptop because of some of the items in
the laptop bios.



LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.


If your system bites you even if running slow, try downloading and
burning a on cd version of LinuxCNC.
Generating the setup file should be reasonably straight forward as you
already have one from MACH3.


But be aware, changing to Linux is not a one size fit all solution...
Nope, you'd want a BDI (brain dead Install) version for easiest
installation. I am not a Linux type anyway, but it might be an
operating system that I use for control of the I2C stuff I build.

Now, the best way that I've been able to figure out how to make good
stepper pulses is to do it completely in hardware. That generally
would involve a CPLD or an FPGA generating the pulses in hardware.

From what I understand, the smooth stepper does this. A
microprocessor running a line drawing algorithm (it would work for 2
1/2 D stuff, not sure about the algorithm for 3 axis stuff, more
complicated and I'd rather do this in hardware) would also work, but
it takes a dedicated microprocessor and some careful timing
interlocking.

An Arduino would do it, though. You'd have to drive it with perhaps
another Arduino to handle an interface and buffer things, that would
keep the software in the stepper generator as simple and dependable as
possible.

Harvey



///Dan, M0DFI


On 08 Nov 2014 11:37:42 -0800
"forjacdf@... [pcb-gcode]" <pcb-gcode@...> wrote:


Hi All

Interested to see yet another report of occasional large jumps (only 2
mm - you lucky man!).

This topic has come up many times, strangely always seems to be the X
axis. About 18 months back I started one myself. I did all the thinks
suggested re currents voltages etc, won't bore everyone by repeating the
list.

In the end the only thing that worked was reducing the speed during
high speed traverses, which of course has less effect on total time than
you would expect.

I only make perhaps 20 boards a year so milling slowly isn't really a
huge problem but the fact that I have had to reduce speed to about a
quarter of what the mill should be capable of irritates me just because I
feel I have failed to get the system to work as it should.


At the reduced speed (for high speed traverse) the mill is totally
reliable.
When it was unreliable it would jump a large amount (5-10mm) but this
only happened perhaps once say every 10 000 instructions, about every
fourth side of a pcb.

I think it is an issue with windows (or perhaps I should say time
sharing systems) . I am using Mach 3, XP and parallel port. Have done all
the tweaking of XP recommended and get the same results on two desktops and
an old laptop

I know I could get smooth stepper and use USB and if I made more boards
I would, but really it is difficult to justify the outlay for what I do,
plus it would be really nice come up with a simple solution.

I was surprised when I searched for parallel port buffer and all I got
were circuits that were only current buffers. I was expecting something
which included memory buffering. Is the reason that they don't seem to
exist because when using a parallel port the computer is determining the
variable speed relationships required for milling complex shapes?

If I was using a USB interface would the responsibility for timing be
handed over to the interface?

Does Mach3 behave differently in these two situations (parallel/USB)?

I did try Linux CNC briefly but couldn't make it work - probably
because I had a Mach3 system 'kind of working' and didn't put the time in.

I did see a posting from someone saying that Linux CNC was the answer
to life the universe ..... but a friend who is a 'Linux man' tells me that
he can see no reason why Linux would look any more like a dedicated system
than Windows does.

My main computer has multiple drives and four different operating
systems. Would be lovely to have a fifth that was a dedicated CNC operating
system that could take the output from PCB-GCODE and just 'do the job'
without having to service interrupts from the Windows/Linux worlds. Though
I guess this would rule out that other great program auto-leveller(?) Hey
ho!!

If anyone has got this far, is still awake and can unscramble the above
ramblings it would be great to hear your thoughts - or perhaps there is a
thread somewhere that explains all?

Roy

Re: Parallel port buffer?

René F. Viancos S. <rene@...>
 

With the last Intel mini itx motherboards with legacy ports (lpt and serial) and atom dual core, winxp unattended,  mach3 and the cheapest Probotix break out board (not opto isolated) and Probotix stepper drivers,  muy probkema with steps loosing dissappear. I think was a problem with the mother board busses and multiplication performance.

Try with the M525WD mini itx Intel mother board (under U$ 100)

Bests from Chile

René

El 08/11/2014 23:00, "Harvey White madyn@... [pcb-gcode]" <pcb-gcode@...> escribió:
 

On Sat, 8 Nov 2014 21:01:56 +0000, you wrote:

>
>
>
>
>Roy,
>
>
>Both environment's shows shortcomings when you push them.
>
>
>XP is probably the best of the Windows versions but you can't push it if using a parallel port.
>Win XP was never designed to do real time stuff so we must applaud it to be able to run MACH3
>as well as it does. Solutions and workarounds? Run it slow as you describe it. Get the kettle on and
>have yourself a cuppa while waiting for the mill. Or - get one of these USB cards for cnc-milling.

No version of windows was designed for real time. From what I
understand, MACH3 runs at top priority and hijacks a number of windows
functions to do as well as it does.

>
>
>Linux can be more demanding as many average users are unfamiliar with it. Linux is as crap as XP when
>dealing with Real Time like CNC milling machines. This is solved by using a special RT Kernel, adopted
>for real time purposes. As far as I know, linux doesn't support the USB milling adapters ( yet? ).

Exactly the case as I understand it, in terms of a real-time kernel.

DOS, since it's a very simple machine, can do real time with turbo
CNC, or at least real time enough that it works well. I've been
advised never to use it on a laptop because of some of the items in
the laptop bios.

>
>
>LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.
>
>
>If your system bites you even if running slow, try downloading and burning a on cd version of LinuxCNC.
>Generating the setup file should be reasonably straight forward as you already have one from MACH3.
>
>
>But be aware, changing to Linux is not a one size fit all solution...

Nope, you'd want a BDI (brain dead Install) version for easiest
installation. I am not a Linux type anyway, but it might be an
operating system that I use for control of the I2C stuff I build.

Now, the best way that I've been able to figure out how to make good
stepper pulses is to do it completely in hardware. That generally
would involve a CPLD or an FPGA generating the pulses in hardware.

From what I understand, the smooth stepper does this. A
microprocessor running a line drawing algorithm (it would work for 2
1/2 D stuff, not sure about the algorithm for 3 axis stuff, more
complicated and I'd rather do this in hardware) would also work, but
it takes a dedicated microprocessor and some careful timing
interlocking.

An Arduino would do it, though. You'd have to drive it with perhaps
another Arduino to handle an interface and buffer things, that would
keep the software in the stepper generator as simple and dependable as
possible.

Harvey

>
>
>///Dan, M0DFI
>
>
>On 08 Nov 2014 11:37:42 -0800
>"forjacdf@... [pcb-gcode]" <pcb-gcode@...> wrote:
>
>
>> Hi All
>>
>> Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).
>>
>> This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.
>>
>> In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.
>>
>> I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.
>>
>>
>> At the reduced speed (for high speed traverse) the mill is totally reliable.
>> When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.
>>
>> I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop
>>
>> I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.
>>
>> I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?
>>
>> If I was using a USB interface would the responsibility for timing be handed over to the interface?
>>
>> Does Mach3 behave differently in these two situations (parallel/USB)?
>>
>> I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.
>>
>> I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.
>>
>> My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!
>>
>> If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?
>>
>> Roy

Re: Parallel port buffer?

Harvey White
 

On Sat, 8 Nov 2014 21:01:56 +0000, you wrote:





Roy,


Both environment's shows shortcomings when you push them.


XP is probably the best of the Windows versions but you can't push it if using a parallel port.
Win XP was never designed to do real time stuff so we must applaud it to be able to run MACH3
as well as it does. Solutions and workarounds? Run it slow as you describe it. Get the kettle on and
have yourself a cuppa while waiting for the mill. Or - get one of these USB cards for cnc-milling.
No version of windows was designed for real time. From what I
understand, MACH3 runs at top priority and hijacks a number of windows
functions to do as well as it does.



Linux can be more demanding as many average users are unfamiliar with it. Linux is as crap as XP when
dealing with Real Time like CNC milling machines. This is solved by using a special RT Kernel, adopted
for real time purposes. As far as I know, linux doesn't support the USB milling adapters ( yet? ).
Exactly the case as I understand it, in terms of a real-time kernel.

DOS, since it's a very simple machine, can do real time with turbo
CNC, or at least real time enough that it works well. I've been
advised never to use it on a laptop because of some of the items in
the laptop bios.



LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.


If your system bites you even if running slow, try downloading and burning a on cd version of LinuxCNC.
Generating the setup file should be reasonably straight forward as you already have one from MACH3.


But be aware, changing to Linux is not a one size fit all solution...
Nope, you'd want a BDI (brain dead Install) version for easiest
installation. I am not a Linux type anyway, but it might be an
operating system that I use for control of the I2C stuff I build.

Now, the best way that I've been able to figure out how to make good
stepper pulses is to do it completely in hardware. That generally
would involve a CPLD or an FPGA generating the pulses in hardware.

From what I understand, the smooth stepper does this. A
microprocessor running a line drawing algorithm (it would work for 2
1/2 D stuff, not sure about the algorithm for 3 axis stuff, more
complicated and I'd rather do this in hardware) would also work, but
it takes a dedicated microprocessor and some careful timing
interlocking.

An Arduino would do it, though. You'd have to drive it with perhaps
another Arduino to handle an interface and buffer things, that would
keep the software in the stepper generator as simple and dependable as
possible.

Harvey



///Dan, M0DFI


On 08 Nov 2014 11:37:42 -0800
"forjacdf@... [pcb-gcode]" <pcb-gcode@...> wrote:


Hi All

Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).

This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.

In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.

I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.


At the reduced speed (for high speed traverse) the mill is totally reliable.
When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.

I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop

I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.

I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?

If I was using a USB interface would the responsibility for timing be handed over to the interface?

Does Mach3 behave differently in these two situations (parallel/USB)?

I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.

I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.

My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!

If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?

Roy

Re: Parallel port buffer?

Dan Andersson
 

Roy,


Both environment's shows shortcomings when you push them.


XP is probably the best of the Windows versions but you can't push it if using a parallel port.
Win XP was never designed to do real time stuff so we must applaud it to be able to run MACH3
as well as it does. Solutions and workarounds? Run it slow as you describe it. Get the kettle on and
have yourself a cuppa while waiting for the mill. Or - get one of these USB cards for cnc-milling.


Linux can be more demanding as many average users are unfamiliar with it. Linux is as crap as XP when
dealing with Real Time like CNC milling machines. This is solved by using a special RT Kernel, adopted
for real time purposes. As far as I know, linux doesn't support the USB milling adapters ( yet? ).


LinuxCNC ( EMC2 ) versus MACH3? Both do the job good enough.


If your system bites you even if running slow, try downloading and burning a on cd version of LinuxCNC.
Generating the setup file should be reasonably straight forward as you already have one from MACH3.


But be aware, changing to Linux is not a one size fit all solution...


///Dan, M0DFI


On 08 Nov 2014 11:37:42 -0800
"forjacdf@... [pcb-gcode]" <pcb-gcode@...> wrote:


Hi All

Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).

This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.

In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.

I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.


At the reduced speed (for high speed traverse) the mill is totally reliable.
When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.

I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop

I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.

I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?

If I was using a USB interface would the responsibility for timing be handed over to the interface?

Does Mach3 behave differently in these two situations (parallel/USB)?

I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.

I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.

My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!

If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?

Roy



--
Your value doesn't decrease based on
someone's inability to see your worth.

Re: Parallel port buffer?

René F. Viancos S. <rene@...>
 

Hi Roy, 

I had similar problems and frustration over a year,

When I bought a Probotix parallel breakout board and steoper drivers from the same brand,  and my problems disappear... Magically

There are a lot issues related with pulses propagation and amplification,  and frecuency related issues whith cheat cnc hardware and these things.
Regards from Chile,

René Viancos

El 08/11/2014 16:37, "forjacdf@... [pcb-gcode]" <pcb-gcode@...> escribió:
 

Hi All

Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).

This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.

In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.

I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.


At the reduced speed (for high speed traverse) the mill is totally reliable.
When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.

I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop

I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.

I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?

If I was using a USB interface would the responsibility for timing be handed over to the interface?

Does Mach3 behave differently in these two situations (parallel/USB)?

I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.

I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.

My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!

If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?

Roy

Parallel port buffer?

Roy Emeny
 

Hi All

Interested to see yet another report of occasional large jumps (only 2 mm - you lucky man!).

This topic has come up many times, strangely always seems to be the X axis. About 18 months back I started one myself. I did all the thinks suggested re currents voltages etc, won't bore everyone by repeating the list.

In the end the only thing that worked was reducing the speed during high speed traverses, which of course has less effect on total time than you would expect.

I only make perhaps 20 boards a year so milling slowly isn't really a huge problem but the fact that I have had to reduce speed to about a quarter of what the mill should be capable of irritates me just because I feel I have failed to get the system to work as it should.


At the reduced speed (for high speed traverse) the mill is totally reliable.
When it was unreliable it would jump a large amount (5-10mm) but this only happened perhaps once say every 10 000 instructions, about every fourth side of a pcb.

I think it is an issue with windows (or perhaps I should say time sharing systems) . I am using Mach 3, XP and parallel port. Have done all the tweaking of XP recommended and get the same results on two desktops and an old laptop

I know I could get smooth stepper and use USB and if I made more boards I would, but really it is difficult to justify the outlay for what I do, plus it would be really nice come up with a simple solution.

I was surprised when I searched for parallel port buffer and all I got were circuits that were only current buffers. I was expecting something which included memory buffering. Is the reason that they don't seem to exist because when using a parallel port the computer is determining the variable speed relationships required for milling complex shapes?

If I was using a USB interface would the responsibility for timing be handed over to the interface?

Does Mach3 behave differently in these two situations (parallel/USB)?

I did try Linux CNC briefly but couldn't make it work - probably because I had a Mach3 system 'kind of working' and didn't put the time in.

I did see a posting from someone saying that Linux CNC was the answer to life the universe ..... but a friend who is a 'Linux man' tells me that he can see no reason why Linux would look any more like a dedicated system than Windows does.

My main computer has multiple drives and four different operating systems. Would be lovely to have a fifth that was a dedicated CNC operating system that could take the output from PCB-GCODE and just 'do the job' without having to service interrupts from the Windows/Linux worlds. Though I guess this would rule out that other great program auto-leveller(?) Hey ho!!

If anyone has got this far, is still awake and can unscramble the above ramblings it would be great to hear your thoughts - or perhaps there is a thread somewhere that explains all?

Roy