Home |
Search |
Today's Posts |
|
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 | Display Modes |
#1
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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 |
#34
Posted to rec.crafts.metalworking
|
|||
|
|||
help with drip feeding R2E4
JB fired this volley in news:7decee28-60ba-4ce4-85b2-
: Any assistance to get me past this hurdle would be very appreciated. 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 |
#35
Posted to rec.crafts.metalworking
|
|||
|
|||
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
Posted to rec.crafts.metalworking
|
|||
|
|||
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 |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Single-Phase, at last! (r2e4) | Metalworking | |||
Drip-drip-drip driving us mad | UK diy | |||
Drip drip drip noise from toilet | Home Repair | |||
Shower head leak - drip...drip...drip... | Home Repair | |||
Delta faucet drip...drip...drip... | Home Repair |