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"

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 2010-12-21, Lloyd E. Sponenburgh <lloydspinsidemindspring.com> wrote:

Then you would be right at home with EMC2!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 2010-12-21, Lloyd E. Sponenburgh <lloydspinsidemindspring.com> wrote:

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.

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus30024 wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

    [ ... ]
    [ ... ]

    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: < snipped-for-privacy@d-and-d.com> | Voice (all times): (703) 938-4564
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

how
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

John, I sent you a long and detailed message yesterday on CNCzone, which I failed to CC to myself.
IF you got it, please forward it back to me so that I may re-post it here. Otherwise, I will re-compile it (which took a bit to get all the details right), and I'll stop using CNCZone for PMs which seem to get lost.
LLoyd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Here it is, John. I hope this turns the trick.
-------------------------------------------------
Drip-Feeding a BOSS-8,9 Bridgeport Mill.
First of all, my machine is a BOSS-9 R2E4, so there may be differences between how mine and an R2E3 BOSS-8 machine works. However, I have an operator's manual for the Series I R2E3 with the BOSS-8, and except for some display differences, it seems pretty much the same.
I have successfully drip-fed programs as large as several hundred K worth of g-code without error on my machine. My configuration is:
-BOSS-9 R2E4 (ca. 1986)
-Dell Laptop (Precision M4300) running Windows XP with a _hardware_ RS232 port (this may be important, I have not used a USB "dongle" to experiment with, yet.
-Original (DOS) Bridgeport EZLink software. There is no version reported. I've even looked it over in a hex editor, and the only date- specific thing I've found is that it was assembled around a 1987 version of the Microsoft run-time libraries. The specific file to use is "LDEZLINK.EXE".
(some of the following is not "drip-feed specific", but worth reviewing.
-I use a g-code file produce by CAMBAM (pretty much any CAM software will work, I guess, but CAMBAM suits my needs, and has a post-processor that is adaptable to make the R2E4 behave. I was using G-Simple, but there simply is no comparison in how easy or well it works.
Points about the g-code: 1) no matter what else, the DNC files must have line-end terminations of LF/CR, which is exactly backwards from what ordinary text files have (CR/LF) and also opposite what you can upload to the machine for a "remote load" program (don't ask why). If your post-processor doesn't allow you to specify the line-end sequence, you'll have to edit the file with a hex editor like XVI32 in order to alter what your CAM system gives into the LF/CR sequence. I can't coach you on the specifics, because without a sense of what hex codes are and how they look when editing a raw hex file you're going to have to develop some skills. You may already have them, though.
2) the BOSS9 _hates_ the G98 code; dunno why, because it ignores other invalid codes. Delete them entirely from your g-code.
3) the BOSS9 wants G2/G3 codes to be "center absolute" when in G90 (absolute) mode. I have not used it in G91 (relative) mode; don't intend to.
4) the BOSS9 expects ALL drilling and peck target depth and peck increments to be UNSIGNED distances relative to the stock surface. Negative values have weird results, even though -Z is the direction in which you drill.
5) a file destined for drip-feeding must begin with the "%" character alone on the first line, and end with a "%" alone on the last line.
OK... you have all the parts together, and you have a g-code file longer than 12K you'd like to upload. Remember that drip-feeding will give unexpected results on files short enough to fit in memory.
I have 10-meter RS232 cables, and have no problems with 4800 baud. If you have any lack of reliability, you may want to drop everything to 2400 baud. It makes a little difference in overall machining speed.
Set the "B" port on the Bridgeport to 4800,8,1,No Parity, No flow control... same for your RS232 port on your computer. Do this on the computer with the hardware manager so that EZLink doesn't have to fool with the settings -- it doesn't do it properly. Remember that, unlike the "upload to remote", DNC handles flow control within the DNC protocol, so any flow control feature you add to the port will introduce stray, unwanted characters into the data stream.
OK... ready to DNC (Direct Numeric Control) a program on the mill:
Before doing anything else, open a DOS window with "Run" and "CMD". Change directories to the EZLink directory.
I find it easiest to put the EZLink directory in the C:\ (root directory), since it's easy to "CD" to. Also, you should save a copy of the g-code file in that directory under the name "mygcode.txt" (or any other name you choose, with the .txt filetype). Start up EZLink by entering "LDEZLINK" at the command line. You should see EZLink fire up, and present you with a bordered black screen with function key definitions at the top.
Select "F1" to enter the filename. Use the directory name in which you stored the g-code file, and for the filename, give it the name you saved under the .txt filetype. When presented with a selection of "remote Load" or "DNC Link"; select "DNC Link".
On the Mill: 1) reset, enable axis drives, and home the machine.
2) Using the Load/Clear/Edit "clear" function, clear the RUN buffer ("0") and the PROGRAM buffer ("1" then "0" for "all").
3) Press RESET PROGRAM, and the program display should show empty ("[EOT]")
4) select LOAD "1" for DNC. The display will report "Setup Load DNC:"
5) enter a "-" followed by "execute". This tells DNC that DNC will supply the program name IF the program contains one. If not, the program will not have a name (which is OK, since it's not stored).
6) the display should now read "Setup Loading:-" and should report "DNC Off"
7) press "execute" once more. The display should now show "Setup Loading:-" and "DNC Link"
now move to your PC
8) The display on EZLink should now say "Filename: c:\yourdir \yourgcode.txt" and "Mode = DNC-Link"
9) press the "F3" key. The display should report "ready". IF you have established an RS232 link with the Mill, it will shortly report "Working". This says it has established control via the DNC protocol, and is actively "talking" to the mill.
    If EZLink doesn't report "working", you have a communications error or no connection at all with the mill. Go back and troubleshoot your settings and connections. If you are able to remote-load programs with the mill and an Xmodem program, then the only thing that should change is the port settings for the "B" port, which must be 4800(or2400)8,1,N,none.
10) when the screen shows "working", return to the mill
11) Nothing will have changed on the display. However, prior to establishing the connection, nothing on the keyboard will have any effect except the Load/Clear/Edit function, which will ABORT the link.
AFTER "working" has been reported, pressing the AUTO key should allow you to select whether you wish to execute the program in automatic or single-block mode. Set it as you wish.
12) Once the execution mode is set, you may press "start" to begin cutting air or metal as your sense of risk permits! <G>
I hope this helps. I'm pretty sure there will be differences between my BOSS-9 and your 8.1, but maybe not many.
LLoyd
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Lloyd E. Sponenburgh" <lloydspinsidemindspring.com> fired this volley in

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.