[Chris64]

Here's a sample...I created a basic sharp shape with a 1/2 outside contour.

The minimum G-code output:

N0000 G20
N0010 M6 T0
N0020 G00 Z0.0000
N0030 M04
N0040 G00 X0.4070 Y0.3875
N0050 G01 X2.0679 Y0.2491 F100 S1000
N0060 G02 X2.0471 Y-0.2500 I-0.0208 J-0.2491
N0070 G01 X-0.0000
N0080 G02 X-0.2500 Y0.0000 I0.0000 J0.2500
N0090 G01 Y0.6241
N0100 G02 X0.2212 Y0.7406 I0.2500 J0.0000
N0110 G01 X0.4070 Y0.3875
N0120 M05
N0130 G00
N0140 M05
N0150 M30

And Here's the Bandit Output:

N001&
G90
F100.
/Z0.000
M04
/X4.070 /Y3.875
X20.679Y2.491Z0.000
X22.971Y0.000/X20.471/Y0.000
X20.471Y-2.500/X20.471/Y0.000
X-0.000Y-2.500
X-2.500Y0.000/X-0.000/Y0.000
X-2.500Y6.241
X-0.000Y8.741/X-0.000/Y6.241
X2.212Y7.406/X-0.000/Y6.241
X4.070Y3.875
M05
M2

I haven't verified this particular file, but all my other tests worked good.

Note: I'm multiplying Scale x10 to make up for problem mentioned earlier.

[HuFlungDung]

Good work!

I'm not sure whether that feedrate problem that you mentioned also might be affected by the resolution setting of the system. I believe I used to be able to program feeds to the nearest 1/10th inch without getting an error.

What communications software are you using? I don't think you can type an ASCII 19 into your program, rather, your comm program will have to have the wherewithall to send that character at the end of the program.

[HuFlungDung]

BTW, you might experience rounding errors from the arc calculations if the number format does not take care of rounding off. I mention this in case you are left scratching your head sometimes. At that point, it is a good thing to understand how to read gcode and calculate arc centers, because you may have to tweak the arc center by 1 unit of resolution, this way or that, to get past an alarm.

[Chris64]

BTW, you might experience rounding errors from the arc calculations if the number format does not take care of rounding off. I mention this in case you are left scratching your head sometimes. At that point, it is a good thing to understand how to read gcode and calculate arc centers, because you may have to tweak the arc center by 1 unit of resolution, this way or that, to get past an alarm.

It should be OK...It should be at least within 1/1000 accuracy which is it's main requirement.

Thanks for the other suggestions...I'll have to look into hyper terminal to see if it will do that.

[Chris64]

80 pounds!! Sheesh...i thought it was $80 US. Oh well.

Is there a way for the modal values to associate a Z command and a /Z as the same command? Non of my Z's are working because they all rapid up to zero and non-rapid down to 1". So basically the first rapid up and the first normal down appear and no others.

[HuFlungDung]

I don't see any Z-1. command in your code sample, so maybe that is why you are not seeing any output.

When programming in absolute, Z rapid moves can be modal, because any command to the same Z, whether rapid or feedrate, will be to the same position and is harmless to omit one command or the other.

I just realized if you get around to programming in incremental, then you would want to turn modal numbers off completely.

[Chris64]

No, I'm programming in absolute (which seems nice - except it resets to incremental with every reset). The samples I put up there are a little old (already).

The modalnumber function has a key & a value. If that value is the same for that key then it won't redisplay it.

What's happening is I'm actually trying to do this:

/Z1.
(move)
Z-1.
(cut stuff)
/Z1.
(move)
Z-1.
(cut stuff)
etc..

but only the first two Z & /Z are appearing because each following Z is considered an already completed move by that key. It doesn't know that Z and /Z are the same axis basically.

What I did to fix it for now is remove rapid Z. It takes longer but it works.

Now...if I can come full circle. I'm having communication problems with my CNC. I've never had programs this long before. I can see invalid characters appearing in the transmission (maybe 1 character every 3-4 pages). So it's randomly screwing up my program. They're usually popping up around line 450 but some have made it all the way to 600 and some at 100...same program (grrrr.)

Anyhoo, here's how I'm connecting...any thoughts?

1200 baud
7 data bits
even Parity
1 stop bit
Hardware flow control

It's always worked OK before. I'm on a new laptop so I'm going to go get my old one and try that too.

[locost_cam]

To keep rapid and feed Z moves synchronised do this:

rapid:
text("/")
modalnumber("Z",endz,"0.0")

move at feed:
modalnumber("Z",endz,"0.0")


Is your serial cable wired for hardware flow control? If not you could get strange things happening if the Bandit pauses to process incoming data.

[Chris64]

To keep rapid and feed Z moves synchronised do this:

rapid:
text("/")
modalnumber("Z",endz,"0.0")

move at feed:
modalnumber("Z",endz,"0.0")


Is your serial cable wired for hardware flow control? If not you could get strange things happening if the Bandit pauses to process incoming data.

I tried that - but then it would output "/" without the Z occasionally. I can't confirm if this would cause problems with the Bandit, but I suspect it would. Infact - it might make the next command become a rapid feed.

Your instincts on the serial were good. At least I think. I tried putting a 50 ms delay between sends and it took it ok. So I guess my new laptop is just too fast.

Anyway - It still had a few random tabs but the program made it in successfully. I'm still having a problem with it terminating after upload. I thought this used to resolved with the ASCII 19, but now I'm not so sure because even if I had it in there it would still terminate after upload.

[HuFlungDung]

I wonder how many instances of the rapid Z move would you get if you did not use the 'modalnumber' function for the Z rapid moves?

[locost_cam]

I tried that - but then it would output "/" without the Z occasionally. I can't confirm if this would cause problems with the Bandit, but I suspect it would. Infact - it might make the next command become a rapid feed.

Oops, I should have thought of that. Use nonmodalnumber for the rapids. It does mean that the Z will always be output but it will track the Z for feed rate moves.

[Chris64]

Just to give an update - The Bandit Post processor appears to be working great.

Now for the bad news...It appears I have some type of glitch. about half the time I send the program to the controller it has an error that crashes execution on the CNC. It's usually around line 400-500. Here's the strange thing - it's a valid entry. It's as if the commands stored in the controller aren't as they appear. One time, I re-entered the command manually and it worked (so it just didn't receive things quite right). I verified the math on the commands (they are correct) so I'm tempted to think it's maybe a memory problem with the bandit...but it's not always the same line number. Also it's always with arcs...but the math on the arcs is correct (I calculated the distance from arc center to start and to finish and the difference between the two are well within the .0001 requirement). Also I put a huge delay (200ms) in between each line to be sure that it wasn't running too fast for the controller but it didn't help.

I know this doesn't really have anything to do with this original topic...I'm just sort of complaining in the hopes that someone can suggest something I didn't think of.

A conversion may be in my future after all (darn!)