Output to a Bandit?

[Chris64]

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]

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

[HuFlungDung]

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

[billystein]

"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.

[HuFlungDung]

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

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]

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

[Chris64]

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.

[HuFlungDung]

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

[Chris64]

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.

[locost_cam]

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...

[Chris64]

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.

[HuFlungDung]

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.