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.
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
formatting link
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).
F. George McDuffee fired this volley in news: snipped-for-privacy@4ax.com:
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.
Ignoramus30138 fired this volley in news:78adnS6FgILEQJbQnZ2dnUVZ snipped-for-privacy@giganews.com:
heh! Ig, THAT I could do with about 30 blocks of g-code in one short macro and a couple of setup steps!
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.
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.
David E. Cloud fired this volley in news: snipped-for-privacy@4ax.com:
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.
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++.
David Billington fired this volley in news:4d0df4f0$0$2503$ snipped-for-privacy@news.zen.co.uk:
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.
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.
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
formatting link
. 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.
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.
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. :-)
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?
"DoN. Nichols" fired this volley in news: snipped-for-privacy@Katana.d-and-d.com:
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.
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".
David E. Cloud fired this volley in news: snipped-for-privacy@4ax.com:
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.
Ignoramus30024 fired this volley in news:V6CdneiRXcqZmI3QnZ2dnUVZ snipped-for-privacy@giganews.com:
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.
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?
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.