833
edits
Changes
Jump to navigation
Jump to search
Line 140:
Line 140: + + + + + + + + + + + + + + + +
→Reference
Because program memory in the TNC 151 is limited by length, complex jobs will probably need to be sent to the machine using a "drip feed" where the computer sequentially feeds G-code instructions to the TNC 151 which executes them directly without storing them in memory.
Because program memory in the TNC 151 is limited by length, complex jobs will probably need to be sent to the machine using a "drip feed" where the computer sequentially feeds G-code instructions to the TNC 151 which executes them directly without storing them in memory.
Due to line numbering requirements, it appears the TNC 151's upper limit for drip feeding is 65535 lines of G-code.
Serial parameters are 9600 baud 7-E-2. Ryan increased the baud rate after having problems with the machine keeping up at 2400 baud with CAM-generated files containing lots of short lines that can be executed quickly.
''' Aspire 8.0 '''
You must give the exported G-code file an exclusively numeric name. It has to end in .H and you probably can't rename the file without editing it because the file number must be embedded in the G-code. This is required so TNCserver can located the program.
When configured for inches, Heidenhain feed rates are in .1 in/min! So <code>N100 G01 X+1.5 F500</code> is a 50 inch/minute feed. The Aspire post-processor language includes a scaling feature so this will work without needing to give Aspire an incorrect feed rate.
The default post-processor did not do rapids. In that case, Aspire simulates a rapid as a linear move at 2x the normal cutting feed rate. No obvious config setting or way to impose a maximum limit exists. So if you have a 300 in/min feed (F3000), your next "rapid" will be F6000. The TNC 151 is configured to reject feeds in excess of F5000 so this cannot be executed. Modifying the post-processor to do rapids with <code>G00</code> fixes this, as Aspire no longer generates these 2x problematic "rapids."
Arcs do not work. They give the error: CIRCLE END POS. INCORRECT Some math seems to show that Aspire has an error greater than 0.006" with the end points and/or center.
Because the Interact Series 1 uses tool holders, not collets, you are supposed to mount each tool in its own holder (which hopefully fixes its length relative to the spindle). You mount your longest tool, touch off the workpiece, call that point Z=0, and designate its tool offset as 0. Then you mount each tool in turn, touch off the workpiece, and store the different Z value (which will be negative) as the tool offset of each other tool. You can define tool offsets in G-code, but Aspire doesn't seem to have that concept. Ryan changed machine parameter 225 to define 25 slots in a central tool table. This is a special Program 0, where you manually key in all your tool offsets and radius values (but that generally isn't used for CAM-generated G-code.) So if T=1 is my zero tool, a cut to Z-0.5 will move the spindle to Z-0.5 and cut a half inch into the workpiece. But if I change to tool T=2 which has a L-1.0 offset, a cut in G-code to Z-0.5 will move the spindle to T-1.5, but since the tool is 1 inch shorter, it will cut a half inch into the workpiece. But it is critical now to check the global tool table before running a job!
''' Emulator '''
''' Emulator '''