Chris64

08-20-2007, 12:08 AM

Does anyone know if it's possible to edit the output parameters (or download an add-on) so that it could output to a Bandit controller?

View Full Version : Output to a Bandit?

Chris64

08-20-2007, 12:08 AM

Does anyone know if it's possible to edit the output parameters (or download an add-on) so that it could output to a Bandit controller?

locost_cam

08-21-2007, 11:54 AM

If you send me some samples of code and if possible a copy of the relevant pages of the manual I can write you a post processor.

Send the details to sales {at} sheetcam.com (replace the {at} with @).

Les

Send the details to sales {at} sheetcam.com (replace the {at} with @).

Les

HuFlungDung

08-21-2007, 01:21 PM

Locost,

Some of the differences between Bandit and ISO code:

1) feed moves: G01 is not used. Just strip that out and any axis address will be considered to be a feed move.

2) rapid moves: G00 is not used. / (forward slash) must be prefixed to the front of each axis address within a rapid command, for example /X /Y /Z. The Bandit is capable of 3 axis motion and of course, no mixing of rapid and feedrate moves is possible on one line.

3) arc movements: maximum movement per command would span 90 degrees within one quadrant. G02 and G03 are not used (not in the normal cam usage anyways). You can simply strip G02 and G03 out, and replace I with /X and J with /Y. So arc movements look like: X Y /X /Y

Arc centers must be absolute coordinates if programming in G90 mode, incremental if in G91 mode. Bandit recognizes the above format as an arc command, even though it contains a mixture of what appears to be feed and rapid movement commands.

4) Feedrate commands must be on a line alone. The feedrate must be altered prior to the feed move.

5) Mcodes must be on a line alone.

6) Because of extreme memory size limitation in Bandit, axis movements are kept modal as much as possible.

Drill cycles: very different, I don't know if you want to go there ;)

Some of the differences between Bandit and ISO code:

1) feed moves: G01 is not used. Just strip that out and any axis address will be considered to be a feed move.

2) rapid moves: G00 is not used. / (forward slash) must be prefixed to the front of each axis address within a rapid command, for example /X /Y /Z. The Bandit is capable of 3 axis motion and of course, no mixing of rapid and feedrate moves is possible on one line.

3) arc movements: maximum movement per command would span 90 degrees within one quadrant. G02 and G03 are not used (not in the normal cam usage anyways). You can simply strip G02 and G03 out, and replace I with /X and J with /Y. So arc movements look like: X Y /X /Y

Arc centers must be absolute coordinates if programming in G90 mode, incremental if in G91 mode. Bandit recognizes the above format as an arc command, even though it contains a mixture of what appears to be feed and rapid movement commands.

4) Feedrate commands must be on a line alone. The feedrate must be altered prior to the feed move.

5) Mcodes must be on a line alone.

6) Because of extreme memory size limitation in Bandit, axis movements are kept modal as much as possible.

Drill cycles: very different, I don't know if you want to go there ;)

billystein

08-21-2007, 01:30 PM

"The Bandit is capable of 3 axis motion and of course, no mixing of rapid and feedrate moves is possible on one line."

i believe that the bandit 1 and 2 could only move 2 axis at a time.

does anyone know where i can get a input plug for bandit.

i believe that the bandit 1 and 2 could only move 2 axis at a time.

does anyone know where i can get a input plug for bandit.

HuFlungDung

08-21-2007, 01:50 PM

There were some very early firmware that were not 3 axis capable, but from 1M on up to 3M, 3 axis linear and 2 axis circular were standard. 3 axis rapids always retracted the Z axis first then moved X and/or Y but the controller would accept the three axis rapid command, AFAIK. Chris will know what his machine can do, I guess :D

Edit: I guess the instances of a 3 axis rapid movement command would be almost nil in programming. I was thinking primarily of how the machine moved with a G98 command, which is as I described.

Edit: I guess the instances of a 3 axis rapid movement command would be almost nil in programming. I was thinking primarily of how the machine moved with a G98 command, which is as I described.

locost_cam

08-21-2007, 03:53 PM

Most of those are not a problem but I'll have to think on the arcs. SheetCam's arcs can be up to 360 degrees (a circle). I'll have to try to work out a way of breaking the arcs into quadrants in the post...

Thanks,

Les

Thanks,

Les

Chris64

08-23-2007, 01:04 PM

Where to start?

Locost: I started modifying the generic post file for my own Bandit conversion...pretty straight forward. (I would post it here, but it's at home and I'm not).

* Only use line number on the first line - no problem

* Remove the g codes for straight line movements.

* I added some other static header stuff - can't remember off the top of my head

* Changed rapid moves from IJK to /X/Y/Z

* footer need some strange character, I think ASCII 19 (?)

Plus I noticed lines were getting put in with no data - for example to move X 0.0000. I found that these were just values >0 but less than 0.0000 (like 0.00005 for example). Since memory is a premium, I put in logic to not put these in.

My big obstacle was exactly what HuFlung spoke of, arcs and seperating the quadrants. G02 and G03 on Bandit are for 90 degree arcs only (I'm pretty sure).

I'm not sure exactly what language the post files are written in but I was beating my head against the wall trying to use "and" and "or" and "<>" in the if statements...of course trying all the common ones like "&&" and "!=". I ended up just relying on the else statement and only use "=".

Needless to say, when it came down to me needing to calculate quadrant separation, I took a break.

It will move in 3 axis at once. Rapid 3 axis do, like Hu said move the Z into position first if it's up, and last if it's down (if memory serves - I toyed with it but I always just separate them in the code so there isn't any question - Like move XY rapid, now lower Z rapid)...and same memory useage.

I have rev 2. I haven't been able to get to move in an XY arc while moving in a Z (although I thought I did this once upon a time with a G code - but haven't been able to do it since). I believe rev 3 can do this.

The only other thing that was a little limiting for me with Sheetcam was inability to utilize subroutines. I'm not faulting it...I'm trying to make it work with a fossile...it's just limiting. Right now (for space), I write a subroutine for the pocket or contour. Then I set the Z and call the routine. Sheetcam will recode the entire contour for each step of the Z. This is prohibitve for me since it only can handle 1000 "entries" or about 500 lines of code (average).

That said, I could us it just to generate the XY code then cut and paste that into another program. That would still be a huge help over writing it all manually.

Thanks everyone for contributing to this topic...I'll post the code I've written so far tonight.

Locost: I started modifying the generic post file for my own Bandit conversion...pretty straight forward. (I would post it here, but it's at home and I'm not).

* Only use line number on the first line - no problem

* Remove the g codes for straight line movements.

* I added some other static header stuff - can't remember off the top of my head

* Changed rapid moves from IJK to /X/Y/Z

* footer need some strange character, I think ASCII 19 (?)

Plus I noticed lines were getting put in with no data - for example to move X 0.0000. I found that these were just values >0 but less than 0.0000 (like 0.00005 for example). Since memory is a premium, I put in logic to not put these in.

My big obstacle was exactly what HuFlung spoke of, arcs and seperating the quadrants. G02 and G03 on Bandit are for 90 degree arcs only (I'm pretty sure).

I'm not sure exactly what language the post files are written in but I was beating my head against the wall trying to use "and" and "or" and "<>" in the if statements...of course trying all the common ones like "&&" and "!=". I ended up just relying on the else statement and only use "=".

Needless to say, when it came down to me needing to calculate quadrant separation, I took a break.

It will move in 3 axis at once. Rapid 3 axis do, like Hu said move the Z into position first if it's up, and last if it's down (if memory serves - I toyed with it but I always just separate them in the code so there isn't any question - Like move XY rapid, now lower Z rapid)...and same memory useage.

I have rev 2. I haven't been able to get to move in an XY arc while moving in a Z (although I thought I did this once upon a time with a G code - but haven't been able to do it since). I believe rev 3 can do this.

The only other thing that was a little limiting for me with Sheetcam was inability to utilize subroutines. I'm not faulting it...I'm trying to make it work with a fossile...it's just limiting. Right now (for space), I write a subroutine for the pocket or contour. Then I set the Z and call the routine. Sheetcam will recode the entire contour for each step of the Z. This is prohibitve for me since it only can handle 1000 "entries" or about 500 lines of code (average).

That said, I could us it just to generate the XY code then cut and paste that into another program. That would still be a huge help over writing it all manually.

Thanks everyone for contributing to this topic...I'll post the code I've written so far tonight.

HuFlungDung

08-23-2007, 02:46 PM

Breaking arcs into quadrants is an interesting problem, I've never given it a second thought before, just exactly how this might be done logically.

I suppose the arc end point, as well as the arc center can be pulled immediately from cad data. So the end point of the full arc is easy to derive.

The pattern of quadrant arc programming would be such that one axis or the other occupies a position identical to the corresponding arc center coordinate, at every quadrant. (The complementary axis lies at a distance of the arc radius added to the corresponding arc center coordinate).

Given the above rule, for every 360 degree circle, I suppose you could immediately spit out 4 quadrant arc commands quite easily by filling in a simple matrix table, minimal calculations actually required.

Then for the partial (or remaining) arcs, you would need a truth table of some sort, to find out which combinations from the matrix table to discard.

I dunno, I'd be interested to hear the actual method...its got to be faster than running a whole wack of heavy duty equations, or toolpathing could be super slow :)

I suppose the arc end point, as well as the arc center can be pulled immediately from cad data. So the end point of the full arc is easy to derive.

The pattern of quadrant arc programming would be such that one axis or the other occupies a position identical to the corresponding arc center coordinate, at every quadrant. (The complementary axis lies at a distance of the arc radius added to the corresponding arc center coordinate).

Given the above rule, for every 360 degree circle, I suppose you could immediately spit out 4 quadrant arc commands quite easily by filling in a simple matrix table, minimal calculations actually required.

Then for the partial (or remaining) arcs, you would need a truth table of some sort, to find out which combinations from the matrix table to discard.

I dunno, I'd be interested to hear the actual method...its got to be faster than running a whole wack of heavy duty equations, or toolpathing could be super slow :)

Chris64

08-23-2007, 04:35 PM

It would be tricky.

Logically it seems - first look at g2/g3 to figure out CW or CCW.

Let's say CW from -15,-15 to +15,+15 with center of 0,0 (180 degree's).

The first thing to figure out is the distance to center. 21.2 in this case.

Given that it's CW, starting in quadrant X, our next quadrant would be up (again, in this case). so it would be +15 on Y, then over 21.2 from center. That would be the first arc. Then repeat for the next quadrant.

Programmatically, it seems like it would have to repeat this type of functionality. 4 static quadrants, and logic that knows which quadrant is next based on CW or CCW. This way you could move theoretically 359 degree's to the same quadrant you started in no problem.

It could probably be done with angles, but I think this would be quicker and less prone to math flaws (I get those quite a bit).

If I knew a little bit more about the syntax in those post files I'd feel a little better about this one.

Logically it seems - first look at g2/g3 to figure out CW or CCW.

Let's say CW from -15,-15 to +15,+15 with center of 0,0 (180 degree's).

The first thing to figure out is the distance to center. 21.2 in this case.

Given that it's CW, starting in quadrant X, our next quadrant would be up (again, in this case). so it would be +15 on Y, then over 21.2 from center. That would be the first arc. Then repeat for the next quadrant.

Programmatically, it seems like it would have to repeat this type of functionality. 4 static quadrants, and logic that knows which quadrant is next based on CW or CCW. This way you could move theoretically 359 degree's to the same quadrant you started in no problem.

It could probably be done with angles, but I think this would be quicker and less prone to math flaws (I get those quite a bit).

If I knew a little bit more about the syntax in those post files I'd feel a little better about this one.

locost_cam

08-23-2007, 05:10 PM

Posts are written in Lua www.lua.org. They have an on-line manual but it can be hard going at times. The wiki is quite handy though. In the posts directory is a file called post processor.rtf. This documents the SheetCam extensions to Lua. And is and, not equal is ~=.

It would be best to work with angles. SheetCam already supplies the arc angle (+ve for clockwise, -ve for CCW). Angles never exceed 360 degrees. You can use the math.hypot function to calculate the radius from the start position and centre. You can then use the math.sin and math.cos functions to calculate the new X,Y coordinates. The tricky bit is actually working out how to split the angles.

The only other thing that was a little limiting for me with Sheetcam was inability to utilize subroutines.

There lies a big can of worms. SheetCam will probably never use subs for multiple passes. I am considering using subs for nesting (step and repeat). However it complicates things quite a lot because at the moment the file is created sequentially. This means you can't refer to line numbers ahead because you don't know what they will be...

It would be best to work with angles. SheetCam already supplies the arc angle (+ve for clockwise, -ve for CCW). Angles never exceed 360 degrees. You can use the math.hypot function to calculate the radius from the start position and centre. You can then use the math.sin and math.cos functions to calculate the new X,Y coordinates. The tricky bit is actually working out how to split the angles.

The only other thing that was a little limiting for me with Sheetcam was inability to utilize subroutines.

There lies a big can of worms. SheetCam will probably never use subs for multiple passes. I am considering using subs for nesting (step and repeat). However it complicates things quite a lot because at the moment the file is created sequentially. This means you can't refer to line numbers ahead because you don't know what they will be...

Chris64

08-25-2007, 12:25 AM

OK...I've put together the basics of what should work for the arc. It's ugly as this isn't my language of choice and I'm simply not familiar with it.

But, I am having a weird problem. The modalnumber function in particular. I'm not sure if this is a custom function within Sheetcam but it seems to be selectively not displaying anything (no real reason that I can see).

but here's the arc portion of the post file:

function arc()

--Here is where we need to break an arc into quadrants

--arccenterx & y is it's physical location

--I'm not allowing Z arcs since my machine can't do it

--

--Quadrants 1(X+Y+),2(X+Y-),3(X-Y-),4(X-Y+)

arc_currentx = arccentrex - currentx

arc_currenty = arccentrey - currenty

arc_endx = arccentrex - endx

arc_endy = arccentrey - endy

arc_distancetocenter = math.sqrt((arc_currentx * arc_currentx) + (arc_currenty * arc_currenty))

-- text (arc_distancetocenter )

current_quadrant = ""

finish_quadrant = ""

if (arc_currentx >= 0 and arc_currenty >= 0) then

current_quadrant = "1"; end

if (arc_currentx >= 0 and arc_currenty <= 0) then

current_quadrant = "2"; end

if (arc_currentx <= 0 and arc_currenty <= 0) then

current_quadrant = "3"; end

if (arc_currentx <= 0 and arc_currenty >= 0) then

current_quadrant = "4"; end

if (arc_endx >= 0 and arc_endy >= 0) then

finish_quadrant = "1"; end

if (arc_endx >= 0 and arc_endy <= 0) then

finish_quadrant = "2"; end

if (arc_endx <= 0 and arc_endy <= 0) then

finish_quadrant = "3"; end

if (arc_endx <= 0 and arc_endy >= 0) then

finish_quadrant = "4"; end

text("quad1: ")

text(current_quadrant)

text(" quad2: ")

text(finish_quadrant)

text("\n")

if (current_quadrant == finish_quadrant) then

--if the move starts and ends in the same quadrant

text("**same quadrant ")

modalnumber (" X", endx * scale, "0.0000")

modalnumber (" y", endy * scale, "0.0000")

modalnumber (" /X", (arccentrex - currentx) * scale, "0.0000")

modalnumber (" /y", (arccentrey - currenty) * scale, "0.0000")

text("\n")

else

while (current_quadrant ~= finish_quadrant) do

--finish point is not in the current quadrant

currentx = 0

currenty = 0

if(arcangle <0) then

if (current_quadrant == "1") then

new_current_quadrant = "4"

currentx = -arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "1"

currentx = arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "2"

currentx = arc_distancetocenter

currenty = -arc_distancetocenter

end

if (current_quadrant == "4") then

new_current_quadrant = "3"

currentx = -arc_distancetocenter

currenty = -arc_distancetocenter

end

current_quadrant = new_current_quadrant

text (" CCW ")

else

if (current_quadrant == "4") then

new_current_quadrant = "1"

currentx = arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "4"

currentx = -arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "3"

currentx = -arc_distancetocenter

currenty = -arc_distancetocenter

end

if (current_quadrant == "1") then

new_current_quadrant = "2"

currentx = arc_distancetocenter

currenty = -arc_distancetocenter

end

current_quadrant = new_current_quadrant

text "cw"

end

text ("Step Arc: ")

text (current_quadrant)

modalnumber ("# X", currentx * scale, "0.0000")

modalnumber ("# y", currenty * scale, "0.0000")

modalnumber ("# /X", (arccentrex - currentx) * scale, "0.0000")

modalnumber ("# /y", (arccentrey - currenty) * scale, "0.0000")

text ("\n")

end

--we have moved into the finish quadrant

text("**exit quadrant ")

modalnumber ("$ X", endx * scale, "0.000")

modalnumber ("$ y", endy * scale, "0.000")

modalnumber ("$ /X", (arccentrex - currentx) * scale, "0.000")

modalnumber ("$ /y", (arccentrey - currenty) * scale, "0.000")

text("\n")

end

eol()

end

Note - the values are still a messed up hybrid of relative and absolute...ignore that for now. Also I have some random characters infront of arcs...this is just to verify the results I'm getting are firing the right lines.

The problem I'm having with the output is this:

**same quadrant X2.3966 y-0.0675 /X-0.0675 /y0.0000

X0.0000 Y-0.0675

quad1: 4 quad2: 2

cwStep Arc: 1# X0.0675# y0.0675# /X-0.0675# /y-0.0675

cwStep Arc: 2# y-0.0675# /y0.0675

**exit quadrant $ X-0.067$ y0.000$ /X-0.068$ /y0.068

X-0.0675 Y1.8474

the bolded line is an example of the data simply not showing the results. No X value or /X although there does appear to be data there.

But, I am having a weird problem. The modalnumber function in particular. I'm not sure if this is a custom function within Sheetcam but it seems to be selectively not displaying anything (no real reason that I can see).

but here's the arc portion of the post file:

function arc()

--Here is where we need to break an arc into quadrants

--arccenterx & y is it's physical location

--I'm not allowing Z arcs since my machine can't do it

--

--Quadrants 1(X+Y+),2(X+Y-),3(X-Y-),4(X-Y+)

arc_currentx = arccentrex - currentx

arc_currenty = arccentrey - currenty

arc_endx = arccentrex - endx

arc_endy = arccentrey - endy

arc_distancetocenter = math.sqrt((arc_currentx * arc_currentx) + (arc_currenty * arc_currenty))

-- text (arc_distancetocenter )

current_quadrant = ""

finish_quadrant = ""

if (arc_currentx >= 0 and arc_currenty >= 0) then

current_quadrant = "1"; end

if (arc_currentx >= 0 and arc_currenty <= 0) then

current_quadrant = "2"; end

if (arc_currentx <= 0 and arc_currenty <= 0) then

current_quadrant = "3"; end

if (arc_currentx <= 0 and arc_currenty >= 0) then

current_quadrant = "4"; end

if (arc_endx >= 0 and arc_endy >= 0) then

finish_quadrant = "1"; end

if (arc_endx >= 0 and arc_endy <= 0) then

finish_quadrant = "2"; end

if (arc_endx <= 0 and arc_endy <= 0) then

finish_quadrant = "3"; end

if (arc_endx <= 0 and arc_endy >= 0) then

finish_quadrant = "4"; end

text("quad1: ")

text(current_quadrant)

text(" quad2: ")

text(finish_quadrant)

text("\n")

if (current_quadrant == finish_quadrant) then

--if the move starts and ends in the same quadrant

text("**same quadrant ")

modalnumber (" X", endx * scale, "0.0000")

modalnumber (" y", endy * scale, "0.0000")

modalnumber (" /X", (arccentrex - currentx) * scale, "0.0000")

modalnumber (" /y", (arccentrey - currenty) * scale, "0.0000")

text("\n")

else

while (current_quadrant ~= finish_quadrant) do

--finish point is not in the current quadrant

currentx = 0

currenty = 0

if(arcangle <0) then

if (current_quadrant == "1") then

new_current_quadrant = "4"

currentx = -arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "1"

currentx = arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "2"

currentx = arc_distancetocenter

currenty = -arc_distancetocenter

end

if (current_quadrant == "4") then

new_current_quadrant = "3"

currentx = -arc_distancetocenter

currenty = -arc_distancetocenter

end

current_quadrant = new_current_quadrant

text (" CCW ")

else

if (current_quadrant == "4") then

new_current_quadrant = "1"

currentx = arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "4"

currentx = -arc_distancetocenter

currenty = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "3"

currentx = -arc_distancetocenter

currenty = -arc_distancetocenter

end

if (current_quadrant == "1") then

new_current_quadrant = "2"

currentx = arc_distancetocenter

currenty = -arc_distancetocenter

end

current_quadrant = new_current_quadrant

text "cw"

end

text ("Step Arc: ")

text (current_quadrant)

modalnumber ("# X", currentx * scale, "0.0000")

modalnumber ("# y", currenty * scale, "0.0000")

modalnumber ("# /X", (arccentrex - currentx) * scale, "0.0000")

modalnumber ("# /y", (arccentrey - currenty) * scale, "0.0000")

text ("\n")

end

--we have moved into the finish quadrant

text("**exit quadrant ")

modalnumber ("$ X", endx * scale, "0.000")

modalnumber ("$ y", endy * scale, "0.000")

modalnumber ("$ /X", (arccentrex - currentx) * scale, "0.000")

modalnumber ("$ /y", (arccentrey - currenty) * scale, "0.000")

text("\n")

end

eol()

end

Note - the values are still a messed up hybrid of relative and absolute...ignore that for now. Also I have some random characters infront of arcs...this is just to verify the results I'm getting are firing the right lines.

The problem I'm having with the output is this:

**same quadrant X2.3966 y-0.0675 /X-0.0675 /y0.0000

X0.0000 Y-0.0675

quad1: 4 quad2: 2

cwStep Arc: 1# X0.0675# y0.0675# /X-0.0675# /y-0.0675

cwStep Arc: 2# y-0.0675# /y0.0675

**exit quadrant $ X-0.067$ y0.000$ /X-0.068$ /y0.068

X-0.0675 Y1.8474

the bolded line is an example of the data simply not showing the results. No X value or /X although there does appear to be data there.

HuFlungDung

08-25-2007, 01:12 AM

The data you say is missing, is that not due to calling a 'modal number' function, whose express purpose is to eliminate a number that is the same as that on a previous line? That is what modal means, but I do not think that the Bandit is going to accept that as a legit arc movement, so all 4 values XY/X/Y must be expressed for every arc (I think you know that). So anyway, I suspect you do not want to use a modal function in this case to discover modal numbers.

Modal number discovery is fine for linear moves, but not circles, in Bandit. This is my WAG.

Modal number discovery is fine for linear moves, but not circles, in Bandit. This is my WAG.

Chris64

08-25-2007, 01:24 AM

I didn't know that's what modal meant...in vb it means you can't click on anything else for example ;)

OK, that makes sense. My question was really asking "what does modal do?" I thought it was just for formating numbers.

I orignally planned on converting it to use Relative values. Everything I've made uses these so that it's easier to put in subroutines. I haven't used absolute values at all so I'm a little torn on which I should use.

So it sounds like if I complete the process of displaying the absolute numbers, the other problem should go away.

Bed time - I'll work on this tomorrow.

But real quick - this language is a bit of a pain!

example

x=1

output of x= .9999999985

WTH?

x=math.floor(67) [should round down]

output 67.00000083968

Obviously this wasn't written for complex math...or maybe a new version that I suck at.

OK, that makes sense. My question was really asking "what does modal do?" I thought it was just for formating numbers.

I orignally planned on converting it to use Relative values. Everything I've made uses these so that it's easier to put in subroutines. I haven't used absolute values at all so I'm a little torn on which I should use.

So it sounds like if I complete the process of displaying the absolute numbers, the other problem should go away.

Bed time - I'll work on this tomorrow.

But real quick - this language is a bit of a pain!

example

x=1

output of x= .9999999985

WTH?

x=math.floor(67) [should round down]

output 67.00000083968

Obviously this wasn't written for complex math...or maybe a new version that I suck at.

HuFlungDung

08-25-2007, 01:39 AM

I do not know of any cad systems that will mix absolute and incremental programming. It is usually a case of 'make your choice' at the start of programming and stick with it through to the end. Of course, if you wish to cut and paste programs together, then you could do your subs in incremental, and write the main program in absolute. I feel your pain....shot by a Bandit :D

The odd multi-axis absolute mode command interjected in an otherwise incremental program can be a workable system to help you find your way around from one feature to another on the part. I doubt that you could do much in this regard other than plot a series of points at the beginning of each feature on your part, program a series of moves to each of those points in absolute in your main program, then, write sub programs using each of those points as a local start point (and switch back to incremental).

About the rounding off: I don't know what you can do, probably Locost Cam would know in a heartbeat. I do know it has to be correctly rounded off, and not just formatted as a 4 decimal place string, or you'll get the Bandit throwing up errors all the time.

The odd multi-axis absolute mode command interjected in an otherwise incremental program can be a workable system to help you find your way around from one feature to another on the part. I doubt that you could do much in this regard other than plot a series of points at the beginning of each feature on your part, program a series of moves to each of those points in absolute in your main program, then, write sub programs using each of those points as a local start point (and switch back to incremental).

About the rounding off: I don't know what you can do, probably Locost Cam would know in a heartbeat. I do know it has to be correctly rounded off, and not just formatted as a 4 decimal place string, or you'll get the Bandit throwing up errors all the time.

locost_cam

08-25-2007, 06:54 AM

There are three number functions:

number(value,format). This simply outputs the number,formatted as per the format string

modalnumber(key,value,format). This keeps a track of the last time that key was used. If number has changed since last time then key and number are output and the new number is stored. Otherwise nothing is output.

nonmodalnumber(key,value,format) Always outputs but keeps the key updated so you can safely use modalnumber at a later date.

Be careful with relative code. The number functions round the number as defined in format. This can result in accumulated rounding errors.

Internally, Lua uses double precision floating point for numbers. As far as I can tell, the number strangeness that you are seeing is a problem with the Lua number to string conversion routines rather than any lack of precision. I am currently using a fairly old version of Lua. I will look into upgrading to the latest release and see if it helps.

number(value,format). This simply outputs the number,formatted as per the format string

modalnumber(key,value,format). This keeps a track of the last time that key was used. If number has changed since last time then key and number are output and the new number is stored. Otherwise nothing is output.

nonmodalnumber(key,value,format) Always outputs but keeps the key updated so you can safely use modalnumber at a later date.

Be careful with relative code. The number functions round the number as defined in format. This can result in accumulated rounding errors.

Internally, Lua uses double precision floating point for numbers. As far as I can tell, the number strangeness that you are seeing is a problem with the Lua number to string conversion routines rather than any lack of precision. I am currently using a fairly old version of Lua. I will look into upgrading to the latest release and see if it helps.

Chris64

08-25-2007, 11:22 AM

Thanks for the new functions - that will handle it. I'm updating it right now. I totally agree with you on the relative movement problem (rounding values).

Hu - I mentioned earlier "values are still a messed up hybrid of relative and absolute...ignore that for now."

But - I do have a question for you that I have never been able to find an answer to. My machine does everything with 1/10 inch values. So feerate of 200.0 is 20 IPM and X50. is 5 inches. I've been OK with this but it also means that I need to limit this POST file to only having 3 decimal places (3rd decimal place being 1/10000 inch). I did find a precision type feature but all that did was move the decimal position on the screen so you could have larger numbers whole (probably for a different type of system that would need 100+ inches of travel).

Hu - I mentioned earlier "values are still a messed up hybrid of relative and absolute...ignore that for now."

But - I do have a question for you that I have never been able to find an answer to. My machine does everything with 1/10 inch values. So feerate of 200.0 is 20 IPM and X50. is 5 inches. I've been OK with this but it also means that I need to limit this POST file to only having 3 decimal places (3rd decimal place being 1/10000 inch). I did find a precision type feature but all that did was move the decimal position on the screen so you could have larger numbers whole (probably for a different type of system that would need 100+ inches of travel).

HuFlungDung

08-25-2007, 11:41 AM

Chris,

I believe there is a DIP switch somewhere in the Bandit that controls the resolution. It seems to me the option was for .001 or .0001 resolution. It sounds like it is set incorrectly for your motor resolver resolution.

If you can contact Len Albright at Albright's CNC in Bozeman, MT, or perhaps Wendland Browning Services in Gallatin Gateway, MT, he might have a sheet of settings for that switch, and which card it is on. Don't play with those switches willy-nilly though, because they control a bunch of different things.

I believe there is a DIP switch somewhere in the Bandit that controls the resolution. It seems to me the option was for .001 or .0001 resolution. It sounds like it is set incorrectly for your motor resolver resolution.

If you can contact Len Albright at Albright's CNC in Bozeman, MT, or perhaps Wendland Browning Services in Gallatin Gateway, MT, he might have a sheet of settings for that switch, and which card it is on. Don't play with those switches willy-nilly though, because they control a bunch of different things.

Chris64

08-25-2007, 12:35 PM

One thing I can't find documentation on maybe you could help.

In an arc in absolute mode - should the arc centers be relative or absolute? For some reason I remember reading that even in absolute mode they need to be relative.

example

your at 2,0

90 degree arc to 3,1 with an arc center of 1,0 (or 3,0 absolute).

In an arc in absolute mode - should the arc centers be relative or absolute? For some reason I remember reading that even in absolute mode they need to be relative.

example

your at 2,0

90 degree arc to 3,1 with an arc center of 1,0 (or 3,0 absolute).

HuFlungDung

08-25-2007, 03:19 PM

In absolute mode, the arc centers are absolute. This is probably not typical of the way that most other cncs are programmed. I suppose in one sense, this simplfies your logic to break arcs at the quadrants, as there is no need to calculate new incremental arc centers at each end point.

Chris64

08-26-2007, 01:08 AM

OK...Got it! (I think). It was really making some nice looking shapes with several quadrants and all. I so excited with the prospect of being able to design a part in Corel instead of notepad!

There's still a few little kinks not related to the arc command.

I am still having a few problems with the post logic though. Here's why;

1) I can't output a ASCII character 19 (should be \019 in LUA). It doesn't spit it out. I need this character last for the Bandit to terminate import.

2) Feedrate, while it requires a decimal, will not allow a character after the decimal. It will error on import.

That's about it. So I guess I need to buy the full version now. Most of my tests exceeded the maximum amount of lines on the trial version.

Here's the function. I could post the whole thing if someone wants it...I just figure for now we could still try to work out the remaining kinks.

function arc()

--Here is where we need to break an arc into quadrants

--I'm not allowing Z arcs since my machine can't do it

--Quadrants 1(X+Y+),2(X+Y-),3(X-Y-),4(X-Y+)

arc_currentx = round3(currentx - arccentrex,3)

arc_currenty = round3(currenty - arccentrey,3)

arc_endx = round3(endx - arccentrex,3)

arc_endy = round3(endy - arccentrey,3)

arc_distancetocenter = math.sqrt((arc_currentx * arc_currentx) + (arc_currenty * arc_currenty))

current_quadrant = ""

finish_quadrant = ""

if (arc_currentx >= 0 and arc_currenty > 0 and arcangle > 0) then current_quadrant = "1";end

if (arc_currentx > 0 and arc_currenty >= 0 and arcangle < 0) then current_quadrant = "1";end

if (arc_currentx > 0 and arc_currenty <= 0 and arcangle > 0) then current_quadrant = "2";end

if (arc_currentx >= 0 and arc_currenty < 0 and arcangle < 0) then current_quadrant = "2";end

if (arc_currentx <= 0 and arc_currenty < 0 and arcangle > 0) then current_quadrant = "3";end

if (arc_currentx < 0 and arc_currenty <= 0 and arcangle < 0) then current_quadrant = "3";end

if (arc_currentx < 0 and arc_currenty >= 0 and arcangle > 0) then current_quadrant = "4";end

if (arc_currentx <= 0 and arc_currenty > 0 and arcangle < 0) then current_quadrant = "4";end

if (arc_endx >= 0 and arc_endy > 0 and arcangle<0) then finish_quadrant = "1";end

if (arc_endx > 0 and arc_endy >= 0 and arcangle>0) then finish_quadrant = "1";end

if (arc_endx > 0 and arc_endy <= 0 and arcangle<0) then finish_quadrant = "2";end

if (arc_endx >= 0 and arc_endy < 0 and arcangle>0) then finish_quadrant = "2";end

if (arc_endx <= 0 and arc_endy < 0 and arcangle<0) then finish_quadrant = "3";end

if (arc_endx < 0 and arc_endy <= 0 and arcangle>0) then finish_quadrant = "3";end

if (arc_endx < 0 and arc_endy >= 0 and arcangle<0) then finish_quadrant = "4";end

if (arc_endx <= 0 and arc_endy > 0 and arcangle>0) then finish_quadrant = "4";end

if (current_quadrant == finish_quadrant) then

--if the move starts and ends in the same quadrant

text("X"); number ( endx * scale, "0.000")

text("Y"); number (endy * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text("\n")

else

while (current_quadrant ~= finish_quadrant) do

--finish point is not in the current quadrant

if(arcangle <0) then

if (current_quadrant == "1") then

new_current_quadrant = "4"

currentxval = 0

currentyval = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "1"

currentxval = arc_distancetocenter

currentyval = 0

end

if (current_quadrant == "3") then

new_current_quadrant = "2"

currentxval = 0

currentyval = -arc_distancetocenter

end

if (current_quadrant == "4") then

new_current_quadrant = "3"

currentxval = -arc_distancetocenter

currentyval = 0

end

current_quadrant = new_current_quadrant

else

if (current_quadrant == "4") then

new_current_quadrant = "1"

currentxval = 0

currentyval = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "4"

currentxval = -arc_distancetocenter

currentyval = 0

end

if (current_quadrant == "2") then

new_current_quadrant = "3"

currentxval = 0

currentyval = -arc_distancetocenter

end

if (current_quadrant == "1") then

new_current_quadrant = "2"

currentxval = arc_distancetocenter

currentyval = 0

end

current_quadrant = new_current_quadrant

end

currentx = currentxval

currenty = currentyval

text("X"); number ((arccentrex+currentx) * scale, "0.000")

text("Y"); number ((arccentrey+currenty) * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text ("\n")

end

--we have moved into the finish quadrant

text("X"); number (endx * scale, "0.000")

text("Y"); number (endy * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text("\n")

end

eol()

end

There's still a few little kinks not related to the arc command.

I am still having a few problems with the post logic though. Here's why;

1) I can't output a ASCII character 19 (should be \019 in LUA). It doesn't spit it out. I need this character last for the Bandit to terminate import.

2) Feedrate, while it requires a decimal, will not allow a character after the decimal. It will error on import.

That's about it. So I guess I need to buy the full version now. Most of my tests exceeded the maximum amount of lines on the trial version.

Here's the function. I could post the whole thing if someone wants it...I just figure for now we could still try to work out the remaining kinks.

function arc()

--Here is where we need to break an arc into quadrants

--I'm not allowing Z arcs since my machine can't do it

--Quadrants 1(X+Y+),2(X+Y-),3(X-Y-),4(X-Y+)

arc_currentx = round3(currentx - arccentrex,3)

arc_currenty = round3(currenty - arccentrey,3)

arc_endx = round3(endx - arccentrex,3)

arc_endy = round3(endy - arccentrey,3)

arc_distancetocenter = math.sqrt((arc_currentx * arc_currentx) + (arc_currenty * arc_currenty))

current_quadrant = ""

finish_quadrant = ""

if (arc_currentx >= 0 and arc_currenty > 0 and arcangle > 0) then current_quadrant = "1";end

if (arc_currentx > 0 and arc_currenty >= 0 and arcangle < 0) then current_quadrant = "1";end

if (arc_currentx > 0 and arc_currenty <= 0 and arcangle > 0) then current_quadrant = "2";end

if (arc_currentx >= 0 and arc_currenty < 0 and arcangle < 0) then current_quadrant = "2";end

if (arc_currentx <= 0 and arc_currenty < 0 and arcangle > 0) then current_quadrant = "3";end

if (arc_currentx < 0 and arc_currenty <= 0 and arcangle < 0) then current_quadrant = "3";end

if (arc_currentx < 0 and arc_currenty >= 0 and arcangle > 0) then current_quadrant = "4";end

if (arc_currentx <= 0 and arc_currenty > 0 and arcangle < 0) then current_quadrant = "4";end

if (arc_endx >= 0 and arc_endy > 0 and arcangle<0) then finish_quadrant = "1";end

if (arc_endx > 0 and arc_endy >= 0 and arcangle>0) then finish_quadrant = "1";end

if (arc_endx > 0 and arc_endy <= 0 and arcangle<0) then finish_quadrant = "2";end

if (arc_endx >= 0 and arc_endy < 0 and arcangle>0) then finish_quadrant = "2";end

if (arc_endx <= 0 and arc_endy < 0 and arcangle<0) then finish_quadrant = "3";end

if (arc_endx < 0 and arc_endy <= 0 and arcangle>0) then finish_quadrant = "3";end

if (arc_endx < 0 and arc_endy >= 0 and arcangle<0) then finish_quadrant = "4";end

if (arc_endx <= 0 and arc_endy > 0 and arcangle>0) then finish_quadrant = "4";end

if (current_quadrant == finish_quadrant) then

--if the move starts and ends in the same quadrant

text("X"); number ( endx * scale, "0.000")

text("Y"); number (endy * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text("\n")

else

while (current_quadrant ~= finish_quadrant) do

--finish point is not in the current quadrant

if(arcangle <0) then

if (current_quadrant == "1") then

new_current_quadrant = "4"

currentxval = 0

currentyval = arc_distancetocenter

end

if (current_quadrant == "2") then

new_current_quadrant = "1"

currentxval = arc_distancetocenter

currentyval = 0

end

if (current_quadrant == "3") then

new_current_quadrant = "2"

currentxval = 0

currentyval = -arc_distancetocenter

end

if (current_quadrant == "4") then

new_current_quadrant = "3"

currentxval = -arc_distancetocenter

currentyval = 0

end

current_quadrant = new_current_quadrant

else

if (current_quadrant == "4") then

new_current_quadrant = "1"

currentxval = 0

currentyval = arc_distancetocenter

end

if (current_quadrant == "3") then

new_current_quadrant = "4"

currentxval = -arc_distancetocenter

currentyval = 0

end

if (current_quadrant == "2") then

new_current_quadrant = "3"

currentxval = 0

currentyval = -arc_distancetocenter

end

if (current_quadrant == "1") then

new_current_quadrant = "2"

currentxval = arc_distancetocenter

currentyval = 0

end

current_quadrant = new_current_quadrant

end

currentx = currentxval

currenty = currentyval

text("X"); number ((arccentrex+currentx) * scale, "0.000")

text("Y"); number ((arccentrey+currenty) * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text ("\n")

end

--we have moved into the finish quadrant

text("X"); number (endx * scale, "0.000")

text("Y"); number (endy * scale, "0.000")

text("/X"); number ((arccentrex) * scale, "0.000")

text("/Y"); number ((arccentrey) * scale, "0.000")

text("\n")

end

eol()

end

Chris64

08-26-2007, 01:19 AM

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.

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

08-26-2007, 10:43 AM

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.

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

08-26-2007, 10:47 AM

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

08-26-2007, 12:27 PM

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.

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

08-26-2007, 01:13 PM

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.

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

08-26-2007, 01:53 PM

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.

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

08-26-2007, 05:58 PM

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.

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

08-26-2007, 07:41 PM

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.

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

08-26-2007, 08:03 PM

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.

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

08-26-2007, 08:31 PM

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

08-27-2007, 05:23 AM

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.

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

10-07-2007, 08:36 PM

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!)

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!)

Powered by vBulletin® Version 4.2.2 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.