Metalworking (rec.crafts.metalworking) Discuss various aspects of working with metal, such as machining, welding, metal joining, screwing, casting, hardening/tempering, blacksmithing/forging, spinning and hammer work, sheet metal work.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

I'm exhausted.

I've already lost the evidence of who suggested I use CAMBAM. I tried
it, and really (really!) like it. Andy provides great support, and the
package works like a dream.

But, like most "modern" packages, it presumes you have unlimited memory
in the machine, and outputs things like pockets as a series of discrete
blocks of code, rather than using the more compact canned cycles older
machines had (for just that reason).

I need CAMBAM -- it's just great, and makes GSimple look like a cludge.
But I can't use it until I figure out how to dripfeed my R2E4. I cannot
find a description of the Bridgeport DNC protocol anywhere. The port
configuration isn't the issue, the issue is that there is a definite
block protocol (that may include things like start characters, BCC
characters, CRC characters, etc...) for the BOSS9 DNC.

So far at least, Bridgeport has not responded to requests for
information. Anybody else got a document? I can do the coding, I just
have to know what to write.

FWIW... all of the commercial DNC packages that have a trial version have
so far failed to communicate with the R2E4, even if they have a BOSS
entry in their machines list. Most don't even know what the protocols
are, and expect you to set them up manually in an editor of some ilk.

Thanks,
LLoyd
  #2   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2,152
Default help with drip feeding R2E4

On Fri, 17 Dec 2010 13:36:36 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:
snip
But I can't use it until I figure out how to dripfeed my R2E4.

snip
May be a repeat of an earlier post but click on
http://mcduffee-associates.us/PE/SPLITTER.ZIP
to download my software solution. [need winzip or pkunzip to
unpack]

Web page description:
Supplied as freeware with no warranty for fitness of use,
not even as a bad example.

A software solution to the problem of a large file and small
controller memory w/o drip feed capability. Divides any
G-code CNC file into smaller user specified size files
(minimum 5k), and adds header.nc and footer .nc to preserve
modal settings, etc. Generated programs are seg00001.nc
through seg99999.nc in the same directory as split02.exe.
you can specify drive and directory of the long input file
and the program will accept long file names as well as the
DOS 8.3 format.

Splitter.zip contains the following files:

split04.bas - the PowerBasic CC source file
split04.exe - the executable program that will run in
Windows no DOS box needed
blade.nc - a long 341k profiling program for test
footer.nc - a sample footer file from test.nc
header.nc - a sample header file from test.nc

Note header.nc and footer.nc must be user generated from the
long program they wish to split. Let me know if you find
this to be useful and any suggestions for improvements or
extensions.

Update 13 Apr 07 from split02 to split03 is that the return
of the tool to the last position is under rapid [G0] except
for last 0.10 unit of Z travel. G1 modal is restored.

Update 14 Apr 07 from split03 to split 04 is that entire
code line is parsed and LAST XYZ values are used, when
multiple moves per line. Rapid approach now to within 0.5
units in Z on following segment, then G1 model.

Take a look at
http://mcduffee-associates.us/cnc_re...nc_related.htm
you may see something else that would be helpful.

Let the group [and me] know if this was helpful.



-- Unka George (George McDuffee)
...............................
The past is a foreign country;
they do things differently there.
L. P. Hartley (1895-1972), British author.
The Go-Between, Prologue (1953).
  #3   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 27
Default help with drip feeding R2E4

On 2010-12-17, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
I'm exhausted.

I've already lost the evidence of who suggested I use CAMBAM. I tried
it, and really (really!) like it. Andy provides great support, and the
package works like a dream.

But, like most "modern" packages, it presumes you have unlimited memory
in the machine, and outputs things like pockets as a series of discrete
blocks of code, rather than using the more compact canned cycles older
machines had (for just that reason).

I need CAMBAM -- it's just great, and makes GSimple look like a cludge.
But I can't use it until I figure out how to dripfeed my R2E4. I cannot
find a description of the Bridgeport DNC protocol anywhere. The port
configuration isn't the issue, the issue is that there is a definite
block protocol (that may include things like start characters, BCC
characters, CRC characters, etc...) for the BOSS9 DNC.

So far at least, Bridgeport has not responded to requests for
information. Anybody else got a document? I can do the coding, I just
have to know what to write.

FWIW... all of the commercial DNC packages that have a trial version have
so far failed to communicate with the R2E4, even if they have a BOSS
entry in their machines list. Most don't even know what the protocols
are, and expect you to set them up manually in an editor of some ilk.


Lloyd, did you ask in the Bridgeport forum on cnczone?

i
  #4   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

F. George McDuffee fired this volley
in news
http://mcduffee-associates.us/PE/SPLITTER.ZIP
to download my software solution. [need winzip or pkunzip to
unpack]


Unka, you gave that to me earlier this week, and it works nicely for what
I had been doing by hand -- much more nicely.

But I have a quandry. I laid out a part in CAMBAM and generated the g-
codes for it. It's a relatively simple part, but with several pockets, a
couple of islands, and a frame around the outside.

With R2E4 special canned cycles, I can fit the thing into about 8K of g-
code (which will fit in the machine). But modern CAM packages eschew
canned cycles (except for drill, peck drill, and tap) for discrete g-code
blocks. This part ended up about 200K worth of code.

That would mean "baby-sitting" the machine for up to six hours, just to
re-load the next 10K-or-so segment.

For a _couple_ of reloads, that wouldn't be too much of a chore. For 20-
odd, it's just untenable.

Don't get me wrong... I like what you supplied, and it helped me through
a couple of pounds of wax to verify some codes. But it just won't work
for what I must do with this machine. I need to drip feed it until I can
save up enough to do a full-up "kit" retro-fit. I just don't have the
time to engineer my own.

LLoyd
  #5   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 27
Default help with drip feeding R2E4

On 2010-12-17, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
F. George McDuffee fired this volley
in news
http://mcduffee-associates.us/PE/SPLITTER.ZIP
to download my software solution. [need winzip or pkunzip to
unpack]


Unka, you gave that to me earlier this week, and it works nicely for what
I had been doing by hand -- much more nicely.

But I have a quandry. I laid out a part in CAMBAM and generated the g-
codes for it. It's a relatively simple part, but with several pockets, a
couple of islands, and a frame around the outside.

With R2E4 special canned cycles, I can fit the thing into about 8K of g-
code (which will fit in the machine). But modern CAM packages eschew
canned cycles (except for drill, peck drill, and tap) for discrete g-code
blocks. This part ended up about 200K worth of code.

That would mean "baby-sitting" the machine for up to six hours, just to
re-load the next 10K-or-so segment.

For a _couple_ of reloads, that wouldn't be too much of a chore. For 20-
odd, it's just untenable.

Don't get me wrong... I like what you supplied, and it helped me through
a couple of pounds of wax to verify some codes. But it just won't work
for what I must do with this machine. I need to drip feed it until I can
save up enough to do a full-up "kit" retro-fit. I just don't have the
time to engineer my own.


Lloyd... Retrofit time...

I was making this today, and watched some youtube stuff and read news,
while this was being made:

http://igor.chudov.com/projects/Brid...Collet-Holder/

i


  #6   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

Ignoramus30138 fired this volley
in :

http://igor.chudov.com/projects/Brid...ract-2-CNC-Mil
l/33-DA-Collet-Holder/


heh! Ig, THAT I could do with about 30 blocks of g-code in one short
macro and a couple of setup steps! G

It IS upgrade time, but I can't afford a kit solution yet, and can't
spare the down-time for a DIY job.

As much as I want to employ EMC2, it looks like I'll have to go with a
Mach3 kit in order to get the machine converted over a week's vacation
time.

I make parts in my shop (and on the mill) almost every day, now. They're
mission-critical to my "real" job, so I have to keep the spindle turning.

The nice guy at CAMBAM (Andy Payne) will upgrade my CAMBAM+simulator
package to include Mach3 for only an additional $162, so at least the
software won't cost me much.

LLoyd
  #7   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 27
Default help with drip feeding R2E4

On 2010-12-17, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus30138 fired this volley
in :

http://igor.chudov.com/projects/Brid...ract-2-CNC-Mil
l/33-DA-Collet-Holder/


heh! Ig, THAT I could do with about 30 blocks of g-code in one short
macro and a couple of setup steps! G


I did it in 11 lines.

(DA collet holder)
O100 sub
G73 Z-0.45 Q0.01 R0.01 F1.2
O100 endsub

S1 M3
M8

Oapply_to_a_grid call [0.7] [0.6] [0.9] [1] [10] [7] [0.05] [100]

M2

It IS upgrade time, but I can't afford a kit solution yet, and can't
spare the down-time for a DIY job.

As much as I want to employ EMC2, it looks like I'll have to go with a
Mach3 kit in order to get the machine converted over a week's vacation
time.


Mach3 is great too.

I make parts in my shop (and on the mill) almost every day, now. They're
mission-critical to my "real" job, so I have to keep the spindle turning.

The nice guy at CAMBAM (Andy Payne) will upgrade my CAMBAM+simulator
package to include Mach3 for only an additional $162, so at least the
software won't cost me much.


That's not a bad price.

I am sure that mach3 will make you very happy.

i
  #8   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4
Default help with drip feeding R2E4

In rec.crafts.metalworking on 2010-12-17 Lloyd E. Sponenburgh wrote:
F. George McDuffee wrote
... http://mcduffee-associates.us/PE/SPLITTER.ZIP

....
But I have a quandry. I laid out a part in CAMBAM [...]

^ quandary
With R2E4 special canned cycles, I can fit the thing into about 8K of g-
code (which will fit in the machine). But modern CAM packages eschew
canned cycles (except for drill, peck drill, and tap) for discrete g-code
blocks. This part ended up about 200K worth of code.

That would mean "baby-sitting" the machine for up to six hours, just to
re-load the next 10K-or-so segment.

....

One way to do this is to mount a keyboard on or near the mill table so
that the spindle or the table can press a lever to operate the Enter
key on the keyboard. Revise George's FOOTER.NC so that it operates
the Enter key and then returns to standard position. On computer S,
run a script that, for each segment Kn to be downloaded, pauses until
Enter is pressed; sleeps a while; and starts download of Kn.

--
jiw
  #9   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

James Waldby fired this volley in news:iegqtl$mr4$1
@news.eternal-september.org:

On computer S,
run a script that, for each segment Kn to be downloaded, pauses until
Enter is pressed; sleeps a while; and starts download of Kn.


Riiiiiight! I'll get right on that...

LLoyd
  #10   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2
Default help with drip feeding R2E4

I have uploaded the protocol description to the Metalworking.com
Dropbox (RemLoad_DncLink_Protocols.txt). I wrote it a LONG time
ago...

- Dave

On Fri, 17 Dec 2010 13:36:36 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

I'm exhausted.

I've already lost the evidence of who suggested I use CAMBAM. I tried
it, and really (really!) like it. Andy provides great support, and the
package works like a dream.

But, like most "modern" packages, it presumes you have unlimited memory
in the machine, and outputs things like pockets as a series of discrete
blocks of code, rather than using the more compact canned cycles older
machines had (for just that reason).

I need CAMBAM -- it's just great, and makes GSimple look like a cludge.
But I can't use it until I figure out how to dripfeed my R2E4. I cannot
find a description of the Bridgeport DNC protocol anywhere. The port
configuration isn't the issue, the issue is that there is a definite
block protocol (that may include things like start characters, BCC
characters, CRC characters, etc...) for the BOSS9 DNC.

So far at least, Bridgeport has not responded to requests for
information. Anybody else got a document? I can do the coding, I just
have to know what to write.

FWIW... all of the commercial DNC packages that have a trial version have
so far failed to communicate with the R2E4, even if they have a BOSS
entry in their machines list. Most don't even know what the protocols
are, and expect you to set them up manually in an editor of some ilk.

Thanks,
LLoyd



  #11   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

David E. Cloud fired this volley in
:

RemLoad_DncLink_Protocols.txt


DAVE! THANKS! That's just what I was looking for.

It took me just a bit to find it. It's under
Bridgeport_RemLoad_DncLink_Protocols.txt.

This is perfect! And I am much impressed by the fact that a Bridgeport
guy gave the solution. So far, my experience with the Hardinge/BP outfit
has been very rewarding.

Now... to learn some Windows (as opposed to DOS) RS232 communications
skills. My goal is to write a plug-in to CAMBAM that will do the drip
feed from within CAMBAM.

LLoyd
  #12   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 856
Default help with drip feeding R2E4

Lloyd E. Sponenburgh wrote:
David E. Cloud fired this volley in
:


RemLoad_DncLink_Protocols.txt


DAVE! THANKS! That's just what I was looking for.

It took me just a bit to find it. It's under
Bridgeport_RemLoad_DncLink_Protocols.txt.

This is perfect! And I am much impressed by the fact that a Bridgeport
guy gave the solution. So far, my experience with the Hardinge/BP outfit
has been very rewarding.

Now... to learn some Windows (as opposed to DOS) RS232 communications
skills. My goal is to write a plug-in to CAMBAM that will do the drip
feed from within CAMBAM.

LLoyd

That should be a fun experience for you learning the Win32
communications stuff. I've not done DOS communications but have done
enough in 16bit Windows which I would expect is similar. The Win32
communications is somewhat different and you have pre-emptive
multitasking and threading to potentially contend with. The pre-emptive
multitasking can throw in a few gotchas. Any idea what language you'll
be using, my experience is with C and C++.
  #13   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

David Billington fired this volley in
:

Any idea what language you'll
be using, my experience is with C and C++.


I can do C, and a smattering of C++. I retired from software work before
C++ had a full following among industrial users, but C was well and
thoroughly rolled out.

However, I'm most likely to do it in Visual Basic. It's not all that
great a language in terms of efficiency, but I have a library of hardware
functions and widgets that claim to deal with all the preemption crap.
Obviously, at 4800 baud, interrupt latency is important. Coupling that
with the fact that the control will choke if you send more than three
characters past the XOFF makes real-time handling pretty important.


Dave, I could not figure out how to make the control use Xon/Xoff "dumb"
protocol for the DNC. I followed your instructions of using a "-1" as
the filename, but my termulator still just blithely sent the whole file,
rather than pausing per-block. I don't yet have a protocol analyser
hooked up, but I presume that means there were no flow-control characters
coming from the control.

OTOH, I can transmit a DNC stream successfully from EZlink, using ONLY a
"-" as the filename (at the control) and two executes. The first one
seems to set the protocol, and the second starts the DNC link.

Perhaps you could explain that -- what is the significance of the "bare"
minus sign as a filename? I just did that from rote per the EZLink
instructions, but have no idea what it does. Can the DNC protocol be
invoked with a "real" filename, also? (haven't tried yet)

I air milled several parts yesterday under DNC via EZLink.

Thanks,
LLoyd
  #14   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 856
Default help with drip feeding R2E4

Lloyd E. Sponenburgh wrote:
David Billington fired this volley in
:


Any idea what language you'll
be using, my experience is with C and C++.



I can do C, and a smattering of C++. I retired from software work before
C++ had a full following among industrial users, but C was well and
thoroughly rolled out.

I started about 20 years ago so I think C++ was around but hadn't become
mainstream, it didn't take many years after that to do so though IIRC.
When I was at college some people were using SmallTalk and I met a guy a
few years ago that was an expert in it, at that point I think it was
officially a dead language. Doesn't take long for some languages but I
don't see C going away for a while.

However, I'm most likely to do it in Visual Basic. It's not all that
great a language in terms of efficiency, but I have a library of hardware
functions and widgets that claim to deal with all the preemption crap.
Obviously, at 4800 baud, interrupt latency is important. Coupling that
with the fact that the control will choke if you send more than three
characters past the XOFF makes real-time handling pretty important.

I've never done any communications that required XON/XOFF but my
understanding is that Windows should handle that for you if configured
correctly. You may want to look at the DCB structure as detailed here
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx . One of
the gotchas I ran into in some code was a call to WriteFile () followed
by a call to WaitCommEvent (). It was regularly timing out on the
WaitCommEvent (), it seems it was frequently being pre-empted between
the 2 calls and at 115k baud the reply had already been picked up by
Windows and placed in the receive queue. WaitCommEvent () won't tell you
if data is already in the queue, only when new data has arrived and been
placed in the queue.


Dave, I could not figure out how to make the control use Xon/Xoff "dumb"
protocol for the DNC. I followed your instructions of using a "-1" as
the filename, but my termulator still just blithely sent the whole file,
rather than pausing per-block. I don't yet have a protocol analyser
hooked up, but I presume that means there were no flow-control characters
coming from the control.

OTOH, I can transmit a DNC stream successfully from EZlink, using ONLY a
"-" as the filename (at the control) and two executes. The first one
seems to set the protocol, and the second starts the DNC link.

Perhaps you could explain that -- what is the significance of the "bare"
minus sign as a filename? I just did that from rote per the EZLink
instructions, but have no idea what it does. Can the DNC protocol be
invoked with a "real" filename, also? (haven't tried yet)

I air milled several parts yesterday under DNC via EZLink.

Thanks,
LLoyd

  #15   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2,584
Default help with drip feeding R2E4

On 2010-12-19, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
David Billington fired this volley in
:

Any idea what language you'll
be using, my experience is with C and C++.


I can do C, and a smattering of C++. I retired from software work before
C++ had a full following among industrial users, but C was well and
thoroughly rolled out.

However, I'm most likely to do it in Visual Basic. It's not all that
great a language in terms of efficiency, but I have a library of hardware
functions and widgets that claim to deal with all the preemption crap.
Obviously, at 4800 baud, interrupt latency is important. Coupling that
with the fact that the control will choke if you send more than three
characters past the XOFF makes real-time handling pretty important.


Dave, I could not figure out how to make the control use Xon/Xoff "dumb"
protocol for the DNC. I followed your instructions of using a "-1" as
the filename, but my termulator still just blithely sent the whole file,


"termulator"? "Terminal Emulator" perhaps?

rather than pausing per-block. I don't yet have a protocol analyser
hooked up, but I presume that means there were no flow-control characters
coming from the control.


Does the control support hardware flow control? The CTS/RTS
lines to tell when to stop and start? Sometimes that will work when the
software DC1/DC3 (also known as Xon/Xoff) won't.

And -- it should result in an *immediate* halt to the
transmitted data if the port is set up to honor it. The program may
have more characters queued up, but they can't go out until the CTS line
on the transmitting system goes true.

OTOH, I can transmit a DNC stream successfully from EZlink, using ONLY a
"-" as the filename (at the control) and two executes. The first one
seems to set the protocol, and the second starts the DNC link.

Perhaps you could explain that -- what is the significance of the "bare"
minus sign as a filename?


On Windows, I don't know. On unix systems, it says "write the
data to "standard output"" (which normally would go to the screen, unless
you follow it with a pipe symbol '|' followed by another program to
receive the data. (It also can mean to read from "standard input",
which would be the keyboard, unless the program name is *preceded* by a
pipe symbol, with another program writing to standard output feeding the
pipe.) Back in the old days, MS-DOS *faked* pipes by writing to a
temporary file, then closing it when the program ended, and opening the
file for reading when the next program started up. (No preemptive
multi-tasking on old MS-DOS. :-)

I just did that from rote per the EZLink
instructions, but have no idea what it does. Can the DNC protocol be
invoked with a "real" filename, also? (haven't tried yet)


No clue there, since I don't know the program, and I don't see
your command line there -- or did you type the '-' to a GUI field?

I air milled several parts yesterday under DNC via EZLink.


Good! Next wax. :-)

Enjoy,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---


  #16   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

"DoN. Nichols" fired this volley in
:

Does the control support hardware flow control? The CTS/RTS
lines to tell when to stop and start? Sometimes that will work when

the
software DC1/DC3 (also known as Xon/Xoff) won't.


According to the maintenance documentation, the R2E4 BOSS9 control
doesn't support hardware flow-control.

And the BOSS9 _may_ have some underlying OS that we'd have been familiar
with in the mid-80s, but the OS isn't exposed to the user. There are no
command-line inputs, merely prompts (and darned few of them).

Ordinarily, one "expects" to load a program that will fit in 12K on the
BOSS9. In that case, no flow-control of any kind is used -- the program
is just buffered. In the direct numeric control mode, it would appear
that DC1/DC3 flow control is the only one available.

However, as Dave's documentation shows, this isn't a "dumb" text-only
protocol with flow control -- there are VRC checks by the control, and
LRC at the end of each block, and STX/ETB headers/footers on each block,
along with the conventional ETX or EOT at the end of the data.

What Dave mentioned was that by entering a filename of "-1" on the
controller, that it would revert to a dumb XON/XOFF protocol without out
all the other overhead -- useful, I guess, if you're dead-sure your link
is solid, and which would save space and communications time when the
programs consisted of lots of very short lines of code.

However, I could not make that work; at least it didn't appear to. Until
I build up a protocol analyser to watch what's being exchanged, I'm not
sure what protocol EZLink is actually using when I enter the bare "-" for
a filename, followed by the two "execute" depressions.

LLoyd

  #17   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2
Default help with drip feeding R2E4

By definition DNC Link requires a "smart" server -- one that "speaks"
the DNC Link protocol.

"-1" as a program number (file name) was intended for Remote Load (as
I said, a serial tape reader, like the GNT 4604), so that a "dumb"
device could stream a file to the CNC.

I believe that I supported the "-1" for DNC Link as well, but that
requires having the "server" already set up to send the file *VIA THE
DNC LINK PROTOCOL*.

Going back and proof-reading this before hitting send, I rember now -
If EZ-CAM got a "transfer request" without a previous "program name
transfer" it popped up a dialog to get the name from the operator -
simple and elegant. What I do not remember is whether we transfered a
null program number (just the "D" protion to flag it as a DNC Link
request). I kind of think we did...

DNC Link is a block-by-block protocol with error detection and
retransmission, to facilitate the execution of machine-generated
(CAD/CAM) programs, which tended to be very large and take a long time
to execute.

Yes, the program name may be alpha-numeric (although there is no way
to do this from the CNC HMI). Two EZ-CAMs can be linked together via
DNCLink / RemoteLoad and the protocol used to transfer arbitrary text
files back and forth. Various implementations of the protocol (on
programming stations, etc.) allowed one to pre-assign a program name
and therefor not require one sent from the CNC. The "8.3" DOS
filename convention made it easy to differentiate a name from a
program, with the caveat that a program had to be longer than 11
characters (did anyone try to send a super-short program and break the
protocol? Of course they did. No Sympathy.)

To the question of "Operating System":
There was no 'Operating System", per say, in the BOSS controls (any of
them), but they each contain(ed) some form of "monitor", a ROM-based
debugger to allow analysis of a crashed system (and in the later
PC-based systems, a bootstrap loader to re-load the motion board (FMDC
or BMDC) if the battery-backed executable failed it's CRC check. In
fact, even the old stepper-motor systems based on the LSI-11 had DEC's
ODT (Online Debugging Tool), which could load a RAM-based executable
from paper tape (the only one that I have is a program to convert
Tab-Sequential programs to Word-Address). But I digress...

The debugger was the first code we wrote, and was used to debug the
different routines that eventually became the CNC. We could load
routines into RAM, single-step through them, examine registers,
variables and memory, etc. Yes, the earliest ROM-based system
required blowing a bank of EPROMS to test -- we usually had a few
banks baking under the UV eraser while whe tried the latest version.
This was one of my primary reasons for converting all but the first
bank of FMDC PROM to RAM, and the birth of the V2XT. The final systems
had TWO debuggers; the ROM based "tool of last resort" and the
RAM-based "real-time monitor", which, when coupled with the DOS-based
Window Monitor and PFM allowed a certain amount of real-time bit
fiddling and process state analysis for the Cognescenti.

In later systems (Boss 8 and up) there was a set of macros and support
subroutines (remember, this was all written in Assembler) for
cooperative multi-tasking. Routines were not pre-empted, but
voluntarily gave up control via a call to a "return" subroutine that
saved CPU state and allowed the next task to run. When that task's
turn came around again it got back its registers and CPU state and
picked up at the instruction afther "Call Return". This was very
usefull for things like the "S" and "M" code handlers, which could
take seconds or minutes to complete. Many Idle Loop tasks check for a
few conditions and return, having nothing to do at the moment. Because
every "wait loop" includes a "call return", the Idle Loop actually
executes at a rather brisk pace, and all tasks get an invocation many
hundreds (or thousands!) of times each second. We counted every
instruction in every routine and knew the execution time to the
microsecond. There are internal checks for re-entrancy, but in a
production system it should not be possible to trigger them (and they
will result in a fatal exception if they ARE triggered!).

The UARTs are fed / read via interrupt-driven queues, but these events
are kept intentionally short (a few instructions).The motion routines
(servo process) are dispached by a timer interrupt, and they interrupt
the routines of the "idle loop". Obviously the Interpolator and Servo
Process must leave enough CPU cycles for the Idle Loop routines to all
run in a timely fashion! The Basic Servo interrupt is (if my memory is
still OK) is every 250 microseconds (for maintaining the axis
counters, which are only a few bits each); every 8 servo periods the
DAC values are calculated (1 milisecond servo rate) and every 4
miliseconds the Interpolator is called to calculate the next path
segment. The Interpreter (the code that handles G-Code and such) is
and Idle Loop task because floating-point operations take FOREVER. The
Interpolator and Servo use only INTEGER math for speed. Internal
positions are kept as quad-precision integers, where one count equals
10 nanometers. This is an interesting value; it can be made into
inches or milimeters with integer math. 2540000 = 1 inch; 100000 = 1
milimeter. There can never be a conversion error no matter HOW many
times one switches between Imperial and Metric units, and this solved
the age-old Inch/Metric round-off error problems (that many controls
still have!) once and for all.

Back to communications: I once wrote the DNC Link and Remote Load
handlers in BASIC for the Radio Shack (Tandy) portable, so I know that
it can be done in just about any language, on just about any CPU! The
early EZ-CAM routines were in Pascal (with some assembler; I wrote new
communications handlers for the UCSD Pascal SBIOS because the default
ones were polled and I wanted interrupts!) and later version in "C".

The final controls (the PC-based ones; "V2XT", "SX-15", DX-32" etc.)
did away with DNC link because they now had on-board disk storage
(even a floppy was huge compared to RAM). On these controls there is
a block-by-block transfer from disk to CNC memory, but it is internal
to the PC -- CNC communications structure. It was assumed that
programs would be available from local storage, and that they would
get there by some external means (sneakernet, various early networking
standards, etc.). One must still choose to use DNC, but the file is
"dripped" from local storage, not a communication channel.

On Sun, 19 Dec 2010 08:23:32 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

David Billington fired this volley in
:

Any idea what language you'll
be using, my experience is with C and C++.


I can do C, and a smattering of C++. I retired from software work before
C++ had a full following among industrial users, but C was well and
thoroughly rolled out.

However, I'm most likely to do it in Visual Basic. It's not all that
great a language in terms of efficiency, but I have a library of hardware
functions and widgets that claim to deal with all the preemption crap.
Obviously, at 4800 baud, interrupt latency is important. Coupling that
with the fact that the control will choke if you send more than three
characters past the XOFF makes real-time handling pretty important.


Dave, I could not figure out how to make the control use Xon/Xoff "dumb"
protocol for the DNC. I followed your instructions of using a "-1" as
the filename, but my termulator still just blithely sent the whole file,
rather than pausing per-block. I don't yet have a protocol analyser
hooked up, but I presume that means there were no flow-control characters
coming from the control.

OTOH, I can transmit a DNC stream successfully from EZlink, using ONLY a
"-" as the filename (at the control) and two executes. The first one
seems to set the protocol, and the second starts the DNC link.

Perhaps you could explain that -- what is the significance of the "bare"
minus sign as a filename? I just did that from rote per the EZLink
instructions, but have no idea what it does. Can the DNC protocol be
invoked with a "real" filename, also? (haven't tried yet)

I air milled several parts yesterday under DNC via EZLink.

Thanks,
LLoyd

  #18   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

David E. Cloud fired this volley in
:

By definition DNC Link requires a "smart" server -- one that "speaks"
the DNC Link protocol.


Great stuff, Dave. The old iron is still good!

Thanks for the retrospective look at what went into it. I, too, was a
"prom blaster" in my day, doing stand-alone controllers for protocol
handling (like mini-to-IBM3780), and writing custom, multi-threaded
terminal emulators for AIX and SCO Unix.


LLoyd
  #19   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 20
Default help with drip feeding R2E4

On 2010-12-21, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
David E. Cloud fired this volley in
:

By definition DNC Link requires a "smart" server -- one that "speaks"
the DNC Link protocol.


Great stuff, Dave. The old iron is still good!

Thanks for the retrospective look at what went into it. I, too, was a
"prom blaster" in my day, doing stand-alone controllers for protocol
handling (like mini-to-IBM3780), and writing custom, multi-threaded
terminal emulators for AIX and SCO Unix.


Then you would be right at home with EMC2!
  #20   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

Ignoramus30024 fired this volley in
:

Then you would be right at home with EMC2!


If one of the vendors sells a kit version with EMC2, I'd be happier than
a pig in slop.

I'm NOT terribly happy with some of the inherent quirks in the BOSS9
control. I have an engraving project I've been fiddling with in the odd
half-hour of spare time for over two months. It just "e-stops" for no
visible reason; every time, at the same line of code. Nothing out of
range, no axis limits exceeded, nothing except in the FIST log a cryptic
"motion command that took too long..." (or some-sort; I don't have the
message handy now) and part of the message cuts off at the edge of the
field. But I cannot find anything it exceeds.

It's in a G03 block, and I run G3s and G2s all the time for cornering
blocks. I'll figure it out, and it'll probably be something like
(haven't explored this) the center of the arc being outside the "frame"
of the work area... It is prepping a very gentle curve when it fails.

LLoyd


  #21   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 20
Default help with drip feeding R2E4

On 2010-12-21, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus30024 fired this volley in
:

Then you would be right at home with EMC2!


If one of the vendors sells a kit version with EMC2, I'd be happier than
a pig in slop.


Lloyd, is your machine servo motor based?

Do you know what your encoders are like?

I considered my mill a "kit", in the sense of coming with servo motors
mounted on it. I just had to add encoders, servo amps, control box
etc.

Also another kit-like element was Jon's PPMC controller.

The reason why I am glad that I did not go with a kit is two fold:

1) I know everything about how my mill functions
2) I can add stuff to it, like a rotary indexer, spindle encoder, 4th
axis, etc, as much as I want, and I am not limited by only three
connectors on a "kit".

Adding the rotary indexer took literally one evening. I thought for a
lot longer about it, as you know, but just doing it was borderline
trivial.

Adding a spindle encoder also took 2 months thinking and some aborted
attempts to make a shaft adaptor, but once I made one, it took only
one day (same day as I made the adaptor).

The 4th axis will be harder, due to resolver converter issues,

I greatly doubt that I could do any of this with a "kit".

Furthermore, I bought (for $2) a Saitek P880 joypad at a garage sale.

Wiring it in took a couple of hours, and that was this long only
because I was stupid. I just copied a config from some guy and did a
bad job at this, otherwise it would be one hour.

Now this joypad, is far superior in convenience to any jogging
controls that I have personally seen, which admittedly is not that
many. Could I do it with a kit? I am not too sure, Pete C may have
something to add about that.


I'm NOT terribly happy with some of the inherent quirks in the BOSS9
control. I have an engraving project I've been fiddling with in the odd
half-hour of spare time for over two months. It just "e-stops" for no
visible reason; every time, at the same line of code. Nothing out of
range, no axis limits exceeded, nothing except in the FIST log a cryptic
"motion command that took too long..." (or some-sort; I don't have the
message handy now) and part of the message cuts off at the edge of the
field. But I cannot find anything it exceeds.

It's in a G03 block, and I run G3s and G2s all the time for cornering
blocks. I'll figure it out, and it'll probably be something like
(haven't explored this) the center of the arc being outside the "frame"
of the work area... It is prepping a very gentle curve when it fails.


Can you break that G3 into two smaller G3s? Would that help?

Eg instead of from (0,0) to (2,0) WITH radis 1, you could go through
(1,1): instead of G3 X2 R1 you would say G3 X1 Y1 R1, G3 X2 Y0 R1,
Would that help?

i
  #22   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2,584
Default help with drip feeding R2E4

On 2010-12-20, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
"DoN. Nichols" fired this volley in
:

Does the control support hardware flow control? The CTS/RTS
lines to tell when to stop and start? Sometimes that will work when

the
software DC1/DC3 (also known as Xon/Xoff) won't.


According to the maintenance documentation, the R2E4 BOSS9 control
doesn't support hardware flow-control.

And the BOSS9 _may_ have some underlying OS that we'd have been familiar
with in the mid-80s, but the OS isn't exposed to the user. There are no
command-line inputs, merely prompts (and darned few of them).


Certainly the BOSS-3 through BOSS-6 did not. The CPU was the
DEC LSI-11, and the OS *was* the control program -- all in ROM.

Ordinarily, one "expects" to load a program that will fit in 12K on the
BOSS9. In that case, no flow-control of any kind is used -- the program
is just buffered. In the direct numeric control mode, it would appear
that DC1/DC3 flow control is the only one available.

However, as Dave's documentation shows, this isn't a "dumb" text-only
protocol with flow control -- there are VRC checks by the control, and
LRC at the end of each block, and STX/ETB headers/footers on each block,
along with the conventional ETX or EOT at the end of the data.


Hmm ... just out of curiosity -- does his documentation show what
kind of serial port chip is used to implement the RS-232 interface? I
know that the BOSS-3 through BOSS-6 used old UART chips (40-pin chips so
fairly easy to identify) and the only thing necessary with those to use
hardware flow control would be to connect the proper pin through a
RS-232 level translator chip (e.g. the MC1488/MC1489 pair (I forget
which is the transmitter and which is the receiver, though I could
always look it up) to the CTS pin of the RS-232 connector. IIRC, when
there was data in the chip which had not yet been read, it would turn
off the CTS pin to stop the flow without CPU involvement.

However, since form an earlier comment about it being run by a
Motroloa 68000 family CPU chip, it is likely that it is using the MC6850
serial port chip (ACIA -- Asynchronous Communications Interface Adaptor)
which required software configuration to honor/manipulate the CTS/RTS
pins.

Does the system have a punched tape reader? If so, it should be
able to stop and start *that* for drip feed, so what you need is an
interface box to make that look like a serial port to the PC.

What Dave mentioned was that by entering a filename of "-1" on the
controller, that it would revert to a dumb XON/XOFF protocol without out
all the other overhead -- useful, I guess, if you're dead-sure your link
is solid, and which would save space and communications time when the
programs consisted of lots of very short lines of code.


That sounds reasonable -- if the system sends a XOFF when it
reaches the end of a line, and an XON when that line has been digested,
that could work.

Hmm ... with a 68000 family CPU -- it theoretically *could*
handle a *lot* of memory (for the time and the task -- up to 16 MB.
(unless is a MC68008, which is limited to an 8-bit wide bus and to a 1
MB address space, IIRC.)

However, I could not make that work; at least it didn't appear to. Until
I build up a protocol analyser to watch what's being exchanged, I'm not
sure what protocol EZLink is actually using when I enter the bare "-" for
a filename, followed by the two "execute" depressions.


Yes -- analyzing it will give you more tools, at least.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
  #23   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 10,399
Default help with drip feeding R2E4

On Mon, 20 Dec 2010 20:02:26 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

Ignoramus30024 fired this volley in
m:

Then you would be right at home with EMC2!


If one of the vendors sells a kit version with EMC2, I'd be happier than
a pig in slop.

I'm NOT terribly happy with some of the inherent quirks in the BOSS9
control. I have an engraving project I've been fiddling with in the odd
half-hour of spare time for over two months. It just "e-stops" for no
visible reason; every time, at the same line of code. Nothing out of
range, no axis limits exceeded, nothing except in the FIST log a cryptic
"motion command that took too long..." (or some-sort; I don't have the
message handy now) and part of the message cuts off at the edge of the
field. But I cannot find anything it exceeds.

It's in a G03 block, and I run G3s and G2s all the time for cornering
blocks. I'll figure it out, and it'll probably be something like
(haven't explored this) the center of the arc being outside the "frame"
of the work area... It is prepping a very gentle curve when it fails.

LLoyd


One assumes you have tried other code totally different from that
particular line?

Gunner

Top 10 Democrat Party Slogans

10. Bitterly clinging to aborton and taxes
9. We didnt destroy your freedoms, you can
visit them at the Smithstonian
8. If you want us to listen to your opinion, move to Europ
7. Someday none of this will be yours
6. We can't tax terrorism, so who cares?
5. Please don't vote us out!! None of us can hold a real job!
4. Why the Founding Fathers limited Government:
Racism!
3. Reducing America's carbon footprint, one job at a time.
2. America: We just cant wait to see how it ends!!
1. Making everything in this country free, except you.
  #24   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

"DoN. Nichols" fired this volley in
:

e.g. the MC1488/MC1489 pair (I forget
which is the transmitter and which is the receiver, though I could
always look it up) to the CTS pin of the RS-232 connector


That's always been an easy one for me to remember.

"8" is binary 0x100. "9" is binary 0x101. The "8" value (1488) has an
"O" at the end; "O" for "Out". The "9" (1489) has an "I" at the end...
"I" for "In".

Just a mnemonic, but it stuck.

LLoyd
  #25   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

Gunner Asch fired this volley in
:

One assumes you have tried other code totally different from that
particular line?


I've tried a lot, but so far there's not a lot of continuity to my
trouble-shooting, for lack of time. "Ordinary" machining goes fine.
It's just these long-trajectory engraving curves giving me fits, and I'll
soon (after Jan 15th), get some real "sit down" time with the machine to
figure it out.

ON the subject of modifying the boards to accommodate hardware flow-
control: Why? If I'm going to start chopping things up, I'll just chop
it ALL out and retro-fit. I have the tools now to do drip-feed, and
wouldn't revert to a BTR, even if I had one. I was never keen on punched
tape, even when it was the fallback medium of choice. One of the first
things I ever did in the field was build a cassette tape system to
replace the paper IPL tapes for our Data General Nova 1200's on my first
"real" computer job.

My iron is in good shape, and a modern control would make this servo-
based system a great platform. In the meanwhile, it does nice work if I
just ignore (or work around) the ideosyncracies.

I have a potential customer coming on line that - if I win the contract -
will permit me the income and time to retro-fit. I'll do it, in that
case.

LLoyd


  #26   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 3,444
Default help with drip feeding R2E4

Lloyd E. Sponenburgh wrote:
"DoN. fired this volley in
:

e.g. the MC1488/MC1489 pair (I forget
which is the transmitter and which is the receiver, though I could
always look it up) to the CTS pin of the RS-232 connector


That's always been an easy one for me to remember.

"8" is binary 0x100. "9" is binary 0x101.


0x1000 and 0x1001, yes?

--Winston
  #27   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

Winston fired this volley in
:

0x1000 and 0x1001, yes?


yes... slipped a zero. The rest is true G

LLoyd
  #28   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 6,746
Default help with drip feeding R2E4


Ignoramus30024 wrote:

On 2010-12-21, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus30024 fired this volley in
:

Then you would be right at home with EMC2!


If one of the vendors sells a kit version with EMC2, I'd be happier than
a pig in slop.


Lloyd, is your machine servo motor based?

Do you know what your encoders are like?

I considered my mill a "kit", in the sense of coming with servo motors
mounted on it. I just had to add encoders, servo amps, control box
etc.

Also another kit-like element was Jon's PPMC controller.

The reason why I am glad that I did not go with a kit is two fold:

1) I know everything about how my mill functions
2) I can add stuff to it, like a rotary indexer, spindle encoder, 4th
axis, etc, as much as I want, and I am not limited by only three
connectors on a "kit".

Adding the rotary indexer took literally one evening. I thought for a
lot longer about it, as you know, but just doing it was borderline
trivial.

Adding a spindle encoder also took 2 months thinking and some aborted
attempts to make a shaft adaptor, but once I made one, it took only
one day (same day as I made the adaptor).

The 4th axis will be harder, due to resolver converter issues,

I greatly doubt that I could do any of this with a "kit".

Furthermore, I bought (for $2) a Saitek P880 joypad at a garage sale.

Wiring it in took a couple of hours, and that was this long only
because I was stupid. I just copied a config from some guy and did a
bad job at this, otherwise it would be one hour.

Now this joypad, is far superior in convenience to any jogging
controls that I have personally seen, which admittedly is not that
many. Could I do it with a kit? I am not too sure, Pete C may have
something to add about that.



From what I've seen there are a lot more turnkey type kits available for

Mach3, i.e. "Mach3 3 axis servo retrofit package for Bridgeport type
mills". With EMC2 there are various compatible modules available, but
few if any turnkey kits packaged with all the components for a common
retrofit.

What this means is that if you want to use EMC2 you have to do more
planning up front to determine the set of "modules" you'll need for the
conversion. You need to select interface cards, power supplies, servo
drives, servo motors, encoders, limit switches, etc. as appropriate for
the machine.

After the upfront planning, I don't think the time to perform the actual
retrofit and get up and running would be much different between the two
since you're doing the same physical work installing and wiring the
components.
  #29   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 6
Default help with drip feeding R2E4

On 2010-12-21, Pete C. wrote:

Ignoramus30024 wrote:

On 2010-12-21, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
Ignoramus30024 fired this volley in
:

Then you would be right at home with EMC2!

If one of the vendors sells a kit version with EMC2, I'd be happier than
a pig in slop.


Lloyd, is your machine servo motor based?

Do you know what your encoders are like?

I considered my mill a "kit", in the sense of coming with servo motors
mounted on it. I just had to add encoders, servo amps, control box
etc.

Also another kit-like element was Jon's PPMC controller.

The reason why I am glad that I did not go with a kit is two fold:

1) I know everything about how my mill functions
2) I can add stuff to it, like a rotary indexer, spindle encoder, 4th
axis, etc, as much as I want, and I am not limited by only three
connectors on a "kit".

Adding the rotary indexer took literally one evening. I thought for a
lot longer about it, as you know, but just doing it was borderline
trivial.

Adding a spindle encoder also took 2 months thinking and some aborted
attempts to make a shaft adaptor, but once I made one, it took only
one day (same day as I made the adaptor).

The 4th axis will be harder, due to resolver converter issues,

I greatly doubt that I could do any of this with a "kit".

Furthermore, I bought (for $2) a Saitek P880 joypad at a garage sale.

Wiring it in took a couple of hours, and that was this long only
because I was stupid. I just copied a config from some guy and did a
bad job at this, otherwise it would be one hour.

Now this joypad, is far superior in convenience to any jogging
controls that I have personally seen, which admittedly is not that
many. Could I do it with a kit? I am not too sure, Pete C may have
something to add about that.



From what I've seen there are a lot more turnkey type kits available for

Mach3, i.e. "Mach3 3 axis servo retrofit package for Bridgeport type
mills". With EMC2 there are various compatible modules available, but
few if any turnkey kits packaged with all the components for a common
retrofit.

What this means is that if you want to use EMC2 you have to do more
planning up front to determine the set of "modules" you'll need for the
conversion. You need to select interface cards, power supplies, servo
drives, servo motors, encoders, limit switches, etc. as appropriate for
the machine.

After the upfront planning, I don't think the time to perform the actual
retrofit and get up and running would be much different between the two
since you're doing the same physical work installing and wiring the
components.


The huge advantage of a kit is that things are pre-planned, pre-wired,
pre-configured etc. I almost bought a kit too.

The minus of a kit is that the kit company has the owner by the balls
and if something goes wrong, the owner is at the mercy of the company.

This applies even to things such as enhancements beyond the original
capability of the kit.

The other minus is that many kit companies are fly by night
operators.

i
  #30   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2,584
Default help with drip feeding R2E4

On 2010-12-21, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
"DoN. Nichols" fired this volley in
:

e.g. the MC1488/MC1489 pair (I forget
which is the transmitter and which is the receiver, though I could
always look it up) to the CTS pin of the RS-232 connector


That's always been an easy one for me to remember.

"8" is binary 0x100. "9" is binary 0x101. The "8" value (1488) has an
"O" at the end; "O" for "Out". The "9" (1489) has an "I" at the end...
"I" for "In".

Just a mnemonic, but it stuck.


Thanks! *That* one I can remember. (Now the question is how
many more times will I need to work with them? :-) I do still have some
on hand for repairs or hardware experimentation.

Thanks again,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---


  #31   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 2,584
Default help with drip feeding R2E4

On 2010-12-21, Gunner Asch wrote:
On Mon, 20 Dec 2010 20:02:26 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:


[ ... ]

[ ... ]

It's in a G03 block, and I run G3s and G2s all the time for cornering
blocks. I'll figure it out, and it'll probably be something like
(haven't explored this) the center of the arc being outside the "frame"
of the work area... It is prepping a very gentle curve when it fails.

LLoyd


One assumes you have tried other code totally different from that
particular line?


How large an angle is that swinging? I know that some machines
have G02 and G03 codes limited to 90 degrees swing at a time -- all in a
single quadrant. If you cross over a quadrant line, you'll need two
consecutive G02 or G03 instructions. Or three or four, depending on how
many quadrants you want to cut in.

I don't know what the limitations of the BOSS-9 were.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
  #32   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

"DoN. Nichols" fired this volley in
:

all in a
single quadrant. If you cross over a quadrant line, you'll need two
consecutive G02 or G03 instructions. Or three or four, depending on

how
many quadrants you want to cut in.

I don't know what the limitations of the BOSS-9 were.


Through the BOSS-6, all the G2/3 instructions were single quadrant.
G75/etc was reserved for multi-quadrant work.

However, although the BOSS9 has the G75 for backwards compatibility, it
can do _almost_ a 360-degree curve with G2/G3. It does, however, use
absolute arc centers, rather than incremental. I'm not even sure how to
make it honor incremental centers, although it _must_ if it's to be
compatible with the earlier BOSS controls. (It actually might be a board
jumper I haven't identified yet.)

LLoyd
  #33   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 1
Default help with drip feeding R2E4


Following your R2E3 link with great interest

I have a Bridgeport R2E3 with Boss 8 control, with great success I
have used Cadem NCNet Lite to flow programs to the machine under 12000
characters but have hit the limit when I started to use Mastercam
(they like to do things the long way ). I have Ezlink and cable to
port b , but from here I have not had results, I believe it may be a
small error I'm not doing (such as the "-" when loading in REM, that
took me a month to solve). Could you run thru the process from start
to finish, what buttons you push, files you name ,program numbers etc
you use. If it is easier , you can give me a phone number and I could
call you or skype. Any assistance to get me past this hurdle would be
very appreciated.

John Bennett Ottawa,Canada
  #35   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 4,632
Default help with drip feeding R2E4

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com fired this volley in
. 3.70:

Here it is, John. I hope this turns the trick.


Hmmmm! 'Makes it almost not worth the hour and a half to compile all
that information!

Not a peep! Three days of repeated requests from him for the info, both
here and on CNCZone... complied with on the first day. No response,
none. I took some time out of my day -- enjoyable time, but time I could
have been cutting metal.

An e-mail follow-up to him; his response... "I didn't get it." OK, I'll
RE-do it, because (my fault) I didn't save it, thinking he got it.
(because he DID read it... read-acknowleged). And I apologize for not
making sure I used a reliable medium G.

I spend another hour on the machine and computer making sure every detail
is nailed down. Write it up...(save it this time). Post it here. Email
that I have done it. Email is acknowleged (by RSVP again).

NADA! Not a freekin' peep.

It almost makes you want not to help (but I won't succumb; there are
worthies out there.)

LLoyd


  #36   Report Post  
Posted to rec.crafts.metalworking
external usenet poster
 
Posts: 1
Default help with drip feeding R2E4

replying to Lloyd E. Sponenburgh, R. White wrote:
Lloyd,

I have searched for weeks trying to find the info you posted above. Thank
you. Thank you
We have followed your directions to a "T", it seems we have a port config
error.. I will let my IT guy figure that out.
Now on to another question,
Your instructions were crystal clear in so much of a way that a novice to this
antique CNC could follow your directions.

Would you have the time to do the same for entering code into the machine,
manually from the console.
I can get one line in, but after that, I am failing miserably.
If that info I need to tell me the keystroke sequence, is in the manual, I
did not see it or recognize it for what it was.

I realize this is a long shot, and would completely understand you not
answering, but info is so scarce for this machine.

You can email me directly here at work.

Million thanks

Richard



--
for full context, visit http://www.polytechforum.com/metalwo...e4-483304-.htm


Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Single-Phase, at last! (r2e4) Lloyd E. Sponenburgh[_3_] Metalworking 49 May 21st 11 01:45 PM
Drip-drip-drip driving us mad Les Desser UK diy 4 April 23rd 08 10:14 AM
Drip drip drip noise from toilet miamicuse Home Repair 1 November 2nd 06 03:14 AM
Shower head leak - drip...drip...drip... miamicuse Home Repair 9 August 20th 05 02:02 AM
Delta faucet drip...drip...drip... orangetrader Home Repair 19 December 25th 04 10:55 PM


All times are GMT +1. The time now is 07:21 AM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 DIYbanter.
The comments are property of their posters.
 

About Us

"It's about DIY & home improvement"